分布式轨迹

分布式轨迹

1）为什么，什么是

分布式跟踪是一种连接整个查询路径上的操作的方法：前端→ API网关→微服务→ DB/缓存 → → joba/pipline经纪人。
结果是来自span（span）的trace（trace），其中每个span捕获具有属性，事件和状态的组件的操作。这会加速RCA，帮助保持SLO并降低MTTR。

• 关键路径和"瓶颈"的可见性。
• 症状（度量）与原因（旋转）和细节（徽标）的相关性。
• Retrais分析，队列，DLQ，粉丝出局，"锯"潜伏期。

2）跟踪数据模型

Trace是带有"trace_id"的调用图。

Span — операция: `name`, `kind` (SERVER/CLIENT/PRODUCER/CONSUMER/INTERNAL), `start/end`, `status`, `attributes`, `events`, `links[]`.

Attributes-键值（route, db.system, messaging.system, cloud.区域等）。
事件是span中的即时标签（例如"retry"，"cache_miss"）。
Span Links是"亲子关系"（batchi，retrai，fan-in/out）之外的链接。
资源-进程/服务元数据（'服务。名称,版本,环境）。

3）上下文和可移植性

3.1 W3C Trace Context

• "traceparent"："version-traceid-spanid-flags"（标志包括采样）。
• "tracestate"：供应商特定状态（最小）。
• Baggage是业务上下文的钥匙（受限制，没有PII/秘密）。

3.2通过上下文

HTTP: `traceparent`/`tracestate`;gRPC： 元数据；WebSocket：升级和消息；

消息：在头部（Kafka/NATS/RabbitMQ）中-我们在PRODUCER下保留原始上下文，并在CONSUMER下传输。
基数：不"携带"上下文,我们在span （query, rows, db.系统），但不重要。

4）采样： 如何不破产

头部采样（在入口处）：概率/规则（route, tenant, endpoint）。
Tail采样（在收集器上）：我们保持"有趣的"路径-错误，长的p95/p99，罕见的路径。
Exemplars：直方图度量存储指向特定"trace_id"的链接。
建议：组合-5xx/timeout/p99的5-20％+tail规则100％。

5）属性和分类法（最低强制性）

• `service.name`, `service.version`, `deployment.environment`, `cloud.region`, `http.route`, `http.method`, `http.status_code`, `db.system`, `db.statement'（简称/无数据）,'messaging.system`, `messaging.operation`, `peer.service`, `net.peer.name`, `tenant.id`, `request.id`.

商业标签： 整洁，没有PII。示例：'order。segment`, `plan.tier`.

6）异步脚本、队列和蹦床

PRODUCER → CONSUMER：创建具有上下文的PRODUCER Span；消息是headers （traceparent, baggage）。CONSUMER从SERVER/CONSUMER span从link到PRODUCER（如果没有严格的层次结构）开始。
Fan-out：一个输入-很多出路→子弹或链接。
Batch： CONSUMER读取一包N消息→每个消息Id的"事件"或N个单独上下文的"链接"。

DLQ： 一个独立的span'messaging。dlq.publish` с reason и count.

Retrai： 'event： retry'+'retry。计数属性；最好是试用新的CHILD。

7）与日志和指标集成

Logi用"trace_id"/"span_id"写作JSON →点击后进入日志。
RED/USE度量标准包含exemplars →从p99峰值进入"不良"spana。
路线通过事件生成tehsignals（依赖性错误）和业务信号（转换）。

8）生产力和成本

采样和倾斜事件。
缩写属性基数（不是'user_id'/'session_id'作为标签!）。
出口商压缩/战斗；出口界限。
存储：热门1-7天，接下来-聚合体/仅"问题"跟踪。

支出类别： 收集器,索引,存储,egress.

9）安全和隐私

In Transit: TLS 1.3/mTLS kollektor↔agenty；At Rest：加密，专有密钥（请参阅"加密In Transit/At Rest"）。
PII和秘密：不要写入属性/事件；prodewser上的令牌/伪装。
多范围：'tenant。id'作为资源标签和空间隔离，阅读策略；审核对跟踪的访问（请参阅"审核和不可更改日志"）。

10）实施计划（参考）

10.1 OpenTelemetry SDK（伪代码）

python from opentelemetry import trace from opentelemetry. sdk. trace import TracerProvider from opentelemetry. sdk. resources import Resource from opentelemetry. sdk. trace. export import BatchSpanProcessor from opentelemetry. exporter. otlp. proto. grpc. trace_exporter import OTLPSpanExporter

provider = TracerProvider(resource=Resource. create({
"service. name":"checkout","service. version":"1. 12. 0","deployment. environment":"prod"
}))
provider. add_span_processor(BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317", insecure=True)))
trace. set_tracer_provider(provider)
tr = trace. get_tracer("checkout")

with tr. start_as_current_span("POST /pay", attributes={
"http. route":"/pay","http. method":"POST","tenant. id":"t-42"
}):
business logic, external API call and pass DB

10.2 OTel Collector-tail采样（片段）

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_codes: [ERROR]
- type: latency threshold_ms: 900
- type: probabilistic sampling_percentage: 10 exporters:
otlphttp: { endpoint: http://trace-backend:4318 }
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tailsampling]
exporters: [otlphttp]

10.3 Kafka-上下文转移（概念）

生产者：我们添加头部"traceparent"，"baggage"。
CONSUMER：如果消息触发新线程-新的SERVER/CONSUMER-span从头部到上下文的链接。

11) Data/ETL и ML

Batch piplines： span to batch/partition with 'dataset。urn`, `run.id`, `rows.in/out`, `freshness.lag`.

对于ML：睡眠训练/地狱,模型版本,latency,功能商店。
与Lineage的捆绑在一起：'运行。id` и `dataset.urn'允许从trace切换到数据来源图。

12）跟踪平台SLO

可用性： ≥ 99。9%

索引前延迟： ≤ 60与p95

覆盖范围： ≥ 5-10%的关键路线

100%保存具有ERROR状态且具有latency>"关键路径"目录的阈值"

平台的Alerts： drops的增长,出口的taymauts,指数器脱落,基数过热。

13）测试和验证

CI中的跟踪合同：关键端点上有旋转，强制属性，正确的"traceparent"飞过网关/代理。
合成/朗姆酒样本：从外部收集步道。
混乱/事件：断开依赖关系，检查尾部采样器"拾取"错误。
Smoke在销售：发布后-"是否有喷雾"和exemplar → trace。

14）支票单

出售前

• W3C Trace Context将随处可见；对于消息-头条。
• 包括基本头部采样；5xx/p99的尾巴规则已配置。
• 强制属性：route、method、status、service。version, tenant.id.
• Logi JSON带有"trace_id"/"span_id"，带有exemplars的度量。
• PII消毒剂；路径/静止加密；访问策略。
• Dashbords："关键路径"，"依赖性错误"，"retrai/taymauts"。

运营

• 属性基本性的每月审查；配额。
• 在SLO上调整尾部采样（在样本中减少噪音，所有"热"）。
• 带有→ exemplar度量转换→ trace → logi的教学RCA。
• 检查队列、DLQ、ETL-jobs的覆盖范围。

15) Runbook’и

RCA： p99 上涨/pay

1.打开RED dashboard；从bin p99穿过exemplar进入步道。
2.找到"窄"CLIENT span（例如,'gateway）。call'），检查"retry"。count'， taymouts。
3.比较服务/依存关系版本,区域/区域。
4.启用降级（缓存响应/RPS限制）,通知依赖关系所有者。
5.小说之后-RCA和缩放优化。

DLQ激增

1."消息传递"上的路径过滤器。dlq.publish`.

2.检查原因（事件）,与发布相关联。
3.运行reprocess,暂时增加CONSUMER的定时,通知下游业主。

16）经常出错

没有通过网关/经纪人对上下文进行近似。解决方桉：middleware/interseptors,统一库。
所有步道100%。昂贵且毫无意义-使用tail采样。
没有"trace_id"的日志。失去相关性→ MTTR ↑。
属性中的PII。伪装/令牌化；仅存储技术上下文。

"无声"背景乔巴。在batch/partition和'run上添加spans。id`.

命名差异。键入span名称和属性密钥字典。

17) FAQ

问：头部还是尾部采样更好？
答：组合。头部给出基层，尾巴确保异常/错误持续存在。

问：如何在没有严格等级制度的情况下穿越卡夫卡？
答：使用PRODUCER和CONSUMER之间的span链接；上下文是头条。

问： 敏感的SQL如何处理?

O： 'db。statement"缩短"/规范化（无值）或'db。operation'+尺寸/时间。

问： 如何与业务指标相关联?

答：添加没有PII （计划/segment）的域属性,使用span内部的"业务阶段"事件,然后从exemplar转换指标转换。

• "可观察性：逻辑，度量，跟踪"
• "审核和不变日志"
• "加密In Transit/At Rest"
• "数据来源（Lineage）"
• «Privacy by Design (GDPR)»
• "秘密管理"