## 前言

有了 Exporter、Grafana、Alertmanager，但应用本身的指标怎么埋？SLI/SLO 怎么定义和落地？本篇从微服务指标埋点到 SLO 告警，给出完整实战方案。

---

## 一、微服务指标埋点

### 四个黄金指标（USE/RED 方法）

```
RED 方法（请求驱动服务）：
  Rate       → 请求速率（QPS）
  Errors     → 错误率
  Duration   → 延迟分布

USE 方法（资源驱动）：
  Utilization → 使用率
  Saturation  → 饱和度
  Errors      → 错误数

四个黄金指标（Google SRE）：
  1. 延迟（Latency）→ 请求处理时间
  2. 流量（Traffic）→ QPS
  3. 错误（Errors）→ 错误率
  4. 饱和度（Saturation）→ 资源使用率
```

### 标准指标定义

```python
from prometheus_client import Counter, Histogram, Gauge

# ===== 四个黄金指标 =====

# 1. 流量：请求总数
http_requests_total = Counter(
    'http_requests_total',
    'Total HTTP requests',
    ['method', 'route', 'status']
)

# 2. 延迟：请求延迟分布
http_request_duration_seconds = Histogram(
    'http_request_duration_seconds',
    'HTTP request duration',
    ['method', 'route'],
    buckets=(0.005, 0.01, 0.025, 0.05, 0.075, 0.1, 0.25, 0.5, 0.75, 1.0, 2.5, 5.0)
)

# 3. 错误：错误请求数
http_request_errors_total = Counter(
    'http_request_errors_total',
    'Total HTTP request errors',
    ['method', 'route', 'error_type']
)

# 4. 饱和度：并发请求
http_requests_in_progress = Gauge(
    'http_requests_in_progress',
    'In-progress HTTP requests',
    ['method']
)
```

### 中间件埋点

```python
# middleware.py
import time
from prometheus_client import Counter, Histogram, Gauge
from flask import request, g

# 指标定义
REQUEST_COUNT = Counter(
    'http_requests_total',
    'Total HTTP requests',
    ['method', 'route', 'status']
)

REQUEST_DURATION = Histogram(
    'http_request_duration_seconds',
    'HTTP request duration',
    ['method', 'route'],
    buckets=(0.005, 0.01, 0.025, 0.05, 0.075, 0.1, 0.25, 0.5, 0.75, 1.0, 2.5, 5.0, 10.0)
)

REQUESTS_IN_PROGRESS = Gauge(
    'http_requests_in_progress',
    'In-progress HTTP requests',
    ['method']
)

def setup_metrics(app):
    @app.before_request
    def before():
        g.start_time = time.time()
        REQUESTS_IN_PROGRESS.labels(method=request.method).inc()
    
    @app.after_request
    def after(response):
        duration = time.time() - g.start_time
        route = request.endpoint or 'unknown'
        
        REQUEST_COUNT.labels(
            method=request.method,
            route=route,
            status=str(response.status_code)
        ).inc()
        
        REQUEST_DURATION.labels(
            method=request.method,
            route=route
        ).observe(duration)
        
        REQUESTS_IN_PROGRESS.labels(method=request.method).dec()
        
        return response
```

### 业务指标埋点

```python
# business_metrics.py
from prometheus_client import Counter, Gauge, Histogram

# 订单指标
ORDERS_TOTAL = Counter(
    'orders_total',
    'Total orders created',
    ['status', 'payment_method']
)

ORDER_AMOUNT = Histogram(
    'order_amount_yuan',
    'Order amount in yuan',
    ['payment_method'],
    buckets=(10, 50, 100, 500, 1000, 5000, 10000, 50000)
)

ORDERS_PENDING = Gauge(
    'orders_pending',
    'Pending orders count',
    ['queue']
)

# 用户指标
USERS_TOTAL = Counter(
    'users_registered_total',
    'Total registered users',
    ['source']  # organic, referral, ad
)

USERS_ACTIVE = Gauge(
    'users_active',
    'Active users count',
    ['platform']  # web, ios, android
)

# 支付指标
PAYMENT_DURATION = Histogram(
    'payment_duration_seconds',
    'Payment processing time',
    ['provider'],  # alipay, wechat
    buckets=(0.1, 0.5, 1.0, 2.0, 5.0, 10.0, 30.0)
)

PAYMENT_FAILED = Counter(
    'payment_failed_total',
    'Failed payments',
    ['provider', 'reason']
)
```

### 数据库指标埋点

```python
# db_metrics.py
import time
from prometheus_client import Histogram, Counter

DB_QUERY_DURATION = Histogram(
    'db_query_duration_seconds',
    'Database query duration',
    ['operation', 'table'],
    buckets=(0.001, 0.005, 0.01, 0.05, 0.1, 0.5, 1.0, 5.0)
)

DB_ERRORS = Counter(
    'db_errors_total',
    'Database errors',
    ['operation', 'error_type']
)

def track_db_query(operation, table):
    def decorator(func):
        def wrapper(*args, **kwargs):
            start = time.time()
            try:
                result = func(*args, **kwargs)
                DB_QUERY_DURATION.labels(operation=operation, table=table).observe(time.time() - start)
                return result
            except Exception as e:
                DB_ERRORS.labels(operation=operation, error_type=type(e).__name__).inc()
                raise
        return wrapper
    return decorator

# 使用
@track_db_query('select', 'orders')
def get_orders(user_id):
    return db.query("SELECT * FROM orders WHERE user_id = ?", user_id)
```

---

## 二、SLI/SLO 概念

### 定义

```
SLI (Service Level Indicator) → 服务等级指标
  - 一个可量化的指标
  - 例：HTTP 请求成功率 = 成功请求数 / 总请求数

SLO (Service Level Objective) → 服务等级目标
  - 对 SLI 设定的目标
  - 例：成功率 ≥ 99.9%（30 天窗口）

SLA (Service Level Agreement) → 服务等级协议
  - 对外承诺，有法律/经济后果
  - 例：成功率低于 99.9% 则赔偿
```

### SLI 类型

```
1. 可用性 SLI
   = 成功请求数 / 总请求数
   例：99.95% 的请求成功

2. 延迟 SLI
   = 满足延迟阈值的请求数 / 总请求数
   例：99% 的请求 < 500ms

3. 正确性 SLI
   = 正确处理数 / 总处理数
   例：99.99% 的订单正确处理

4. 吞吐量 SLI
   = 实际处理量 / 预期处理量
   例：处理 ≥ 10000 QPS

5. 覆盖度 SLI
   = 被覆盖的数据量 / 总数据量
   例：99.9% 的日志被采集
```

---

## 三、SLI/SLO 落地

### 定义 SLI

```yaml
# rules/sli_recording.yml
groups:
  - name: sli_recording
    interval: 30s
    rules:
      # 1. 可用性 SLI：成功率
      - record: service:availability:ratio_rate5m
        expr: |
          sum(rate(http_requests_total{status!~"5.."}[5m])) by (service)
          / sum(rate(http_requests_total[5m])) by (service)
      
      - record: service:availability:ratio_rate1h
        expr: |
          sum(rate(http_requests_total{status!~"5.."}[1h])) by (service)
          / sum(rate(http_requests_total[1h])) by (service)
      
      # 2. 延迟 SLI：99% 请求 < 500ms
      - record: service:latency_p99:5m
        expr: |
          histogram_quantile(0.99,
            sum by (service, le)(rate(http_request_duration_seconds_bucket[5m])))
      
      - record: service:latency_slo:ratio_rate5m
        # 延迟满足 SLO 的请求比例
        # bucket le="0.5" 是 ≤500ms 的请求数
        expr: |
          sum(rate(http_request_duration_seconds_bucket{le="0.5"}[5m])) by (service)
          / sum(rate(http_request_duration_seconds_count[5m])) by (service)
```

### 定义 SLO

```yaml
# rules/slo_alerting.yml
groups:
  - name: slo_alerts
    rules:
      # 可用性 SLO：30 天成功率 ≥ 99.9%
      - alert: AvailabilitySLOBurnRate
        expr: |
          (
            service:availability:ratio_rate5m{service="payment"} < 0.999
            and
            service:availability:ratio_rate1h{service="payment"} < 0.999
          )
        for: 2m
        labels:
          severity: critical
          slo: availability
          service: payment
        annotations:
          summary: "Payment SLO: availability burning fast"
      
      # 延迟 SLO：P99 < 500ms
      - alert: LatencySLOBurnRate
        expr: service:latency_p99:5m{service="payment"} > 0.5
        for: 5m
        labels:
          severity: warning
          slo: latency
          service: payment
```

### 多窗口多燃烧率

```yaml
groups:
  - name: slo_multi_window
    rules:
      # 快速燃烧：5分钟 + 1小时
      # 2% 错误率持续 1 小时 = 消耗 30 天预算的 14.4%
      - alert: SLOFastBurn
        expr: |
          (
            service:availability:ratio_rate5m < (1 - 0.001) * 0.02
            and service:availability:ratio_rate1h < (1 - 0.001) * 0.02
          )
        for: 5m
        labels:
          severity: critical
      
      # 慢速燃烧：30分钟 + 6小时
      # 0.1% 错误率持续 6 小时 = 消耗 30 天预算的 3.6%
      - alert: SLOSlowBurn
        expr: |
          (
            service:availability:ratio_rate30m < (1 - 0.001) * 0.001
            and service:availability:ratio_rate6h < (1 - 0.001) * 0.001
          )
        for: 30m
        labels:
          severity: warning
```

### 错误预算（Error Budget）

```
SLO = 99.9% 可用性（30 天）
错误预算 = 0.1% × 30天 = 43.2 分钟

  时间段    剩余预算     已用
  Day 1     43.2m       0m
  Day 7     43.2m       5m（正常波动）
  Day 15    43.2m       20m（需要注意）
  Day 25    43.2m       40m（即将耗尽）
  Day 28    43.2m       45m（超支！停止发版）
```

```yaml
# 错误预算计算
groups:
  - name: error_budget
    rules:
      - record: service:error_budget:remaining
        expr: |
          1 - (
            (1 - service:availability:ratio_rate30d)
            / (1 - 0.999)
          )
      
      - alert: ErrorBudgetExhausted
        expr: service:error_budget:remaining < 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Error budget exhausted, freeze deployments"
```

---

## 四、SLO Dashboard

### Grafana SLO 面板

```promql
# 1. 当前 SLI 值（30 天窗口）
service:availability:ratio_rate30d

# 2. SLO 目标线（99.9%）
# Grafana Threshold: 0.999

# 3. 错误预算消耗
1 - service:error_budget:remaining

# 4. SLI 趋势（多时间窗口）
service:availability:ratio_rate1h    # 1 小时
service:availability:ratio_rate6h     # 6 小时
service:availability:ratio_rate1d     # 1 天
service:availability:ratio_rate7d     # 7 天
service:availability:ratio_rate30d    # 30 天
```

### SLO 燃烧率图

```promql
# 燃烧率 = 实际错误率 / 允许错误率
(1 - service:availability:ratio_rate5m) / (1 - 0.999)

# 燃烧率 > 1 → 消耗速度超过预算
# 燃烧率 < 1 → 消耗速度低于预算
```

---

## 五、SLO 实施流程

### 第一步：定义关键服务

```
关键服务 → 定义 SLO
  - 核心业务路径
  - 用户直接使用
  - 故障影响大

非关键服务 → 不需要 SLO
  - 内部工具
  - 后台任务
```

### 第二步：选择 SLI

```
支付服务 SLI：
  1. 可用性 → 成功率 ≥ 99.95%
  2. 延迟 → P99 ≤ 500ms
  3. 正确性 → 0 重复扣款

用户服务 SLI：
  1. 可用性 → 登录成功率 ≥ 99.9%
  2. 延迟 → P95 ≤ 200ms
```

### 第三步：设定 SLO 目标

```
SLO 目标设定原则：
  - 不要追求 100%（不可能实现）
  - 99.9% 是合理起点
  - 99.99% 需要大量工程投入
  - 99.999% 只有极少数系统能达到
```

### 第四步：监控与告警

```
告警层级：
  SLO 快速燃烧 → 立即处理（Critical）
  SLO 慢速燃烧 → 计划处理（Warning）
  错误预算耗尽 → 冻结发布（Critical）
```

### 第五步：定期回顾

```
每月 SLO 回顾会议：
  1. 上月 SLI 是否达到 SLO？
  2. 错误预算使用情况？
  3. 超支原因分析？
  4. SLO 目标是否需要调整？
  5. 下月改进计划？
```

> ⚠️ **踩坑提示**：
> - 不要所有服务都设 99.99%，成本太高
> - SLI 要可量化，不要用"用户满意度"这种模糊指标
> - 告警只设"快/慢燃烧"两种，不要每次低于 SLO 就告警
> - 错误预算用完要真的冻结发布，否则 SLO 就是空话

---

## 要点回顾

| 概念 | 定义 | 示例 |
|------|------|------|
| SLI | 服务等级指标 | 成功率 = 成功/总数 |
| SLO | 服务等级目标 | 成功率 ≥ 99.9% |
| SLA | 服务等级协议 | 低于 99.9% 赔偿 |
| Error Budget | 错误预算 | 0.1% × 30天 = 43.2m |
| Burn Rate | 燃烧率 | 实际错误率/允许错误率 |

- 四个黄金指标：延迟、流量、错误、饱和度
- RED 方法适合请求驱动服务，USE 适合资源
- SLI 用 Recording Rule 预计算多时间窗口
- 多窗口多燃烧率告警避免误报
- 错误预算用完要冻结发布

---

## 下一篇预告

最后一篇 **【Prometheus·落地篇】企业级监控平台架构：从规划到运维手册** 将从全局视角讲解企业监控平台的完整建设。

有了 Exporter、Grafana、Alertmanager，但应用本身的指标怎么埋？SLI/SLO 怎么定义和落地？本篇从微服务指标埋点到 SLO 告警，给出完整实战方案。

【Prometheus·进阶篇】监控实战：微服务指标埋点与 SLI/SLO 落地

研发部经理

云计算

后端

运维

本文详解微服务指标埋点与SLO告警实践：基于RED/USE方法定义四个黄金指标，通过Prometheus实现请求、业务、数据库埋点；阐述SLI/SLO/SLA概念及Recording Rule落地；提供多窗口燃烧率告警、错误预算计算和Grafana面板方案，附完整代码示例与实施避坑指南。

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【Prometheus·进阶篇】监控实战：微服务指标埋点与 SLI/SLO 落地-腾讯云开发者社区-腾讯云

【Prometheus·进阶篇】监控实战：微服务指标埋点与 SLI/SLO 落地

【Prometheus·进阶篇】监控实战：微服务指标埋点与 SLI/SLO 落地

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐