contrib: Update non-client contrib packages to measure their spans #603
Conversation
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
knusbaum
force-pushed
the
knusbaum/measured-span-integrations
branch
from
a24ca16
to
27c7640
Compare
knusbaum
force-pushed
the
knusbaum/measured-span-integrations
branch
from
27c7640
to
2eb1c21
Compare
cgilmour
reviewed
Feb 27, 2020
knusbaum
force-pushed
the
knusbaum/measured-span-integrations
branch
from
2eb1c21
to
32a02a9
Compare
knusbaum
changed the base branch from
apm/add-measured-span-api-to-go-tracer
to
v1
brettlangdon
reviewed
Mar 4, 2020
knusbaum
force-pushed
the
knusbaum/measured-span-integrations
branch
from
87fb359
to
f814af8
Compare
gbbr
suggested changes
Mar 10, 2020
knusbaum
changed the title
knusbaum
changed the title
gbbr
reviewed
Mar 13, 2020
Co-Authored-By: Gabriel Aszalos <gabriel.aszalos@gmail.com>
The criteria I was given was "every integration that's not a client for an external service." I know the kafka producer is a network client, but that one was explicitly approved. They decided to do the producer and skip the consumer. The rest end up being mostly http servers and grpc. |
mingrammer
pushed a commit
to mingrammer/dd-trace-go
that referenced
this pull request
Dec 22, 2020
…ataDog#603) This commit marks relevant spans in our integrations to be measured. Previously, choosing which spans are measured was done elsewhere. We are able to do this now that we have support for manually marking spans to be measured (DataDog#591). A relevant span is any span that sets a service name, and is likely to have a parent span from the user's code or a different integration. Any spans that will be children of spans from the same integration don't need to be measured. We also don't measure spans that are for integrations for external service clients. This is a very generic class of integrations, and includes any integration for a package that is primarily an API to an external service. This includes SQL integrations, the aws integration, the client portion of the grpc integration, the http client integration, etc. This is actually most of our integrations. The reason for this is that there can be conflicts when measuring client spans that may cause inaccurate metrics.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Until recently, spans were measured only when they were considered "top-level" for a service - i.e. their service name differed from their parent's. Now we have support for manually marking a span to be measured (#591).
Since we have this option, we want to mark relevant spans in our integrations to be measured. Any span that sets its own service name, and is most likely to have a parent span from the user's code or a different integration should be measured. Any spans that will be children of spans from the same integration don't need to be measured.
There is another caveat, which is that we don't want to measure spans that are for integrations for external service clients. This is a very generic class of integrations, and includes any integration for a package that is primarily an API to an external service. This includes SQL integrations, the aws integration, the client portion of the grpc integration, the http client integration, etc. This is actually most of our integrations. The reason for this is that there can be conflicts when measuring client spans that may cause inaccurate metrics.