3. SLA度量与监控：度量方法、监控工具选型、数据采集策略、告警阈值设定

这一章，我们聊聊SLA落地中最“实在”的部分——度量与监控。

说实话，很多团队把SLA写得很漂亮，但一到度量就抓瞎。指标定义模糊、工具选型拍脑袋、告警阈值全靠猜。结果呢？SLA成了一纸空文。

我个人习惯，在设计SLA的度量体系时，先问三个问题：量什么？怎么量？量完怎么办？ 这三个问题捋清楚了，后面的工作就是填细节。

3.1 度量方法：从定性到定量

SLA的度量，说白了就是把“服务好不好”这个模糊概念，变成一串可比较的数字。

我见过最典型的错误，是直接拿“系统可用性”一个指标打天下。你想想看，一个电商网站，后端数据库挂了5分钟，但前端CDN还在正常服务静态页面——这时候可用性算多少？

所以，度量方法要分层、分维度。

举个例子。我之前负责过一个支付网关的SLA设计。我们定义了三个核心指标：

• 可用性 ≥ 99.99%（排除计划内维护）
• P99响应时间 ≤ 200ms
• 错误率 ≤ 0.1%

这三个指标组合起来，基本能覆盖用户的核心体验。单看可用性，可能系统一直活着但慢得像蜗牛；单看响应时间，可能快但经常报错。

3.2 监控工具选型：选对工具，事半功倍

度量方法定好了，接下来就是找工具来落地。市面上的监控工具五花八门，选型时我一般看三个维度：数据采集能力、数据存储与查询性能、告警与可视化能力。

下面这张表是我个人常用的工具对比，供你参考：

选型时，我建议你考虑以下几点：

• 团队技术栈：如果你们已经是Kubernetes+微服务架构，Prometheus几乎是标配。如果是传统物理机+虚拟机环境，Zabbix可能更顺手。
• 数据规模：每天产生多少指标？Prometheus单机处理百万级时间序列没问题，再大就需要Thanos或VictoriaMetrics做扩展。
• 告警复杂度：简单的阈值告警，大部分工具都能做。但如果你需要基于历史数据的动态阈值、多条件组合告警，那就要仔细评估了。

3.3 数据采集策略：采得准，才能测得对

工具选好了，接下来是数据采集。这一步看似简单，其实坑最多。

我总结了几条核心策略：

1. 采集频率要合理：不是越快越好。比如CPU使用率，10秒采集一次足够了；但像交易成功率这种关键业务指标，可能需要1秒甚至实时采集。频率太高，存储和网络开销会爆炸。
2. 数据采样 vs 全量采集：对于高吞吐系统，全量采集可能不现实。我习惯的做法是：核心指标全量采集，非核心指标按比例采样（比如1%的请求）。
3. 标签化数据：给每个指标打上标签（如服务名、机房、版本号），这样后续可以按维度聚合和筛选。Prometheus的Label机制就是为此设计的。
4. 数据完整性校验：采集端要加心跳和序列号，防止数据丢失。我遇到过采集进程挂了三天没人发现，那段时间的SLA数据全是空的。

scrape_configs:
  - job_name: 'api-service'
    scrape_interval: 15s
    scrape_timeout: 10s
    metrics_path: '/metrics'
    static_configs:
      - targets: ['localhost:8080', 'localhost:8081']
        labels:
          service: 'payment-api'
          env: 'production'
  - job_name: 'node-exporter'
    scrape_interval: 30s
    static_configs:
      - targets: ['192.168.1.10:9100']

3.4 告警阈值设定：别让告警变成噪音

告警阈值设得好，运维团队能睡个安稳觉；设得不好，半夜被电话吵醒，结果发现是误报。

我设定阈值时，一般遵循以下原则：

• 基于历史数据：不要拍脑袋设阈值。先跑一段时间数据，看看指标的波动范围。比如P99响应时间平时在100ms左右，偶尔跳到150ms，那阈值设在200ms比较合理。
• 分级告警：不要所有问题都P0。我习惯分三级：
  • Warning：指标接近阈值，需要关注，但不一定立即处理。
  • Critical：指标超过阈值，需要立即响应。
  • Disaster：指标严重超标，需要启动应急预案。
• 持续时间窗口：单次抖动不一定是故障。我通常设置“持续N分钟超过阈值”才触发告警。比如错误率超过1%持续5分钟才告警，避免瞬时波动干扰。
• 避免告警风暴：一个服务挂了，可能触发几十个关联告警。我建议做告警聚合和依赖分析，只发根因告警。

下面这张图，是我对SLA度量与监控体系的一个整体梳理：

你看，整个体系是自上而下、层层递进的。度量方法定义了“量什么”，工具选型解决了“用什么量”，采集策略保证了“量得准”，告警阈值决定了“量完怎么办”。最后，所有环节都要回到持续优化——根据实际运行数据，不断调整度量指标、工具配置和阈值设定。