jaegertracing/jaeger

[Feature]: Visualize uninstrumented services in the dependency diagrams

Open

#3,804 opened on Jul 8, 2022

View on GitHub
 (8 comments) (5 reactions) (0 assignees)Go (18,974 stars) (2,326 forks)batch import
enhancementhelp wanted

Description

Requirement

Visualize services in the dependency diagram even when they are not instrumented, but known from the caller side.

Problem

When the trace leaf nodes that represent outbound calls to uninstrumented services, those services are not shown in the dependency diagram (e.g. see how Zipkin shows them in #3803).

Proposal

Jaeger can infer that there is an existing callee service when the caller service logs a span with tag span.kind=client without the corresponding span.kind=server span.

There are several places in the code base where this will need to be accounted for:

  • in the in-memory storage used by all-in-one (the easiest to start with)
  • in the Flink/Spark jobs for production usage

Aside from changing the graph logic, another alternative is to have a trace enrichment which will add artificial server spans to the trace. Then the graph building logic would not need to change at all, and the inferred nodes could also be shown in the single-trace views.

Open questions

Deciding what to call the missing callee services can be tricky. We will need to implement a heuristic that derives the name from some of the tags of the client span:

  • based on OpenTracing semantic conventions
    • peer.service
    • peer.address
    • peer.ip? + peer.port
  • based on similar OTEL semantic conventions

There was a discussion in OTEL once about labeling the type of downstream service (e.g. an SQL db, etc), which could also be taken into account when naming the derived services.

Contributor guide

Tech stack
go
Domain
backendobservability
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
4
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
3-5 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Go programmingDistributed tracing conceptsJaeger architectureOpenTracing/OTEL semantics
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
Start by examining the in memory storage implementation in Jaeger to understand how spans are stored and retrieved. Look at the dependency graph generation code to see how services are currently visualized. Consider implementing a trace enrichment approach that adds artificial server spans for uninstrumented services. For naming, review the OpenTracing and OpenTelemetry semantic conventions for peer.service and peer.address tags.