How to Monitor AWS with OpenTelemetry

Monitoring AWS with OpenTelemetry means using the AWS Distro for OpenTelemetry (ADOT) and Collector receivers to collect CloudWatch metrics, traces and logs over OTLP, so AWS services sit in one open pipeline..

Monitoring AWS with OpenTelemetry means using the AWS Distro for OpenTelemetry (ADOT) and Collector receivers to collect CloudWatch metrics, traces and logs over OTLP, so AWS services sit in one open pipeline.

What to observe across an AWS estate

An AWS estate is many services, so the goal is one correlated view rather than a console tab per service: application error rate and latency, the saturation and throttling of the managed services underneath (RDS, DynamoDB, ELB, Lambda), and cost. The recurring pattern behind AWS incidents is an application symptom, elevated 5xx or latency, whose real cause is a throttled or saturated managed service one layer down.

The practical split is: use application traces (over OTLP) for request latency and error attribution, and pull CloudWatch metrics for the managed services you do not run yourself, then correlate the two so an ALB 5xx spike lines up with the unhealthy target or the throttled database behind it.

How OpenTelemetry collects it

The clean way to collect AWS telemetry with OpenTelemetry is the AWS Distro for OpenTelemetry (ADOT), an AWS-supported build of the Collector. Its awscloudwatch receiver pulls CloudWatch metrics for managed services, application traces arrive over OTLP and integrate with AWS X-Ray, and Container Insights covers ECS and EKS. Everything exports over OTLP to your backend, so AWS data sits beside the rest of your telemetry.

Two operational notes: pulling from CloudWatch has both a cost and a delay (metrics are minute-granularity and the API is billed), so pull the managed-service metrics you need rather than everything, and lean on OTLP application traces for low-latency request data. Give the Collector an IAM role scoped to the CloudWatch and X-Ray reads it needs, no more.

CloudWatch metric names below are AWS's own, grouped by service namespace; the receiver surfaces them as OpenTelemetry metrics.

Key metrics to watch

Key CloudWatch signals by service, the ones behind most AWS incidents:

What to put on a dashboard

An AWS dashboard should be organised so an application symptom leads straight to the managed-service cause. Row one is the application: error rate and p95 latency by service, from your OTLP traces. Row two is the data and edge tier: RDS connections and CPU, ALB 5xx and unhealthy-host count, DynamoDB throttling. Row three is serverless and cost: Lambda throttles and duration-against-timeout, and daily spend by service so a runaway cost is visible the same day.

# ALB 5xx correlated with unhealthy targets AWS/ApplicationELB.HTTPCode_Target_5XX_Count by (load_balancer) AWS/ApplicationELB.UnHealthyHostCount by (target_group) # RDS connection saturation AWS/RDS.DatabaseConnections / rds_max_connections # Lambda functions approaching their timeout AWS/Lambda.Duration / lambda_timeout_ms by (function_name)

Reading the signals: common failure modes

RDS connection exhaustion

The application starts erroring under load, and AWS/RDS DatabaseConnections is pinned near the instance limit. Requests queue or fail to get a connection. The fix is a connection pooler (RDS Proxy) and finding the service that opens connections without releasing them, not simply a bigger instance.

Unhealthy targets behind an ALB

HTTPCode_Target_5XX_Count spikes and UnHealthyHostCount rises together: the load balancer is returning 5xx because targets are failing health checks. Trace into the targets, the cause is usually the application on those instances crashing, out of memory, or dependent on something that is itself down.

Lambda throttling and timeouts

Invocations throttle (concurrency limit reached) or their Duration creeps toward the configured timeout and they start failing. Watch throttles and duration-against-timeout; raise reserved concurrency for the former and profile the slow path or downstream call for the latter.

DynamoDB throttling

ThrottledRequests rises because reads or writes exceed provisioned (or burst) capacity, surfacing as application errors and retries. Switch to on-demand capacity or raise provisioned throughput, and check for a hot partition key concentrating traffic.

Example alert conditions

Starting thresholds to tune:

From monitoring to autonomous resolution

Opstral's Telemetry Ops ingests AWS telemetry over OpenTelemetry and its Fin Ops pillar tracks AWS cost, while Sentinel AI resolves incidents across the estate through governed Action Tickets. Explore Telemetry Ops and Fin Ops.