Update Logstash single pipeline dashboard with batch byte_size metrics for p50 p90 max

[andsel]

Proposed commit message

Update the cel script to store p50 p90 and max byte size metrics of the batch for the last minute.
Update the Single Pipeline View to include these new values.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

Author's Checklist

• [ ]

How to test this PR locally

Follow the test plan shaped in #17009

Related issues

• Closes Update the Elastic integration to present p50 p90 and max batch byte size metrics logstash#18972

Screenshots

[github-actions]

✅ Vale Linting Results

No issues found on modified lines!

---

The Vale linter checks documentation changes against the Elastic Docs style guide.

To use Vale locally or report issues, refer to Elastic style guide for Vale.

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[robbavey]

Couple of concerns about presentation:

I'm not sure about having multiple areas, and why p50 and p90 are represented by areas, but max is not. WDYT about only p50 being represented by area, or nothing?

average lifetime is difficult to read on this graph too

[andsel]

I imagined p50 an p90 as areas because those make immediately visible the where the current and max are respect to the range that should contains the majority of the measures.
I tried to add also max as an area, but the graph became too much cluttered, because max is an upper limit, I think it's fine to be a line.

If we keep all percentiles plus current and average as lines, the graph it's hard to understand, you have to consider 5 lines and understanding the relationship it's not easy.
The areas permit an immediate separation between percentiles and current, average values.
Let me know if you think that we are presenting too much information in a single graph. I think that the idea of the graph is to provide how current and average relates to percentiles in a glipse.

[robbavey]

@perk @jsvd Do you have any thoughts here?

[perk]

What if we've made the shaded area between p50 and p90, with current and average as lines in between them and max as a line above the shaded area?

But that isn't 100% bulletproof. It feels like we could split this into two separate charts: one for Current vs. Average, and another strictly for Percentiles (p50, p90, Max).

[andsel]

@perk so your suggestion is to keep as it is but only change the shaded areas, maintaining the shading only for the strip between p50 and p90. Am I right?

In that case I don't know hot to do it, I think we need to speak to someone in Kibana hot to that (who?).

It feels like we could split this into two separate charts: one for Current vs. Average, and another strictly for Percentiles (p50, p90, Max).

It could be, but at that point I think it became difficult to correlate current with the percentile measures (and max). Do you think that there is a benefit, in terms of better understanding, being able to correlate percetniles and current ?

[perk]

suggestion is to keep as it is but only change the shaded areas, maintaining the shading only for the strip between p50 and p90. Am I right?

Yes, I think that would be more clear than the current dashboard. But I'm not sure it's feasible either. Is it?

Do you think that there is a benefit, in terms of better understanding, being able to correlate percetniles and current?

Let me know if you think that we are presenting too much information in a single graph.

Fair question. I think that ability to correlate on a single dashboard is a good thing in general.

[andsel]

Playing with colo, stacking and custom formula I was able to draw colored stripe that reppresent the p50-p90, as in the following image:

@perk I've one doubt: how effective is to graph the "average lifetime" value for both event count and byte value. If there is an increase or decrease, the time that metrics take to reach a "stable value" is proportional to the time the LS process was running. For example, suppose it was running for some days with pretty steady flow, that originated a an average of 100KB, if there is an increase to 1MB , the average lifetime takes sometime to get close to the 1MB value. I would suggest to use the average last 1 minute, so that all data series reflect the same temporal window.

Let me know what you think.

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 2377e3d

History

• 💚 Build #41163 succeeded 240db5e

cc @andsel