本文详细介绍了 SRE 最应该监控的指标，通过引入 Google 4 Golden Signals、RED、USE 等方法论，并配合 Prometheus 配置说明，全面梳理讲解了各类关键指标的定义、计算方法和应用场景，帮助读者深入理解 SRE 监控的核心要素。这些知识是算是 SRE 的必备知识了。

现代系统越来越复杂，包含众多组件，以有时不可预测的方式相互作用。为了有效监控这些系统，您需要结构化的方法来帮助您关注最重要的指标。

四个黄金指标代表了一种以服务为中心的监控方法，能够直接让您了解用户体验和系统健康状况。这些信号由 Google 的 SRE 团队开发和记录，已成为现代可观测性实践的核心。四大黄金指标是：

这些指标共同提供了服务健康状况的全面视图。延迟和错误指标告诉您用户正在体验的服务质量。流量指标帮助您了解系统上的负载，并为其他指标提供上下文。饱和度指标表明您的服务接近其极限，并且可能会很快出现降级。

让我们深入探讨这些信号，了解它们如何共同形成一个全面的监控策略。

延迟衡量处理请求所需的时间。这通常以毫秒或秒为单位进行测量，提供了从用户角度来看服务性能的见解。

在衡量延迟时，区分成功的请求和失败的请求至关重要。失败的请求往往具有误导性的低延迟（例如，立即返回错误响应）或极高的延迟（如超时）。通过将这些测量值分开，可以更清楚地了解服务的实际性能。

类似于 RED 方法论中的持续时间指标，延迟应该作为分布而不是平均值来衡量。这意味着跟踪百分位数，例如：

中位数（第 50 百分位或 p50 ），这代表了典型的用户体验

第 90 百分位数（ p90 ），显示最慢的 10% 请求的表现

第 99 百分位数（ p99 ），突出显示您最慢的 1% 请求的体验

这是如何使用 Prometheus 和 Node.js 实现延迟跟踪的示例：

import { Histogram } from'prom-client';
constrequestLatency=newHistogram({
name:'http_request_duration_seconds',
help:'HTTP request latency in seconds',
labelNames: ['method', 'route', 'status_code'],
buckets: [0.01, 0.05, 0.1, 0.5, 1, 2.5, 5, 10]
});
functionlatencyMiddleware(req, res, next) {
conststart= Date.now();
res.on('finish', () => {
constduration= (Date.now() -start) /1000;
requestLatency.observe(
      {
method:req.method,
route:req.route?.path||req.path,
status_code:res.statusCode
      },
duration
    );
  });
next();
}

监控延迟有助于您设置合理的服务级别目标（SLO），并能快速检测性能降级，尤其是在只有部分请求受到影响的情况下。

流量指标衡量系统所承受的需求。这通常以每秒请求数的形式表示，但具体单位会因服务类型而异。

流量指标是您监控策略的基础元素。它们为解释其他指标提供了关键背景，并帮助您检测异常，例如使用量的意外激增或下降。

对于不同的系统，流量可能被测量为：

对于 Web 服务，每秒 HTTP 请求量

对于数据库，每秒查询数

对于队列系统，每秒处理的消息的数量

支付系统的每秒交易量

在实现流量指标时，你通常会使用一个随时间单调增加的计数器：

import { Counter } from'prom-client';
constrequestCounter=newCounter({
name:'http_requests_total',
help:'Total number of HTTP requests',
labelNames: ['method', 'route']
});
functiontrafficMiddleware(req, res, next) {
requestCounter.inc({
method:req.method,
route:req.route?.path||req.path
  });
next();
}

流量指标也有助于容量规划。通过分析历史流量模式，您可以预测未来的需求，并适当调整基础设施规模。通过流量指标，季节性模式、一周中的不同变化以及增长趋势都会变得清晰可见。

错误指标跟踪失败请求的速率。这包括任何没有按预期完成的请求，无论是由于显式错误、超时还是不正确的结果。

错误指标帮助你从用户的角度理解服务的可靠性。它们通常以绝对速率（每秒错误数）和总请求数的百分比来跟踪。

在实现错误指标时，明确你的服务中什么是“错误”非常重要。对于 Web 服务，HTTP 状态码在 4xx 和 5xx 范围内的通常被认为是错误，尽管你可能希望将客户端错误（4xx）和服务器错误（5xx）区分开来。

这是如何使用 Prometheus 实现错误跟踪的方法：

import { Counter } from'prom-client';
consterrorCounter=newCounter({
name:'http_request_errors_total',
help:'Total number of HTTP request errors',
labelNames: ['method', 'route', 'status_code', 'error_type']
});
functionerrorHandler(err, req, res, next) {
errorCounter.inc({
method:req.method,
route:req.route?.path||req.path,
status_code:res.statusCode||500,
error_type:err.name||'UnknownError'
  });
res.status(500).send('Something went wrong');
}

错误指标应包含足够的细节以帮助进行故障排除。添加错误类型、受影响的端点或错误来源等维度可以为调试问题提供有价值的上下文。

满载指标表示您的服务“满载”到何种程度。它们衡量系统当前使用的资源比例，并帮助预测系统何时可能开始经历性能降级。

饱和度通常是这四个信号中最复杂的，因为它因系统类型和资源而异。对于一个 Web 服务，饱和度可能涉及：

线程池利用率

数据库连接池使用情况

内存消耗

CPU 利用率

网络带宽使用情况

满载指标的关键洞察是，大多数系统在达到 100%利用率之前就开始降级。通过识别并监控系统中最受限的资源，您可以在影响用户之前预测和防止性能问题。

这是如何为连接池实现饱和度监控的一个示例：

import { Gauge } from'prom-client';
constconnectionPoolGauge=newGauge({
name:'db_connection_pool_usage_ratio',
help:'Database connection pool usage ratio',
labelNames: ['pool_name']
});
// Update the gauge regularly
functionupdateConnectionPoolMetrics() {
constpoolSize=db.pool.max;
constactiveConnections=db.pool.used;
connectionPoolGauge.set(
    { pool_name:'main' },
activeConnections/poolSize
  );
}
setInterval(updateConnectionPoolMetrics, 5000);

对于许多系统，饱和度的最佳衡量标准是存在排队现象。当系统开始排队工作而不是立即处理时，这是饱和的明显迹象。队列长度或等待时间等指标可以提供即将出现的问题的早期预警。

Prometheus 已经成为云原生环境中事实上的标准用于指标收集。其基于拉取的架构、强大的查询语言和广泛的生态系统使其成为实现“四大黄金信号”的优秀选择。

如果你是第一次使用 Prometheus，可以从设置一个基本实例开始。你可以将 Prometheus 作为 Docker 容器运行：

docker run -p 9090:9090 -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus

你的 prometheus.yml 配置文件应该包含你的服务的目标：

global:
scrape_interval: 15s
scrape_configs:
  - job_name: 'your-service'
static_configs:
      - targets: ['localhost:8080']

在你的服务中，你需要暴露一个 Prometheus 可以抓取的端点。对于 Node.js 应用程序，可以使用 prom-client 库：

importexpressfrom'express';
importpromClientfrom'prom-client';
constapp=express();
constregister=promClient.register;
// Expose metrics endpoint
app.get('/metrics', async (req, res) => {
res.set('Content-Type', register.contentType);
res.end(awaitregister.metrics());
});
app.listen(8080);

四个黄金指标并不是监控的唯一框架。它们可以与其他方法如 RED（速率、错误、持续时间）和 USE（利用率、饱和度、错误）相结合：

RED 关注服务级别的指标，与四个黄金信号类似，但不明确包含饱和度。

USE 侧重于资源级别的指标，并且非常关注基础设施健康。

四个黄金信号处于这些方法之间，提供了一个平衡的观点，既包括服务性能（延迟、错误），也包括资源健康（饱和度）。流量指标则为所有三种框架提供了上下文。

为了进行全面监控，请考虑使用这三个框架的所有元素：

对于服务健康状况：跟踪延迟、流量和错误（来自四大黄金指标或 RED）。

对于资源健康：跟踪饱和度（来自四大黄金指标）和详细的 USE 指标。

对于业务影响：在这些技术指标上添加自定义业务指标（极为关键）。

四大黄金指标提供了警报的基础。以下是每个信号的一些警报策略：

警报基于持续增加的高百分位延迟（例如 p99），因为这通常表示正在出现的问题。根据您的服务水平目标（SLO）设置阈值。示例 Prometheus 警报:

- alert: HighLatency
expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route)) > 2
for: 5m
labels:
severity: warning
annotations:
summary: "High latency on {{ $labels.route }}"
description: "P99 latency for {{ $labels.route }} is above 2 seconds"

当流量模式出现显著偏差时发出警报。这包括意外下降（可能表明上游问题）和意外峰值（可能表明攻击或病毒内容）。示例 Prometheus 警报:

- alert: LowTraffic
expr: sum(rate(http_requests_total[5m])) < 10
for: 10m
labels:
severity: warning
annotations:
summary: "Unusually low traffic detected"
description: "Request rate has fallen below 10 rps for 10 minutes"

当错误率或百分比超过 SLO 时发出警报。不同的服务可能对错误有不同的容忍度。示例 Prometheus 警报：

- alert: HighErrorRate
expr: sum(rate(http_request_errors_total[5m])) / sum(rate(http_requests_total[5m])) > 0.05
for: 5m
labels:
severity: critical
annotations:
summary: "High error rate detected"
description: "Error rate is above 5% for 5 minutes"

当资源接近其容量限制时发出警报。具体的阈值取决于系统的特性，但常见的做法是在达到 100%利用率之前发出警报。示例 Prometheus 警报：

- alert: HighConnectionPoolSaturation
expr: avg(db_connection_pool_usage_ratio) > 0.8
for: 5m
labels:
severity: warning
annotations:
summary: "Connection pool nearing capacity"
description: "Database connection pool usage is above 80% for 5 minutes"

四大黄金指标提供了一种强大的框架，用于监控和可观测性在现代服务中。通过实现这些指标，您可以获得对用户体验和系统健康状况的可见性，从而能够快速识别、诊断和解决问题。

虽然具体实现细节可能因您的特定技术栈而异，但基本原则保持不变：监控延迟、流量、错误和饱和度，以获得服务健康状况的全面视图。

通过将四大黄金指标与其他监控框架（如 RED 和 USE）结合使用，您可以构建一个强大的可观测性平台，帮助您维护可靠且高性能的服务，并使您的用户满意。

作者丨Ayooluwa Isaiah    编译丨SRETalk

来源丨原文网址：https://betterstack.com/community/guides/monitoring/sre-golden-signals/

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn