Add DogStatsD Package#606
Conversation
This reverts commit 7dc9799.
|
Currently the sidecar crate is using cadence for its dogstatsd needs. Maybe, as a first use case, and to show the crate working properly, the sidecar might be switched over to this crate? |
|
@bwoebi The original motivation for this is to use this dogstatsd crate in the serverless so I've done some initial testing to confirm that it works there. But the sidecar can definitely be switched over to use this crate as well! I should have this PR ready to review soon once I get CI passing. |
|
Ah, I'm seeing you're using 1.77.2. We're currently locked in php to use at most rust 1.76.0 until the next alpine release. |
c8a3b98 to
14241de
Compare
14241de to
ddb3fc0
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #606 +/- ##
==========================================
+ Coverage 72.69% 73.18% +0.48%
==========================================
Files 246 252 +6
Lines 34990 35959 +969
==========================================
+ Hits 25437 26317 +880
- Misses 9553 9642 +89
🚀 New features to boost your workflow:
|
|
I'd like to avoid bumping the rust version but I'm running into these errors on versions below
Update: I forked saluki into https://github.com/DataDog/saluki-backport and replaced |
|
|
||
| [dependencies] | ||
| datadog-protos = { version = "0.1.0", default-features = false, git = "https://github.com/DataDog/saluki-backport/" } | ||
| ddsketch-agent = { version = "0.1.0", default-features = false, git = "https://github.com/DataDog/saluki-backport/" } |
There was a problem hiding this comment.
We already have a ddsketch implementation in libdatadog, there is one in mp-rs and there is one on crates.io that is not owned by DD. We should probably all agree on a single implementation.
There was a problem hiding this comment.
Interesting, this package uses the same implementation used by the Datadog Lambda Extension (owned by the Serverless team). Since I intend to use this DogStatsD package for a Serverless solution in Azure I'm inclined to stay consistent with the implementations.
https://github.com/DataDog/datadog-lambda-extension/tree/main/bottlecap/src/metrics
There was a problem hiding this comment.
I tried to remove the duplication but I read that this one is slightly different and optimized for the agent. So it might be not possible
https://github.com/DataDog/saluki/blob/main/lib/ddsketch-agent/src/lib.rs#L149
/// This implementation is subtly different from the open-source implementations of
DDSketch, as Datadog made some
/// slight tweaks to configuration values and in-memory layout to optimize it for insertion performance within the
/// agent.
There was a problem hiding this comment.
slight tweaks to configuration values and in-memory layout to optimize it for insertion performance within the agent.
I'm not familiar with sketches, but optimizing in-memory layout and optimizing for insertion performance also sound relevant to a library, if it is feasible. Any insight as to whether it's appropriate or not?
There was a problem hiding this comment.
I am afraid I did not understand your question, can you elaborate more?
There was a problem hiding this comment.
👋🏻
I'm the original author of the ported DDSketch implementation being used here. As the doc comments allude to, the main goal of the port was to maintain fidelity with the Agent's own DDSketch implementation, which at the time (and to this day) is not based on the open-source Go implementation of DDSketch.
I didn't write the original Agent-specific implementation, so I can't speak to all of the decisions made there, but I also tried to port over some of the code comments to, again, maintain fidelity with the Agent implementation.
While it probably behooves us, in a general sense, to have One True Implementation in Rust... maintaining compatibility with the Datadog Agent in the most important factor in this case.
be204a6 to
ddac4ee
Compare
morrisonlevi
left a comment
There was a problem hiding this comment.
Does this spawn any threads on the client side of things? I see a test server which probably does, and that's okay. I scanned through it, but it's a big PR so I may have missed something.
Most languages need to have control over threads so they can mask off appropriate signals, register them with the runtime, etc, so the libraries generally need to design APIs that don't spawn threads.
@morrisonlevi Correct, the only thread spawned is in the test. libdatadog/dogstatsd/tests/integration_test.rs Lines 83 to 85 in 5d181a0 |
* feat: upstream dogstatsd from datadog lambda extension * add: stand alone dogstatsd binary as example * fix: imports * fix: make test utils public * fix: more test utils public * fix: make entry public * fix: clippy * fix: make test config public * Revert "fix: make test config public" This reverts commit 7dc9799. * fix: make fields public for tests and assertions * use reqwest 0.12.4 in Cargo.lock * add copyright headers * apply formatting * update license * upgrade rust to 1.77.2 * install protoc binary for lint, test, and miri workflows * install protoc binary for cross on centos7 * add dogstatsd to alpine build and upgrade alpine version * install protoc binary for coverage * use rust 1.76.0 and forked saluki-backport repo * remove package specific toolchain * refactor protoc install script to pass install path as an argument * install protoc for benchmark ci job * remove unzip install since it is now part of base image * add dogstatsd integration test * fix license * fix merge * fix lint error * use localhost address for dogstatsd test * use port 18125 for dogstatsd test * disable dogstatsd test for miri * dogstatsd cleanup * fix license * fix merge conflicts * update alpine base image to 3.19.3 --------- Co-authored-by: alexgallotta <5581237+alexgallotta@users.noreply.github.com>
What does this PR do?
Adds the package
dogstatsd, a DogStatsD server which uses Saluki for distribution metrics.Moved upstream from https://github.com/DataDog/datadog-lambda-extension/tree/main/bottlecap/src/metrics
Motivation
Add a DogStatsD server that will allow the Serverless Mini Agent to send runtime and custom metrics from Azure Spring Apps and Azure Functions (to be done in an upcoming PR).
https://datadoghq.atlassian.net/browse/SVLS-5177
Additional Notes
1.71.1to1.76.0-> changes moved to Upgrade to Rust 1.76.0 #612error[E0445]: crate-private trait MapFieldAccessor in public interfaceon1.71.1,1.72.0,1.73.0error[E0658]: use of unstable library feature 'round_ties_even'on1.74.0,1.75.0,1.76.0round_ties_even()withround()reqwest 0.12.4reqwest 0.12.5=>no process-level CryptoProvider available -- call CryptoProvider::install_default() before this pointlint,test, andmiriworkflowsbashshell when running test commands soPATHis picked up properly in Windowsdogstatsdadded to Alpine Dockerfile3.19.3to work with Rust1.76.0invalid_reference_castinginstead ofclippy::cast_ref_to_mutHow to test the change?