Add Multi-Azure Function Unique Named Pipe Configuration#8164
Open
Add Multi-Azure Function Unique Named Pipe Configuration#8164
Conversation
Lewis-E
force-pushed
the
lewis/SVLS-8244/add-multifunction-named-pipes
branch
from
37f021e to
1b6956c
Compare
BenchmarksBenchmark execution time: 2026-04-16 20:38:40 Comparing candidate commit 2547db2 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 27 metrics, 0 unstable metrics, 87 known flaky benchmarks.
|
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (8164) and master. ✅ No regressions detected - check the details below Full Metrics ComparisonFakeDbCommand
HttpMessageHandler
Comparison explanationExecution-time benchmarks measure the whole time it takes to execute a program, and are intended to measure the one-off costs. Cases where the execution time results for the PR are worse than latest master results are highlighted in **red**. The following thresholds were used for comparing the execution times:
Note that these results are based on a single point-in-time result for each branch. For full results, see the dashboard. Graphs show the p99 interval based on the mean and StdDev of the test run, as well as the mean value of the run (shown as a diamond below the graph). Duration chartsFakeDbCommand (.NET Framework 4.8)gantt
title Execution time (ms) FakeDbCommand (.NET Framework 4.8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8164) - mean (73ms) : 70, 77
master - mean (73ms) : 70, 76
section Bailout
This PR (8164) - mean (79ms) : 75, 84
master - mean (77ms) : 75, 79
section CallTarget+Inlining+NGEN
This PR (8164) - mean (1,081ms) : 1032, 1131
master - mean (1,077ms) : 1031, 1124
FakeDbCommand (.NET Core 3.1)gantt
title Execution time (ms) FakeDbCommand (.NET Core 3.1)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8164) - mean (117ms) : 111, 122
master - mean (115ms) : 110, 120
section Bailout
This PR (8164) - mean (117ms) : 111, 123
master - mean (115ms) : 112, 118
section CallTarget+Inlining+NGEN
This PR (8164) - mean (798ms) : 774, 822
master - mean (804ms) : 776, 831
FakeDbCommand (.NET 6)gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8164) - mean (100ms) : 97, 103
master - mean (100ms) : 97, 103
section Bailout
This PR (8164) - mean (104ms) : 98, 110
master - mean (104ms) : 99, 109
section CallTarget+Inlining+NGEN
This PR (8164) - mean (939ms) : 907, 971
master - mean (938ms) : 901, 975
FakeDbCommand (.NET 8)gantt
title Execution time (ms) FakeDbCommand (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8164) - mean (100ms) : 95, 106
master - mean (102ms) : 97, 108
section Bailout
This PR (8164) - mean (101ms) : 99, 103
master - mean (103ms) : 97, 108
section CallTarget+Inlining+NGEN
This PR (8164) - mean (827ms) : 786, 867
master - mean (827ms) : 792, 863
HttpMessageHandler (.NET Framework 4.8)gantt
title Execution time (ms) HttpMessageHandler (.NET Framework 4.8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8164) - mean (210ms) : 205, 214
master - mean (210ms) : 204, 216
section Bailout
This PR (8164) - mean (215ms) : 211, 219
master - mean (213ms) : 210, 216
section CallTarget+Inlining+NGEN
This PR (8164) - mean (1,228ms) : 1175, 1281
master - mean (1,229ms) : 1181, 1277
HttpMessageHandler (.NET Core 3.1)gantt
title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8164) - mean (304ms) : 295, 314
master - mean (304ms) : 296, 312
section Bailout
This PR (8164) - mean (304ms) : 299, 309
master - mean (304ms) : 297, 311
section CallTarget+Inlining+NGEN
This PR (8164) - mean (1,007ms) : 978, 1035
master - mean (1,006ms) : 979, 1033
HttpMessageHandler (.NET 6)gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8164) - mean (296ms) : 290, 302
master - mean (298ms) : 287, 308
section Bailout
This PR (8164) - mean (298ms) : 293, 303
master - mean (297ms) : 291, 304
section CallTarget+Inlining+NGEN
This PR (8164) - mean (1,182ms) : 1137, 1226
master - mean (1,183ms) : 1145, 1221
HttpMessageHandler (.NET 8)gantt
title Execution time (ms) HttpMessageHandler (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8164) - mean (294ms) : 286, 301
master - mean (297ms) : 291, 303
section Bailout
This PR (8164) - mean (293ms) : 288, 298
master - mean (299ms) : 288, 310
section CallTarget+Inlining+NGEN
This PR (8164) - mean (1,075ms) : 989, 1162
master - mean (1,077ms) : 977, 1178
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Lewis-E
force-pushed
the
lewis/SVLS-8244/add-multifunction-named-pipes
branch
2 times, most recently
from
aaff9b5 to
08a6c72
Compare
Lewis-E
force-pushed
the
lewis/SVLS-8244/add-multifunction-named-pipes
branch
3 times, most recently
from
2fcae54 to
edb4121
Compare
duncanpharvey
approved these changes
Mar 13, 2026
Contributor
duncanpharvey
left a comment
duncanpharvey
left a comment
There was a problem hiding this comment.
We check the presence of the compat layer + windows configs (using undocumented envvar DD_SERVERLESS_COMPAT_BINARY_PATH if necessary to adapt to Azure changes) to see if named pipes can be used or if we should rely on TCP
What is meant by this? I don't see DD_SERVERLESS_COMPAT_BINARY_PATH in any of the PR changes.
Contributor
|
Should this dependency for |
Member
|
@codex review |
| && !Util.EnvironmentHelpers.IsUsingAzureAppServicesSiteExtension() | ||
| && IsCompatLayerAvailableWithPipeSupport()) | ||
| { | ||
| var baseName = Util.EnvironmentHelpers.GetEnvironmentVariable(ConfigurationKeys.TracesPipeName); |
Member
There was a problem hiding this comment.
This is only reading the "base" name from environment variables, but the tracer can be configured in other ways (e.g. config files), and those configs would be ignored there. Instead of reading from env vars directly, I think you can read the user setting from rawSettings.TracesPipeName, passed in via parameter.
Member
There was a problem hiding this comment.
Agreed, but we also need to make sure we record the new "calculated" value in telemetry as well
Member
There was a problem hiding this comment.
Looks like my comment is addressed (no reading env vars directly), but I'll leave this open for Andrew's comment (configuration telemetry).
| // Check that the compat binary exists — it's what actually listens on the named pipe | ||
| // Check that the compat DLL exists and has a version that supports named pipes. | ||
| // Named pipe support was added in compat version 1.4.0 (dev builds use 0.0.0). | ||
| const string compatBinaryPath = @"C:\home\site\wwwroot\datadog\bin\windows-amd64\datadog-serverless-compat.exe"; |
Member
There was a problem hiding this comment.
We should take into account that this path can be overridden with DD_SERVERLESS_COMPAT_PATH (see here).
Member
There was a problem hiding this comment.
Most of these helpers feel like they shouldn't live in ExporterSettings at all 🤔 I'd suggest moving them out to a separate helper, and writing unit tests for them there.
Author
There was a problem hiding this comment.
What's a good way to include DD_SERVERLESS_COMPAT_PATH? Claude and I both don't see any obvious options.
Environment.GetEnvironmentVariable is banned (RS0030) and EnvironmentHelpers.GetEnvironmentVariable requires a constant from ConfigurationKeys or PlatformKeys (DD0011). Adding it to ConfigurationKeys via supported-configurations.yaml fails config registry validation since it's not a tracer config. And PlatformKeys rejects the DD_ prefix (DD0010)
Member
There was a problem hiding this comment.
Try giving Claude this doc: docs/development/Configuration/AddingConfigurationKeys.md. I was hoping it would loaded automatically with this note, but maybe we need better wording in the Load when... to trigger that, or maybe we should move some of this things into claude skills now that those are a thing.
(AI agent tooling is still very WIP 😅)
andrewlock
reviewed
Mar 24, 2026
Member
andrewlock
left a comment
andrewlock
left a comment
There was a problem hiding this comment.
LGTM in general, but there's some specific things to address before we merge it (mostly already highlighted by Lucas)
- We should only target existing major versions, and bump support later, otherwise we need strict backward and forward compatibility, which is very hard to maintain and very easy to screw up 😅
- We shouldn't have static state if we can help it. If we want to cache things, we typically handle that by:
- Move the calculating and storage of the value to a helper type as instance methods.
- Create a "singleton" instance of the helper
- Pass the singleton in to the constructor (or, if this gives too much blast radius, allow passing in a null value for the helper, and grab the singleton in the body. This isn't the preferred approach, but it's sometimes the practical one)
- We need to ensure we record the new calculated values in telemetry
- The instrumentation seems a little overly complex considering the behaviours we need and the failure cases
| && !Util.EnvironmentHelpers.IsUsingAzureAppServicesSiteExtension() | ||
| && IsCompatLayerAvailableWithPipeSupport()) | ||
| { | ||
| var baseName = Util.EnvironmentHelpers.GetEnvironmentVariable(ConfigurationKeys.TracesPipeName); |
Member
There was a problem hiding this comment.
Agreed, but we also need to make sure we record the new "calculated" value in telemetry as well
| // Check that the compat binary exists — it's what actually listens on the named pipe | ||
| // Check that the compat DLL exists and has a version that supports named pipes. | ||
| // Named pipe support was added in compat version 1.4.0 (dev builds use 0.0.0). | ||
| const string compatBinaryPath = @"C:\home\site\wwwroot\datadog\bin\windows-amd64\datadog-serverless-compat.exe"; |
Member
There was a problem hiding this comment.
Most of these helpers feel like they shouldn't live in ExporterSettings at all 🤔 I'd suggest moving them out to a separate helper, and writing unit tests for them there.
Lewis-E
force-pushed
the
lewis/SVLS-8244/add-multifunction-named-pipes
branch
from
c9b7aee to
1df4f5a
Compare
Lower MinimumVersion from 1.0.0 to 0.0.0 for the CalculateTracePipeName and CalculateDogStatsDPipeName integrations so the dev (0.0.0) compat assembly is also instrumented. Add missing trimming XML entries for types newly referenced by the tracer. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…on expressions - Remove duplicated GenerateUniquePipeName from ExporterSettings, delegate to ServerlessCompatPipeNameHelper - Remove #if !NETFRAMEWORK guard from helper (no .NET Core-only APIs used) - Remove redundant Log.Information from helper (callers already log) - Use [] instead of new string[0] for ParameterTypeNames per project convention Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ions - ServerlessCompatPipeNameHelper: format, truncation, uniqueness - Integration OnMethodEnd: exception passthrough, caching, override behavior - ExporterSettings: constructor pipe name selection, generated name format Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Check for the compat binary and DLL on disk before generating pipe names in ExporterSettings static init. This prevents the tracer from switching to pipe transport when no compat layer is deployed to listen on the pipe. The version check allows 0.0.0 (dev builds) or >= 1.4.0 (first release with named pipe support). Also fix integration fallbacks to pass through the compat layer's return value instead of generating a new random GUID when no pre-generated pipe name exists. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Wrap RuntimeInformation.IsOSPlatform in #if !NETFRAMEWORK (net461 doesn't have it) - Add null-coalescing for AppDomain.CurrentDomain.BaseDirectory (nullable warning) - Remove unused argument from Log.Debug call (DDLOG003 analyzer error) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…exists When ExporterSettings hasn't pre-generated a pipe name, the integrations now generate one via ServerlessCompatPipeNameHelper instead of falling back to the compat layer's value. Also use realistic GUID-format pipe names in test fixtures to match actual compat layer behavior. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Fix "Compatability" → "Compatibility" typo (3 occurrences) - Use `is null` / `is not null` instead of `== null` / `!= null` - Use `StringUtil.IsNullOrEmpty()` instead of `string.IsNullOrEmpty()` - Remove duplicate test file in Datadog.Trace.Tests - Remove tests already covered by ServerlessCompatPipeNameHelperTests - Fix SA1508 blank line before closing brace in PlatformKeys Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…nique pipe generation Instead of skipping pipe generation when an explicit pipe name is configured, use the configured value as the base name with a GUID suffix appended. This allows users to customize the pipe base name while still getting per-instance isolation on shared Azure Functions hosting plans. If no explicit pipe name is set, falls back to "dd_trace" / "dd_dogstatsd". Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
… integrations CalculateDogStatsDPipeName and CalculateTracePipeName are each only called once during Start(), so caching is unnecessary. The fallback to generate a new unique name is also removed since ExporterSettings always pre-generates the pipe name before these instrumentations fire, and generating a name the tracer doesn't know about is pointless — fall back to the compat layer's own value instead. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…e constructor Replace static field initializers that read env vars directly with instance methods that use rawSettings.TracesPipeName/MetricsPipeName, respecting all config sources (env vars, config files, etc.) instead of only environment variables. Record the calculated pipe names in telemetry. Integrations now read pipe names from Tracer.Instance.Settings.Exporter instead of removed static properties. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…e generation Check the Azure Functions/compat layer condition once in the constructor instead of duplicating it in two separate methods. Consolidate the two per-pipe methods into a single GenerateUniquePipeName overload. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…eHelper and make testable Move compat layer detection out of ExporterSettings into ServerlessCompatPipeNameHelper alongside the related pipe name logic. Extract I/O dependencies (file existence, assembly version) as delegates so version-checking logic can be fully unit tested. Add support for DD_SERVERLESS_COMPAT_PATH env var to override the default binary path, matching the compat layer's own behavior. Add comprehensive tests for all branches: version checks, file missing, null version, exceptions. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
… fix ExporterSettings access path - Add DD_SERVERLESS_COMPAT_PATH to supported-configurations.yaml so the source generator creates ConfigurationKeys.ServerlessCompatPath - Fix integration classes to use the correct property path: Tracer.Instance.Settings.Manager.InitialExporterSettings - Restore using Datadog.Trace.Configuration (needed for IntegrationId) - Remove unused System.Reflection/InteropServices from ExporterSettings Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
+ Maximum Version change Co-authored-by: Andrew Lock <andrewlock.net@gmail.com>
StringUtil.IsNullOrEmpty has [NotNullWhen(false)] so the compiler already knows the value is non-null in the false branch. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…SERVERLESS_COMPAT_PATH config key Update supported_calltargets.g.json and generated_calltargets.g.cpp to reflect MaximumVersion change from 2.*.* to 1.*.*. Add DD_SERVERLESS_COMPAT_PATH to supported-configurations.yaml and restore ConfigurationKeys usage in ServerlessCompatPipeNameHelper. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Version 1.4.0 adds the CalculateTracePipeName and CalculateDogStatsDPipeName methods that the tracer instruments for named pipe coordination. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…ests - Update version range comments from 2.*.* to 1.*.* in both integrations - Update DD_SERVERLESS_COMPAT_PATH documentation for linux default path - Rewrite ServerlessCompatIntegrationTests: remove reflection-based tests for removed cache fields, add Theory-based tests for exception passthrough and fallback behavior with exact value assertions Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…typo, use SkipOn in tests - Move ServerlessCompatPipeNameHelper from ClrProfiler.AutoInstrumentation.Serverless to Datadog.Trace.Serverless to avoid Configuration depending on instrumentation code - Fix "compatability" -> "compatibility" typo in YAML documentation - Replace silent early-return platform guards with SkipOn/SkippableFact so Windows-only tests show as skipped instead of silently passing Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Compat 1.4.0 isn't published yet and has a dependency on these tracer changes. Keep the 1.2.0 dependency — the instrumentation silently skips when the target methods don't exist, and IsCompatLayerAvailableWithPipeSupport gates on >= 1.4.0 at runtime. The dependency will be bumped when compat 1.4.0 is published. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The sig index shifted due to new signatures added in master. Use the correct sig173 as determined by CI's Nuke build. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Master #8231 extracted serverless platform detection from EnvironmentHelpers into dedicated cached classes under Datadog.Trace.Serverless. Update the Azure-Functions pipe-name generation gate to call AzureInfo.Instance.IsAzureFunction and IsUsingSiteExtension instead of the removed EnvironmentHelpers methods. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Lewis-E
force-pushed
the
lewis/SVLS-8244/add-multifunction-named-pipes
branch
from
791e2e7 to
d64e802
Compare
Addresses review feedback: a customer-set TracesPipeName/MetricsPipeName (from any configuration source) should pass through verbatim even when running in Azure Functions, even though this can cause pipe-name collisions across multiple function instances sharing a plan. We only fabricate a GUID-suffixed default pipe name when the customer has not configured one themselves. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Author
|
@lucaspimentel @andrewlock Sorry for the slow back-and-forths here. I've recorded the new setting in telemetry, documented DD_SERVERLESS_COMPAT_PATH, and moved the helpers around. Does GenerateUniquePipeName need to be inlined further & are you happy with the tests? Right now we have one flaky integration test that I don't seem to have permissions to re-run, but other than that, it appears to be passing. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary of changes
Reason for change
Implementation details
For Azure Functions, the tracer loads first, then the compat layer, and then the compat layer launches a rust binary to act as the agent. Additionally, the client may or may not be using the DogstatsD client, and it is also possible to have the compat layer and DogstatsD in place without the tracer. We need to coordinate named pipes across all three/four of these codebases, noting that the tracer will use DogstatsD's pipe for runtime metrics if available.
Given this order of operations, and that we want this to work with immutable configuration, the tracer should set pipe names for the compatibility layer via instrumentation if the tracer is present.
DD_SERVERLESS_COMPAT_BINARY_PATHif necessary to adapt to Azure changes) to see if named pipes can be used or if we should rely on TCPTest coverage