fix(telemetry): skip agent proxy URL when agent doesn't expose /telemetry/proxy/#4454
Conversation
…etry/proxy/ When the Datadog Lambda extension is running at localhost:8126, it serves traces but does not expose the /telemetry/proxy/ endpoint. Previously the tracer always set AgentURL in the telemetry client config, causing a WARN log on every flush: appsec: error while flushing SCA Security Data: Post "http://localhost:8126/telemetry/proxy/api/v2/apmtelemetry": dial tcp 127.0.0.1:8126: connect: connection refused This fix uses the /info endpoint response (already fetched at startup) to determine whether the agent actually exposes the telemetry proxy: - Add hasTelemetryProxy bool to agentFeatures, set when /telemetry/proxy/ appears in the endpoints list returned by /info. - Add reachable bool to agentFeatures, set only when /info returns a valid parseable response. This distinguishes "agent is reachable but has no proxy" (Lambda extension) from "agent is unreachable" (transient issue). - In startTelemetry, only set AgentURL when the agent is reachable with the proxy, or when the agent was unreachable at startup (preserving previous behaviour of still attempting to send telemetry). Fixes #3808. Supersedes #4421. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files
🚀 New features to boost your workflow:
|
BenchmarksBenchmark execution time: 2026-02-20 09:25:45 Comparing candidate commit e26fd6b in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 156 metrics, 8 unstable metrics.
|
What does this PR do?
When the Datadog Lambda extension is running at
localhost:8126, it serves traces but does not expose the/telemetry/proxy/endpoint. Previously the tracer always setAgentURLin the telemetry client config unconditionally, causing a WARN log on every flush:This PR fixes the root cause by using the
/infoendpoint response (already fetched at tracer startup) to determine whether the agent actually supports the telemetry proxy, rather than assuming it always does.Changes
hasTelemetryProxy booltoagentFeatures, set when/telemetry/proxy/appears in the endpoints list returned by/info(the agent only advertises this whenTelemetryConfig.Enabledis true).reachable booltoagentFeatures, set only when/inforeturns a valid parseable response. This distinguishes "agent is reachable but has no proxy" (Lambda extension case) from "agent is unreachable" (transient startup failure).startTelemetry, only setAgentURLwhen!reachable || hasTelemetryProxy:reachable=true,hasTelemetryProxy=false):AgentURLnot set →NewClientfails at debug level → no WARN logs ✓reachable=true,hasTelemetryProxy=true):AgentURLset → telemetry flows through proxy ✓reachable=false):AgentURLstill set → preserves previous behaviour, still attempts ✓Why this is better than #4421
PR #4421 uses
IsLambdaFunction()(checkingAWS_LAMBDA_FUNCTION_NAME) as a heuristic. The actual problem is not Lambda-specific: any environment where the agent doesn't expose the telemetry proxy would benefit from this fix. This approach derives the behaviour from what the agent actually advertises rather than from environment detection.Fixes
Fixes #3808. Supersedes #4421.
Reviewer's Checklist