-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
Summary
The FaaS detection logic added in DRIVERS-2209 can mistakenly identify EKS as AWS Lambda.
For example in HELP-54555, this connection handshake metadata was sent even though the app was not using Lambda or using 256MB memory:
"env": {"name": "aws.lambda", "region": "us-east-1", "memory_mb": 256}
Instead the app was hosted in EKS with 2 GB memory. CPU memory config from k8s container is as follows:
resources: requests: memory: 2Gi cpu: 1000m limits: memory: 5Gi cpu: 5000m
Motivation
How does this affect the end user?
This behavior is confusing for users, support engineers, and results in potentially unwanted changes in MongoClient behavior (eg serverMonitoringMode).
How likely is it that this problem or use case will occur?
Unknown. Need to investigate EKS to reproduce.
Acceptance Criteria
Investigate EKS to reproduce and fix false positives. Audit GCP, Azure, and other platform detection logic to see if those can be improved too.
- related to
-
DRIVERS-2570 Driver Container and Kubernetes Awareness
- In Progress
- split to
-
CDRIVER-5638 Record both FaaS and container metadata when both are present
- Backlog
-
CSHARP-5199 Record both FaaS and container metadata when both are present
- Backlog
-
CXX-3074 Record both FaaS and container metadata when both are present
- Backlog
-
GODRIVER-3283 Record both FaaS and container metadata when both are present
- Backlog
-
JAVA-5541 Record both FaaS and container metadata when both are present
- Backlog
-
NODE-6288 Record both FaaS and container metadata when both are present
- Backlog
-
RUBY-3518 Record both FaaS and container metadata when both are present
- Backlog
-
PHPLIB-1490 Record both FaaS and container metadata when both are present
- Blocked
-
MOTOR-1342 Record both FaaS and container metadata when both are present
- Closed
-
RUST-2000 Record both FaaS and container metadata when both are present
- Closed
-
PYTHON-4574 Record both FaaS and container metadata when both are present
- Closed