Centralizing ECS Telemetry: The ADOT Gateway Approach
In a multi-account AWS environment, managing telemetry can become a daunting task. The ADOT gateway centralizes telemetry from Amazon ECS workloads, making it easier to monitor and analyze performance across accounts. By utilizing the AWS Distro for OpenTelemetry (ADOT) collector, you can streamline the process of gathering and exporting telemetry data, ensuring that your observability strategy is both efficient and effective.
Here's how it works: Instrumented applications in your workload accounts generate OTLP telemetry, which is sent to the gateway's Network Load Balancer (NLB) DNS name. This communication typically occurs over gRPC on port 4317 or HTTP on port 4318 for .NET applications. The traffic routes through the AWS Transit Gateway, connecting your workload VPCs to the observability VPC. The NLB forwards the telemetry to a healthy ADOT collector task, which batches and enriches the data before exporting traces to AWS X-Ray, metrics to Amazon CloudWatch, and logs to CloudWatch Logs. Key configuration parameters include the AWS region and stack name, with Terraform version 1.5.0 or later required for deployment.
In production, ensure you have an AWS Organizations setup with a dedicated observability account and workload accounts. A shared AWS Transit Gateway is crucial for cross-account connectivity. Be mindful of nonoverlapping CIDR ranges for your VPCs to avoid routing issues. Additionally, workloads must be instrumented with an OpenTelemetry SDK or expose a Prometheus endpoint for effective telemetry collection. The ADOT gateway is a powerful tool, but understanding its configuration and prerequisites is essential for success.
Key takeaways
- →Utilize the ADOT collector to streamline telemetry across AWS accounts.
- →Configure the Network Load Balancer for secure and private telemetry routing.
- →Ensure nonoverlapping CIDR ranges for observability and workload VPCs.
- →Deploy with Terraform version 1.5.0 or later for compatibility.
- →Instrument workloads with OpenTelemetry SDKs for effective data collection.
Why it matters
Centralizing telemetry across accounts enhances visibility and simplifies monitoring, leading to quicker troubleshooting and improved application performance.
Code examples
git clone https://github.com/aws-samples/sample-ecs-adot-centralised-gateway.git
cd sample-ecs-adot-centralised-gateway
cp terraform.tfvars.example terraform.tfvars
# edit terraform.tfvars with the values for your environmentWhen NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsIndustry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.
Get CKA certified →Vultr Joins CNCF as Platinum Member: What This Means for AI and Kubernetes
Vultr's new Platinum membership with CNCF marks a significant step towards enhancing open cloud infrastructure for AI. Their Vultr Kubernetes Engine (VKE) is now a CNCF Certified Kubernetes product, showcasing their commitment to interoperability and innovation.
Open Cluster Management: Simplifying Kubernetes at Scale
Open Cluster Management (OCM) is now a CNCF Incubating Project, and it’s a game changer for managing Kubernetes clusters across diverse environments. Its hub-and-spoke architecture allows for seamless cluster registration and workload placement without a proprietary control plane.
Cloud Native Developers: The AI-Ready Workforce of Tomorrow
The rise of cloud native developers is reshaping the tech landscape, with their numbers surpassing 21 million globally. These developers are not just familiar with cloud technologies; they are increasingly adept at leveraging AI coding tools to enhance their productivity.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.