可觀察性堆棧

1）為什麼需要觀測堆棧

快速RCA和減少MTTR：從癥狀到原因在幾分鐘內。
SLO控制：測量錯誤/潛伏期,通過錯誤的預算進行排序。
發行控制：金絲雀布局，按指標自動回滾。
安全和審計：訪問路線，異常，法律保留。
FinOps-Process：存儲/查詢成本，每次SLO成本。

方法：金色信號（latency/traffic/errors/saturation），RED，USE。

2）基本堆棧架構

按圖層分組的組件

收集/代理：Exporters, Promtail/Fluent Bit, OTel SDK/Auto-Instr, Blackbox-probes。

Шина/ingest: Prometheus remote_write → Mimir/Thanos, Loki distributors/ingesters, Tempo/Jaeger ingesters.

存儲：對象S3/GCS/MinIO（長期寒冷），SSD（熱排）。
查詢/可視化：Grafana（面板，SLO小部件），Kibana（如果ELK）。
管理：Alertmanager/Grafana-alerta，服務目錄，RBAC，秘密經理。

部署模式

托管（Grafana Cloud/雲服務）-在數量上快速而昂貴。
自我托管在K8s-完全控制，需要操作和FinOps。

3）數據標準： 單一「可觀察性方案」

3.1個指標（Prometheus/OpenMetrics）

強制性標簽是：「env」，「region」，「cluster」，「namespace」，「service」，「version」，「tenant」（如果是多特南特），「endpoint」。
命名：「snake_case」，後綴「_total」，「_seconds」，「_bytes」。
直方圖：固定的「buckets」（SLO定向）。
基數：不在標簽中包含「user_id」、「request_id」。

3.2 Logi

格式：JSON；必填字段「ts」、「level」、「service」、「env」、「trace_id」、「span_id」、「msg」。
PII：掩蓋代理（PAN、令牌、電子郵件等）。
Loki標簽：只有低基數（「app」，「namespace」，「level」，「tenant」）。

3.3條賽道

OTel語義： '服務。name`, `deployment.environment`, `db.system`, `http.`.

Sampling：p99的目標路徑是「always_on」/tail-sampling，其余路徑是「parent/ratio」。
嵌入ID：將「trace_id/span_id」推入日誌和度量（labels/fields）。

4）M-L-T相關性（Metrics/Logs/Traces）

從Alert圖形（度量）→，「trace_id」上的過濾邏輯→特定的路徑。
從軌道（慢速span）→調用span間隔上的特定後端指標。
面板中的Drilldown按鈕是：「到日誌」和「到軌道」，並帶有變量替換（「$env」，「$service」，「$trace_id」）。

5） OpenTelemetry Collector： 參考管線

yaml receivers:
otlp:
protocols: { http: {}, grpc: {} }
prometheus:
config:
scrape_configs:
- job_name: kube-nodes static_configs: [{ targets: ['kubelet:9100'] }]

processors:
batch: {}
memory_limiter: { check_interval: 1s, limit_mib: 512 }
attributes:
actions:
- key: deployment. environment value: ${ENV}
action: insert tail_sampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code: { status_codes: [ERROR] }
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/payments","/login"] }
- name: probabilistic type: probabilistic probabilistic: { sampling_percentage: 10 }

exporters:
otlphttp/mimir: { endpoint: "https://mimir/api/v1/push" }
otlphttp/tempo: { endpoint: "https://tempo/api/traces" }
loki:
endpoint: https://loki/loki/api/v1/push labels:
attributes:
env: "deployment. environment"
service: "service. name"

service:
pipelines:
metrics: { receivers: [prometheus, otlp], processors: [memory_limiter, batch], exporters: [otlphttp/mimir] }
logs:   { receivers: [otlp], processors: [batch], exporters: [loki] }
traces:  { receivers: [otlp], processors: [memory_limiter, attributes, tail_sampling, batch], exporters: [otlphttp/tempo] }

6） Alerting： SLO和多燒傷

想法是：alertim不在「CPU> 80%」的水平，而是在Error Budget的消費上。

promql
5-minute error rate err_ratio_5m =
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m]))

Quick burn (1m window)
(err_ratio_1m / (1 - SLO)) > 14. 4

Slow burn (30m)
(err_ratio_30m / (1 - SLO)) > 2

promql latency_p95 =
histogram_quantile(0. 95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

7） Dashbords： 文件夾結構

00_Overview平臺：SLO, p95, 5xx%, capacity,活動事件。
10_Services服務：RPS，p95/p99，錯誤，版本（註釋）。
20_Infra-K8s/nods/storage/網絡，etcd，控制器。

30_DB/Queues — PostgreSQL/Redis/Kafka/RabbitMQ.

40_Edge/DNS/CDN/WAF-ingress, LB, WAF規則。
50_Synthetic是藥房和無頭腳本。
60_Cost/FinOps-存儲，查詢，熱/冷，預測。

每個面板：說明,單位,所有者,運行手冊鏈接,drilldown。

8） Logi： LogQL講習班

logql
API errors
{app="api", level="error"}     = "Exception"

Nginx 5xx in 5 minutes
{app="nginx"}      json      status=~"5.."      count_over_time([5m])

Extract Fields
{app="payments"}      json      code!=""      unwrap duration      avg()

9）軌道： TraceQL和焦點

{ service. name = "api" }      duration > 500ms

{ name = "HTTP GET /order" }      child. span. name = "SELECT" & child. duration > 50ms

10）合成和制藥

Blackbox-exporter：來自≥3 個區域/ASN的HTTP/TCP/TLS/DNS樣本。
Headless： 登錄/deposit腳本按計劃。
Quorum-alerts：如果≥2地區看到故障,則觸發。
狀態頁面：自動更新+手動評論。

11）存儲和重構

度量標準：熱7天至30天（快速行）、降低/記錄規則、冷-對象存儲（月）。
Logs：熱3-7天，然後是索引S3/GCS（Loki chunk store/ELK ILM）。
路線：3-7天「always_on」+長期存儲樣本（tail-sampled/check）。

• Rollover的大小和時間；請求預算（配額/限額）。
• prod/stage和安全數據的單獨策略。

12）多重性和可用性

按「tenant」/「namespace」/Spaces，索引模式和分辨率劃分。
對計費資源進行標記：「tenant」、「service」、「team」。
進口dashbords/alerta-在特定命令的空間中。

13）安全和合規性

從代理商到bekends的TLS/mTLS，用於私人健康的HMAC。
RBAC用於閱讀/寫入，審核所有請求和差異。

邊緣的PII修訂版；禁止登錄中的秘密；DSAR/Legal Hold.

隔離：敏感域的單個群集/neyspace。

14） FinOps： 可觀測性的成本

我們降低了ingest（而不是查詢）中的標簽基數和邏輯。
Sampling Trass+針對關鍵路徑的目標前進。
用於重聚的downsampling/recording規則。
將罕見的訪問歸檔到冷對象。

Метрики: `storage_cost_gb_day`, `query_cost_hour`, `cost_per_rps`, `cost_per_9`.

15） CI/CD和可觀察性測試

放大CI中的指標/標誌：禁止基數「爆炸」，檢查直方圖/單位。
可觀察性合同測試：中間件中的「trace_id」強制性指標/邏輯字段。
金絲雀：圖上發布的註釋,SLO-auto-rollback。

16）示例： 快速查詢

promql topk(10, sum by (route) (rate(http_requests_total{status=~"5.."}[5m])))

CPU throttling:

promql sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m])) > 0

Kafka lag:

promql max by (topic, group) (kafka_consumergroup_lag)

從日誌到軌道（Loki → Tempo）：在Tempo UI/dashboard上傳輸「trace_id」作為鏈接。

17）堆棧質量： 支票清單

• 統一指標/標誌/軌跡圖和度量單位。
• 「trace_id」在日誌和度量標準中，從面板中刪除。
• Multi-burn SLO-alerta無翻轉（quorum/multi-window）。
• Downsampling、查詢配額、步驟/範圍限制。
• 重建和存儲類已記錄並應用。
• RBAC/審計/PII修訂版包括在內。
• Dashbords：所有者,runbooks, ≤2 -3屏幕,快速響應。
• FinOps-dashbord（體積、成本、頂級對話者）。

18）實施計劃（3次叠代）

1.MVP（2周）：Prometheus→Mimir，Loki，Tempo；OTel Collector;基本的dashbords和SLO-alerta；blackbox樣本。
2.尺度（3-4周）：tail-sampling，downsampling，多區域ingest，RBAC/Spaces，FinOps-dashbords。
3.Pro （4周以上）：通過SLO、無頭關鍵路徑合成、Legal Hold、SLO產品組合和報告自動回滾。

19）反模式

「沒有SLO的美麗圖形」-沒有動作→沒有好處。
高基數標簽（「user_id」，「request_id」）是內存和成本的爆炸。
沒有JSON且沒有「trace_id」的日誌沒有相關性。
根據資源而不是癥狀，Alerts是噪音和呼喚倦怠。
缺乏重組政策是成本的不受控制的增長。

20）迷你常見問題

選擇什麼： Loki或ELK?

ELK用於復雜的搜索/面板；對於類似於grep的場景,Loki更便宜、更快。他們經常使用混合動力車。

每個人都需要賽道嗎？
是的，至少在帶有尾部采樣的關鍵路徑（登錄，檢查，支付）上-這大大加快了RCA。

如何從頭開始？
OTel Collector → Mimir/Loki/Tempo →基本的SLO和blackbox樣本→然後是行車記錄儀和burn-alerta。

底線

可觀察性堆棧不是一組不同的工具，而是一致的系統：統一的數據標準→ M-L-T相關性→ SLO對等和合成→安全性和FinOps。記錄電路、標簽紀律和續集，連接OTel，添加滾動和自動滾動-並獲得可管理的可靠性，成本可理解。