[Feature Request] Expose iops & throughput capacity metrics for ebs volume

[just1900]

Is your feature request related to a problem?/Why is this needed

Since the csi-driver already exposes ReadOps and WriteOps, I want to know if it's possible to also expose the IOPS and throughput capacity for EBS volumes as metrics. This would allow us to set up alerts for when these levels reach a certain point, enabling us to expand volumes and plan capacity in advance.

/feature

Describe the solution you'd like in detail
Expose the iops & throughput capacity for ebs volume as metrics.

[torredil]

Hi @just1900, in addition to ReadOps and WriteOps, the driver exposes IOPS and throughput exceeded data points via NVMe metrics, which you can alarm on.

Please let us know if that is sufficient for your use case, or if you are more looking for a signal to tune volume performance before data points on those exceeded metrics are observed.

/kind feature

[just1900]

you are more looking for a signal to tune volume performance before data points on those exceeded metrics are observed.

@torredil Thanks for reply, It's exactly what I want. I do notice those exceeded metrics, but I want to alarm in advance

[torredil]

Got it, thank you for clarifying.

/priority backlog
/retitle [Feature Request] Expose iops & throughput capacity metrics for ebs volume

[ksliu58]

@just1900 I did some digging on this request. My understanding is that your team is already collecting IOPS/throughput exceeded data via the CSI driver and is now meeting your needs. Are there additional gaps in existing monitoring tools you are looking for?

[just1900]

@just1900 I did some digging on this request. My understanding is that your team is already collecting IOPS/throughput exceeded data via the CSI driver and is now meeting your needs. Are there additional gaps in existing monitoring tools you are looking for?

@ksliu58 Hi, as mentioned before, I'm looking for the capacity metrics to help alarm in advance rather than after IOPS/throughput exceeded.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale