可观察性：逻辑、度量、跟踪

可观察性： 逻辑、度量、跟踪

1）为什么需要它

• 度量标准是用于SLI/SLO和症状识别的紧凑集合。
• 跟踪是因果查询链（端到端）。
• Logi是用于调查和审计的详细事件。

目的：快速的RCA、先发制人的抗逆性和受控的可靠性。

2）架构原则

单一上下文：到处都有"trace_id"、"span_id"、"tenant_id"、"request_id"、"user_agent"、"client_ip_hash"。
标准：OpenTelemetry （OTel） for SDK/Agents, JSON log格式（规范,带电路）。
症状>原因：由于自定义症状（潜伏期/错误）而不是CPU引起的异常。
信号耦合：从度量→到spans（exemplars）→通过"trace_id"到特定的逻辑。
安全性和隐私性：在日志中掩盖PII,加密in transit/at rest,不变日志进行审核。
多范围：分离名称/密键/策略空间。

3）信号和方案的分类法

3.1个指标

服务的RED （Rate, Errors, Duration）和基础架构的USE （Utilization, Saturation, Errors）。
Типы: counter, gauge, histogram/summary.对于潜伏期，是具有固定bucket 'ami的历史图。
Exemplars：在"热"条形图中引用"trace_id"。

name: http_server_duration_seconds labels: {service, route, method, code, tenant}
type: histogram buckets: [0. 01, 0. 025, 0. 05, 0. 1, 0. 25, 0. 5, 1, 2, 5]
exemplar: trace_id

3.2条轨迹

Span=使用"name"，"start/end"，"attributes"，"events"，"status"的操作。
W3C Trace Context可移植性。
采样：基本（头）+动态（尾）+"重要性"规则（错误,高p95）。

3.3 Logi

仅结构化JSON；级别：DEBUG/INFO/WARN/ERROR。
强制性字段是：'ts_utc'，'level'，'message'，'trace_id'，'span_id'，'tenant_id'，'env'，'service'，'region'，'host'，'labels{}"。
禁止：秘密，代币，PAN，密码。PII-仅标记化/掩码。

json
{"ts":"2025-10-31T12:05:42. 123Z","level":"ERROR","service":"checkout","env":"prod",
"trace_id":"c03c...","span_id":"9ab1...","tenant_id":"t-42","route":"/pay",
"code":502,"msg":"payment gateway timeout","retry":true}

4）收集和运输

代理商/出口商（daemonset/sidecar）→ → 总线/ingest（TLS/mTLS）节点上的缓冲区→信号存储。
要求：背靠背压力,背靠背,重复数据消除,基数限制（标签!）,防护"日志风暴"。

度量标准：pull （Prometheus兼容）或通过OTLP推送。
跟踪：OTLP/HTTP（gRPC），收集器上的尾部采样器。
Logs：本地收集（journald/docker/stdout）→解析器→归一化器。

5）存储和娱乐（tiered）

度量标准：热TSDB 7-30天（带下标记），聚合时间更长（90-365天）。
跟踪：1-7天满,然后是"重要"服务的aggregata/Spa；以"service"、"status"、"error"存储索引。
Logi：热指数7-14天,温暖3-6个月,存档长达1-7年（合规）。审计-WORM。

成本优化：downsampling、销售DEBUG过滤、标签配额、轨道采样。

6）SLI/SLO，警戒和值班

SLI：可用性（成功查询的百分比），潜在性（p95/p99），5xx份额，数据新鲜度，成功乔布比例。
SLO：SLI上的目标（例如99。9%的成功≤ 400毫秒）。
Error budget: 0.1％的"错误权利"→菲奇弗里斯/实验规则。

• `ALERT HighLatency` если `p99(http_server_duration_seconds{route="/pay"}) > 1s` 5мин.
• `ALERT ErrorRate` если `rate(http_requests_total{code=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.02`.
• Silos-alerta （CPU/Disk）-仅作为辅助,不带针脚。

7）信号相关性

"红色"度量标准→在exemplar中单击→特定"trace_id" →观看"慢速"span →通过相同的"trace_id"打开日志。
与发行版的相关性："version"、"image_sha"、"feature_flag"属性。
对于数据/ETL："dataset_urn"，"run_id"，与lineage的关系（请参阅相关文章）。

8）采样和基数

度量：限制标签（没有"user_id"，"session_id"）；登记时的配额/验证。
跟踪：结合头标记（在入口处）和尾标记（在收集器上）的规则："所有的5xx, p99,错误100%"。
Logs：水平和节流；对于频繁重复的错误-聚合事件（dedupe key）。

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_code: ERROR rate_allocation: 1. 0
- type: latency threshold_ms: 900 rate_allocation: 1. 0
- type: probabilistic hash_seed: 42 sampling_percentage: 10

9）安全和隐私

在公交/休息： 加密（TLS 1.3, AEAD, KMS/HSM).

PII/秘密：发货前消毒剂，令牌化，掩盖。
访问：ABAC/RBAC阅读；分离生产者/读者/管理员的角色。
审计：不变的登录访问/跟踪日志；导出-加密形式。
多范围：带有策略的namespaces/tenant-labels；加密密钥隔离。

10）配置配置文件（片段）

yaml global: { scrape_interval: 15s, evaluation_interval: 30s }
scrape_configs:
- job_name: 'app'
static_configs: [{ targets: ['app-1:8080','app-2:8080'] }]
rule_files: ['slo. rules. yaml']

yaml groups:
- name: http_slo rules:
- record: job:http_request_duration_seconds:p99 expr: histogram_quantile(0. 99, sum(rate(http_server_duration_seconds_bucket[5m])) by (le,route))
- alert: HighLatencyP99 expr: job:http_request_duration_seconds:p99{route="/pay"} > 1 for: 5m

python provider = TracerProvider(resource=Resource. create({"service. name":"checkout","service. version":"1. 8. 3"}))
provider. add_span_processor(BatchSpanProcessor(OTLPExporter(endpoint="otel-collector:4317")))
set_tracer_provider(provider)
with tracer. start_as_current_span("pay", attributes={"route":"/pay","tenant":"t-42"}):
business logic pass

python log. info("gw_timeout", extra={"route":"/pay","code":502,"trace_id":get_trace_id()})

11） 数据/ETL和流媒体

数据的SLI：新鲜（max lag），完整性（rows vs曝光），"质量"（验证器/复制）。
Alerts：跳过窗口,消费者脱落,DLQ增长。
相关性："run_id"，"dataset_urn"，lineage事件；piplines的跟踪（batch/partition）。
Kafka/NATS：生产者/消费者的度量，掉期/弃权；通过头部进行跟踪（例如"traceparent"）。

12）分析和eBPF（信号）

低级CPU/alloc/IO热路；事件简介。
带有"trace_id"/PID绑定的eBPF遥测（网络延迟，DNS，系统调用）。

13）可观察性测试

信号合同：检查将指标/标签/直方图导出到CI。
Synthetic probes：外部SLI的RUM脚本/模拟客户端。
Chaos/Fire drills：关闭依赖关系,退化-观察警官和值班人员的反应。
销售中的烟雾：对新终端有指标和跟踪的后期验证。

14）成本和数量控制

信号/命令预算；dashbord "cost per signal"。
预算下的基数（cardinality的SLO），对新标签的限制。
Downsampling，按数据类别的撤回，"冷"存档和用于审核的WORM。

15）可观察性平台的运行和SLO

SLO平台：99。9％成功的ingests；延迟到指标指数≤ 30秒，标志≤ 2分钟，轨道≤ 1分钟。
平台Alerts： Ingest Lage, Drop,签名/加密错误,缓冲区溢出。
DR/HA：多区域，复制，config/规则备份。

16）支票单

• 随处可见"trace_id"/"span_id"；带有电路的JSON徽标。
• 带有直方图的RED/USE度量；exemplar →轨道。
• Tail-sampling已启用；规则5xx/p99=100%。
• Alerta的症状+runibuka；安静的手表/反翻转。
• PII消毒剂；加密at rest/in transit；WORM用于审核。
• 复仇和数量/基数预算。

• 每月审查（噪音/精度）、调节阈值。
• 关于错误预算的报告和所采取的措施（fichfries, hardening）。
• 检查关键路径的达什板/标志/轨道涂层。
• 培训事件和运行手册更新。

17) Runbook’и

RCA： p99/pay上涨

1.打开"checkout"的RED dashboard。

2.沿着exemplar →缓慢的轨道→显示"狭窄的垃圾桶"（例如，"门户"。call`).

3.在"trace_id"上打开日志→查看taymout/retrai。
4.启用RPS回滚/限值幻灯片标志,通知相关性所有者。
5.稳定后-RCA，优化滴答声，重播测试。

1.SLI"新鲜"红色→乔巴赛道→失败的步骤。

2.检查经纪人/DLQ差,连接器错误。

3.运行reprocess,通过状态通道通知消费者（BI/产品）。

18）常见错误

没有模式且没有"trace_id"的日志。调查被拖延了很多次。
Alerts通过基础设施而不是症状。Paging"进入牛奶"。
无限基数指标。成本爆炸和不稳定。
所有轨道均为100％。价格昂贵，不需要；打开智能采样。
逻辑中的PII/秘密。包括消毒剂和"红色清单"。
"沉默"的仙女。没有指标/路径/logs的新代码。

19) FAQ

问： 是否需要保留原始的日志文本?

答：是的，但有回避和档案；对于Alert和SLO，有足够的聚集体。审计-在WORM中。

问：如何选择步道-头部或尾部采样？
O：组合：head-probabilistic for basic涂层+tail-rules for错误和异常。

问： 如何将自定义指标与技术指标联系起来?

答：通过通用的"trace_id"和商业标签（"route"，"tenant"，"plan"）以及与轨道相关的产品事件（转换）。

问：如何不淹死在警报中？
答：按症状,输入安静时钟,重复数据消除,分组,SLO优先级,以及每个警报的默认所有者。

• "审核和不变日志"
• "加密In Transit/At Rest"
• "秘密管理"
• "数据来源（Lineage）"
• «Privacy by Design (GDPR)»
• "网络手册交付保证"