Add gateway usage for otel-agent #34435
Conversation
ogaca-dd
changed the title
ogaca-dd
added
changelog/no-changelog
qa/done
ogaca-dd
force-pushed
the
olivierg/gateway-usage-otel-agent
branch
from
e4956b4 to
1b798f2
Compare
…/gateway-usage-otel-agent
Uncompressed package size comparisonComparison with ancestor Diff per package
Decision |
Test changes on VMUse this command from test-infra-definitions to manually test this PR changes on a VM: dda inv aws.create-vm --pipeline-id=58834378 --os-family=ubuntuNote: This applies to commit 5e93a70 |
Static quality checks ✅Please find below the results from static quality gates Successful checksInfo
|
Regression DetectorRegression Detector ResultsMetrics dashboard Baseline: d2566ec Optimization Goals: ✅ No significant changes detected
|
| perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
|---|---|---|---|---|---|---|
| ➖ | quality_gate_logs | % cpu utilization | +0.77 | [-1.99, +3.53] | 1 | Logs |
| ➖ | uds_dogstatsd_to_api_cpu | % cpu utilization | +0.76 | [-0.06, +1.57] | 1 | Logs |
| ➖ | quality_gate_idle_all_features | memory utilization | +0.15 | [+0.09, +0.21] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_idle | memory utilization | +0.09 | [+0.02, +0.16] | 1 | Logs bounds checks dashboard |
| ➖ | file_to_blackhole_0ms_latency_http1 | egress throughput | +0.01 | [-0.83, +0.85] | 1 | Logs |
| ➖ | file_to_blackhole_0ms_latency_http2 | egress throughput | +0.01 | [-0.89, +0.90] | 1 | Logs |
| ➖ | tcp_dd_logs_filter_exclude | ingress throughput | +0.01 | [-0.01, +0.03] | 1 | Logs |
| ➖ | file_to_blackhole_1000ms_latency | egress throughput | +0.00 | [-0.77, +0.78] | 1 | Logs |
| ➖ | file_to_blackhole_300ms_latency | egress throughput | -0.00 | [-0.63, +0.62] | 1 | Logs |
| ➖ | uds_dogstatsd_to_api | ingress throughput | -0.01 | [-0.30, +0.27] | 1 | Logs |
| ➖ | file_to_blackhole_0ms_latency | egress throughput | -0.02 | [-0.81, +0.77] | 1 | Logs |
| ➖ | file_to_blackhole_100ms_latency | egress throughput | -0.03 | [-0.66, +0.61] | 1 | Logs |
| ➖ | tcp_syslog_to_blackhole | ingress throughput | -0.03 | [-0.09, +0.02] | 1 | Logs |
| ➖ | file_to_blackhole_500ms_latency | egress throughput | -0.13 | [-0.92, +0.66] | 1 | Logs |
| ➖ | file_tree | memory utilization | -0.21 | [-0.33, -0.10] | 1 | Logs |
| ➖ | file_to_blackhole_1000ms_latency_linear_load | egress throughput | -0.23 | [-0.70, +0.25] | 1 | Logs |
Bounds Checks: ✅ Passed
| perf | experiment | bounds_check_name | replicates_passed | links |
|---|---|---|---|---|
| ✅ | file_to_blackhole_0ms_latency | lost_bytes | 10/10 | |
| ✅ | file_to_blackhole_0ms_latency | memory_usage | 10/10 | |
| ✅ | file_to_blackhole_0ms_latency_http1 | lost_bytes | 10/10 | |
| ✅ | file_to_blackhole_0ms_latency_http1 | memory_usage | 10/10 | |
| ✅ | file_to_blackhole_0ms_latency_http2 | lost_bytes | 10/10 | |
| ✅ | file_to_blackhole_0ms_latency_http2 | memory_usage | 10/10 | |
| ✅ | file_to_blackhole_1000ms_latency | memory_usage | 10/10 | |
| ✅ | file_to_blackhole_1000ms_latency_linear_load | 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_300ms_latency | lost_bytes | 10/10 | |
| ✅ | file_to_blackhole_300ms_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 | |
| ✅ | quality_gate_logs | lost_bytes | 10/10 | |
| ✅ | quality_gate_logs | memory_usage | 10/10 |
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 memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check lost_bytes: 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_idle, bounds check intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_idle, bounds check memory_usage: 10/10 replicas passed. Gate passed.
…/gateway-usage-otel-agent
ogaca-dd
requested review from
jeremy-hanna,
IbraheemA,
liustanley and
hush-hush
There was a problem hiding this comment.
So, I see you've taken the time to create a component so the attribute could also be leveraged elsewhere in the codebase. The thing is I think the metric only makes sense in the context of the otel-agent (aka. the Collector), so I'm not sure if it's worth to componentize it and have it injected everywhere. We should maybe discuss if this is overkill and unneeded elsewhere.
cmd/serverless/main.go
Outdated
| @@ -128,7 +131,7 @@ func runAgent(tagger tagger.Component, compression logscompression.Component) { | |||
| wg.Add(3) | |||
|
|
|||
| go startTraceAgent(&wg, lambdaSpanChan, coldStartSpanId, serverlessDaemon, tagger, rcService) | |||
| go startOtlpAgent(&wg, metricAgent, serverlessDaemon, tagger) | |||
| go startOtlpAgent(&wg, metricAgent, serverlessDaemon, tagger, gatewayUsage) | |||
There was a problem hiding this comment.
Serverless could never be a gateway, so this isn't really required at all here.
In general I feel like this metric should only be coming from the OTel Collector (aka otel-agent) but not necessarily other processes with some OTel processing capabilities like serverless or the trace-agent, etc. We should maybe discuss.
There was a problem hiding this comment.
Good to know. My understand was that it should be sent for serverless and OTLP.
I created a component for several reasons:
That said, if gateway usage is strictly limited to the OTel agent, there’s no strong reason to keep it as a component, and I should remove it. |
|
Just formal confirmation that the gateway usage metric is only to be expected in the Collectors (both embedded and OSS), but not in the OTLP ingests we see in the trace-agent or serverless. I'm not sure if the component is still needed in those cases, but indeed I would avoid making the change larger than necessary. |
Serverless Benchmark Results
tl;drUse these benchmarks as an insight tool during development.
What is this benchmarking?The The benchmark is run using a large variety of lambda request payloads. In the charts below, there is one row for each event payload type. How do I interpret these charts?The charts below comes from The benchstat docs explain how to interpret these charts.
I need more helpFirst off, do not worry if the benchmarks are failing. They are not tests. The intention is for them to be a tool for you to use during development. If you would like a hand interpreting the results come chat with us in Benchmark stats |
There was a problem hiding this comment.
Had a short conversation to make sure it makes sense that indeed the gatewayusage is leveraged in all the DD exporters (traces, logs, metrics), and it does seem to make sense because we can't guarantee any single signal type will be exporter. This looks good 👍
…package. Update references from attributes.GatewayUsage to otel.GatewayUsage for improved nil handling
Go Package Import DifferencesBaseline: d2566ec
|
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
What does this PR do?
This PR introduces gateway usage for the otel-agent. For more context, refer to open-telemetry/opentelemetry-collector-contrib#37499.
The
datadog.otel.gatewaymetrics is now sent for OTLP metrics, traces, and logs by the otel-agent. Additionally, it is also sent for OTLP metrics when using OTLP ingestion, but not for traces and logs.Motivation
Describe how you validated your changes
The following commands generates the metric datadog.otel.gateway at 1
Same tests were performed for traces and for logs.
Possible Drawbacks / Trade-offs
Additional Notes