-
Notifications
You must be signed in to change notification settings - Fork 9
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[PROF-7645] Add support for attaching internal metadata in profiling …
…export (#181) * [PROF-7645] Add support for attaching internal metadata in profiling exporter **What does this PR do?**: This PR adds support for attaching internal metadata to profiles sent via the profiling exporter. This is a (small) breaking API change, since the signatures of both `ProfileExporter::build` and `ddog_prof_Exporter_Request_build` now take an extra argument. FYI if you're upgrading libdatadog, you'll probably want to supply `None` / `null` until in the future you figure out that you want to send internal metadata. **Motivation**: The intention of this internal metadata is to allow profilers to attach extra pieces of information to profiles that are not very interesting to show to customers by default (such as Ruby's "no_signal_workaround_enabled" or Go's "execution_trace_enabled"). For more details on this, check the Datadog internal "RFC: Attaching internal metadata to pprof profiles". **Additional Notes**: Design-wise, I could've gone in a few different directions for: a. How to represent the internal metadata in `ProfileExporter::build` b. How to represent the internal metadata across the FFI in `ddog_prof_Exporter_Request_build` Starting with a: Since the information is going to be represented in JSON, I opted to "leak" this implementation detail by making the parameter a `serde_json::Value`. This means that callers can take full advantage of JSON to send whatever they want (e.g. nested objects, types other than string, etc), rather than being constrained to some smaller subset (e.g. if I imposed a list of pairs of strings). This seemed a reasonable trade-off; I don't expect we'll go away from JSON for encoding this info anytime soon, and even if we do, we can always put a JSON string inside whatever we end up going with. Concerning b: Getting complex types across the FFI boundary is really really really annoying, for both libdatadog (which needs to expose a bunch of types, and handle them), and the caller (which needs to think about how they're going to manage lifetimes and whatnot of the whole thing). To avoid this, I chose to instead represent the parameter as a raw JSON string across the FFI. This allows ffi users the same expressiveness as Rust users in terms of what they can send as internal metadata, with the trade-off that ffi callers need to serialize their stuff as JSON and libdatadog needs to deserialize it again. Since internal metadata is something that gets passed along only once per minute AND it's not expected to have high complexity, I think the small overhead of throwing JSON strings across the ffi boundary is worth the simplification to code on both sides. **How to test the change?**: I have expanded the tests to test the `event.json` file, including the new parameter. You should shortly see linked in this PR the Ruby PR to make use of this feature to send the `no_signal_workaround_enabled` parameter. * Make rustfmt happy * Add comment asking people to track usage of internal_metadata parameter * Minor: Fix comment using wrong name for variable
- Loading branch information
Showing
6 changed files
with
282 additions
and
16 deletions.
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.