DevOps - 持续监控

更新于 2025/12/12 10:11:00

DevOps 中的持续监控 (CM) 意味着实时观察、跟踪和检查系统、应用程序和基础设施的指标。主要目标是保持一切运行良好，尽早发现问题，并在影响用户之前修复它们。

持续监控包括以下内容 −

从应用程序和基础设施收集日志、指标和跟踪。
当某些东西超过设定的限制时发送警报。
提供有关性能、可靠性和安全性的见解。

与老式监控不同，CM 非常适合 DevOps 管道。这确保了反馈循环在软件交付过程中保持顺畅。

持续监控在 DevOps 生命周期中的作用

持续监控对于保持 DevOps 工作流程的可靠性和高效性非常重要。它在许多方面都有帮助 −

改进反馈循环 − 为团队提供部署的实时更新，以便他们能够更快地发现和修复问题。
增强自动化 − 与 CI/CD 工具配合使用以自动处理事情，例如回滚不良部署或扩展资源。
支持性能优化 − 检查资源的使用方式以及应用程序的运行方式，以使情况变得更好。
确保安全合规性 −实时监控安全问题、未经授权的访问和合规性问题。

通过在 DevOps 流程的每个步骤中添加监控，我们可以提供更好的软件，减少停机时间并提高用户满意度。

持续监控的组成部分

下表简要说明了持续监控的关键组成部分。

组件	描述	示例
监控工具和技术	这些工具帮助我们收集、组织和检查性能或操作数据。	Prometheus、Nagios、Zabbix、Datadog、Splunk、New Relic
指标	显示系统性能的可测量数据，如 CPU 和内存使用情况。	CPU 利用率、内存使用率、延迟、请求率
日志	日志是应用程序、服务器或设备创建的事件详细信息。它们为我们提供操作信息。	ELK Stack(Elasticsearch、Logstash、Kibana)、Fluentd、Graylog
跟踪	跟踪跟踪跨服务的请求路径。它们对于调试微服务很有用。	Jaeger、Zipkin、OpenTelemetry
警报和通知系统	当超过阈值时，这些系统会发送警报。它们会通知正确的团队。	Alertmanager (Prometheus)、PagerDuty、Opsgenie、Slack 集成、Microsoft Teams 通知

监控指标:要衡量什么

当我们进行持续监控时，我们需要跟踪不同的指标。这些指标有助于我们保持系统健康，使应用程序运行良好并实现业务目标。让我们看看关键类型的指标、它们的重要性以及一些示例。

系统指标:CPU、内存、磁盘和网络利用率

系统指标显示我们基础设施的运行情况。

CPU 利用率 − 告诉我们 CPU 的使用量。如果使用率过高，可能会导致性能问题。
内存使用率 − 跟踪已使用和可用内存。内存不足可能会导致崩溃。
磁盘 I/O − 测量读写速度。帮助我们找到存储瓶颈。
网络利用率 − 检查带宽、数据丢失和延迟。确保数据正常流动。

示例(Prometheus 查询)

# 所有节点的 CPU 利用率
rate(node_cpu_seconds_total{mode!="idle"}[5m])

# 内存使用率
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100

# 磁盘读/写
rate(node_disk_read_bytes_total[5m]), rate(node_disk_write_bytes_total[5m])

应用程序指标:请求率、响应时间和错误率

这些指标确保应用程序保持可靠并满足用户期望 −

请求速率 − 跟踪每秒有多少请求。显示工作量模式。
响应时间 − 说明处理请求需要多长时间。这对用户体验很重要。
错误率 − 以百分比形式跟踪失败的请求。数字高可能意味着存在错误或过载。

示例(Nginx 配置示例)

# 启用响应时间日志记录
log_format timed_combined '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" $request_time';
# Prometheus Exporter(响应时间示例指标)
http_server_requests_seconds_sum{job="nginx"}

业务指标:SLA、SLO 和用户体验指标

这些指标将系统性能与业务目标联系起来。

SLA(服务水平协议) − 我们向客户承诺的内容，例如 99.9% 的正常运行时间。
SLO(服务水平目标) − 满足 SLA 的内部目标，例如将响应时间保持在 200 毫秒以下。
用户体验指标 −跟踪延迟、可用性和无错误交互。

示例(使用 Prometheus 和 Alertmanager 的 SLO 配置)

# 定义响应时间的 SLO
- alert: ResponseTimeHigh
  expr: histogram_quantile(0.99, rate(http_server_requests_seconds_bucket[5m])) > 0.2
  for: 1m
  labels:
    severity: warning
  annotations:
    summary: "High response time detected"

通过跟踪系统、应用程序和业务指标，我们可以更快地解决问题。这可以保持性能平稳，并使 IT 与业务需求保持一致。Prometheus、Grafana 和 Nginx 日志等工具可以更轻松地设置强大的监控系统。

设置持续监控基础设施

要设置持续监控，我们需要工具来收集数据、显示指标和发送警报。下面，我们将逐步使用 Prometheus(用于监控)、Grafana(用于仪表板)和 Alertmanager(用于警报)创建一个完整的监控系统。

步骤 1:安装和配置 Prometheus

Prometheus 是监控的主要工具。它从系统和应用程序收集指标。

Prometheus 配置文件 (prometheus.yml)−

global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'node_exporter' # 监控系统指标
    static_configs:
      - targets: ['localhost:9100']
  - job_name: 'app'
    static_configs:
      - targets: ['localhost:8080'] # 您的应用程序指标端点

首先，下载 Prometheus 并安装它。然后，使用配置文件 − 运行 Prometheus

./prometheus --config.file=prometheus.yml

第 2 步:安装 Node Exporter 以获取系统指标

我们使用 Node Exporter 收集系统数据，如 CPU 和内存使用情况。

安装和启动 Node Exporter 的命令:

wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz
tar -xvf node_exporter-1.6.0.linux-amd64.tar.gz
./node_exporter &

步骤 3:配置应用程序指标(例如 Spring Boot)

我们的应用程序需要公开指标以供 Prometheus 收集。

将 Micrometer 依赖项添加到 pom.xml −

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

在 application.properties 中公开指标端点 −

management.endpoints.web.exposure.include=prometheus
management.metrics.export.prometheus.enabled=true

第 4 步:设置 Grafana 进行可视化

Grafana 帮助我们在图表和仪表板中查看指标。

安装 Grafana 并在 http://localhost:3000 中打开它。
添加 Prometheus 作为数据源。
使用预构建的仪表板来获取系统和应用指标。

仪表板查询示例(CPU 使用率)

rate(node_cpu_seconds_total{mode!="idle"}[5m])

第 5 步:使用 Alertmanager 配置警报

Prometheus 与 Alertmanager 配合使用发送警报。

prometheus.yml 中的警报规则 −

rule_files:
  - "alert_rules.yml"
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']

示例 alert_rules.yml

groups:
  - name: system_alerts
    rules:
      - alert: HighCPUUsage
        expr: avg(rate(node_cpu_seconds_total[2m])) > 0.8
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "High CPU Usage Detected"

运行 Alertmanager −

./alertmanager --config.file=alertmanager.yml

步骤 6:验证并测试设置

在 Grafana 中检查 系统指标，如 CPU 和内存。查看 应用指标，如请求率和错误计数。通过创建高 CPU 负载来测试警报。

通过此设置，我们拥有一个强大的监控系统。Prometheus 收集数据，Grafana 显示仪表板，Alertmanager 发送警报。这有助于 DevOps 团队跟踪性能并快速处理任何问题。

日志记录和分布式跟踪

日志记录和分布式跟踪对于发现问题、提高性能和跟踪微服务中发生的情况非常重要。以下是设置集中式日志记录和分布式跟踪的简单指南。我们还将展示如何配置日志聚合和跟踪采样。

集中式日志记录解决方案(例如 ELK Stack、Fluentd)

集中式日志记录意味着将来自许多服务的日志收集到一个地方。这使得分析和修复问题变得更加容易。

ELK Stack(Elasticsearch、Logstash、Kibana)

Elasticsearch 存储日志并允许我们搜索它们。
Logstash 处理日志并将其发送到 Elasticsearch。
Kibana 让我们使用 Web 界面查看和分析日志。

配置示例(Logstash 到 Elasticsearch) −

input {
   file {
      path => "/var/log/*.log"
      start_position => "beginning"
   }
}
filter {
   grok {
      match => { "message" => "%{COMMONAPACHELOG}" }
   }
}
output {
   elasticsearch {
      hosts => ["http://localhost:9200"]
      index => "logs-%{+YYYY.MM.dd}"
   }
}

Fluentd − Fluentd 是一个可以收集、处理并将日志发送到 Elasticsearch、Kafka 或云存储等地方的工具。

配置示例(Fluentd 与 Elasticsearch) −

<source>
   @type tail
   path /var/log/*.log
   pos_file /var/log/fluentd.pos
   format none
</source>
<match **>
   @type elasticsearch
   host localhost
   port 9200
   index_name fluentd
</match>

微服务的分布式跟踪(例如 Jaeger、Zipkin)

分布式跟踪可帮助我们跟踪请求在不同微服务中的移动情况。它让我们清楚地了解系统中发生延迟或错误的位置。

Jaeger − Jaeger 是一个用于分布式跟踪的开源工具。它可帮助我们跟踪请求在微服务中的移动情况并发现问题。

Jaeger 与 Spring Boot 集成的示例 −

<dependency>
    <groupId>io.jaegertracing</groupId>
    <artifactId>jaeger-client</artifactId>
    <version>1.7.0</version>
</dependency>

配置(application.properties)−

spring.sleuth.sampler.probability=1.0
spring.sleuth.trace-id128=true
spring.zipkin.enabled=true
spring.zipkin.baseUrl=http://localhost:9411/

Zipkin − Zipkin 是微服务中使用的另一种跟踪工具。它收集有关请求如何移动的数据并帮助发现延迟等问题。

Zipkin 集成(Spring Boot 示例) −

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

配置(application.properties)−

spring.zipkin.base-url=http://localhost:9411/
spring.sleuth.sampler.probability=1.0

配置日志聚合和跟踪采样

日志聚合 − 像 ELK 或 Fluentd 这样的集中式系统会从不同的来源(服务器、应用程序、容器)收集日志并将它们发送到一个地方。

在微服务中，我们可以向日志添加标签，例如服务名称和跟踪 ID，以连接不同服务之间的事件。

示例日志格式(带跟踪 ID)−

{
   "timestamp": "2024-11-22T14:00:00Z",
   "service": "payment-service",
   "trace_id": "abcd1234",
   "message": "Transaction successful"
}

跟踪采样 − 采样在分布式跟踪中非常重要。它帮助我们避免发送过多数据，从而降低系统速度。我们可以设置采样率来控制发送的数据量。

示例配置(Jaeger 采样率) −

sampling:
  rate: 0.1  # 对 10% 的请求进行抽样

示例配置(Zipkin 采样率)−

spring.sleuth.sampler.probability=0.1

日志记录和分布式跟踪对于理解系统如何工作以及修复微服务中的问题非常重要。像 ELK 和 Fluentd 这样的集中式日志记录工具可以轻松收集日志。Jaeger 和 Zipkin 帮助我们跟踪跨服务的请求流。

配置跟踪采样和日志聚合有助于保持系统快速运行并使故障排除更容易。这让 DevOps 团队能够确保其系统的高可靠性和可用性。

结论

在本章中，我们讨论了 DevOps 中持续监控的重要部分。我们介绍了一些关键内容，例如监控工具、指标、警报系统以及集中式日志记录和分布式跟踪的需求。

我们研究了 ELK 堆栈、用于日志聚合的 Fluentd 以及用于跨服务跟踪请求的 Jaeger 和 Zipkin 等解决方案。我们还提供了示例并展示了如何配置这些工具。这些实践和工具对于保持系统可靠性、提高性能和快速解决问题非常重要。

❮ DevOps 持续部署 DevOps 持续改进 ❯

DevOps 教程

DevOps 生命周期

DevOps 基础设施

DevOps 有用资源