You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
On the NodeGraph in Service Graph, external components are not showing up by default (without adding extra tags to "their" spans). There are lots of components that are not instrumented so they will not emit spans: DBs, message brokers, Kafka, RabbitMQ, etc. These components are not visible on the NodeGraph by default, users need to add custom tags like database.name to these spans to see them on the NodeGraph.
Describe the solution you'd like
In order to do this Tempo should detect the "leaf" spans that are calling out to external components and show them on the NodeGraph. Tempo is able to detect this scenario as of today in another use-case, it seems it is just not implemented for NodeGraph. If I have an external component and I look at the tree view of a trace, Tempo detects the "external" components and shows them in a client => external service format, see here:
This is even more important for rare "protocols"/components that does not have any instrumentation support or components that are not public and built in-house.
Fyi: Zipkin does this out of the box too without custom tags.
Describe alternatives you've considered
I'm not sure there are many ways to do this, not doing anything is an option but I don't think it is a good one.
Additional context
I think this should work in any accepted formats (Zipkin, OTLP) sent by any SDK (OTel, Brave, home-grown libs).
The text was updated successfully, but these errors were encountered:
Service A (nodejs) I have is using service graph through grafana+tempo+metricGenerator+prometheus+opentelemetry (nodejs auto instrumentation).
By the way, service A is making an API call to external system B through axios.
The trace span is displayed fine.
It is not displayed in the service graph. We don't need to monitor external system B, but we want to see calls from service A to external system in the service graph.
Maybe that feature is not currently supported?
The problem is we generate the Service Graph based on generated metrics that are stored in Promethues. So in order to have that information the metric generation part would have to include it somehow. Will move this to Tempo project for considereation.
The problem is we generate the Service Graph based on generated metrics that are stored in Promethues.
Are you sure? How can you get the call-tree information from metrics? :o
If this is true, can you add the remote service name of the span to the time series automatically? This would be the same as users add db.name but Tempo could add a remote.name tag that has a value of span.getRemoteServiceName().
Is your feature request related to a problem? Please describe.
On the NodeGraph in Service Graph, external components are not showing up by default (without adding extra tags to "their" spans). There are lots of components that are not instrumented so they will not emit spans: DBs, message brokers, Kafka, RabbitMQ, etc. These components are not visible on the NodeGraph by default, users need to add custom tags like
database.name
to these spans to see them on the NodeGraph.Describe the solution you'd like
In order to do this Tempo should detect the "leaf" spans that are calling out to external components and show them on the NodeGraph. Tempo is able to detect this scenario as of today in another use-case, it seems it is just not implemented for NodeGraph. If I have an external component and I look at the tree view of a trace, Tempo detects the "external" components and shows them in a
client => external service
format, see here:This is even more important for rare "protocols"/components that does not have any instrumentation support or components that are not public and built in-house.
Fyi: Zipkin does this out of the box too without custom tags.
Describe alternatives you've considered
I'm not sure there are many ways to do this, not doing anything is an option but I don't think it is a good one.
Additional context
I think this should work in any accepted formats (Zipkin, OTLP) sent by any SDK (OTel, Brave, home-grown libs).
The text was updated successfully, but these errors were encountered: