-
Notifications
You must be signed in to change notification settings - Fork 8.1k
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
[Stack monitoring] logstash - read from correct aggregation #122443
Conversation
@elasticmachine merge upstream |
@elasticmachine merge upstream |
expected head sha didn’t match current head ref. |
Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI) |
Did that go in another PR? Curious why I'm not seeing a diff to |
There's a diff for |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
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 had a few thoughts/questions but overall this looks like an improvement to me so merge when ready!
@@ -76,6 +76,17 @@ export function _enrichStateWithStatsAggregation( | |||
statsAggregation: any, | |||
timeseriesIntervalInSeconds: number | |||
) { | |||
// we could have data in both legacy and metricbeat collection, we pick the bucket most filled |
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.
Wonder if we should consider plotting both? I'd guess this will mean a break in the graph when moving from internal collection to metricbeat.
Since the pipeline stack monitoring is beta though, maybe that's okay.
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.
That could be an option. We could also merge the aggregations and ensure we only consider a single datasource per node, since a pipeline can run on multiple nodes if we receive both legacy and metricbeat monitoring for a pipeline-node tuple there is duplication that we should ignore
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.
That's a really good point. I opened #123191 to capture the improvement for later.
const SUBJ_PIPELINE_SECTION_PREFIX = 'pipelineViewerSection_'; | ||
const PIPELINE_SECTION_ITEM_CLS = 'monPipelineViewer__listItem'; | ||
|
||
return new (class LogstashPipelineViewer { |
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.
The return new class pattern is really interesting. Not sure why we do it that way, but indeed this fits with the rest of the monitoring test services.
} | ||
} | ||
|
||
throw new Error(`pipeline with id ${id} not found`); |
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.
Just nit picking but, seems like this is the pipeline "name" rather than "id". Pretty sure pipelines get a unique id number as well as a string name.
💚 Build Succeeded
Metrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: cc @klacabane |
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
…122443) * add test-subj to pipeline viewer section * pipeline viewer service * clickPipeline * pipeline viewer_mb test * lint * lint * update component snapshot * fix get_pipeline bucket selection * align metricbeat pipeline data with internal monitoring * collect filters * fix pipeline viewer test * clean logstash_pipelines_mb archive Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 6c6a2ed)
…#123149) * add test-subj to pipeline viewer section * pipeline viewer service * clickPipeline * pipeline viewer_mb test * lint * lint * update component snapshot * fix get_pipeline bucket selection * align metricbeat pipeline data with internal monitoring * collect filters * fix pipeline viewer test * clean logstash_pipelines_mb archive Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 6c6a2ed) Co-authored-by: Kevin Lacabane <klacabane@gmail.com>
…122443) * add test-subj to pipeline viewer section * pipeline viewer service * clickPipeline * pipeline viewer_mb test * lint * lint * update component snapshot * fix get_pipeline bucket selection * align metricbeat pipeline data with internal monitoring * collect filters * fix pipeline viewer test * clean logstash_pipelines_mb archive Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
In logstash paths that need to query the
pipelines
nested property we have to set two aggregations, one for each of legacy and metricbeat properties (see context).This change fixes a bug where we would exclusively read the legacy aggregation and ignore the metricbeat one, failing to compute the processing time of the vertices when the latter contains the data.
Testing
logstash_state
document to the metricbeat archive (see document details)