[SVLS-8160] Add serverless-identifying profile tags to serverless-init#44361
Conversation
Static quality checks✅ Please find below the results from static quality gates Successful checksInfo
|
Regression DetectorRegression Detector ResultsMetrics dashboard Baseline: b665fd4 Optimization Goals: ✅ No significant changes detected
|
| perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
|---|---|---|---|---|---|---|
| ➖ | docker_containers_cpu | % cpu utilization | -0.34 | [-3.33, +2.64] | 1 | Logs |
Fine details of change detection per experiment
| perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
|---|---|---|---|---|---|---|
| ➖ | ddot_metrics | memory utilization | +1.39 | [+1.18, +1.60] | 1 | Logs |
| ➖ | quality_gate_logs | % cpu utilization | +0.99 | [-0.47, +2.45] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_idle | memory utilization | +0.46 | [+0.41, +0.50] | 1 | Logs bounds checks dashboard |
| ➖ | ddot_metrics_sum_delta | memory utilization | +0.42 | [+0.22, +0.63] | 1 | Logs |
| ➖ | ddot_logs | memory utilization | +0.39 | [+0.33, +0.46] | 1 | Logs |
| ➖ | ddot_metrics_sum_cumulativetodelta_exporter | memory utilization | +0.36 | [+0.13, +0.59] | 1 | Logs |
| ➖ | ddot_metrics_sum_cumulative | memory utilization | +0.30 | [+0.14, +0.46] | 1 | Logs |
| ➖ | otlp_ingest_metrics | memory utilization | +0.21 | [+0.05, +0.36] | 1 | Logs |
| ➖ | file_tree | memory utilization | +0.08 | [+0.04, +0.11] | 1 | Logs |
| ➖ | uds_dogstatsd_to_api | ingress throughput | +0.02 | [-0.10, +0.14] | 1 | Logs |
| ➖ | file_to_blackhole_100ms_latency | egress throughput | +0.01 | [-0.03, +0.06] | 1 | Logs |
| ➖ | tcp_dd_logs_filter_exclude | ingress throughput | +0.01 | [-0.07, +0.09] | 1 | Logs |
| ➖ | file_to_blackhole_1000ms_latency | egress throughput | +0.00 | [-0.42, +0.42] | 1 | Logs |
| ➖ | file_to_blackhole_0ms_latency | egress throughput | -0.01 | [-0.43, +0.41] | 1 | Logs |
| ➖ | uds_dogstatsd_to_api_v3 | ingress throughput | -0.01 | [-0.14, +0.12] | 1 | Logs |
| ➖ | otlp_ingest_logs | memory utilization | -0.03 | [-0.13, +0.08] | 1 | Logs |
| ➖ | file_to_blackhole_500ms_latency | egress throughput | -0.09 | [-0.46, +0.28] | 1 | Logs |
| ➖ | uds_dogstatsd_20mb_12k_contexts_20_senders | memory utilization | -0.09 | [-0.15, -0.03] | 1 | Logs |
| ➖ | quality_gate_idle_all_features | memory utilization | -0.30 | [-0.34, -0.25] | 1 | Logs bounds checks dashboard |
| ➖ | docker_containers_memory | memory utilization | -0.34 | [-0.41, -0.26] | 1 | Logs |
| ➖ | docker_containers_cpu | % cpu utilization | -0.34 | [-3.33, +2.64] | 1 | Logs |
| ➖ | quality_gate_metrics_logs | memory utilization | -1.29 | [-1.50, -1.08] | 1 | Logs bounds checks dashboard |
| ➖ | tcp_syslog_to_blackhole | ingress throughput | -2.40 | [-2.47, -2.32] | 1 | Logs |
Bounds Checks: ✅ Passed
| perf | experiment | bounds_check_name | replicates_passed | links |
|---|---|---|---|---|
| ✅ | docker_containers_cpu | simple_check_run | 10/10 | |
| ✅ | docker_containers_memory | memory_usage | 10/10 | |
| ✅ | docker_containers_memory | simple_check_run | 10/10 | |
| ✅ | file_to_blackhole_0ms_latency | lost_bytes | 10/10 | |
| ✅ | file_to_blackhole_0ms_latency | memory_usage | 10/10 | |
| ✅ | file_to_blackhole_1000ms_latency | lost_bytes | 10/10 | |
| ✅ | file_to_blackhole_1000ms_latency | memory_usage | 10/10 | |
| ✅ | file_to_blackhole_100ms_latency | lost_bytes | 10/10 | |
| ✅ | file_to_blackhole_100ms_latency | memory_usage | 10/10 | |
| ✅ | file_to_blackhole_500ms_latency | lost_bytes | 10/10 | |
| ✅ | file_to_blackhole_500ms_latency | memory_usage | 10/10 | |
| ✅ | quality_gate_idle | intake_connections | 10/10 | bounds checks dashboard |
| ✅ | quality_gate_idle | memory_usage | 10/10 | bounds checks dashboard |
| ✅ | quality_gate_idle_all_features | intake_connections | 10/10 | bounds checks dashboard |
| ✅ | quality_gate_idle_all_features | memory_usage | 10/10 | bounds checks dashboard |
| ✅ | quality_gate_logs | intake_connections | 10/10 | bounds checks dashboard |
| ✅ | quality_gate_logs | lost_bytes | 10/10 | bounds checks dashboard |
| ✅ | quality_gate_logs | memory_usage | 10/10 | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | cpu_usage | 10/10 | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | intake_connections | 10/10 | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | lost_bytes | 10/10 | bounds checks dashboard |
| ✅ | quality_gate_metrics_logs | memory_usage | 10/10 | bounds checks dashboard |
Explanation
Confidence level: 90.00%
Effect size tolerance: |Δ mean %| ≥ 5.00%
Performance changes are noted in the perf column of each table:
- ✅ = significantly better comparison variant performance
- ❌ = significantly worse comparison variant performance
- ➖ = no significant change in performance
A regression test is an A/B test of target performance in a repeatable rig, where "performance" is measured as "comparison variant minus baseline variant" for an optimization goal (e.g., ingress throughput). Due to intrinsic variability in measuring that goal, we can only estimate its mean value for each experiment; we report uncertainty in that value as a 90.00% confidence interval denoted "Δ mean % CI".
For each experiment, we decide whether a change in performance is a "regression" -- a change worth investigating further -- if all of the following criteria are true:
-
Its estimated |Δ mean %| ≥ 5.00%, indicating the change is big enough to merit a closer look.
-
Its 90.00% confidence interval "Δ mean % CI" does not contain zero, indicating that if our statistical model is accurate, there is at least a 90.00% chance there is a difference in performance between baseline and comparison variants.
-
Its configuration does not mark it "erratic".
CI Pass/Fail Decision
✅ Passed. All Quality Gates passed.
- quality_gate_logs, bounds check lost_bytes: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_idle, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_idle, bounds check intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_idle_all_features, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_idle_all_features, bounds check intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_logs, bounds check intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_logs, bounds check cpu_usage: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_logs, bounds check lost_bytes: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.
ce9e8c1 to
1c74132
Compare
1c74132 to
b4cc0ff
Compare
| "aas.subscription.id", | ||
| "aas.resource.group", | ||
| "aas.resource.id", | ||
| "_dd.origin", |
There was a problem hiding this comment.
where does this origin actually get set?
There was a problem hiding this comment.
It gets set in their respective cloudservice files: appservice.go for Azure App Service and containerapp.go for Azure Container Apps! And then GetTags gets called in main.go here
|
/merge |
|
View all feedbacks in Devflow UI.
This pull request is not mergeable according to GitHub. Common reasons include pending required checks, missing approvals, or merge conflicts — but it could also be blocked by other repository rules or settings.
[email protected] unqueued this merge request |
|
/merge -c |
|
View all feedbacks in Devflow UI.
|
|
/merge |
|
View all feedbacks in Devflow UI.
This pull request is not mergeable according to GitHub. Common reasons include pending required checks, missing approvals, or merge conflicts — but it could also be blocked by other repository rules or settings.
The expected merge time in
|
…ws profiles (#44488) ### What does this PR do? - Adds `_dd.origin:appservice` tag to profiles for Azure App Service Windows Apps - The tag gets passed via `apm_config.additional_profile_tags`, which is set in [this PR](DataDog/datadog-aas-extension#419) in the AAS Site Extension - Refactors how extra tags get added to profiles - Turns AzureServerlessTags into a map called `AdditionalProfileTags` for clearer future use ### Motivation - This will help the profiling backend filter out and track serverless profiles for billing purposes. [See related PR](#44361) ### Describe how you validated your changes Deployed Node.js and .NET Azure App Service Windows Apps with the Site Extension with `DD_PROFILING_ENABLED=true` and looked at network request to validate that `_dd.origin` is set correctly 1. Downloaded `datadog-trace-agent.exe` and `dogstatsd.exe` from the `package_build > windows_zip_agent_binaries_x64-a7` job 2. Stopped an existing AAS Windows app using the site extension 3. In Kudu, replaced `datadog-trace-agent.exe` and `dogstatsd.exe` with the dev version 4. Copied and pasted the changes in `datadog.yaml` from the related [AAS Extension PR](DataDog/datadog-aas-extension#419) over 5. Started the app 6. Saw `_dd.origin` in the profile tags! <img width="204" height="127" alt="image" src="https://github.com/user-attachments/assets/6a08a29c-be18-4604-9d6f-af7b43c87fa7" /> - Also tested with an Azure Container App to make sure the refactoring didn't affect anything there Co-authored-by: kathie.huang <[email protected]>
…ws profiles (#44488) ### What does this PR do? - Adds `_dd.origin:appservice` tag to profiles for Azure App Service Windows Apps - The tag gets passed via `apm_config.additional_profile_tags`, which is set in [this PR](DataDog/datadog-aas-extension#419) in the AAS Site Extension - Refactors how extra tags get added to profiles - Turns AzureServerlessTags into a map called `AdditionalProfileTags` for clearer future use ### Motivation - This will help the profiling backend filter out and track serverless profiles for billing purposes. [See related PR](#44361) ### Describe how you validated your changes Deployed Node.js and .NET Azure App Service Windows Apps with the Site Extension with `DD_PROFILING_ENABLED=true` and looked at network request to validate that `_dd.origin` is set correctly 1. Downloaded `datadog-trace-agent.exe` and `dogstatsd.exe` from the `package_build > windows_zip_agent_binaries_x64-a7` job 2. Stopped an existing AAS Windows app using the site extension 3. In Kudu, replaced `datadog-trace-agent.exe` and `dogstatsd.exe` with the dev version 4. Copied and pasted the changes in `datadog.yaml` from the related [AAS Extension PR](DataDog/datadog-aas-extension#419) over 5. Started the app 6. Saw `_dd.origin` in the profile tags! <img width="204" height="127" alt="image" src="https://github.com/user-attachments/assets/6a08a29c-be18-4604-9d6f-af7b43c87fa7" /> - Also tested with an Azure Container App to make sure the refactoring didn't affect anything there Co-authored-by: kathie.huang <[email protected]>
…ws profiles (#45281) **Note:** This is a reimplementation of [this PR](#44488), which was reverted [here](#45200). This fixes the failing CI test. Working CI tests: [Job 1](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1370634331), [Job 2](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1370634332) ### What does this PR do? - Adds `_dd.origin:appservice` tag to profiles for Azure App Service Windows Apps - The tag gets passed via `apm_config.additional_profile_tags`, which is set in [this PR](DataDog/datadog-aas-extension#419) in the AAS Site Extension - Refactors how extra tags get added to profiles - Turns AzureServerlessTags into a map called `AdditionalProfileTags` for clearer future use The only changes between this PR and the reverted PR is commit [ef27a8a](ef27a8a), which fixes the CI test ([failed job #1](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1356878378), [failed job #2](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1356827817)), and dcc9ad9, which renames `azureServerlessTags` to be cloud-agnostic as `_dd.origin` gets set for profiles in Google Cloud Run Services, Jobs, and Functions, not just Azure products. ### Motivation - This will help the profiling backend filter out and track serverless profiles for billing purposes. [See related PR](#44361) ### Describe how you validated your changes Deployed Node.js and .NET Azure App Service Windows Apps with the Site Extension with `DD_PROFILING_ENABLED=true` and looked at network request to validate that `_dd.origin` is set correctly 1. Downloaded `datadog-trace-agent.exe` and `dogstatsd.exe` from the `package_build > windows_zip_agent_binaries_x64-a7` job 2. Stopped an existing AAS Windows app using the site extension 3. In Kudu, replaced `datadog-trace-agent.exe` and `dogstatsd.exe` with the dev version 4. Copied and pasted the changes in `datadog.yaml` from the related [AAS Extension PR](DataDog/datadog-aas-extension#419) over 5. Started the app 6. Saw `_dd.origin` in the profile tags! <img width="204" height="127" alt="image" src="https://github.com/user-attachments/assets/6a08a29c-be18-4604-9d6f-af7b43c87fa7" /> - Also tested with an Azure Container App to make sure the refactoring didn't affect anything there, and tested in GCP environments to verify the `_dd.origin` tag gets set in profiles Co-authored-by: kathie.huang <[email protected]>
…ws profiles (#45281) **Note:** This is a reimplementation of [this PR](#44488), which was reverted [here](#45200). This fixes the failing CI test. Working CI tests: [Job 1](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1370634331), [Job 2](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1370634332) ### What does this PR do? - Adds `_dd.origin:appservice` tag to profiles for Azure App Service Windows Apps - The tag gets passed via `apm_config.additional_profile_tags`, which is set in [this PR](DataDog/datadog-aas-extension#419) in the AAS Site Extension - Refactors how extra tags get added to profiles - Turns AzureServerlessTags into a map called `AdditionalProfileTags` for clearer future use The only changes between this PR and the reverted PR is commit [ef27a8a](ef27a8a), which fixes the CI test ([failed job #1](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1356878378), [failed job #2](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/1356827817)), and dcc9ad9, which renames `azureServerlessTags` to be cloud-agnostic as `_dd.origin` gets set for profiles in Google Cloud Run Services, Jobs, and Functions, not just Azure products. ### Motivation - This will help the profiling backend filter out and track serverless profiles for billing purposes. [See related PR](#44361) ### Describe how you validated your changes Deployed Node.js and .NET Azure App Service Windows Apps with the Site Extension with `DD_PROFILING_ENABLED=true` and looked at network request to validate that `_dd.origin` is set correctly 1. Downloaded `datadog-trace-agent.exe` and `dogstatsd.exe` from the `package_build > windows_zip_agent_binaries_x64-a7` job 2. Stopped an existing AAS Windows app using the site extension 3. In Kudu, replaced `datadog-trace-agent.exe` and `dogstatsd.exe` with the dev version 4. Copied and pasted the changes in `datadog.yaml` from the related [AAS Extension PR](DataDog/datadog-aas-extension#419) over 5. Started the app 6. Saw `_dd.origin` in the profile tags! <img width="204" height="127" alt="image" src="https://github.com/user-attachments/assets/6a08a29c-be18-4604-9d6f-af7b43c87fa7" /> - Also tested with an Azure Container App to make sure the refactoring didn't affect anything there, and tested in GCP environments to verify the `_dd.origin` tag gets set in profiles Co-authored-by: kathie.huang <[email protected]>
What does this PR do?
_dd.origintag to profiles for Azure App Service Linux and Azure Container Appscontainerappfor Azure Container Appsappservicefor Azure App Servicecloudrunfor Cloud Run Functions and Cloud Run Servicecloudrunjobsfor Cloud Run JobsMotivation
Describe how you validated your changes
Deployed with
DD_PROFILING_ENABLED=trueand looked at network request to validate that_dd.originis set correctly (following this local testing guide for serverless-init)Additional Notes