[Infra UI] Normalise network and Disk rates for Hosts across time ranges

[roshan-elastic]

🔗 Key Links

• Hosts List

Issues

Note : This will be completed once the epic has been refined and issues created

Related

Preview Give feedback

1. [Infra UI] Network TX/RX show inaccurate spikes in activity #164159
   0 of 1
   Feature:Metrics UI Feature:ObsHosts Team:obs-ux-infra_services bug needs-refinement +5
   

Issues/Tasks

Preview Give feedback

1. Add issues here

📖 Description

Update Network RX/TX and Disk throughput/IOPS metrics to be normalised across different durations to allow SREs to compare them across different durations in Host List, fly-outs and detail view.

Background

When SREs look across different time periods, they need a consistent metrics to allow them to be able to compare the same metric across different durations.

The following metrics are not normalised in way which makes them comparable across different length durations (across both the Host List, fly-out and detail view):

Disk IOPS (read/write) (docs)

Fly-out

Disk Throughput (read/write) (docs)

Fly-out

Network (RX/TX) (docs)

Host Fly-out

Host List

💡 Solution

For normalising all of the metrics, apply the per second normalisation to all of the above in the lens charts:

I have confirmed this outcome would be desirable with @elkargig (George the SRE)

✔️ Acceptance criteria

1. Must Have

Must be delivered in this issue in order for the release to be valuable

Name	Description	Notes
Disk and Network metrics must be normalised across different durations	The user should be able to compare the metrics across any duration	-

2. Should Have

Name	Description	Notes
-	-	-

3. Could Have

Would be nice to have but not critical

Name	Description	Notes
-	-	-

4. Will Not Have (for now)

Explicitly will not be looked at within this issue

Name	Description	Notes
-	-	-

📈 Telemetry Process

• Telemetry requirements must be part of the acceptance criteria (above) (defined by the Epic creator, e.g. the Product Manager) during refinement.
• See Telemetry Process for full details/process/implementation conventions.

[elasticmachine]

Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI)

[roshan-elastic]

Hey @smith, I had some internal feedback on the overview that has made me realise 3 of the charts need updating (minor changes to the config) - otherwise they don't really provide value and undermine the fly-out value.

Do you think there's any scope to making this change and back-porting to 8.10?

If possible, I'd like to add one more chart to the overview as well (it's something which is going into the detail view anyway)?

• Infra UI : Add Disk Space Usage by Mount Point to Hosts Fly Out #164209

Note : On this latter one, we've found that the disk usage metric is disguising volumes which are running out of space. I created a separate issue to refine this but the above issue is to add the breakdown by mount point so users can easily see which volume is running out in the fly-out

[smith]

Do you think there's any scope to making this change and back-porting to 8.10?

Yes probably if we're fixing the normalization

If possible, I'd like to add one more chart to the overview as well (it's something which is going into the detail view anyway)?

This would probably be something we should not backport.

[roshan-elastic]

Do you think there's any scope to making this change and back-porting to 8.10?

Yes probably if we're fixing the normalization

Great - thanks @smith. Could I leave it with you to try and get it done before 8.10 goes out?

If possible, I'd like to add one more chart to the overview as well (it's something which is going into the detail view anyway)?

This would probably be something we should not backport.

Could you share your thinking here (if only I can understand what is a good/bad candidate for back-porting in the future)?

Would love to get this in here because it's a really important use case:

• Infra UI : Add Disk Space Usage by Mount Point to Hosts Fly Out #164209

If it can't/shouldn't be done though, I'll respect your judgement on this...

[smith]

@roshan-elastic:

Could you share your thinking here (if only I can understand what is a good/bad candidate for back-porting in the future)?

Following the Kibana guidelines:

• Features should not be backported to a <major>.<minor> branch.
• Bug fixes can be backported to a <major>.<minor> branch if the changes are safe and appropriate. Safety is a judgment call you make based on factors like the bug’s severity, test coverage, confidence in the changes, etc. Your reasoning should be included in the pull request description.

Adding one more chart is not a bug fix, it's a feature.

[roshan-elastic]

Cool - thanks @smith. This is really helpful.

I understand your thinking now so supportive of that. Will leave the new chart for 8.11...