Observability и trace sampling

1）为什么观察力

• 度量（聚合，反应迅速）；
• Logi（零件和伪装）；
• Traces（端到端因果关系）；
• Profile （prod模式下的CPU/heap/lock contention）。

关键：信号之间的相关性+遥测经济学（采样、回避、压缩）。

2）信号图和原理

2.1 RED/USE

RED（用于API）： Rate （RPS）, Errors（%5xx/4xx重要）,Duration （p50/p95/p99）。
USE（用于资源）：Utilization, Saturation, Errors （NIC、CPU、磁盘、队列）。

2.2产品不变量

定义SLO（例如"p95 latents"/v1/payments "≤ 300毫秒，预算错误0。5%在30天内）。Alerts只有在违反SLO或其燃烧时"尖叫"。

2.3个背景

实施W3C Trace Context（"traceparent"，"tracestate"）和baggage，以安全地传输那些/业务属性（例如"tenant"，"region"，没有PII）。

3）可观察性架构

SDK/自动工具：服务中的OpenTelemetry（OTel）（HTTP/gRPC/DB/客户端）。
OTel Collector作为总线：接收→浓缩→采样→出口（Prometheus，Tempo/Jaeger，Loki/ELK，ClickHouse）。

• 度量：Prometheus/Mimir/VictoriaMetrics；
• 步道：Tempo/Jaeger/Zipkin；
• Logs：Loki/ELK/Vector→S3+deshevoye存储；
• Profyles：Pyroscope/Parca。
• 相关：服务图，exemplars，从p99图到特定轨迹的过渡。

4）示踪剂： 策略

4.1基于头部的采样（在入口处，直到知道结果）

简单而便宜的实现（在SDK/ingress中）。
缺点：可能会错过罕见的错误/缓慢查询。

当：高的RPS，严格的预算，需要可预测的份额（例如1-5％）。

4.2基于尾巴的采样（出口，知道结果）

Span完成后,将在Collector中做出决定。
可以保证选择异常：错误，p99，特定路由器/tenant。
缺点：缓冲更复杂，更昂贵。

何时：需要"有意义的"步道，成本适中。

4.3组合模型

全球头部1-5％，加上尾巴规则："始终保存错误/慢速播放"，"采样50％的金丝雀流量"，"在事件发生时保留所有支付路径跟踪"。

5）动态采样和遥测预算

Budget-aware： 保持≤ N Trays/Min的体积；超过时-提高阈值（例如，仅选择p99。5+, error-only).

Route/tenant规则：重要的终端/tenant-具有更大的份额。
自适应窗口：爆发→暂时增加错误/缓慢的百分比。
降低基数：规范化用户代理、IP/ASN、squash堆栈跟踪,掩盖秘密。

6）Configa（裁判）

6.1 OpenTelemetry Collector-tail-sampling （yaml片段）

yaml receivers:
otlp: { protocols: { http: {}, grpc: {} } }

processors:
batch: { send_batch_size: 8192, timeout: 2s }
tail_sampling:
decision_wait: 5s num_traces: 100000 expected_new_traces_per_sec: 5000 policies:
- name: always-error type: status_code status_code: { status_codes: [ERROR] }
- name: slow-endpoints type: latency latency: { threshold_ms: 300 }      # p95 цель
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/v1/payments", "/v1/payouts"] }
- name: tenant-eu1 type: string_attribute string_attribute: { key: tenant, values: ["eu-1"] }
- name: probabilistic-default type: probabilistic probabilistic: { sampling_percentage: 5. 0 }

exporters:
otlphttp/tempo: { endpoint: http://tempo:4318 }
prometheus: { endpoint: "0. 0. 0. 0:9464" }

service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tail_sampling]
exporters: [otlphttp/tempo]

6.2 Prometheus-exemplars（片段）

在应用程序中,写直方图时,请使用"trace_id"添加exemplars。在格拉法纳（Grafana），"针头"的点击导致步道。

yaml scrape_configs:
- job_name: api scrape_interval: 10s honor_labels: true static_configs: [{ targets: ["api:9100"] }]
exemplar_limit: 10

6.3 Loki-降低日志成本

标签仅稳定（"服务"，"env"，"区域"，"route_class"）。
高基数（request_id，user_id）-在付费中，但带有redaction。
采样"成功"信息日志,保存所有错误/警告。

6.4 Jaeger/Tempo-重建和指数

保存3-7天的原始步道，聚合/对称性更长。
在便宜的存储（S3兼容）中启用parquet/blocks,索引是紧凑的。

7）跟踪模拟

7.1命名和属性

`service.name`, `service.version`, `deployment.environment`.

`http.method`, `http.route`, `http.target`, `http.status_code`, `net.peer.name`.

没有PII的业务属性："tenant"，"region"，"payment_provider"，"game_id"。

7.2事件和联系

Span events：重要点（DB事务开始、转发、电路打开、小姐小姐）。
Links：zapros→vebkhuk/sobytiye联系；对EDA和outbox/inbox有用。

7.3个实例（exemplars）

在直方图中添加带有"trace_id"的latency/size示例：从度量→到跟踪"单次单击。

8）度量： 哪些和如何

8.1个技术

路线/tenant/提供商（PSP，KYC）上的RED。

Пулы: `db_connections_in_use`, `http_client_in_flight`, `queue_depth`.

稳定：retries、timeouts、circuit open/half open、rate-limit hits。
Go/Java/Python运行时：GC暂停，重播，safepoints，GIL延迟。

8.2个业务指标

注册/登录/存款/结算，转换，3DS/KYC失败，收费率。
重要的fici：时间到钱包，成功率付款。

8.3基数和存储

带有显式桶的直方图（例如"［50.100.200.300.500.1000.000］ ms"）。

避免使用高基数标记（raw user_id, request_id）-将标记传递到logi/traces.

9） Logi： 标准与相关性

格式：JSON+必需的密钥（"timestamp"，"level"，"message"，"trace_id"，"span_id"，"service"，"env"）。
编辑：伪装PAN、令牌、PII。
采样：100% for 'error/warn'、5-20% for 'info' on"嘈杂"的路径。
绑定到traces-通过"trace_id"。Log字符串在Trace中→ "pivot"，反之亦然。

10） Profailing在销售

为CPU/heap/alloc/locks启用连续分析（Pyroscope/Parca）。
将p99峰与热堆栈相关联；保存7-14天。

11） Alerting on SLO/预算错误

SLO-alerta："错误的预算花费速度快于X%/小时"（预测Alerta）。
症状，不是原因：在客户级别（RUM/edge或per-rout）上而不是在CPU上。
多窗口、多燃烧率：1小时2%，6小时5%-两个条件。
计划退化的沉默：菲奇旗/金丝雀的阈值变化。

12）成本和重置

数量配额：Trains ≤ N TB/mes，logi-热3-7天，冷S3 30-90天，指标-downsampling（1分钟→ 5分钟→ 1小时）。
Tail-rules将体积降低× 10-× 100，同时保持错误/缓慢。
成本最低的信号是度量；最有价值的是"正确"的预告片和专业文件。

13）反模式

"100% treas" →成本爆炸、噪音和刹车。
没有密钥/掩码的免费格式的日志。
具有无限标签的度量（user_id/ip/full UA）。
没有"traceparent"/"baggage"-无法进行联合。
Alerts on CPU/heap而不是SLO-聊天"燃烧"没有好处。
没有错误/慢速优先级的"random 1%"采样-失去了宝贵的案例。

14）dashbords的示例（骨架）

API综述：RPS，按类别排列的error-rate，latency p95/p99（exemplars clickable），顶级路由。

Release/Canary： 比较旧版/新版,outlier-rate, open-circuits, retries.

PSP/KYC：提供商的成功率，后退和失败，与付款错误相关。
Infra： USE按资源、排队、网络下降。

15） iGaming/财务细节

关键途径（存款/结论）：仅在事件或受限窗口中进行100％的跟踪；在正常模式下-"一切都有错误/长期潜伏"。
区域/tenant：在baggage中添加"tenant"，"jurisdiction"，"brand"；根据管辖权构建SLO。
Antifrod/bot过滤器：Risk API （allow/deny/challenge）、challenge-pass-rate、velocity-hits解决方桉指标和预告片。
审计/合规性：存储最低要求,不含PII；不变的日志-在单独的轮廓中。

16）准备就绪支票清单

• 端到端宣传（"traceparent"，"baggage"），博客/度量/跟踪相关性。
• OTel Collector with tail-sampling （errors/slow/重要路由）+probabilistic default。
• RED/USE度量标准,显式桶,exemplars →过渡到轨迹。
• SLO和差额预算（两个时间尺度）。
• 遥测规章和预算；downsampling指标；用于登录的冷库。
• 标准化的JSON-log, redaction PII/secrets。
• Profailing包含在销售中；事件中的"热"堆栈。
• 金丝雀行车记录和版本比较；没有"盲点"的问题。
• Runbook：如何暂时提高事件中的采样比例。
• 属性/标签的神经元文档和禁止高碱性。

17) TL;DR

围绕相关性构建可观察性：RED/USE → exemplars度量→预告片→ 徽标/profyles。通过组合采样管理成本：小头数%+尾数规则（错误、慢速、重要路线/tenants）。Alerta-通过SLO和错误预算。保持谨慎和基本控制，使用OTel Collector作为"中枢神经系统"。对于支付/管辖途径-优先遥测和严格的数据卫生。