tracer-cloud--opensre/tests/synthetic/rds_postgres/004-cpu-saturation-bad-query/answer.yml

root_cause_category: cpu_saturation_bad_query
equivalent_root_cause_categories:
  - cpu_saturation
required_keywords:
  - CPU
  - query
  - Performance Insights
required_evidence_sources:
  - aws_performance_insights
forbidden_categories:
  - connection_exhaustion
optimal_trajectory:
  - query_grafana_metrics
  - query_grafana_logs
  - query_grafana_alert_rules
  - describe_rds_instance
  - describe_rds_events
max_investigation_loops: 4
model_response: |
  ROOT_CAUSE: CPU saturation on catalog-prod caused by a full table scan query (SELECT * FROM orders WHERE status = ?) running at 7.2 out of 8 available vCPUs. The query lacks a selective index on the status column, forcing sequential scans at 16,000–18,000 ReadIOPS.
  ROOT_CAUSE_CATEGORY: cpu_saturation_bad_query

  VALIDATED_CLAIMS:
  - CPUUtilization sustained 88–97% over the full 20-minute window. [evidence: aws_cloudwatch_metrics]
  - ReadIOPS peaked at 18,100 consistent with repeated full table scans. [evidence: aws_cloudwatch_metrics]
  - DatabaseConnections remained stable at ~160, ruling out connection exhaustion as a factor. [evidence: aws_cloudwatch_metrics]
  - Performance Insights shows "SELECT * FROM orders WHERE status = $1" consuming 7.2 avg active sessions, with CPU:user as the dominant wait event (5.9 AAS). [evidence: aws_performance_insights]
  - No RDS infrastructure events occurred during the window. [evidence: aws_rds_events]

  NON_VALIDATED_CLAIMS:
  - Adding a partial index on (status) for non-completed orders would likely reduce CPU load by 80%+.

  CAUSAL_CHAIN:
  - The orders table has no index on the status column.
  - api_reader sessions execute repeated full-table scans at 3.8 calls/sec.
  - Each scan reads ~18,000 IOPS worth of data pages, saturating the CPU at 90%+.
  - Query response times degraded, causing application-level timeouts.