-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Heartbeat] Handle data streams #24223
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
Pinging @elastic/uptime (Team:Uptime) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks really good. Didn't see any issues and looks well tested.
Only thing is the imports seem a little bit jumbled. It would just make the code cleaner to fix the groupings.
// UnnestStream detects configs that come from fleet and transforms the config into something compatible | ||
// with heartbeat, by mixing some fields (id, data_stream) with those from the first stream. It assumes | ||
// that there is exactly one stream associated with the input. | ||
func UnnestStream(config *common.Config) (res *common.Config, err error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we can rather have agent (or the spec file) to produce a complete/correct configuration (for all Beats). The merging code here makes it look like the responsibility of understanding streams from Fleet configurations is shared between agent+heartbeat.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if I know the answer to that since I'm unfamiliar with how the parsing for the other beats works. For heartbeat we decided to keep the agent logic minimal and put more in heartbeat. That decision has worked out well since debugging issues in heartbeat is much simpler without fleet involved. I know that effectively heartbeat.monitors
is equivalent to inputs
in agent, so I can copy / paste fleet configs straight in for manual testing to confirm.
Would be nice if you can add the change to Filebeat/Packetbeat/Metricbeat right away in order to reduce fragmentation. |
Handles data streams from fleet, the current heartbeat code doesn't handle data_streams at all, this fixes that. Additionally, it hoists the id from the top level of the yaml config, and merges both levels of data_streams, since one is at the input level, and the other is at the stream level. Additionally, this cleans up the data streams code significantly, introducing a new add_data_streams_index processor that: More efficiently formats index names for data streams Allows individual events to override the dataset (useful for synthetics where we have a base browser dataset, but also browser_screenshot and browser_network for extended data that can take up lots of space, and often requires a different ILM policy).
Handles data streams from fleet, the current heartbeat code doesn't handle data_streams at all, this fixes that. Additionally, it hoists the id from the top level of the yaml config, and merges both levels of data_streams, since one is at the input level, and the other is at the stream level. Additionally, this cleans up the data streams code significantly, introducing a new add_data_streams_index processor that: More efficiently formats index names for data streams Allows individual events to override the dataset (useful for synthetics where we have a base browser dataset, but also browser_screenshot and browser_network for extended data that can take up lots of space, and often requires a different ILM policy).
Handles data streams from fleet, the current heartbeat code doesn't handle data_streams at all, this fixes that. Additionally, it hoists the id from the top level of the yaml config, and merges both levels of data_streams, since one is at the input level, and the other is at the stream level. Additionally, this cleans up the data streams code significantly, introducing a new add_data_streams_index processor that: More efficiently formats index names for data streams Allows individual events to override the dataset (useful for synthetics where we have a base browser dataset, but also browser_screenshot and browser_network for extended data that can take up lots of space, and often requires a different ILM policy).
Handles data streams from fleet, the current heartbeat code doesn't handle data_streams at all, this fixes that. Additionally, it hoists the id from the top level of the yaml config, and merges both levels of data_streams, since one is at the input level, and the other is at the stream level. Additionally, this cleans up the data streams code significantly, introducing a new add_data_streams_index processor that: More efficiently formats index names for data streams Allows individual events to override the dataset (useful for synthetics where we have a base browser dataset, but also browser_screenshot and browser_network for extended data that can take up lots of space, and often requires a different ILM policy).
Handles data streams from fleet, the current heartbeat code doesn't handle
data_streams
at all, this fixes that. Additionally, it hoists theid
from the top level of the yaml config, and merges both levels ofdata_streams
, since one is at the input level, and the other is at the stream level.Additionally, this cleans up the data streams code significantly, introducing a new
add_data_streams_index
processor that:browser
dataset, but alsobrowser_screenshot
andbrowser_network
for extended data that can take up lots of space, and often requires a different ILM policy).Checklist
- [ ] I have made corresponding changes to the documentation- [ ] I have made corresponding change to the default configuration filesCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.How to test this PR locally
Use the following
heartbeat.yml
and verify the output sets the correct monitor ID and writes to the correct data streams