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
We noticed that with several redis services setup (session tokens, cache, ...), the service map displayed only displays a single "redis" bubble in signoz UI. According to the opentelemetry spec, a way to specify the logical instances of a service from the client perspective (application being instrumented) is to use peer.service.
As far as I understand the code the service map is built from information which comes from the query service which in turn becomes its information from the clickhouse database.
Shouldn't this use primarily the peer.service attribute instead of db.system ?
IMHO dest should be changed to be
peer.service if set
db.system otherwise (fallback)
Tested changes working:
-- in dependency_graph_minutes_db_calls_mv_v2
coalesce(tagMap['peer.service'], tagMap['db.system']) as dest,
-- in dependency_graph_minutes_messaging_calls_mv_v2
coalesce(tagMap['peer.service'], tagMap['messaging.system']) as dest,
What is your opinion?
PS: I tried the above code change and matching migrations added. I did a brute force replacement of the materialized view, maybe there is a more subtle way by updating....
The text was updated successfully, but these errors were encountered:
Tried it out with really brutal migrations, delete and recreate the materialized views. It works as intended, although the UI now seems not adapted to display service maps of unrelated service sets. I mean different groups of services not connected to each other themselves. But basically that yieds data-wise the expected results for me.
We noticed that with several redis services setup (session tokens, cache, ...), the service map displayed only displays a single "redis" bubble in signoz UI. According to the opentelemetry spec, a way to specify the logical instances of a service from the client perspective (application being instrumented) is to use
peer.service
.As far as I understand the code the service map is built from information which comes from the query service which in turn becomes its information from the clickhouse database.
Then I drilled down to the code here:
tagMap['db.system'] as dest,
Shouldn't this use primarily the
peer.service
attribute instead ofdb.system
?IMHO
dest
should be changed to bepeer.service
if setdb.system
otherwise (fallback)Tested changes working:
What is your opinion?
PS: I tried the above code change and matching migrations added. I did a brute force replacement of the materialized view, maybe there is a more subtle way by updating....
The text was updated successfully, but these errors were encountered: