基础架构监控

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%"。
错误预算：允许的偏差；用于发行版的自动脚。

SLO示例（YAML）：

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）。
结合："外部特征"+"内部诊断"。

示例"blackbox_exporter"：

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（输入）：趋势、预测容量、证书到期。

升级规则：重复的沉默/压缩时间，呼叫旋转，"跟随太阳"。

Alertmanager routes的示例：

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作为中央网关：过滤、采样、导出到选定的培根。

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))

🚨 Check Alertmanager-值班和沉默

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的单一环路,将其捆绑到发行版和回滚中,并且该平台将是可预测的、快速的和经济的。

基础架构监控