Skip to main content

Analyze latency trends for EDA in Workload Factory

Contributors netapp-sineadd
PDFs

After a latency breach is detected, use the charts to see how volume latency, IOPS, and throughput change over time. This helps you spot patterns and validate whether remediation improved performance.

Before you begin

You need to have configured latency monitoring and at least one detected breach. To view the charts, ensure AWS credentials are available. To view QoS latency component breakdown, ensure the file system is linked.

The Detailed latency analysis page provides performance graphs to help you analyze volume behavior over time: latency, IOPS, and throughput.

About this task

The graphs show CloudWatch metrics for the affected volume. All graphs use the same timeline. They automatically display metrics based on which alarm triggered the event.

You can change the time range to see performance over different periods. You can also switch between All, Read, Write, or Metadata operations.

The visualization includes:

  • Latency graph: Shows volume latency (ms) over time with warning and critical threshold lines and breach markers.

  • IOPS graph: Shows IOPS over time, with thresholds and breach markers (if configured).

  • Throughput graph: Shows throughput over time for the selected time frame. If Metadata is selected in the filter, the throughput graph shows no data.

  • Threshold lines: Dotted horizontal lines show warning and critical thresholds.

  • Breach markers: Visual markers indicate detected breaches. Hover over a marker to view severity, time detected, CloudWatch median latency (ms), and QoS latency component breakdown.

Steps

  1. In the Latency tab, select the event in the Severity column.

    The latency analysis panel opens.

  2. Review the latency chart and the breach summary for the selected Time frame and Type.

  3. Select View full analysis to open Detailed latency analysis.

  4. In Latency charts, use Time frame (for example, 72 Hours) and Type (Read/Write/Metadata) to adjust the charts.

  5. Review the charts for:

    • Latency (ms) with warning/critical threshold lines

    • IOPS with threshold lines (if configured)

    • Throughput over the same time range

  6. Use the spike markers and the breach summary (for example, “1 critical breach detected in this timeframe”) to correlate latency increases with IOPS and throughput changes.

  7. Change the time range to review other periods and look for patterns.

  8. Check the trend lines for latency, IOPS, and throughput. The IOPS and latency graphs include threshold lines for comparison.

  9. Hover over a breach marker to view breach details (severity, time detected, CW median latency, and QoS latency components).

  10. Use the graph insights to:

    • See whether latency issues happen once or occur repeatedly

    • Identify times of day when latency is higher

    • Determine whether latency spikes are short or long-lasting

    • Compare latency events with workload patterns or system changes

Result

You can see how latency for the volume changes over time. This helps you decide whether to take action now, change alert limits, or check for system issues.

Note The charts use CloudWatch metrics. These might differ slightly from QoS-reported latency components because they are collected in different ways.

Graph interpretation

Use these tips when reviewing changes in response time:

  • Use multiple time frames: Look at the graphs in different time ranges to tell the difference between brief spikes and ongoing slowdowns. Start with the 24-hour view for overall context. Then zoom in to shorter periods to examine specific incidents, or switch to the 72-hour view to spot daily patterns.

  • Compare thresholds visually: Use the threshold lines on the graph to check if your warning and critical settings fit your workload. If latency often gets close to the threshold but does not cross it, the threshold might be too high. If you see many short spikes that cross the threshold but do not affect operations, the threshold might be too sensitive.

  • Identify daily patterns: Use the 24-hour and 72-hour views to spot patterns during the day. If latency spikes happen at the same times, schedule heavy tasks during quieter periods or add more capacity for busy times.

  • Distinguish spike types: Short spikes usually mean temporary issues, such as brief resource contention. Latency that stays high over time points to deeper system problems, like limited capacity or configuration issues. Each situation needs a different fix.

  • Monitor trends after changes: After adjusting thresholds, adding capacity, or changing settings, monitor the graph for at least 72 hours to make sure the changes worked.