您将如何从头开始为应用程序设计监控？

Question

您将如何从头开始为应用程序设计监控？

Accepted Answer

从**用户的感受出发**，而不是从基础设施往上走。最可靠的主机集群在请求失败时就毫无价值，所以要从**面向用户的 SLI** 开始——**延迟**、**错误率**、**可用性**——然后添加四个黄金信号，最后再添加基础设施指标。

## 分层结构，从用户向内

```text
1. USER-FACING SLIs   → what the user experiences (latency, errors, availability)
2. GOLDEN SIGNALS     → latency, traffic, errors, saturation per service
3. INFRA METRICS      → CPU, memory, disk, network (causes, not symptoms)
```

如果您只关注 CPU 和磁盘（自下而上），您可能显示一切正常，但用户却收到 500 错误。从 SLI 开始监控（自上而下）意味着您对**用户实际感受到的症状**进行告警，然后深入到黄金信号和基础设施来找出根本原因。

## 流程：instrument → collect → dashboard → alert

```text
INSTRUMENT  app emits metrics/logs/traces (e.g. request_duration_seconds histogram)
   ↓
COLLECT     a TSDB scrapes/ingests them (Prometheus, Datadog agent)
   ↓
DASHBOARD   visualize SLIs + golden signals (Grafana) for humans to read
   ↓
ALERT       fire on SLO violations / burn rate, routed to on-call
```

## 一个具体的起点

```promql
# Availability SLI: fraction of requests that succeed
sum(rate(http_requests_total{status!~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# Latency SLI: p99 request latency
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
```

为每个 SLI 定义一个 **SLO**（例如 99.9% 可用性、p99 < 300ms），在仪表板上展示它们，并在 SLO 处于风险中时触发告警——而不是对每个抖动都告警。

## 为什么这很重要

自下而上构建的监控告诉您磁盘已满 80%，但不能告诉您客户是否无法结账。从面向用户的 SLI 开始，将每个仪表板和告警与真实的用户影响关联起来，保持告警噪声低，并在问题发生时提供清晰的分层路径（症状 → 黄金信号 → 基础设施原因）。