-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Post process e2e tests logs to make them more readable #31615
Conversation
Gitlab CI Configuration ChangesChanges Summary
ℹ️ Diff available in the job log. |
cd259a1
to
88dc105
Compare
Regression DetectorRegression Detector ResultsMetrics dashboard Baseline: 8d89378 Optimization Goals: ✅ No significant changes detected
|
perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
---|---|---|---|---|---|---|
➖ | quality_gate_logs | % cpu utilization | +1.97 | [-0.97, +4.92] | 1 | Logs |
➖ | file_tree | memory utilization | +0.48 | [+0.36, +0.60] | 1 | Logs |
➖ | file_to_blackhole_1000ms_latency_linear_load | egress throughput | +0.47 | [+0.01, +0.94] | 1 | Logs |
➖ | file_to_blackhole_1000ms_latency | egress throughput | +0.46 | [-0.33, +1.25] | 1 | Logs |
➖ | quality_gate_idle_all_features | memory utilization | +0.27 | [+0.16, +0.39] | 1 | Logs bounds checks dashboard |
➖ | uds_dogstatsd_to_api | ingress throughput | +0.01 | [-0.08, +0.11] | 1 | Logs |
➖ | tcp_dd_logs_filter_exclude | ingress throughput | -0.00 | [-0.01, +0.01] | 1 | Logs |
➖ | file_to_blackhole_100ms_latency | egress throughput | -0.02 | [-0.75, +0.72] | 1 | Logs |
➖ | file_to_blackhole_0ms_latency | egress throughput | -0.03 | [-0.92, +0.85] | 1 | Logs |
➖ | otel_to_otel_logs | ingress throughput | -0.04 | [-0.73, +0.65] | 1 | Logs |
➖ | file_to_blackhole_300ms_latency | egress throughput | -0.04 | [-0.67, +0.58] | 1 | Logs |
➖ | file_to_blackhole_0ms_latency_http1 | egress throughput | -0.05 | [-0.91, +0.81] | 1 | Logs |
➖ | file_to_blackhole_0ms_latency_http2 | egress throughput | -0.07 | [-0.88, +0.74] | 1 | Logs |
➖ | file_to_blackhole_500ms_latency | egress throughput | -0.36 | [-1.14, +0.41] | 1 | Logs |
➖ | quality_gate_idle | memory utilization | -0.40 | [-0.44, -0.35] | 1 | Logs bounds checks dashboard |
➖ | tcp_syslog_to_blackhole | ingress throughput | -0.78 | [-0.84, -0.72] | 1 | Logs |
➖ | uds_dogstatsd_to_api_cpu | % cpu utilization | -1.80 | [-2.51, -1.08] | 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 | memory_usage | 10/10 | bounds checks dashboard |
✅ | quality_gate_idle_all_features | memory_usage | 10/10 | bounds checks dashboard |
✅ | 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 lost_bytes: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_idle_all_features, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_idle, bounds check memory_usage: 10/10 replicas passed. Gate passed.
39103f4
to
0736aaf
Compare
tasks/new_e2e_tests.py
Outdated
color_message( | ||
"Too many logs to print, skipping pretty print. You can still find them properly organized in the job artifacts", | ||
"yellow", | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🥜 nitpick: I prefer to print WARNING: <message>
with WARNING
in yellow and the message as usual
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or maybe we can color all the message in bold?
[Fast Unit Tests Report] On pipeline 50699042 (CI Visibility). The following jobs did not run any unit tests: Jobs:
If you modified Go files and expected unit tests to run in these jobs, please double check the job logs. If you think tests should have been executed reach out to #agent-devx-help |
script: | ||
- inv -e new-e2e-tests.run --targets $TARGETS -c ddagent:imagePullRegistry=669783387624.dkr.ecr.us-east-1.amazonaws.com -c ddagent:imagePullUsername=AWS -c ddagent:imagePullPassword=$(aws ecr get-login-password) --junit-tar junit-${CI_JOB_ID}.tgz ${EXTRA_PARAMS} --test-washer | ||
- inv -e new-e2e-tests.run --targets $TARGETS -c ddagent:imagePullRegistry=669783387624.dkr.ecr.us-east-1.amazonaws.com -c ddagent:imagePullUsername=AWS -c ddagent:imagePullPassword=$(aws ecr get-login-password) --junit-tar junit-${CI_JOB_ID}.tgz ${EXTRA_PARAMS} --test-washer --logs-folder=$E2E_OUTPUT_DIR/logs --logs-post-processing --logs-post-processing-test-depth=$E2E_LOGS_PROCESSING_TEST_DEPTH |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💬 suggestion
What about parsing E2E_LOGS_PROCESSING_TEST_DEPTH
at python time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could, but I prefered to keep it as a parameter so it is more discoverable. Otherwise you can only use it if you know it exists
…/post-process-e2e-logs
Package size comparisonComparison with ancestor Diff per package
Decision✅ Passed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ADEL owned file lgtm
/merge |
Devflow running:
|
What does this PR do?
This PR add a step in e2e tests that will read the json output of e2e tests result. And parse it to produce the test logs in a format where they are not mixed all together.
If the logs are not too long they will be displayed directly in the PR logs with a dropdown: like here
If the logs are too long we do not display them directly in the logs to avoid deteriorating the logs output (collapsed lines still count in the limit of output size). We just indicate that all the logs can be found in job artifacts: like here + artifacts
The logs are always stored in the artifacts under
e2e-output/logs
The
E2E_LOGS_PROCESSING_TEST_DEPHT
allows you to configure the logs post processing.If the test use a single TestSuite and instantiate subtests to run different tests. Like
new-e2e-installer
does for example. You should increase this value, so it consider not only the parent test when splitting logsMotivation
Describe how to test/QA your changes
Possible Drawbacks / Trade-offs
Additional Notes