-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[datadogexporter] Send host metadata #1351
Conversation
Set it to false in tests to avoid creating goroutines
The backend will add these tags since they are sent with metadata
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.
lgtm 👍 , we may need to update the example and test yaml though?
(disregard the bit about needing to update the yaml, lgtm) |
Reusing the `GetTags` function for this since this PR leaves it without use
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.
LGTM, left a few nits
Fix documentation comments Co-authored-by: Kylian Serrania <kylian.serrania@datadoghq.com>
This is now reviewable by maintainers (the previous two reviewers are from Datadog). |
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.
Is this not a duplicate of the https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/master/processor/resourcedetectionprocessor? why do we have duplicate functionality? Can you use that?
@bogdandrutu No: there is some overlap on the information this PR and the resource detector gather, but at least some goals are different. This PR aims to
We use metadata from 1.a to make sure that host names that refer to the same host are identified as such, since this impacts usability and billing. This is not covered by the resource detection processor: it sends data to Datadog and it is not attached to metrics/traces. 1.b and 1.c are not related to EC2 in any way. Aim (2) could be covered by the resource detection processor (and I want to open a PR to make use of the metadata set by that component in the future), but, since we had the EC2 information available from (1), I thought it made sense to add it here too: for usability we must send telemetry data with some hostname so this would be a last resort mechanism to get a coherent hostname. |
@mx-psi please at least consider to create an issue, to understand how can we remove duplicate code, and how can we share the functionality at least between the processor and this exporter. Once the issue is created and assign to you :) I will merge this :) |
@bogdandrutu one thing to note here is that, even if a processor could do all of these things, the issue is that exporters can not create/control processors (or other components) on their own. It requires user configuration. And in general asking users to setup multiple pieces of a pipeline increases the room for error/mistakes. Something to keep in mind as I think i've seen a few use cases now where it would be nice to have an option that would allow exporters to have more control over the whole pipeline. |
@ericmustin good observation, that is one of the reason some companies decided to ship their own distribution of the collector, which is in a sense just the collector with a builtin configuration. We can discuss about that as well I think. |
Is this about detecting metadata for ec2, gcp, etc.? There is an OTEP that has been accepted for this (https://github.com/open-telemetry/oteps/blob/master/text/0111-auto-resource-detection.md). I think the long term plan would be to implement this which the resourcedetectionprocessor could use as well as other components that needed it. Perhaps there could be an extension that you configure once that exporters and processors could centrally source the metadata from. @james-bebbington any progress on the autodetection API? |
The spec for that was merged here: open-telemetry/opentelemetry-specification#811 But in the end I don't think there's too much value using that in the collector. We may as well continue with the resource detection processor as is imo. |
@bogdandrutu I created issue #1379 to track this overlapping functionality; let me know if I should expand/modify this in any way. I can't assign it to me but feel free to do so when you read this. |
CI keeps failing because of a flaky load test and a flaky unit test (the latter I believe is being fixed on #1384). I am going to try a couple times more to see if I can get them to pass, sorry for the noise. If I can't, rerunning the individual tests from the CircleCI UI would be an option (but I can't do that since I don't have write access to this repo) |
Adding #1387 to make CI pass more easily
Codecov Report
@@ Coverage Diff @@
## master #1351 +/- ##
==========================================
- Coverage 89.86% 89.41% -0.46%
==========================================
Files 326 328 +2
Lines 16061 16154 +93
==========================================
+ Hits 14434 14444 +10
- Misses 1182 1263 +81
- Partials 445 447 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
@bogdandrutu tests have passed now, please let me know if there is anything else that should be addressed (edit: I improved test coverage a bit given the Codecov report) |
Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
Description:
Get hostname and instance ID from EC2 instance metadata if available.
When either the metrics or traces exporter in the Datadog exporter are started, a single goroutine is created that sends host metadata (currently comprised of: EC2 instance metadata, tags and OS metadata) to our backend every 30 minutes. This goroutine is stopped at shutdown. This is controlled by a (opt-out) flag.
Remove logic adding tags to metrics and traces in favour of the metadata goroutine.
Link to tracking Issue: n/a
Testing: Added some unit tests, amended existing ones, tested on an EC2 instance against Datadog's backend.
Documentation: Documented public functions