-
Notifications
You must be signed in to change notification settings - Fork 1.4k
[clusteragent/admission] Decouple default label selectors from APM opts #41977
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[clusteragent/admission] Decouple default label selectors from APM opts #41977
Conversation
Regression DetectorRegression Detector ResultsMetrics dashboard Baseline: dde380f Optimization Goals: ✅ No significant changes detected
|
| perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
|---|---|---|---|---|---|---|
| ❌ | docker_containers_cpu | % cpu utilization | +13.44 | [+11.66, +15.22] | 1 | Logs |
Fine details of change detection per experiment
| perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
|---|---|---|---|---|---|---|
| ❌ | docker_containers_cpu | % cpu utilization | +13.44 | [+11.66, +15.22] | 1 | Logs |
| ➖ | docker_containers_memory | memory utilization | +1.96 | [+1.47, +2.44] | 1 | Logs |
| ➖ | uds_dogstatsd_20mb_12k_contexts_20_senders | memory utilization | +0.67 | [+0.60, +0.75] | 1 | Logs |
| ➖ | ddot_metrics_sum_cumulative | memory utilization | +0.17 | [+0.05, +0.29] | 1 | Logs |
| ➖ | file_to_blackhole_0ms_latency | egress throughput | +0.08 | [-0.52, +0.68] | 1 | Logs |
| ➖ | ddot_logs | memory utilization | +0.07 | [+0.02, +0.13] | 1 | Logs |
| ➖ | file_to_blackhole_500ms_latency | egress throughput | +0.07 | [-0.55, +0.68] | 1 | Logs |
| ➖ | uds_dogstatsd_to_api | ingress throughput | +0.01 | [-0.22, +0.24] | 1 | Logs |
| ➖ | quality_gate_idle | memory utilization | +0.00 | [-0.03, +0.04] | 1 | Logs bounds checks dashboard |
| ➖ | tcp_dd_logs_filter_exclude | ingress throughput | +0.00 | [-0.01, +0.01] | 1 | Logs |
| ➖ | ddot_metrics_sum_delta | memory utilization | -0.00 | [-0.15, +0.15] | 1 | Logs |
| ➖ | file_to_blackhole_100ms_latency | egress throughput | -0.02 | [-0.63, +0.58] | 1 | Logs |
| ➖ | file_to_blackhole_1000ms_latency | egress throughput | -0.03 | [-0.63, +0.58] | 1 | Logs |
| ➖ | ddot_metrics | memory utilization | -0.13 | [-0.29, +0.04] | 1 | Logs |
| ➖ | tcp_syslog_to_blackhole | ingress throughput | -0.30 | [-0.37, -0.22] | 1 | Logs |
| ➖ | quality_gate_idle_all_features | memory utilization | -0.32 | [-0.37, -0.27] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_metrics_logs | memory utilization | -0.35 | [-0.56, -0.15] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_logs | % cpu utilization | -0.43 | [-3.20, +2.34] | 1 | Logs bounds checks dashboard |
| ➖ | otlp_ingest_metrics | memory utilization | -0.52 | [-0.64, -0.39] | 1 | Logs |
| ➖ | ddot_metrics_sum_cumulativetodelta_exporter | memory utilization | -0.53 | [-0.73, -0.33] | 1 | Logs |
| ➖ | file_tree | memory utilization | -0.58 | [-0.63, -0.52] | 1 | Logs |
| ➖ | otlp_ingest_logs | memory utilization | -0.97 | [-1.10, -0.84] | 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 | 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_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 memory_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 cpu_usage: 10/10 replicas passed. Gate passed.
- quality_gate_metrics_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 intake_connections: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check lost_bytes: 10/10 replicas passed. Gate passed.
Static quality checks✅ Please find below the results from static quality gates Successful checksInfo
|
e830bb2 to
c16f7cd
Compare
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
What does this PR do?
This PR moves APM-specific config options out of the default label selectors used in the DCA admission controller.
The default label selectors are used by 4 webhooks: APM, config, tags-from-labels, and kubernetes-admission-events. In the past, the config and tags-from-labels webhooks needed to run when APM was enabled. They're now decoupled, so this is no longer needed. The kubernetes-admission-events webhook was tied to APM by accident because it has nothing to do with APM.
This PR moves the current default label selectors to the APM webhook without changes and modifies the default ones used by the other 3 webhooks to avoid depending on APM config options.
Not sure if kubernetes-admission-events should check
mutate_unlabelledsince it validates rather than mutates. I'll keep the existing behavior for now.The APM label selector logic is unchanged. There may be other optimization opportunities, but I'm leaving those for injection-platform.
Describe how you validated your changes
CI and manual tests to verify that basic injection scenarios work as expected.