[RC] Support alternative ALPN protocol for websocket tests#49597
[RC] Support alternative ALPN protocol for websocket tests#49597
Conversation
To bypass hostile proxies the agent is going to negotiate a custom ALPN value (dd-rc-v1) during the TLS handshake so meshes cannot match the connection to any HTTP route and forwards it as opaque TCP, bypassing the streaming time length limitation.
Add unit tests to verify the new ALPN websocket functions exist and are accessible. Tests cover newWebSocketClientWithALPN, runEchoLoopWithALPN, and runWebSocketTestWithALPN functions. Full end-to-end ALPN protocol testing requires backend server support for dd-rc-v1 protocol negotiation. RC-3097
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7f4cd9271f
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
ALPN protocol negotiation only works during TLS handshake. When remote_configuration.no_tls is true, the websocket connection uses plain ws:// instead of wss://, making ALPN negotiation impossible. Previously the test would run as a duplicate plain websocket test but log misleading ALPN-specific messages. Now the test is skipped with a clear error message when TLS is disabled. Changes: - Return error from newWebSocketClientWithALPN when URL scheme is http - Update runWebSocketTestWithALPN to distinguish skip vs failure in logs - Add strings import to ping_pong.go RC-3097
domodwyer
left a comment
There was a problem hiding this comment.
We should DRY this with the other impl - it's only 1 line of difference in config (setting the ALPN).
Files inventory check summaryFile checks results against ancestor fe5f79fe: Results for datadog-agent_7.80.0~devel.git.53.f35283e.pipeline.108593864-1_amd64.deb:No change detected |
Regression DetectorRegression Detector ResultsMetrics dashboard Baseline: fe5f79f Optimization Goals: ✅ No significant changes detected
|
| perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
|---|---|---|---|---|---|---|
| ➖ | docker_containers_cpu | % cpu utilization | +1.14 | [-1.82, +4.11] | 1 | Logs |
Fine details of change detection per experiment
| perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
|---|---|---|---|---|---|---|
| ➖ | quality_gate_metrics_logs | memory utilization | +1.31 | [+1.08, +1.54] | 1 | Logs bounds checks dashboard |
| ➖ | docker_containers_cpu | % cpu utilization | +1.14 | [-1.82, +4.11] | 1 | Logs |
| ➖ | tcp_syslog_to_blackhole | ingress throughput | +1.03 | [+0.87, +1.19] | 1 | Logs |
| ➖ | uds_dogstatsd_20mb_12k_contexts_20_senders | memory utilization | +0.39 | [+0.32, +0.45] | 1 | Logs |
| ➖ | docker_containers_memory | memory utilization | +0.24 | [+0.15, +0.32] | 1 | Logs |
| ➖ | ddot_logs | memory utilization | +0.20 | [+0.14, +0.26] | 1 | Logs |
| ➖ | ddot_metrics_sum_cumulativetodelta_exporter | memory utilization | +0.18 | [-0.04, +0.40] | 1 | Logs |
| ➖ | ddot_metrics_sum_delta | memory utilization | +0.12 | [-0.05, +0.30] | 1 | Logs |
| ➖ | otlp_ingest_logs | memory utilization | +0.10 | [-0.00, +0.21] | 1 | Logs |
| ➖ | file_to_blackhole_0ms_latency | egress throughput | +0.10 | [-0.43, +0.62] | 1 | Logs |
| ➖ | file_to_blackhole_100ms_latency | egress throughput | +0.09 | [-0.03, +0.22] | 1 | Logs |
| ➖ | tcp_dd_logs_filter_exclude | ingress throughput | +0.00 | [-0.10, +0.10] | 1 | Logs |
| ➖ | uds_dogstatsd_to_api | ingress throughput | -0.00 | [-0.21, +0.21] | 1 | Logs |
| ➖ | uds_dogstatsd_to_api_v3 | ingress throughput | -0.01 | [-0.23, +0.20] | 1 | Logs |
| ➖ | file_to_blackhole_500ms_latency | egress throughput | -0.01 | [-0.41, +0.38] | 1 | Logs |
| ➖ | file_tree | memory utilization | -0.05 | [-0.11, +0.00] | 1 | Logs |
| ➖ | file_to_blackhole_1000ms_latency | egress throughput | -0.08 | [-0.52, +0.37] | 1 | Logs |
| ➖ | otlp_ingest_metrics | memory utilization | -0.16 | [-0.32, -0.00] | 1 | Logs |
| ➖ | quality_gate_idle | memory utilization | -0.19 | [-0.25, -0.14] | 1 | Logs bounds checks dashboard |
| ➖ | ddot_metrics | memory utilization | -0.37 | [-0.54, -0.19] | 1 | Logs |
| ➖ | quality_gate_logs | % cpu utilization | -0.44 | [-2.09, +1.20] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_idle_all_features | memory utilization | -0.45 | [-0.48, -0.41] | 1 | Logs bounds checks dashboard |
| ➖ | ddot_metrics_sum_cumulative | memory utilization | -0.69 | [-0.85, -0.54] | 1 | Logs |
Bounds Checks: ✅ Passed
| perf | experiment | bounds_check_name | replicates_passed | observed_value | links |
|---|---|---|---|---|---|
| ✅ | docker_containers_cpu | simple_check_run | 10/10 | 567 ≥ 26 | |
| ✅ | docker_containers_memory | memory_usage | 10/10 | 275.96MiB ≤ 370MiB | |
| ✅ | docker_containers_memory | simple_check_run | 10/10 | 705 ≥ 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.24GiB ≤ 1.20GiB | |
| ✅ | file_to_blackhole_1000ms_latency | missed_bytes | 10/10 | 0B = 0B | |
| ✅ | file_to_blackhole_100ms_latency | memory_usage | 10/10 | 0.20GiB ≤ 1.20GiB | |
| ✅ | file_to_blackhole_100ms_latency | missed_bytes | 10/10 | 0B = 0B | |
| ✅ | file_to_blackhole_500ms_latency | memory_usage | 10/10 | 0.22GiB ≤ 1.20GiB | |
| ✅ | file_to_blackhole_500ms_latency | missed_bytes | 10/10 | 0B = 0B | |
| ✅ | quality_gate_idle | intake_connections | 10/10 | 4 = 4 | bounds checks dashboard |
| ✅ | quality_gate_idle | memory_usage | 10/10 | 176.58MiB ≤ 181MiB | bounds checks dashboard |
| ✅ | quality_gate_idle_all_features | intake_connections | 10/10 | 4 = 4 | bounds checks dashboard |
| ✅ | quality_gate_idle_all_features | memory_usage | 10/10 | 497.70MiB ≤ 550MiB | bounds checks dashboard |
| ✅ | quality_gate_logs | intake_connections | 10/10 | 4 ≤ 6 | bounds checks dashboard |
| ✅ | quality_gate_logs | memory_usage | 10/10 | 206.32MiB ≤ 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.02 ≤ 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 | 423.81MiB ≤ 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 intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_idle, 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 memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check missed_bytes: 10/10 replicas passed. Gate passed.
- quality_gate_idle_all_features, 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.
Merge newWebSocketClient and newWebSocketClientWithALPN into single function with ALPNMode enum parameter. This reduces code duplication where two functions differed only in ALPN configuration. Add ALPNMode type with ALPN_Default and ALPN_DD_RC constants to specify whether to use dd-rc-v1 ALPN protocol negotiation.
Check URL scheme upfront to determine if TLS is enabled instead of running the test and parsing error strings. This avoids fragile error message comparison and fails fast when TLS is not available. ALPN protocol requires TLS, so skip the test early if the base URL uses http scheme.
Define alpnProtocolDDRC constant for the dd-rc-v1 ALPN protocol identifier instead of using hardcoded strings throughout the code. This centralizes the protocol name and makes it easier to maintain. The constant is used in TLS configuration and log messages.
Add new websocket test that negotiates dd-rc-v1 ALPN protocol during TLS handshake. This allows the agent to bypass hostile proxies and meshes that enforce streaming time limitations by making the connection appear as opaque TCP rather than HTTP.
The agent now runs two websocket echo tests in parallel:
Both tests use the same endpoint and test logic. The server distinguishes between them via ALPN protocol tags in metrics, enabling separate monitoring of each connection type.
Changes are backward compatible. Existing tests continue to work unchanged.
RC-3097