[SVLS-6367] Update Step Function Trace Context #34264
Conversation
…onata-based context objects
Test changes on VMUse this command from test-infra-definitions to manually test this PR changes on a VM: inv aws.create-vm --pipeline-id=56943243 --os-family=ubuntuNote: This applies to commit 12c3cbd |
Uncompressed package size comparisonComparison with ancestor Diff per package
Decision✅ Passed |
Static quality checks ✅Please find below the results from static quality gates Successful checksInfo
|
Regression DetectorRegression Detector ResultsMetrics dashboard Baseline: 4eb26be Optimization Goals: ✅ No significant changes detected
|
| perf | experiment | goal | Δ mean % | Δ mean % CI | trials | links |
|---|---|---|---|---|---|---|
| ➖ | uds_dogstatsd_to_api_cpu | % cpu utilization | +2.94 | [+2.04, +3.84] | 1 | Logs |
| ➖ | file_tree | memory utilization | +0.25 | [+0.19, +0.31] | 1 | Logs |
| ➖ | file_to_blackhole_1000ms_latency_linear_load | egress throughput | +0.20 | [-0.27, +0.67] | 1 | Logs |
| ➖ | file_to_blackhole_1000ms_latency | egress throughput | +0.02 | [-0.75, +0.79] | 1 | Logs |
| ➖ | file_to_blackhole_0ms_latency_http2 | egress throughput | +0.02 | [-0.79, +0.82] | 1 | Logs |
| ➖ | uds_dogstatsd_to_api | ingress throughput | +0.01 | [-0.29, +0.31] | 1 | Logs |
| ➖ | file_to_blackhole_0ms_latency_http1 | egress throughput | +0.00 | [-0.82, +0.83] | 1 | Logs |
| ➖ | tcp_dd_logs_filter_exclude | ingress throughput | -0.00 | [-0.03, +0.03] | 1 | Logs |
| ➖ | file_to_blackhole_300ms_latency | egress throughput | -0.00 | [-0.63, +0.63] | 1 | Logs |
| ➖ | file_to_blackhole_0ms_latency | egress throughput | -0.01 | [-0.84, +0.83] | 1 | Logs |
| ➖ | file_to_blackhole_100ms_latency | egress throughput | -0.01 | [-0.62, +0.60] | 1 | Logs |
| ➖ | quality_gate_idle_all_features | memory utilization | -0.03 | [-0.08, +0.02] | 1 | Logs bounds checks dashboard |
| ➖ | quality_gate_idle | memory utilization | -0.06 | [-0.11, -0.02] | 1 | Logs bounds checks dashboard |
| ➖ | file_to_blackhole_500ms_latency | egress throughput | -0.11 | [-0.89, +0.68] | 1 | Logs |
| ➖ | quality_gate_logs | % cpu utilization | -0.30 | [-3.15, +2.55] | 1 | Logs |
| ➖ | tcp_syslog_to_blackhole | ingress throughput | -0.81 | [-0.87, -0.75] | 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_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_logs, bounds check memory_usage: 10/10 replicas passed. Gate passed.
- quality_gate_logs, bounds check lost_bytes: 10/10 replicas passed. Gate passed.
- quality_gate_logs, 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_idle, bounds check intake_connections: 10/10 replicas passed. Gate passed.
github-actions
bot
added
long review
avedmala
added
qa/done
github-actions
bot
added
long review
|
/trigger-ci --variable RUN_ALL_BUILDS=true --variable RUN_KITCHEN_TESTS=true --variable RUN_E2E_TESTS=on --variable RUN_UNIT_TESTS=on --variable RUN_KMT_TESTS=on |
|
View all feedbacks in Devflow UI.
Started pipeline #56646487 |
| if !lp.DetectLambdaLibrary() && lp.InferredSpansEnabled { | ||
| lp.GetInferredSpan().EnrichInferredSpanWithLambdaFunctionURLEvent(event) | ||
| } | ||
| lp.addTag(tagFunctionTriggerEventSource, functionURL) | ||
| lp.addTag(tagFunctionTriggerEventSourceArn, fmt.Sprintf("arn:aws:lambda:%v:%v:url:%v", region, accountID, functionName)) | ||
| lp.addTags(trigger.GetTagsFromLambdaFunctionURLRequest(event)) | ||
| } | ||
|
|
||
| func (lp *LifecycleProcessor) initFromStepFunctionPayload(event events.StepFunctionPayload) { | ||
| lp.requestHandler.event = event |
There was a problem hiding this comment.
This value is never being used, the Event() interface{} in lifecycle.go was probably used by something before but not anymore so I removed both
| } | ||
|
|
||
| // genericUnmarshal helps extract fields from _datadog. | ||
| func genericUnmarshal(data []byte, fieldMap map[string]interface{}) error { |
There was a problem hiding this comment.
The custom unmarshaler is a consequence of how I defined the types above.
For example, the StepFunctionPayload should be at the same top-level as the RootExecutionID and ServerlessVersion for type NestedStepFunctionPayload if we want to follow how the JSON payloads look.
But, I liked this nested approach so that we can deal with this shared context object the exact same way in all cases in carriers.go. We can simply pass the whole payload into extractTraceContextFromStepFunctionContext() without needing to deal with each case separately.
Happy to change this but this way felt cleaner overall. The unmarshaler is also easy to edit if we want to include more arguments in the future.
| } | ||
| ev = eventPayload | ||
| case trigger.LegacyLambdaRootStepFunctionEvent: | ||
| var event events.StepFunctionEvent[events.LambdaRootStepFunctionPayload] |
There was a problem hiding this comment.
It felt a little repetitive to repeat the whole case for every "legacy lambda" case when in reality the only difference is the whole payload is wrapped in a "Payload": {...}
But the alternative was to parse out this Payload somewhere upstream so we treat legacy vs non-legacy the same here. We're basically doing the same thing because the extractors won't know the difference. I also didn't want to modify the value as it's being passed down
| return nil, errorNoStepFunctionContextFound | ||
| } | ||
|
|
||
| tc, err := extractTraceContextFromStepFunctionContext(event.Payload) |
There was a problem hiding this comment.
Being able to do this is why I liked the custom unmarshal route, otherwise we'd need to be dynamic about types to create some shared handler or parse out each of the values for each function here and in extractTraceContextFromLambdaRootStepFunctionContext()
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 |
What does this PR do?
Updates the creation of trace context from a Step Function execution's context object to...
State.RetryCountandExecution.RedriveCountfor inferable parent ID generation in a backwards compatible manner (related to Update Step Functions Parent ID Generation datadog-lambda-python#559)Motivation
Bring feature parity from Node and Python layers to the Universal runtimes
State.RetryCountthe other values we use for the hash are identical across triesTwo things worth looking at for context:
Describe how you validated your changes
WIP - Will build the extension and tested it manually with a Step Function in our sandbox account
Possible Drawbacks / Trade-offs
Additional Notes