feat: Add Enhanced CPU Metrics for Serverless by duncanpharvey · Pull Request #47421 · DataDog/datadog-agent

duncanpharvey · 2026-03-05T16:31:38Z

What does this PR do?

Adds enhanced CPU metrics for Azure App Service Web Apps, Azure Container Apps, Google Cloud Run (Services, Functions, Jobs).

Motivation

https://datadoghq.atlassian.net/browse/SVLS-8356

Describe how you validated your changes

Deployed to Azure Web Apps, Azure Container Apps, Google Cloud Run (Services, Functions, Jobs) using both in container and sidecar modes.

Additional Notes

Implementation Details

When the collector is started metrics are collected immediately, then with a collection interval of 3 seconds. The metrics aggregator has a bucket size of 10 seconds and the metrics agent flushes those buckets every 3 seconds. If there is a shutdown event, there is a final collection and flush of metrics with a partial interval.
CPU metrics are collected from cgroup v1 system files
Because the CPU metrics will not have a tag with a unique identifier for the instance they are sent from, they need to be sent as distribution metrics in order to avoid aggregation issues.
The usage metrics will have a unique identifier for instance or replica so these metrics will be submitted as gauge metrics to reduce internal costs.
A new sidecar: <true|false> tag will be added to enhanced metrics to identify if the metrics came from a sidecar container
Limited tag set consists of configured tags (DD_TAGS, DD_EXTRA_TAGS), base tags (env, service, version), cloud service specific tags, datadog_init_version, datadog_sidecar_version, and sidecar
Enhanced Metrics can are enabled by default and can be disabled with DD_ENHANCED_METRICS_ENABLED=false
Enhanced metrics added as part of this PR - these metrics have an updated prefix in order to align with the metric prefix of the corresponding cloud integration metrics. They also have a limited tag set instead of having all of the available tags that are added to traces, logs, and dogstatsd metrics . High cardinality tags will only be added to the cpu.limit metric.
- azure.app_services.enhanced.cpu.usage
- azure.app_services.enhanced.cpu.limit
- azure.app_services.enhanced.instance
- azure.app_containerapp.enhanced.cpu.usage
- azure.app_containerapp.enhanced.cpu.limit
- azure.app_containerapp.enhanced.replica
- gcp.run.container.enhanced.cpu.usage
- gcp.run.container.enhanced.cpu.limit
- gcp.run.container.enhanced.instance
Legacy enhanced Metrics - these metrics will continue to be sent with the same full tag set for backwards compatibility. The metrics can be removed in a future major version update.
- azure.appservice.enhanced.cold_start
- azure.appservice.enhanced.shutdown
- azure.containerapp.enhanced.cold_start
- azure.containerapp.enhanced.shutdown
- gcp.run.enhanced.cold_start
- gcp.run.enhanced.shutdown
- gcp.run.enhanced.cold_start
- gcp.run.enhanced.shutdown
Updated enhanced metrics - these metrics have the same namespace but are updated to have a more limited tag set to be consistent with the other enhanced metrics as part of this PR. Google Cloud Run jobs is still in preview.
- gcp.run.job.enhanced.task.duration
- gcp.run.job.enhanced.task.started
- gcp.run.job.enhanced.task.ended

Other updates and fixes

Assign correct namespace for Google Cloud Run Jobs. Currently some tags are assigned under the gcrfx namespace. As a result, add gcrj.container_id as a high cardinality tag so it is excluded from metrics
cloudService.GetStartMetricName() refactored to cloudService.AddStartMetric(metricAgent) in order to accommodate prefix changes
Remove cmd/serverless-init/metric/metric.go and move into pkg/serverless/metrics/metric.go
- Add separate methods for adding a legacy enhanced metric (full tag set), new enhanced metric (limited tag set), and a new enhanced metric with high cardinality tags (limited tag set, including high cardinality tags)
Refactor MergeWithOverwrite to accept multiple tag maps
Refactor serverlessInitTag.GetBaseTagsMapWithMetadata to serverlessInitTag.GetBaseTagsMap so it only handles setting base tags (service, env, version)
Set use_v2_api.series to true for metric agent so metric source is submitted correctly for gauge usage metric

agent-platform-auto-pr · 2026-03-05T16:51:08Z

Files inventory check summary

File checks results against ancestor 25b438f9:

Results for datadog-agent_7.79.0~devel.git.136.2e2ef9f.pipeline.104369606-1_amd64.deb:

No change detected

agent-platform-auto-pr · 2026-03-05T17:01:06Z

Static quality checks

✅ Please find below the results from static quality gates
Comparison made with ancestor 25b438f
📊 Static Quality Gates Dashboard
🔗 SQG Job

Successful checks

Info

	Quality gate	Change	Size (prev → curr → max)
✅	docker_agent_amd64	+4.97 KiB (0.00% increase)	813.065 → 813.070 → 815.700
✅	docker_agent_arm64	+4.0 KiB (0.00% increase)	816.217 → 816.221 → 821.970
✅	docker_agent_jmx_amd64	+4.98 KiB (0.00% increase)	1003.981 → 1003.986 → 1006.580
✅	docker_agent_jmx_arm64	+3.99 KiB (0.00% increase)	995.911 → 995.915 → 1001.570

26 successful checks with minimal change (< 2 KiB)

	Quality gate	Current Size
✅	agent_deb_amd64	752.760 MiB
✅	agent_deb_amd64_fips	709.727 MiB
✅	agent_heroku_amd64	313.141 MiB
✅	agent_rpm_amd64	752.744 MiB
✅	agent_rpm_amd64_fips	709.711 MiB
✅	agent_rpm_arm64	731.132 MiB
✅	agent_rpm_arm64_fips	691.112 MiB
✅	agent_suse_amd64	752.744 MiB
✅	agent_suse_amd64_fips	709.711 MiB
✅	agent_suse_arm64	731.132 MiB
✅	agent_suse_arm64_fips	691.112 MiB
✅	docker_cluster_agent_amd64	205.320 MiB
✅	docker_cluster_agent_arm64	219.677 MiB
✅	docker_cws_instrumentation_amd64	7.142 MiB
✅	docker_cws_instrumentation_arm64	6.689 MiB
✅	docker_dogstatsd_amd64	39.230 MiB
✅	docker_dogstatsd_arm64	37.445 MiB
✅	dogstatsd_deb_amd64	29.874 MiB
✅	dogstatsd_deb_arm64	28.026 MiB
✅	dogstatsd_rpm_amd64	29.874 MiB
✅	dogstatsd_suse_amd64	29.874 MiB
✅	iot_agent_deb_amd64	43.254 MiB
✅	iot_agent_deb_arm64	40.305 MiB
✅	iot_agent_deb_armhf	41.052 MiB
✅	iot_agent_rpm_amd64	43.255 MiB
✅	iot_agent_suse_amd64	43.255 MiB

On-wire sizes (compressed)

	Quality gate	Change	Size (prev → curr → max)
✅	agent_deb_amd64	+78.63 KiB (0.04% increase)	174.786 → 174.862 → 178.360
✅	agent_deb_amd64_fips	-17.09 KiB (0.01% reduction)	165.400 → 165.383 → 172.790
✅	agent_heroku_amd64	-2.81 KiB (0.00% reduction)	74.981 → 74.979 → 79.970
✅	agent_rpm_amd64	-36.11 KiB (0.02% reduction)	177.686 → 177.650 → 181.830
✅	agent_rpm_amd64_fips	-54.09 KiB (0.03% reduction)	167.729 → 167.676 → 173.370
✅	agent_rpm_arm64	-94.48 KiB (0.06% reduction)	159.682 → 159.590 → 163.060
✅	agent_rpm_arm64_fips	+13.77 KiB (0.01% increase)	151.483 → 151.497 → 156.170
✅	agent_suse_amd64	-36.11 KiB (0.02% reduction)	177.686 → 177.650 → 181.830
✅	agent_suse_amd64_fips	-54.09 KiB (0.03% reduction)	167.729 → 167.676 → 173.370
✅	agent_suse_arm64	-94.48 KiB (0.06% reduction)	159.682 → 159.590 → 163.060
✅	agent_suse_arm64_fips	+13.77 KiB (0.01% increase)	151.483 → 151.497 → 156.170
✅	docker_agent_amd64	+15.28 KiB (0.01% increase)	268.247 → 268.262 → 272.480
✅	docker_agent_arm64	+25.61 KiB (0.01% increase)	255.439 → 255.464 → 261.060
✅	docker_agent_jmx_amd64	+16.86 KiB (0.00% increase)	336.888 → 336.905 → 341.100
✅	docker_agent_jmx_arm64	+13.48 KiB (0.00% increase)	320.081 → 320.094 → 325.620
✅	docker_cluster_agent_amd64	-6.09 KiB (0.01% reduction)	71.929 → 71.923 → 72.920
✅	docker_cluster_agent_arm64	+6.75 KiB (0.01% increase)	67.510 → 67.517 → 68.220
✅	docker_cws_instrumentation_amd64	neutral	2.999 MiB → 3.330
✅	docker_cws_instrumentation_arm64	neutral	2.729 MiB → 3.090
✅	docker_dogstatsd_amd64	neutral	15.169 MiB → 15.820
✅	docker_dogstatsd_arm64	+4.01 KiB (0.03% increase)	14.488 → 14.492 → 14.830
✅	dogstatsd_deb_amd64	neutral	7.890 MiB → 8.790
✅	dogstatsd_deb_arm64	neutral	6.776 MiB → 7.710
✅	dogstatsd_rpm_amd64	neutral	7.902 MiB → 8.800
✅	dogstatsd_suse_amd64	neutral	7.902 MiB → 8.800
✅	iot_agent_deb_amd64	neutral	11.397 MiB → 12.040
✅	iot_agent_deb_arm64	neutral	9.699 MiB → 10.450
✅	iot_agent_deb_armhf	neutral	9.934 MiB → 10.620
✅	iot_agent_rpm_amd64	-3.48 KiB (0.03% reduction)	11.414 → 11.411 → 12.060
✅	iot_agent_suse_amd64	-3.48 KiB (0.03% reduction)	11.414 → 11.411 → 12.060

cit-pr-commenter-54b7da · 2026-03-05T17:26:10Z

Regression Detector

Regression Detector Results

Metrics dashboard
Target profiles
Run ID: d57c474b-079f-4f30-84c2-ff0e8dd1613b

Baseline: 25f0b9c
Comparison: a1f24cb
Diff

Optimization Goals: ✅ No significant changes detected

Experiments ignored for regressions

Regressions in experiments with settings containing erratic: true are ignored.

perf	experiment	goal	Δ mean %	Δ mean % CI	trials	links
➖	docker_containers_cpu	% cpu utilization	+1.76	[-1.29, +4.81]	1	Logs

Fine details of change detection per experiment

perf	experiment	goal	Δ mean %	Δ mean % CI	trials	links
➖	docker_containers_cpu	% cpu utilization	+1.76	[-1.29, +4.81]	1	Logs
➖	quality_gate_metrics_logs	memory utilization	+0.69	[+0.45, +0.93]	1	Logs bounds checks dashboard
➖	quality_gate_idle	memory utilization	+0.16	[+0.10, +0.21]	1	Logs bounds checks dashboard
➖	otlp_ingest_logs	memory utilization	+0.10	[-0.00, +0.20]	1	Logs
➖	ddot_metrics_sum_cumulative	memory utilization	+0.06	[-0.08, +0.20]	1	Logs
➖	file_to_blackhole_0ms_latency	egress throughput	+0.04	[-0.49, +0.57]	1	Logs
➖	uds_dogstatsd_20mb_12k_contexts_20_senders	memory utilization	+0.02	[-0.04, +0.08]	1	Logs
➖	uds_dogstatsd_to_api	ingress throughput	+0.00	[-0.21, +0.21]	1	Logs
➖	tcp_dd_logs_filter_exclude	ingress throughput	+0.00	[-0.10, +0.11]	1	Logs
➖	uds_dogstatsd_to_api_v3	ingress throughput	+0.00	[-0.20, +0.20]	1	Logs
➖	file_to_blackhole_100ms_latency	egress throughput	-0.02	[-0.09, +0.05]	1	Logs
➖	file_tree	memory utilization	-0.03	[-0.09, +0.04]	1	Logs
➖	file_to_blackhole_500ms_latency	egress throughput	-0.05	[-0.44, +0.35]	1	Logs
➖	file_to_blackhole_1000ms_latency	egress throughput	-0.06	[-0.49, +0.37]	1	Logs
➖	ddot_logs	memory utilization	-0.06	[-0.13, +0.00]	1	Logs
➖	quality_gate_idle_all_features	memory utilization	-0.14	[-0.18, -0.11]	1	Logs bounds checks dashboard
➖	otlp_ingest_metrics	memory utilization	-0.19	[-0.35, -0.03]	1	Logs
➖	ddot_metrics_sum_cumulativetodelta_exporter	memory utilization	-0.26	[-0.49, -0.04]	1	Logs
➖	ddot_metrics_sum_delta	memory utilization	-0.30	[-0.46, -0.13]	1	Logs
➖	tcp_syslog_to_blackhole	ingress throughput	-0.30	[-0.44, -0.16]	1	Logs
➖	ddot_metrics	memory utilization	-0.45	[-0.62, -0.28]	1	Logs
➖	docker_containers_memory	memory utilization	-1.25	[-1.40, -1.09]	1	Logs
➖	quality_gate_logs	% cpu utilization	-2.38	[-4.00, -0.76]	1	Logs bounds checks dashboard

Bounds Checks: ✅ Passed

perf	experiment	bounds_check_name	replicates_passed	observed_value	links
✅	docker_containers_cpu	simple_check_run	10/10	711 ≥ 26
✅	docker_containers_memory	memory_usage	10/10	272.23MiB ≤ 370MiB
✅	docker_containers_memory	simple_check_run	10/10	685 ≥ 26
✅	file_to_blackhole_0ms_latency	memory_usage	10/10	0.19GiB ≤ 1.20GiB
✅	file_to_blackhole_0ms_latency	missed_bytes	10/10	0B = 0B
✅	file_to_blackhole_1000ms_latency	memory_usage	10/10	0.23GiB ≤ 1.20GiB
✅	file_to_blackhole_1000ms_latency	missed_bytes	10/10	0B = 0B
✅	file_to_blackhole_100ms_latency	memory_usage	10/10	0.19GiB ≤ 1.20GiB
✅	file_to_blackhole_100ms_latency	missed_bytes	10/10	0B = 0B
✅	file_to_blackhole_500ms_latency	memory_usage	10/10	0.21GiB ≤ 1.20GiB
✅	file_to_blackhole_500ms_latency	missed_bytes	10/10	0B = 0B
✅	quality_gate_idle	intake_connections	10/10	3 = 3	bounds checks dashboard
✅	quality_gate_idle	memory_usage	10/10	174.60MiB ≤ 175MiB	bounds checks dashboard
✅	quality_gate_idle_all_features	intake_connections	10/10	3 = 3	bounds checks dashboard
✅	quality_gate_idle_all_features	memory_usage	10/10	491.36MiB ≤ 550MiB	bounds checks dashboard
✅	quality_gate_logs	intake_connections	10/10	3 ≤ 6	bounds checks dashboard
✅	quality_gate_logs	memory_usage	10/10	204.16MiB ≤ 220MiB	bounds checks dashboard
✅	quality_gate_logs	missed_bytes	10/10	0B = 0B	bounds checks dashboard
✅	quality_gate_metrics_logs	cpu_usage	10/10	357.51 ≤ 2000	bounds checks dashboard
✅	quality_gate_metrics_logs	intake_connections	10/10	4 ≤ 6	bounds checks dashboard
✅	quality_gate_metrics_logs	memory_usage	10/10	411.91MiB ≤ 475MiB	bounds checks dashboard
✅	quality_gate_metrics_logs	missed_bytes	10/10	0B = 0B	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_metrics_logs, bounds check missed_bytes: 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 intake_connections: 10/10 replicas passed. Gate passed.
quality_gate_metrics_logs, bounds check memory_usage: 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_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.
quality_gate_logs, bounds check missed_bytes: 10/10 replicas passed. Gate passed.
quality_gate_logs, 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.

…s metrics

…metrics, general cleanup

…s for cpu usage, remove unused mode enum, remove todos

Lewis-E · 2026-03-24T20:35:54Z

cmd/serverless-init/cloudservice/cloudrun.go

 		val := fnMetadata(httpClient, url)
 		metaChan <- keyVal{baseKey, val}
-		if isCloudRun {
+		if cloudRunType == CloudRunJob {


Nit, can be later: These two conditional branches aren't covered by unit tests, looks like?

cmd/serverless-init/cloudservice/cloudrun_jobs.go

cmd/serverless-init/cloudservice/appservice.go

cmd/serverless-init/cloudservice/cloudrun.go

cmd/serverless-init/enhanced-metrics/collector.go

Lewis-E · 2026-03-24T21:24:19Z

Ok, from the LLM comparison reviews, comes this chunk, which seems worth putting a test on:


  Go (calculateCPUUsage):
  valueDiff = currentTotal - previousTotal
  usage = valueDiff / timeDiff   (ns / s = nanocores)

  Rust (collect_and_submit):
  delta_ns = (current_usage_ns - last_usage_ns) as f64
  usage_rate_nc = delta_ns / elapsed_secs

 Same formula. But edge case handling differs:

* valueDiff <= 0  - Returns NaN (skips metric) - Skips interval, updates last_usage_ns 
* timeDiff <= 0 - Returns NaN (skips metric) - Not checked - Instant monotonically increases, so can't happen
* valueDiff == 0 exactly │ Returns NaN (discards zero-CPU intervals) - Rust would compute 0.0 and emit it                           

 Behavioral difference on valueDiff == 0: If a container is idle and has exactly 0 CPU delta, Go drops the data point (treats <= 0 as invalid), while Rust would emit 0.0. This could matter for dashboards — Go shows gaps during idle, Rust shows flat zero.

Behavioral difference on valueDiff < 0 (counter reset): Go returns NaN and does not update previousRateStats — the stale previous value persists, so the next interval will also likely be wrong (huge spike or another negative). Rust updates last_usage_ns to the current value, so it recovers cleanly on the next tick.

In the Go code: after a counter reset, it keeps the old previousTotal, so every subsequent collection computes (new_rising_value - old_high_value) which stays negative, producing NaN indefinitely until the counter climbs back above the old value. The Rust approach resets the baseline.

cmd/serverless-init/enhanced-metrics/collector.go

duncanpharvey · 2026-03-24T22:37:03Z

Ok, from the LLM comparison reviews, comes this chunk, which seems worth putting a test on:


  Go (calculateCPUUsage):
  valueDiff = currentTotal - previousTotal
  usage = valueDiff / timeDiff   (ns / s = nanocores)

  Rust (collect_and_submit):
  delta_ns = (current_usage_ns - last_usage_ns) as f64
  usage_rate_nc = delta_ns / elapsed_secs

 Same formula. But edge case handling differs:

* valueDiff <= 0  - Returns NaN (skips metric) - Skips interval, updates last_usage_ns 
* timeDiff <= 0 - Returns NaN (skips metric) - Not checked - Instant monotonically increases, so can't happen
* valueDiff == 0 exactly │ Returns NaN (discards zero-CPU intervals) - Rust would compute 0.0 and emit it                           

 Behavioral difference on valueDiff == 0: If a container is idle and has exactly 0 CPU delta, Go drops the data point (treats <= 0 as invalid), while Rust would emit 0.0. This could matter for dashboards — Go shows gaps during idle, Rust shows flat zero.

Behavioral difference on valueDiff < 0 (counter reset): Go returns NaN and does not update previousRateStats — the stale previous value persists, so the next interval will also likely be wrong (huge spike or another negative). Rust updates last_usage_ns to the current value, so it recovers cleanly on the next tick.

In the Go code: after a counter reset, it keeps the old previousTotal, so every subsequent collection computes (new_rising_value - old_high_value) which stays negative, producing NaN indefinitely until the counter climbs back above the old value. The Rust approach resets the baseline.

Behavioral difference on valueDiff < 0 (counter reset): Go returns NaN and does not update previousRateStats — the stale previous value persists, so the next interval will also likely be wrong (huge spike or another negative). Rust updates last_usage_ns to the current value, so it recovers cleanly on the next tick.

@Lewis-E On this point I believe the case is covered. I added a test to validate it here: 8d11b92. Let me know if there is another case that I'm missing!

apiarian-datadog

looks great! some nits but we can skip them or note them for a future refactor or something if you're not going to be making any more changes

apiarian-datadog · 2026-03-25T14:39:19Z

cmd/serverless-init/cloudservice/appservice.go

+	appServiceLegacyShutdownMetricName = "azure.appservice.enhanced.shutdown"
+	appServiceLegacyStartMetricName    = "azure.appservice.enhanced.cold_start"
+
+	appServiceUsageMetricName = "instance"


nit: this is a suffix, isn't it?

apiarian-datadog · 2026-03-25T14:42:12Z

cmd/serverless-init/cloudservice/cloudrun.go

 func (c *CloudRun) GetTags() map[string]string {
-	isCloudRun := c.spanNamespace == cloudRunService
-	tags := metadataHelperFunc(GetDefaultConfig(), isCloudRun)
+	isCloudRun := c.spanNamespace == cloudRunServiceTagPrefix


(not for this pr, but...) humph. what a funky bit of sneaky coupling =/

apiarian-datadog · 2026-03-25T14:44:06Z

cmd/serverless-init/cloudservice/cloudrun.go

 		metaChan <- keyVal{baseKey, val}
-		if isCloudRun {
-			metaChan <- keyVal{cloudRunService + baseKey, val}
+		if cloudRunType == CloudRunJob {


nit: why not a switch here? https://gobyexample.com/enums

apiarian-datadog · 2026-03-25T14:47:20Z

cmd/serverless-init/cloudservice/service.go

+}
+
+// CloudRunType identifies the GCP Cloud Run variant.
+type CloudRunType int


nit: since we print this out in some panic situations, might be worth using a string for this?

apiarian-datadog · 2026-03-25T14:57:09Z

cmd/serverless-init/main.go

+			enhancedMetricsCollector.Stop()
+		}
+
+		metricAgent.WaitForPendingSamples() // wait for worker to consume it


nit: are we also waiting for the metrics agent to consume the enhanced metrics? in this case is this "wait for worker to consume them"?

apiarian-datadog · 2026-03-25T14:58:23Z

pkg/config/setup/common_settings.go

 	config.SetDefault("serverless.enabled", false)
 	config.BindEnvAndSetDefault("serverless.logs_enabled", true)
-	config.BindEnvAndSetDefault("enhanced_metrics", true)
+	config.BindEnvAndSetDefault("enhanced_metrics", true, "DD_ENHANCED_METRICS_ENABLED")


nit: is this DD_SERVERLESS_INIT_ENHANCED_METRICS_ENABLED or something like that? or is a generic enhanced metrics flag okay?

There aren't enhanced metrics in non-serverless so I don't think we need to add SERVERLESS in the name to explicitly say that this setting is related to Serverless.

For what it's worth Lambda uses DD_ENHANCED_METRICS without SERVERLESS in the name. I added _ENABLED in the environment variable for Serverless Init so the naming consistent with other environment variables like DD_TRACE_ENABLED or DD_LOGS_ENABLED.

https://github.com/DataDog/datadog-lambda-extension/blob/a69ae6304b91554917be8f3ae17b255d454ed72b/bottlecap/src/metrics/enhanced/constants.rs#L50

…d to be consumed at shutdown

duncanpharvey · 2026-03-25T18:50:05Z

/merge

gh-worker-devflow-routing-ef8351 · 2026-03-25T18:50:10Z

View all feedbacks in Devflow UI.

2026-03-25 18:50:09 UTC ℹ️ Start processing command /merge

2026-03-25 18:50:15 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in main is approximately 2h (p90).

2026-03-25 19:25:34 UTC ℹ️ MergeQueue: This merge request was merged

### What does this PR do? Adds enhanced CPU metrics for Azure App Service Web Apps, Azure Container Apps, Google Cloud Run (Services, Functions, Jobs). ### Motivation https://datadoghq.atlassian.net/browse/SVLS-8356 ### Describe how you validated your changes Deployed to Azure Web Apps, Azure Container Apps, Google Cloud Run (Services, Functions, Jobs) using both in container and sidecar modes. ### Additional Notes #### Implementation Details - When the collector is started metrics are collected immediately, then with a collection interval of 3 seconds. The metrics aggregator has a bucket size of 10 seconds and the metrics agent flushes those buckets every 3 seconds. If there is a shutdown event, there is a final collection and flush of metrics with a partial interval. - CPU metrics are collected from cgroup v1 system files - Because the CPU metrics will not have a tag with a unique identifier for the instance they are sent from, they need to be sent as distribution metrics in order to avoid aggregation issues. - The usage metrics will have a unique identifier for instance or replica so these metrics will be submitted as gauge metrics to reduce internal costs. - A new `sidecar: <true|false>` tag will be added to enhanced metrics to identify if the metrics came from a sidecar container - Limited tag set consists of configured tags (`DD_TAGS`, `DD_EXTRA_TAGS`), base tags (`env`, `service`, `version`), cloud service specific tags, `datadog_init_version`, `datadog_sidecar_version`, and `sidecar` - Enhanced Metrics can are enabled by default and can be disabled with `DD_ENHANCED_METRICS_ENABLED=false` - Enhanced metrics added as part of this PR - these metrics have an updated prefix in order to align with the metric prefix of the corresponding cloud integration metrics. They also have a limited tag set instead of having all of the available tags that are added to traces, logs, and dogstatsd metrics . High cardinality tags will only be added to the `cpu.limit` metric. * `azure.app_services.enhanced.cpu.usage` * `azure.app_services.enhanced.cpu.limit` * `azure.app_services.enhanced.instance` * `azure.app_containerapp.enhanced.cpu.usage` * `azure.app_containerapp.enhanced.cpu.limit` * `azure.app_containerapp.enhanced.replica` * `gcp.run.container.enhanced.cpu.usage` * `gcp.run.container.enhanced.cpu.limit` * `gcp.run.container.enhanced.instance` - Legacy enhanced Metrics - these metrics will continue to be sent with the same full tag set for backwards compatibility. The metrics can be removed in a future major version update. * `azure.appservice.enhanced.cold_start` * `azure.appservice.enhanced.shutdown` * `azure.containerapp.enhanced.cold_start` * `azure.containerapp.enhanced.shutdown` * `gcp.run.enhanced.cold_start` * `gcp.run.enhanced.shutdown` * `gcp.run.enhanced.cold_start` * `gcp.run.enhanced.shutdown` - Updated enhanced metrics - these metrics have the same namespace but are updated to have a more limited tag set to be consistent with the other enhanced metrics as part of this PR. Google Cloud Run jobs is still in preview. * `gcp.run.job.enhanced.task.duration` * `gcp.run.job.enhanced.task.started` * `gcp.run.job.enhanced.task.ended` #### Other updates and fixes - Assign correct namespace for Google Cloud Run Jobs. Currently some tags are assigned under the `gcrfx` namespace. As a result, add `gcrj.container_id` as a high cardinality tag so it is excluded from metrics - `cloudService.GetStartMetricName()` refactored to `cloudService.AddStartMetric(metricAgent)` in order to accommodate prefix changes - Remove `cmd/serverless-init/metric/metric.go` and move into `pkg/serverless/metrics/metric.go` * Add separate methods for adding a legacy enhanced metric (full tag set), new enhanced metric (limited tag set), and a new enhanced metric with high cardinality tags (limited tag set, including high cardinality tags) - Refactor `MergeWithOverwrite` to accept multiple tag maps - Refactor `serverlessInitTag.GetBaseTagsMapWithMetadata` to `serverlessInitTag.GetBaseTagsMap` so it only handles setting base tags (`service`, `env`, `version`) - Set `use_v2_api.series` to `true` for metric agent so metric source is submitted correctly for gauge usage metric Co-authored-by: duncan.harvey <duncan.harvey@datadoghq.com>

dd-octo-sts bot added the internal Identify a non-fork PR label Mar 5, 2026

github-actions bot added the long review PR is complex, plan time to review it label Mar 5, 2026

duncanpharvey added the team/serverless-azure-gcp label Mar 5, 2026

dd-octo-sts bot added the team/agent-configuration label Mar 6, 2026

duncanpharvey added 23 commits March 6, 2026 17:21

prototype cpu metrics

333d802

clean up prototype, add to all cloud services, and refactor serverles…

757bad6

…s metrics

minor cleanup

2e8b071

update todo

50908f3

calculate rate directly and submit as distribution

7458451

refactor distribution metric calculation

d3afabe

fix manual rate calculation

b394e15

add todos

ded39f9

update debug logs and add todo

a99093c

add high cardinality tags to metrics from collector

33e36bc

move go routine to main, simplify cloud services, fix tagging

36b7d58

revert unnecessary changes, only start for init mode, add percentage …

dca195c

…metrics, general cleanup

fix errors

4e6d93c

fix linter errors

22753af

add new metric prefixes

8481d21

clean up collector go routine

7e02168

Use cloud run prefix for metrics common to cloud run and cloud run jobs

e82bf83

collect enhanced metrics from sidecar

2dd2b41

add todos

85c8acd

fix google cloud run job metric prefix, only add high cardinality tag…

bb5c7e5

…s for cpu usage, remove unused mode enum, remove todos

configure cpu usage for cloud run jobs

8cfea22

use subset of tags for enhanced metrics

0b82dd7

minor updates

029d552

Lewis-E reviewed Mar 24, 2026

View reviewed changes

default value of enhanced metric tags to unknown if empty string

34cc1f0

Lewis-E reviewed Mar 24, 2026

View reviewed changes

cmd/serverless-init/cloudservice/cloudrun_jobs.go Outdated Show resolved Hide resolved

apiarian-datadog reviewed Mar 24, 2026

View reviewed changes

Lewis-E reviewed Mar 24, 2026

View reviewed changes

cmd/serverless-init/enhanced-metrics/collector.go Show resolved Hide resolved

Lewis-E reviewed Mar 24, 2026

View reviewed changes

cmd/serverless-init/enhanced-metrics/collector.go Outdated Show resolved Hide resolved

duncanpharvey added 7 commits March 24, 2026 17:42

set cpu total to *uint64

116e88d

add unit test for google cloud run types and tag prefixes

2f1d5f4

assign metric names as constants next to metric prefix

701c403

update prefix naming and formatting to be consistent

98bea38

use fmt.Sprintf for panic message

271b910

use math.NaN when cpu limit can't be fetched

bb90831

add computeEnhancedMetrics test

8d11b92

duncanpharvey requested review from Lewis-E and apiarian-datadog March 25, 2026 14:26

Lewis-E approved these changes Mar 25, 2026

View reviewed changes

apiarian-datadog approved these changes Mar 25, 2026

View reviewed changes

duncanpharvey added 5 commits March 25, 2026 11:23

rename usage metric references to indicate it is a suffix

6860646

use switch statement for cloudRunType check

fe4d543

updated CloudRunType enum to string

f862b04

update metric agent comment to indicate multiple types of metrics nee…

c98126c

…d to be consumed at shutdown

use correct type for cloudRunType in panic message

2e2ef9f

gh-worker-dd-mergequeue-cf854d bot merged commit a1f24cb into main Mar 25, 2026
227 checks passed

gh-worker-dd-mergequeue-cf854d bot deleted the duncan-harvey/serverless-init-enhanced-cpu-metrics branch March 25, 2026 19:25

github-actions bot added this to the 7.79.0 milestone Mar 25, 2026

Conversation

duncanpharvey commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

Motivation

Describe how you validated your changes

Additional Notes

Implementation Details

Other updates and fixes

Uh oh!

agent-platform-auto-pr bot commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Files inventory check summary

Results for datadog-agent_7.79.0~devel.git.136.2e2ef9f.pipeline.104369606-1_amd64.deb:

Uh oh!

agent-platform-auto-pr bot commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Static quality checks

Info

Uh oh!

cit-pr-commenter-54b7da bot commented Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Regression Detector

Regression Detector Results

Optimization Goals: ✅ No significant changes detected

Experiments ignored for regressions

Fine details of change detection per experiment

Bounds Checks: ✅ Passed

Explanation

CI Pass/Fail Decision

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Lewis-E commented Mar 24, 2026

Uh oh!

Uh oh!

duncanpharvey commented Mar 24, 2026

Uh oh!

apiarian-datadog left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

duncanpharvey Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

duncanpharvey commented Mar 25, 2026

Uh oh!

gh-worker-devflow-routing-ef8351 bot commented Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

duncanpharvey commented Mar 5, 2026 •

edited

Loading

agent-platform-auto-pr bot commented Mar 5, 2026 •

edited

Loading

agent-platform-auto-pr bot commented Mar 5, 2026 •

edited

Loading

cit-pr-commenter-54b7da bot commented Mar 5, 2026 •

edited

Loading

duncanpharvey Mar 25, 2026 •

edited

Loading

gh-worker-devflow-routing-ef8351 bot commented Mar 25, 2026 •

edited

Loading