fix(dogstatsd): change stream handler task name to avoid unbounded cardinality#1899
Conversation
Binary Size Analysis (Agent Data Plane)Baseline: ed28518 · Comparison: 17d7737 · diff ✅ Binary size difference within thresholdChanges by Module
Detailed Symbol Changes |
Regression Detector (Agent Data Plane)Run ID: Optimization Goals: ✅ No significant changes detectedFine details of change detection per experiment (35)Experiments configured
Bounds Checks: ✅ Passed (5)
ExplanationA change is flagged as a regression when |Δ mean %| > 5.00% in the regressing direction for its optimization goal AND SMP marks the experiment as a regression ( |
…rdinality (#1899) ## Summary As stated in the PR title. For DSD stream handlers tasks, we were naming them like so: `dogstatsd-stream-handler-{}-{}`, where the first portion was the listener type (`udp`, `unix`, etc) and the second was a "stream index.". For UDP and UDS datagram, this basically meant a single value: zero. For UDS streams, however, this value would grow over time as new connections were established. On systems with a high volume of connect churn, this can lead to a number of orphaned metrics where the task name is used as a tag, thus creating a unique metric... which in turn becomes a memory leak, and CPU hog as more and more metrics have to be processed, copied during map resizes, and so on. While we'd like to solve the problem of orphaned metrics not being automatically cleaned up, we're making a tactical fix here since the unbounded cardinality being removed will solve our immediate problem of said memory leakage. ## Change Type - [x] Bug fix - [ ] New feature - [ ] Non-functional (chore, refactoring, docs) - [ ] Performance ## How did you test this PR? - Manual local testing. ## References DADP-2 Co-authored-by: toby.lawrence <toby.lawrence@datadoghq.com> aeda7d8
…rdinality (backport #1899 to 1.2.x) (#1902) ## Summary Backport of #1899 to the `releases/1.2.x` line. ## Backport notes Our cherry pick of `aeda7d87a1bd7acc0f00e35d993862dc45c1a32d` didn't apply cleanly itself but the diff we have here is identical to the diff in the original PR. ## Change Type - [x] Bug fix - [ ] New feature - [ ] Non-functional (chore, refactoring, docs) - [ ] Performance ## How did you test this PR? - Manual local testing (original PR). - `cargo check -p saluki-components` on the backport branch. ## References DADP-2 Co-authored-by: toby.lawrence <toby.lawrence@datadoghq.com>
## Summary Bumps the `agent-data-plane` crate version from `1.2.1` to `1.2.2`. This release contains the backport of #1899 (DSD stream-handler task-name cardinality fix), landed via #1902. ## Change Type - [ ] Bug fix - [ ] New feature - [x] Non-functional (chore, refactoring, docs) - [ ] Performance ## How did you test this PR? N/A ## References DADP-2 Co-authored-by: toby.lawrence <toby.lawrence@datadoghq.com>
Summary
As stated in the PR title.
For DSD stream handlers tasks, we were naming them like so:
dogstatsd-stream-handler-{}-{}, where the first portion was the listener type (udp,unix, etc) and the second was a "stream index.". For UDP and UDS datagram, this basically meant a single value: zero. For UDS streams, however, this value would grow over time as new connections were established.On systems with a high volume of connect churn, this can lead to a number of orphaned metrics where the task name is used as a tag, thus creating a unique metric... which in turn becomes a memory leak, and CPU hog as more and more metrics have to be processed, copied during map resizes, and so on.
While we'd like to solve the problem of orphaned metrics not being automatically cleaned up, we're making a tactical fix here since the unbounded cardinality being removed will solve our immediate problem of said memory leakage.
Change Type
How did you test this PR?
References
DADP-2