服务图

服务图是各种服务之间相互关系的视觉表示。服务图有助于您理解分布式系统的结构，以及其组件之间的连接和依赖关系。

Service graphs example

工作原理

metrics-generator 处理追踪并以 Prometheus 指标的形式生成服务图。

服务图通过检查追踪并查找代表请求的具有父子关系的 Span 来工作。该处理器使用 OpenTelemetry 语义约定来检测各种请求。它支持以下请求

两个服务之间的直接请求，其中出站 Span 和入站 Span 必须分别具有 span.kind、client 和 server。
跨消息系统的请求，其中出站 Span 和入站 Span 必须分别具有 span.kind、producer 和 consumer。
数据库请求；在这种情况下，处理器会查找包含属性 span.kind=client 以及 db.name 或 db.system 之一的 Span。有关如何确定数据库请求的节点名称，请参见下文。

每个可以配对形成请求的 Span 都保存在内存存储中，直到收到其对应的配对 Span 或达到最大等待时间。当满足任一条件时，该请求将被记录并从本地存储中移除。

每个发出的指标序列都带有 client 和 server 标签，分别对应于发起请求的服务和接收请求的服务。

  traces_service_graph_request_total{client="app", server="db", connection_type="database"} 20

虚拟节点是构成追踪生命周期的节点，但未为其收集 Span，因为它们超出了用户范围或未进行插桩。例如，对于用户交互之外的支付处理外部服务，您可能不会收集其 Span。

可以通过两种不同的方式检测虚拟节点

根 Span 的 span.kind 设置为 server。这表示该请求是由未进行插桩的外部系统（如前端应用或通过 curl 的工程师）发起的。
一个 client Span 没有匹配的 server Span，但存在对等属性。在这种情况下，假设调用了一个外部服务，Tempo 将不会收到其 Span。
- 默认对等属性为 peer.service、db.name 和 db.system。
- 属性的顺序很重要，因为第一个属性用作虚拟节点名称。

数据库节点通过至少具有 db.name 或 db.system 属性的 Span 来识别。

数据库节点的名称按优先级顺序使用以下 Span 属性确定：peer.service、server.address、network.peer.address:network.peer.port、db.name。

导出以下指标

指标	类型	标签	描述
`traces_service_graph_request_total`	计数器	client, server, connection_type	两个节点之间的请求总数
`traces_service_graph_request_failed_total`	计数器	client, server, connection_type	两个节点之间失败的请求总数
`traces_service_graph_request_server_seconds`	直方图	client, server, connection_type	从服务器端看到的两个节点之间的请求时间
`traces_service_graph_request_client_seconds`	直方图	client, server, connection_type	从客户端看到的两个节点之间的请求时间
`traces_service_graph_request_messaging_system_seconds`	直方图	client, server, connection_type	（默认关闭）通过消息系统通信的服务之间发布者和消费者之间的时间
`traces_service_graph_unpaired_spans_total`	计数器	client, server, connection_type	未配对 Span 的总数
`traces_service_graph_dropped_spans_total`	计数器	client, server, connection_type	丢弃的 Span 总数