[SVLS-9015] Use consts and instance resolution logic from libdd-common#134
Conversation
…nstance name [SVLS-8931] (#2077) # What does this PR do? - Moves logic for resolving Azure Functions instance name from [serverless-components](https://github.com/DataDog/serverless-components/blob/da82dd574ac4eae73afc7201b9781e057643c2d6/crates/datadog-metrics-collector/src/azure_instance.rs#L21) to libdd-common. - Logic for resolving instance name: `COMPUTERNAME` -> `WEBSITE_POD_NAME` -> `CONTAINER_NAME` - This matches the `instance` tag of `azure.functions.function_execution_count` integration metric - Before, we only checked `COMPUTERNAME`. The investigation to determine which env vars should be used is in the Instance tab of [Enhanced Metrics in the Serverless Compatibility Layer](https://docs.google.com/document/d/1uMT4fphW7C31JLmf5KY1CdrXGPkn2QLfIvHZK3CJD40/edit?usp=sharing) - This has the added benefit of populating the instance name span attribute `aas.environment.instance_name` in hosting plans where the attribute was `unknown` before - Before, we only looked at `COMPUTERNAME` for instance name, which was empty for Linux Flex Consumption and Consumption functions - This PR also makes some consts public so that they can be used by serverless-components; see DataDog/serverless-components#134 for usage # Motivation https://datadoghq.atlassian.net/browse/SVLS-8931 https://datadoghq.atlassian.net/browse/SVLS-9015 # Additional Notes Once this PR is merged, we plan to make a new PR in serverless-components to update the libdatadog commit hash and remove the redundant consts and instance name logic. Draft PR: DataDog/serverless-components#134 # How to test the change? Unit tests: Run `cargo test -p libdd-common azure_app_services` 1. Use git log to find this PR's most recent commit hash 2. Clone [serverless-components](https://github.com/DataDog/serverless-components/tree/main) and update the commit hash in [datadog-trace-agent/Cargo.toml](https://github.com/DataDog/serverless-components/blob/main/crates/datadog-trace-agent/Cargo.toml) everywhere that libdatadog is used 3. Follow the instructions in the [Serverless Compatibility Layer docs](https://datadoghq.atlassian.net/wiki/spaces/SLS/pages/2977497119/Serverless+Compatibility+Layer) to deploy sample apps Flex Consumption function with fix: <img width="956" height="568" alt="image" src="https://github.com/user-attachments/assets/b11585cf-7e1c-4d89-a60d-490bfe6bf45e" /> Flex Consumption function without fix: <img width="1267" height="504" alt="Screenshot 2026-06-03 at 4 33 58 PM" src="https://github.com/user-attachments/assets/252c9ffa-3918-457f-95b5-adc1b794aa2b" /> Consumption function with fix: <img width="974" height="564" alt="image" src="https://github.com/user-attachments/assets/2d92d604-be97-4eb1-8e6a-9d048420c715" /> Consumption function without fix: <img width="1276" height="534" alt="image" src="https://github.com/user-attachments/assets/b9918da9-c177-45df-8432-92f7eee001eb" /> I tested by deploying with [serverless-compat-self-monitoring](https://github.com/DataDog/serverless-compat-self-monitoring): - FC1 and Y1 linux functions get the `aas.environment.instance_name` span attribute populated - The span attributes for all other functions still look the same (same shape and casing) Co-authored-by: kathie.huang <kathie.huang@datadoghq.com>
b082204 to
3515b51
Compare
There was a problem hiding this comment.
Pull request overview
Updates this repo to the newer libdatadog revision that moved Azure instance-name resolution and related environment-constant definitions into libdd-common, and switches local code to consume those shared APIs/consts.
Changes:
- Bump
libdatadoggit rev across crates (and updateCargo.lockaccordingly). - Replace local Azure env-var const usage with
libdd_common::azure_app_services::*consts. - Remove local Azure instance-id resolution logic in metrics collector and use
libdd_common’s instance resolution.
Reviewed changes
Copilot reviewed 7 out of 8 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| crates/datadog-trace-agent/src/env_verifier.rs | Use azure_app_services::WEBSITE_SKU for Flex Consumption detection and update tests accordingly. |
| crates/datadog-trace-agent/Cargo.toml | Bump libdd-* git dependencies to the new libdatadog rev. |
| crates/datadog-serverless-compat/Cargo.toml | Bump libdd-trace-utils git dependency to the new libdatadog rev. |
| crates/datadog-metrics-collector/src/azure_tags.rs | Use azure_app_services consts (including UNKNOWN_VALUE) for tag building. |
| crates/datadog-metrics-collector/src/azure_instance.rs | Switch instance tag resolution to libdd_common::azure_app_services metadata. |
| crates/datadog-metrics-collector/Cargo.toml | Bump libdd-common git dependency rev. |
| crates/datadog-agent-config/Cargo.toml | Bump libdd-trace-* git dependencies to the new libdatadog rev. |
| Cargo.lock | Lockfile updates reflecting the new libdatadog rev and crate versions. |
| let instance_name = azure_app_services::AAS_METADATA_FUNCTION | ||
| .as_ref() | ||
| .map(|m| m.get_instance_name().to_lowercase()) | ||
| .filter(|n| n != azure_app_services::UNKNOWN_VALUE); | ||
|
|
There was a problem hiding this comment.
get_instance_name uses get_value_or_unknown! which returns either the stored instance_name string or unknown - never an empty string
| impl InstanceMetricsCollector { | ||
| /// Creates a new collector, returning `None` if no instance ID is found. | ||
| pub fn new(aggregator: AggregatorHandle, tags: Option<SortedTags>) -> Option<Self> { | ||
| let instance_id = resolve_instance_id(); | ||
| let Some(instance_id) = instance_id else { | ||
| let instance_name = azure_app_services::AAS_METADATA_FUNCTION | ||
| .as_ref() | ||
| .map(|m| m.get_instance_name().to_lowercase()) | ||
| .filter(|n| n != azure_app_services::UNKNOWN_VALUE); | ||
|
|
||
| let Some(instance_id) = instance_name else { | ||
| warn!("No instance ID found, instance metric will not be submitted"); | ||
| return None; |
There was a problem hiding this comment.
I feel like unit tests would be redundant since we have tests for the instance name resolution in libdatadog but happy to add if we feel they're needed!
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 56f6df1849
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let instance_name = azure_app_services::AAS_METADATA_FUNCTION | ||
| .as_ref() | ||
| .map(|m| m.get_instance_name().to_lowercase()) | ||
| .filter(|n| n != azure_app_services::UNKNOWN_VALUE); |
There was a problem hiding this comment.
Preserve consumption instance resolution
In FlexConsumption/Dynamic Azure Functions where Azure also exposes COMPUTERNAME, this now takes the instance name from the pinned libdd-common metadata resolver, which prioritizes COMPUTERNAME before WEBSITE_POD_NAME/CONTAINER_NAME. The previous implementation deliberately used the container/pod values for those SKUs so the azure.functions.enhanced.instance tag matched the Azure integration's instance dimension; using COMPUTERNAME in that scenario causes the enhanced instance metric to be attributed under a different instance tag.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
In FlexConsumption/Dynamic Azure Functions, COMPUTERNAME is unset. My investigation to identify what env vars should be used for each hosting plan can be found here
What does this PR do?
With DataDog/libdatadog#2077 we moved the instance name resolution logic and any consts gathered from environment variables to libdd-common. This PR updates the libdatadog rev and uses the libdd-common logic and public consts.
Motivation
https://datadoghq.atlassian.net/browse/SVLS-9015
Additional Notes
Describe how to test/QA your changes
Deployed an Azure Function and confirmed that the
instancetag in the instance enhanced metric is the same. See DataDog/libdatadog#2077 for testing theinstance_namespan attribute with screenshots.