14、可观测性：监控与告警实践

最新推荐文章于 2025-11-02 09:00:46 发布

web99

最新推荐文章于 2025-11-02 09:00:46 发布

阅读量20

点赞数

CC 4.0 BY-SA版权

分类专栏： DevOps生存指南文章标签：可观测性监控告警

本文链接：https://blog.youkuaiyun.com/web99/article/details/151341468

DevOps生存指南专栏收录该内容

17 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

可观测性：监控与告警实践

1. 检查 CronJob 状态

在默认命名空间中，可通过以下命令检查 bbs-warrior CronJob 的状态：

$ minikube kubectl -- get pods -l app=bbs-warrior

示例输出如下：
| NAME | READY | STATUS | RESTARTS | AGE |
|--------------------------------|-------|-----------|----------|-----|
| bbs-warrior-1600646880-chkbw | 0/1 | Completed | 0 | 60s |

若输出显示 Completed ，则表明 bbs-warrior CronJob 约 60 秒前已成功完成。若状态不同，可检查 Pod 的日志以查找错误。

2. 指标监控

2.1 通用指标模式

为了更好地监控应用程序，建议使用通用的指标模式来统一所有应用。以 telnet-server 应用为例，将探索常见的黄金信号（Golden Signals）指标模式。

2.2 黄金信号指标

黄金信号由谷歌首次提出，包含四个指标，用于评估微服务的健康状况：
- 延迟（Latency） ：服务处理请求所需的时间。
- 流量（Traffic） ：应用程序接收的请求数量。
- 错误（Errors） ：应用程序报告的错误数量，如 Web 服务器报告的 500 错误。
- 饱和度（Saturation） ：服务的满负荷程度，可通过测量 CPU 使用率来确定系统在应用程序或主机变慢或无响应之前的剩余空间。

2.3 调整监控模式

实际应用可能无法完全适配预定义的监控模式，需根据实际情况判断重要指标。例如，在监控 telnet-server 应用时，由于用户通常不会连接、执行命令后立即退出，因此可以不跟踪延迟指标，而是关注流量、错误和饱和度信号，以从用户角度了解应用程序的整体健康状况。

2.4 其他指标模式

除了黄金信号，还有另外两种常见的指标模式：
- RED 方法 ：由 Grafana Labs 的 Tom Wilkie 创建，关注应用程序的健康状况，包括每秒请求率（Rate）、每秒失败请求数（Error）和请求处理时间（Duration）。
- USE 方法 ：由 Brendan Gregg 开发，用于快速发现基于底层资源的性能问题，包括资源利用率（Utilization）、饱和度（Saturation）和错误数（Errors）。

2.5 `telnet-server` 仪表盘

在 Grafana 仪表盘中， telnet-server 仪表盘包含三个黄金信号图和两个折叠的图形行，分别为系统（System）和应用程序（Application）。重点关注黄金信号图：
- 每秒连接数（Connections per second） ：提供流量黄金信号，测量两分钟内每秒的连接数。
- 饱和度（Saturation） ：表示饱和度黄金信号，测量 Kubernetes 对 telnet-server 容器 CPU 进行限流的时间。
- 每秒错误数（Errors per second） ：对应错误黄金信号，跟踪两分钟内每秒的连接错误数。

2.6 PromQL 查询语言

PromQL 是 Prometheus 应用内置的查询语言，用于查询和操作指标数据。以下是生成每秒错误数图的查询示例：

rate(telnet_server_connection_errors_total{job="kubernetes-pods"}[2m])

在创建告警规则时，可使用以下查询：

sum(rate(telnet_server_connection_errors_total{job="kubernetes-pods"}[2m])) > 2

该规则表示若每秒错误率大于 2，则告警查询结果为真。

3. 告警设置

3.1 良好告警的准则

创建告警时，需遵循以下准则：
- 不要将阈值设置过低，以免因指标波动导致告警频繁触发和清除，这种现象称为抖动（Flapping）。
- 避免创建无法采取行动的告警，即状态告警，以免给值班工程师带来困扰。

3.2 示例告警

提供了三个告警：
- HighErrorRatePerSecond ：关注每秒连接错误数，若两分钟内连接错误率大于 2，则告警触发。
- HighConnectionRatePerSecond ：检测两分钟内每秒连接率是否大于 2，当前该告警处于触发状态。
- HighCPUThrottleRate ：检测高 CPU 饱和度，若两分钟内 CPU 被 Kubernetes 限流超过 300 微秒，则告警触发。

3.3 查看告警

可在 Prometheus 或 Alertmanager 的 Web 界面查看告警。Prometheus 会显示所有告警，而 Alertmanager 仅显示触发的告警。在 Prometheus 中，告警有三种状态：待处理（Pending，黄色）、非活动（Inactive，绿色）和触发（Firing，红色）。

4. 路由与通知

4.1 配置 Alertmanager

为了在告警触发时发送电子邮件通知，需对 Alertmanager 进行配置。默认情况下，Alertmanager 配置将所有严重性标签为 Critical 的告警路由到 none 接收器，即不发送通知。为了实现电子邮件通知，需进行以下操作：

4.2 启用电子邮件通知

打开 Alertmanager 的 configmap.yaml 文件，其内容如下：

--snip--
    global: null
    receivers:
  1 #- name: email
    #  email_configs:
    #  - send_resolved: true
    #    to: <GMAIL_USERNAME@gmail.com>
    #    from: <GMAIL_USERNAME@gmail.com>
    #    smarthost: smtp.gmail.com:587
    #    auth_username: <GMAIL_USERNAME@gmail.com>
    #    auth_identity: <GMAIL_USERNAME@gmail.com>
    #    auth_password: <GMAIL_PASSWORD>
  2 - name: none
    route:
      group_by:
        - job
      group_interval: 5m
      group_wait: 10s
    3 receiver: none
      repeat_interval: 3h
      routes:
      4 - receiver: none
          match:
            severity: "Critical"

取消注释 email 接收器的相关行，并替换为可用于测试的电子邮件账户。
若使用 Gmail 且启用了 2FA，需设置应用专用密码作为通用用户名。
将 routes 部分下的 receiver 改为 email ，配置 Alertmanager 将严重性标签为 Critical 的告警路由到电子邮件接收器。修改后的 receiver 行如下：

- receiver: email

保存文件。

4.3 应用配置更改

在终端中执行以下命令更新 Alertmanager 的 ConfigMap：

$ minikube kubectl -- apply -f monitoring/alertmanager/configmap.yaml

然后重启 Alertmanager Deployment 以应用新配置：

$ minikube kubectl -- -n monitoring rollout restart deployment alertmanager

总结

通过以上步骤，我们可以实现对 telnet-server 应用的监控和告警设置，并配置 Alertmanager 发送电子邮件通知。在实际应用中，可根据具体需求调整监控指标和告警阈值，以确保应用程序的稳定运行。

流程图

graph LR
    A[检查 CronJob 状态] --> B[指标监控]
    B --> C[告警设置]
    C --> D[路由与通知]
    D --> E[应用配置更改]

指标模式对比表格

指标模式	关注重点	包含指标
黄金信号	微服务健康状况	延迟、流量、错误、饱和度
RED 方法	应用程序健康	每秒请求率、每秒失败请求数、请求处理时间
USE 方法	底层资源性能	资源利用率、饱和度、错误数

5. 告警系统深入理解

5.1 告警规则详解

在 Prometheus 中，告警规则是判断指标是否处于异常状态的依据。一个完整的告警规则包含告警名称、PromQL 查询、阈值和标签等信息。例如前面提到的 HighErrorRatePerSecond 告警，它使用了如下的 PromQL 查询：

sum(rate(telnet_server_connection_errors_total{job="kubernetes-pods"}[2m])) > 2

这里的 telnet_server_connection_errors_total 是指标名称， rate() 函数计算指定时间间隔内的每秒平均连接错误数， sum() 函数将两个 telnet-server Pod 的错误率相加。阈值设置为 2，即当总错误率大于 2 时，告警触发。

5.2 标签的作用

标签在告警系统中起着重要的作用。在 PromQL 查询中，标签可以用来筛选数据。例如在上面的查询中， {job="kubernetes-pods"} 就是一个标签筛选条件，它指定只获取 job 标签为 kubernetes-pods 的数据。在告警规则中，标签还可以用于分类和路由。比如在前面的三个示例告警中，都设置了 severity 标签，值为 Critical ，这样在 Alertmanager 中就可以根据这个标签来进行告警的路由。

5.3 告警状态转换

告警在 Prometheus 中有三种状态：待处理（Pending）、非活动（Inactive）和触发（Firing）。当指标满足告警规则的条件，但还未达到一定的持续时间时，告警处于待处理状态；当指标不满足告警规则的条件时，告警处于非活动状态；当指标满足告警规则的条件且达到了持续时间要求时，告警进入触发状态。例如 HighConnectionRatePerSecond 告警，当连接率大于 2 且持续一段时间后，就会从待处理状态转变为触发状态。

6. 监控系统的优化建议

6.1 指标选择优化

在选择监控指标时，要根据应用的特点和业务需求进行筛选。对于 telnet-server 应用，由于其使用场景的特殊性，不跟踪延迟指标是合理的。在其他应用中，也需要仔细分析哪些指标对了解应用的健康状况最有帮助，避免监控过多无关的指标，增加系统的负担。

6.2 阈值调整

阈值的设置要合理，既不能过高导致无法及时发现问题，也不能过低导致告警频繁触发。可以通过对历史数据的分析，结合业务的实际情况来确定合适的阈值。例如对于 HighErrorRatePerSecond 告警，初始设置的阈值为 2，在实际运行一段时间后，可以根据系统的稳定性和用户的反馈来调整这个阈值。

6.3 监控系统性能优化

随着监控数据的不断增加，监控系统的性能可能会受到影响。可以通过以下方式进行优化：
- 定期清理过期的监控数据。
- 对监控指标进行采样，减少数据量。
- 优化 PromQL 查询，避免复杂的查询操作。

7. 实际应用案例分析

7.1 高连接率告警处理

假设 HighConnectionRatePerSecond 告警触发，显示当前连接率超过了阈值。首先，我们需要查看 Connections per second 图，分析连接率的变化趋势。如果连接率突然升高，可能是由于某个时间段内有大量用户访问，或者是出现了异常的自动化脚本在频繁连接。可以通过查看系统日志，确定是否有异常的 IP 地址在发起连接。如果是正常的业务高峰导致连接率升高，可以考虑增加系统的资源，如增加 CPU 或内存，以提高系统的处理能力。

7.2 高错误率告警处理

当 HighErrorRatePerSecond 告警触发时，需要查看 Errors per second 图和相关的系统日志。如果错误率持续升高，可能是应用程序的代码出现了问题，或者是网络连接不稳定。可以通过分析错误日志，定位具体的错误原因。如果是代码问题，需要及时进行修复；如果是网络问题，需要检查网络设备和配置。

7.3 CPU 限流告警处理

对于 HighCPUThrottleRate 告警，当触发时需要查看 Saturation 图。如果 CPU 被限流，可能是系统资源不足，导致应用程序运行缓慢。可以通过增加 CPU 资源，或者优化应用程序的代码，减少 CPU 的使用。同时，要注意设置合适的 CPU 资源限制，避免过度限制导致系统性能下降。

8. 总结与展望

8.1 整体回顾

通过对 telnet-server 应用的监控和告警设置，我们学习了如何使用黄金信号等指标模式来评估应用的健康状况，如何使用 PromQL 查询语言来获取和处理监控数据，以及如何配置告警规则和 Alertmanager 进行告警的路由和通知。同时，我们也了解了在实际应用中如何优化监控系统和处理告警。

8.2 未来发展趋势

随着云计算和容器技术的不断发展，监控系统也将面临新的挑战和机遇。未来的监控系统将更加智能化，能够自动发现和分析问题，并提供更准确的告警和建议。同时，监控系统也将与其他系统进行更紧密的集成，如与自动化运维系统集成，实现自动修复问题。

流程图

graph LR
    A[告警触发] --> B[查看监控图]
    B --> C{问题类型}
    C -->|高连接率| D[分析连接率趋势]
    C -->|高错误率| E[查看错误日志]
    C -->|CPU 限流| F[查看饱和度图]
    D --> G[确定原因并处理]
    E --> G
    F --> G

告警处理步骤表格

告警类型	处理步骤
高连接率告警	查看 `Connections per second` 图，分析连接率趋势，查看系统日志，确定是否有异常 IP 地址，根据情况增加系统资源
高错误率告警	查看 `Errors per second` 图和系统日志，分析错误原因，根据情况修复代码或检查网络配置
CPU 限流告警	查看 `Saturation` 图，分析 CPU 使用情况，根据情况增加 CPU 资源或优化代码