Repository navigation
Conversation
A JVM agent can set system properties after startup but not environment variables. serverless-compat-java will set dd.dogstatsd.pipe.name to a per-function pipe on Azure Functions shared plans, so a client built with default settings now uses it. Precedence: explicit builder settings, then the system property, then the existing DD_DOGSTATSD_URL, DD_DOGSTATSD_PIPE_NAME and DD_AGENT_HOST environment variables. If the system-property pipe can't be opened at build time, the client falls back to UDP (DD_AGENT_HOST and DD_DOGSTATSD_PORT, else localhost:8125) instead of throwing. The serverless compat binary also listens on UDP, so this covers a cold start where the client starts before the binary creates its pipe. Explicit and environment-variable pipes still throw as before. SVLS-8246
The fallback from dd.dogstatsd.pipe.name to UDP was silent. The client now passes one StatsDClientException to the error handler when it falls back. It happens once, while the client is built, so it can't repeat per message. SVLS-8246
|
Why the JVM agent can't pass the correct value to the client directly during construction? |
|
@vickenty Apologies for the unclear initial description/PR! I've revised it to explain the various serverless cases where we need to get the value after construction; didn't expect you to be taking a look at the draft, but appreciate the quick review regardless. Basically, Azure does not do isolation the way you would expect in certain serverless environments, and serverless does not do instrumentation the way you would expect with the main datadog agent, so we want to handle some edge cases where the pipe name is generated after construction. |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
2 participants
This PR is part of a project to support named pipes on windows for Azure Serverless environments.
See Also:
propertyNameToSystemPropertyName+DOGSTATSD_NAMED_PIPE = "dogstatsd.pipe.name1, 2).Implementation
Precedence:
addressLookup/address,namedPipe,hostname/port).dd.dogstatsd.pipe.namesystem property.DD_DOGSTATSD_URL,DD_DOGSTATSD_PIPE_NAMEandDD_AGENT_HOST/DD_DOGSTATSD_PORTenvironment variables.If the system-property pipe can't be opened when the client is built, the client falls back to UDP (
DD_AGENT_HOST, elselocalhost, andDD_DOGSTATSD_PORT, else customer's set value or the 8125 default). The serverless compat binary listens on UDP and the pipe together (serverless-components#181), so this covers a cold start where the client starts before the binary creates its pipe. The client reports the fallback to the error handler once, during the build, so it can't repeat per message. Explicit and environment-variable pipes can still compete and will throw errors as expected.Tests
BuilderAddressTest.system_property_named_pipe_resolutionchecks that the property takes priority over every existing environment case, and explicit settings take priority over the property.NonBlockingStatsDClientBuilderTest.system_property_named_pipe_falls_back_to_udpchecks that an unopenable property pipe still builds, sends over UDP, and reports to the error handler exactly once.NonBlockingStatsDClientBuilderTest.environment_named_pipe_does_not_fall_backchecks that an unopenableDD_DOGSTATSD_PIPE_NAMEstill throws.We tested this end to end on Azure Functions Elastic Premium (EP1) and Dedicated (B2) plans. Each plan ran three Java apps sharing an instance with .NET and Node apps, and each Java app used a dev build of this branch with a default-settings client. Every app's distribution metrics arrived in Datadog, one per request. A
jcmd GC.class_histogramin each JVM showed onlyNamedPipeClientChannelinstances and no UDP channel, so the property pipe was used rather than the fallback.