可觀察性：邏輯、度量、跟蹤

可觀察性： 邏輯、度量、跟蹤

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)»
• 「網絡手冊交付保證」