[WIP] Visualize uninstrumented services in the dependency diagrams #3805
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
yurishkuro
reviewed
Jul 10, 2022
| @@ -71,6 +71,20 @@ func (m *Store) GetDependencies(ctx context.Context, endTs time.Time, lookback t | |||
| trace, _ := m.deduper.Adjust(orig) | |||
| if m.traceIsBetweenStartAndEnd(startTs, endTs, trace) { | |||
| for _, s := range trace.Spans { | |||
| // this finds unmanged peers of the service. So this are all external dependcies | |||
| peer := m.findPeer(s) | |||
There was a problem hiding this comment.
This will not address the issue in the ticket. While peer.service is a recommended tag, it's often impossible for the instrumentation to know.
There was a problem hiding this comment.
How you mean? What is the case this tag doesn't catch? And shouldn't this be more an issue for the collector? Shouldn't the observability layer trust the open telemetry spec?
There was a problem hiding this comment.
Or did you referring too the other informations that the open telemetry gives for peers?
Something like
- peer.port
- peer.ipv6
- peer.ipv4
- peer.hostname
- peer.address
So we should combine all these information for the key?
There was a problem hiding this comment.
There are two issues.
- You're force-adding a dependency based on the presence of
peer.servicetag regardless of whether the current node is the leaf in the call graph or an inner node that would produce a dependency anyway from its child span. - None of the tags you listed are actually required to be present in the span. In a typical HTTP client instrumentation, the instrumentation layer does not know the name of the downstream service, only its URL, so
peer.servicetag is likely to be missing, while otherpeer.*tags might be present. We would need some heuristic function that would decide how to name the downstream service in this case.
|
closing stale PR |
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.
Which problem is this PR solving?
This PR resolves the feature #3804 for the memory storage.
Short description of the changes
remote containers developmentextension of vscode.It looks nice so far:
cc @yurishkuro