Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EKS detector using method that relies on AWS CloudWatch exporter presence which is not really common #6309

Open
IgorEulalio opened this issue Nov 7, 2024 · 2 comments
Labels
area: detector Related to a detector package bug Something isn't working detector: aws:eks

Comments

@IgorEulalio
Copy link

Description

EKS detector relies on the presence of a configmap that is not deployed in EKS environment by default, it is only deployed when using the cloudwatch exporter which is really not used much:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-setup-metrics.html
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/detectors/aws/eks/detector.go#L162

With the current approach, only clusters with this installed will get the clusterName populated, a better approach would be to rely on EC2 Metadata + EKS Worker node labels.

There's a issue open on AWS containers roadmap asking for a more straightforward way to collect this information but this is the unique approach that current works consistently across EKS deployments:
aws/containers-roadmap#686

Environment

  • OS: an
  • Architecture: any
  • Go Version: any
  • eks version: any

Steps To Reproduce

  1. Deploy application with detector EKS in any fresh EKS cluster
  2. Detect will return empty clusterName

Expected behavior

For any EKS environment we should be able to perform the resource collection and inform back the cluster name.

@IgorEulalio IgorEulalio added area: detector Related to a detector package bug Something isn't working detector: aws:eks labels Nov 7, 2024
@dmathieu
Copy link
Member

dmathieu commented Nov 8, 2024

cc @pyohannes as code owner.

@IgorEulalio
Copy link
Author

@pyohannes @dmathieu I have a PR open implementing above mentioned behavior.

It relies on AWS EC2 metadata + IAM role associated to EKS worker node which by default need access to list labels:
IgorEulalio#1

Let me know if that's something that makes sense and I'll be glad to open a PR to sync the fork.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: detector Related to a detector package bug Something isn't working detector: aws:eks
Projects
None yet
Development

No branches or pull requests

2 participants