基礎架構監控

基礎架構監控

1）目標和框架

• 提前警告用戶發生故障（早期檢測）。
• 提供根本原因診斷（從癥狀到原因）。
• 支持SLO登錄版本和自動回滾。
• 提供事後分析（evidence as data）。

支持原則：通過設計觀察,噪音更少-信號更多,反應自動化,單個真相面板。

2）可觀察性三合會

度量（時間序列）：速度/需求/錯誤/飽和（USE/RED）。
Logi：具有上下文的事件細節；不含秘密/PII。
Traces：因果關系的分布式處理。

• 分析系統（CPU/heap/lock/io）、eBPF。
• 事件/審計（K8s事件，密碼/密碼更改）。

3）SLI/SLO/SLA-質量語言

SLI（指標）：「可用性」，「error_rate」，「p95_latency」，「queue_lag」。
SLO（目標）："成功查詢≥ 99。在30天內達到9%"。
錯誤預算：允許的偏差；用於發行版的自動腳。

yaml service: "api-gateway"
slis:
- name: success_rate query_good: sum(rate(http_requests_total{status!~"5.."}[5m]))
query_total: sum(rate(http_requests_total[5m]))
slo: 99. 9 window: 30d

4）監控層圖

1.主機/VM/節點： CPU/Load/Steal, RAM/Swap, Disk IOPS/Latency, Filesystem。
2.網絡/LB/DNS：RTT，軟件包/垃圾箱，backlog，SYN/Timeout，health-probes。
3.Kubernetes/Orchestrator：API服務器，etcd，控制器，scheduler；Pod/節點, pending/evicted, throttling, kube-events。
4.服務/容器：RED （Rate/Errors/Duration）, readiness/Liveness。
5.數據庫/緩存：QPS,鎖定等待,repliclag, buffer hit, slow queries。
6.隊列/總線：consumer lag, requeue/dead-letter, throughput。
7.存儲/雲：S3/Blob錯誤和延遲,429/503來自提供商。
8.外圍邊界：WAF/Rate限制，沿路線4xx/5xx，CDN。
9.合成：HTTP腳本驗證（存款/輸出），TLS/證書。
10.經濟/容量：每項服務的成本，utilization，headroom。

5) Whitebox и Blackbox

Whitebox： 服務內部的出口商/SDK （Prometheus, OpenTelemetry）。
Blackbox：來自不同地區的外部樣本（可用性，後坐力，TLS expiry）。
結合：「外部特征」+「內部診斷」。

yaml modules:
https_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"

6）Kubernetes： 關鍵信號

Кластер: `apiserver_request_total`, `etcd_server_has_leader`, etcd fsync.

Узлы: `container_cpu_cfs_throttled_seconds_total`, `node_pressure`.

Pods： Pending/CrashLoopBackOff, OOMKilled,重新開始。
計劃/限制：要求vs限制，PodDisruptionBudget，HPA/VPA。
網絡：NetworkPolicy，conntrack exhaustion。

Дашборды: «Cluster health», «Workload saturation», «Top erroring services».

7） DB和隊列

PostgreSQL/MySQL: replication lag, deadlocks, slow query %, checkpoint I/O.

Redis/Memcached: hit ratio, evictions, rejected connections.

Kafka/RabbitMQ: consumer lag, unacked, requeue, broker ISR, disk usage.

8） RED/USE和業務相關度量

RED: `rate` (RPS), `errors` (4xx/5xx), `duration` (p95/p99).

USE（用於資源）：Utilization, Saturation, Errors。
與產品相關聯：存款/付款成功，贈品，轉換是金絲雀釋放中的「警衛」。

9）Alerting的結構

Tier-1 （page）：影響SLO的事件（可用性、5xx、潛在性、群集關鍵組件故障）。
Tier-2 （tiket）：容量降解，錯誤增加而不影響SLO。
Tier-3（輸入）：趨勢、預測容量、證書到期。

升級規則：重復的沈默/壓縮時間，呼叫旋轉，「跟隨太陽」。

yaml route:
group_by: ["service","severity"]
receiver: "pager"
routes:
- match: { severity: "critical" }
receiver: "pager"
- match: { severity: "warning" }
receiver: "tickets"

10） Prometheus規則示例

10.1錯誤5xx c SLO閾值

yaml groups:
- name: api rules:
- alert: HighErrorRate expr:
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m])) > 0. 005 for: 10m labels: { severity: "critical", service: "api-gateway" }
annotations:
summary: "5xx > 0. 5% 10m"
runbook: "https://runbooks/api-gateway/5xx"

10.2 Error-budget燃燒（多窗口燃燒）

yaml
- alert: ErrorBudgetBurn expr:
(1 - (
sum(rate(http_requests_total{status!~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
)) > (1 - 0. 999) 14 for: 5m labels: { severity: "critical", slo: "99. 9" }
annotations: { summary: "Fast burn >14x for 5m" }

10.3系統飽和度（CPU Throttling）

yaml
- alert: CPUThrottlingHigh expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1 for: 10m labels: { severity: "warning" }
annotations: { summary: "CPU throttling >10%" }

11） Logi： 收集、正常化、重組

標準化：JSON logs：'ts'，'level'，'service'，'trace_id'，'user/tenant'。
Pipline： Agent （Fluent Bit/Vector） →緩沖區→索引/存儲。
社論：掩蓋邊緣的PII/秘密。
重建：快速存儲類（7-14天）,冷存檔（30-180天）。
語義：error budgets/deprequeites-單獨的通道。

12） Traces和OpenTelemetry

指示輸入點（gateway）、kliyent→servis呼叫、DB/緩存/隊列。
將指標綁定到trace屬性（Exemplars）,以便快速導航。
OTel Collector作為中央網關：過濾、采樣、導出到選定的培根。

yaml receivers: { otlp: { protocols: { http: {}, grpc: {} } } }
processors: { batch: {}, tail_sampling: { policies: [ { name: errors, type: status_code, status_codes: [ERROR] } ] } }
exporters: { prometheus: {}, otlp: { endpoint: "traces. sink:4317" } }
service:
pipelines:
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }
traces: { receivers: [otlp], processors: [tail_sampling,batch], exporters: [otlp] }

13）合成和外部檢查

業務腳本的HTTP運行（登錄，存款，輸出，購買）。
TLS/域：證書/CAA/DNS健康期限。
區域性：主要國家/提供商的樣本（路由/路由表）。
即使使用綠色內部遙測，如果用戶無法使用，也必須對合成材料進行變色。

14）分析和eBPF

持續分析：識別熱功能,鎖定。
eBPF：系統事件（syscalls, TCP retransmits）,以最小的超頭銷售。
沒有水龍頭（滴答聲）的簡介變量，以及發布後的回歸-作為回滾信號。

15）Dashbords和「真相小組」

1.平臺概述：關鍵服務SLI/SLO，錯誤預算和Alerta。

2.RED API：RPS/ERRORS/DURATION路由。

3.K8s Cluster: control-plane, узлы, capacity headroom.

4.DB/Cache: lag/locks/slow query %, hit ratio.

5.Queues： backlog/lag,故障/重復。

6.按發布：前後指標比較（金絲雀窗口）。

7.FinOps: cost per namespace/service, idle/oversized ресурсы.

16）事件，警報噪音和升級

重復數據消除：按服務/原因分組、級聯抑制。
沈默/維護：發行版/遷移不必將所有內容「染色」為紅色。
Runbooks：每個具有診斷步驟和「按鈕」回滾的關鍵警報。
Postmortem：學到什麼的時間線，哪些信號添加/清理。

17）監控中的安全性

RBAC 讀取/編輯規則/datasors。
秘密：出口商/代理商代幣-通過Secret Manager。
隔離：客戶端/tenant度量-進入單獨的空間/標簽。
完整性：通過GitOps （merj review）簽名代理/廣告牌、configi。

18）財務和容量（FinOps）

配額和預算；異常生長。
Right-sizing：分析查詢/限制、CPU/RAM處置、非關鍵任務的現場實例。
「Cost per request/tenant」作為效率KPI。

19）反模式

只有沒有自定義SLI的基礎架構指標。
100+alerts「關於所有人」→電話失明。
Logi是唯一的來源（沒有指標和跟蹤）。
Mutable dashbords，無翻轉/咆哮。
缺乏合成劑：「全部綠色」，但前部不可用。
發行版沒有捆綁在一起：無法回答「X時刻發生了什麼變化」。

20）實施清單（0-60天）

0-15天

為3-5項關鍵服務定義SLI/SLO。
包括基本出口商/代理商,標準化JSON邏輯。
設置Tier-1 Alerta（可用性,5xx, p95）。

16-30天

在關鍵場景中添加合成。
在輸入/關鍵服務上啟用步道（OTel）。
Dashbords 「Per-release」和error-budget burn規則。

31-60天

用高級信號覆蓋DB/隊列/緩存。
為高級CPU服務實施eBPF/分析。
GitOps 用於規則/dashbords/alerts，定期清潔噪音。

21）成熟度量標準

關鍵服務的SLO覆蓋率≥ 95％。
MTTA/MTTR（目標：分鐘/幾十分鐘）。
Tier-1的分量，通過自動動作或快速回滾關閉。
「有用「/」嘈雜」變量比>3：1。
合成覆蓋所有「現金」路徑=100％。

22）應用程序： 迷你模板

Prometheus-可按狀態類訪問

yaml
- record: job:http:availability:ratio_rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Grafana-金絲雀的線索

expr: histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket{version=~"stable    canary"}[5m])) by (le,version))

yaml receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true inhibit_rules:
- source_match: { severity: "critical" }
target_match: { severity: "warning" }
equal: ["service"]

23）結論

監視不是一組圖形，而是SRE操作系統：SLI/SLO作為質量合同，度量/跟蹤器/logi作為真理的來源，Alerta作為可控信號，合成為「用戶聲音」，GitOps作為變更學科。構建一個從主機到API的單一環路,將其捆綁到發行版和回滾中,並且該平臺將是可預測的、快速的和經濟的。