28、微服务监控、告警与日志追踪全解析

吃瓜不吐籽595

于 2025-08-20 11:21:19 发布

阅读量87

点赞数

CC 4.0 BY-SA版权

分类专栏：构建与部署微服务的实战指南文章标签：微服务监控告警

本文链接：https://blog.youkuaiyun.com/oauth7security/article/details/150756843

构建与部署微服务的实战指南专栏收录该内容

33 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

微服务监控、告警与日志追踪全解析

1. 利用 Prometheus 和 Grafana 监控系统

在系统监控方面，我们可以借助 Prometheus 和 Grafana 构建有效的监控体系。设置好的仪表盘虽简单，但能让我们对系统的运行状态有一个整体的了解，还能收集系统中各项服务操作的时间相关指标。

1.1 设置告警

当我们开始收集并存储指标后，就可以为特定指标设置告警，当指标值偏离正常范围时触发通知。例如，处理请求时间增加、错误百分比上升、计数器异常变化等情况都可以作为告警的触发条件。

以市场服务为例，当通过网关服务下达卖单时，会触发多个事件，而市场服务处理下单事件往往是瓶颈所在。我们可以设置一个告警，当市场下单队列中的消息数量超过某个阈值时发送通知。通知渠道可以有多种，如电子邮件、Slack、PagerDuty、Pingdom、Webhook 等。

这里我们将设置一个 Webhook 通知，当任何消息队列中的消息数量超过 100 时，告警服务器会收到消息。当前的告警服务是一个简单的应用程序，在启动其他应用和服务时也会同时启动，它会监听传入的 POST 消息。

以下是一个告警消息的示例：

alerts.alert.d26ab4ca-1642-445f-a04c-41adf84145fd: 
{
  "evalMatches": [
    {
      "value":158.33333333333334, 
      "metric":"evt-orders_service-order_created--market_service.place_order", 
      "tags":{
        "__name__":"rabbitmq_queue_messages",
        "exporter":"rabbitmq",
        "instance":"rabbitmq:15672",
        "job":"rabbitmq",
        "queue":"evt-orders_service-order_created--market_service.place_order", 
        "vhost":"/"
      }
    }
  ],
  "message":"Messages accumulating in the queue",
  "ruleId":1,
  "ruleName":"High number of messages in a queue", 
  "ruleUrl":"http://localhost:3000/dashboard/db/rabbitmq-metrics?fullscreen\u0026edit\u0026tab=alert\u0026panelId=2\u0026orgId=1",
  "state":"alerting", 
  "title":"[Alerting] High number of messages in a queue"
}

当队列中的消息数量低于告警阈值时，服务也会发出通知：

alerts.alert.209f0d07-b36a-43f4-b97c-2663daa40410: 
{
  "evalMatches":[],
  "message":"Messages accumulating in the queue",
  "ruleId":1,
  "ruleName":"High number of messages in a queue", 
  "ruleUrl":"http://localhost:3000/dashboard/db/rabbitmq-metrics?fullscreen\u0026edit\u0026tab=alert\u0026panelId=2\u0026orgId=1",
  "state":"ok",
  "title":"[OK] High number of messages in a queue"
}

1.2 在 Grafana 中设置告警的步骤

1.2.1 设置通知渠道

点击屏幕左上角的 Grafana 图标。
在“Alerting”菜单下，选择“Notification Channels”。
输入渠道名称，选择类型为“Webhook”，然后勾选“Send on All Alerts”选项。
输入接收告警的服务的 URL，这里使用告警服务并监听 POST 请求。
点击“Send Test”按钮验证是否正常工作，如果正常则点击“Save”保存更改。

1.2.2 创建告警

在之前创建的 RabbitMQ 仪表盘的消息队列面板上设置告警。点击“Messages/Queue”面板标题，在弹出的菜单中选择“Edit”，然后在“Alert”标签下创建新的告警。
- 在“Alert Config”屏幕中，首先添加告警名称以及评估条件的频率（这里设置为每 30 秒）。
- 设置告警条件，当从查询 A 收集的值的平均值在最后一分钟内高于 100 时触发告警。点击“Metrics”标签可以查看查询 A，它对应的是“rabbitmq_queue_messages”指标，还可以点击“Test Rule”按钮测试设置的规则。
- 在“Alert”标签下，还可以查看已配置告警的历史记录。

1.3 告警设置流程图

graph LR
    A[点击 Grafana 图标] --> B[选择 Alerting 菜单下的 Notification Channels]
    B --> C[输入渠道名称，选择 Webhook 类型，勾选 Send on All Alerts]
    C --> D[输入接收告警服务的 URL]
    D --> E[点击 Send Test 按钮验证]
    E --> F{验证是否通过}
    F -- 是 --> G[点击 Save 保存更改]
    F -- 否 --> C
    G --> H[在 RabbitMQ 仪表盘的 Messages/Queue 面板点击 Edit]
    H --> I[在 Alert 标签下创建新告警]
    I --> J[设置告警名称和评估频率]
    J --> K[设置告警条件（查询 A 平均值最后一分钟高于 100）]
    K --> L[可点击 Metrics 查看指标，点击 Test Rule 测试规则]
    L --> M[在 Alert 标签查看告警历史记录]

2. 发出合理且可操作的告警

拥有监控基础设施可以测量系统性能并记录历史数据，还能设置阈值，当阈值被突破时自动发出通知。但要注意，过多的信息可能会让人应接不暇，导致人们忽略重要的告警。因此，发出的告警必须是可操作的，并且要针对组织中正确的人员。

2.1 确定告警目标人群

在日常运营中，告警应针对服务的创建和拥有团队，这符合“你构建，你运行”的理念。团队创建和部署服务后，对服务最了解的人最能解读和响应服务产生的告警。

组织可能有轮班值班或专门的团队来接收和监控告警，并在必要时将其升级到专业团队。设置告警和通知时，要考虑到其他人员可能会接收这些信息，所以告警应简洁明了，每个服务最好有常见问题和诊断方法的文档，方便值班团队处理告警。

2.2 告警优先级分类

严重问题 ：应触发通知，确保服务构建团队的工程师或值班工程师收到消息。
中度严重问题 ：在合适的渠道生成告警通知，监控人员可以及时处理，但不需要立即中断工作或在半夜唤醒某人。
低优先级告警 ：仅生成记录，不一定供人类使用，服务可以接收并根据需要采取行动，如响应时间增加时自动扩展服务。

2.3 以症状而非原因触发告警

告警应基于症状而非原因触发。例如，用户无法访问服务这一症状应触发告警，而不是针对每个未处于正常范围的参数都设置告警。因为部分信息无法让我们了解系统的整体情况和问题所在。

以股票市场下单流程为例，多个服务协同工作，通信主要是异步的，很难确定错误发生的原因。我们可以设置一个告警，关联到达网关的请求数量和下达订单的通知数量，通过比较这两个指标的比率，能发现订单下达数量大于完成数量这一症状，然后以此为起点进行调查，找出问题的根源。

2.4 告警设置要点总结

要点	说明
目标人群	针对服务拥有团队，考虑其他接收人员
优先级分类	严重、中度、低优先级
触发依据	以症状而非原因触发
信息要求	简洁明了，有常见问题文档

3. 观察整个应用程序

关联不同服务的指标可以帮助我们更全面地了解系统状态，监控还能让我们理解系统在不同条件下的行为，从而预测和调整系统容量。

3.1 指标关联示例

A ：创建一个新的可视化，比较到达网关的请求速率和订单服务的请求速率，当这个比率低于 99% 时设置告警，以了解处理用户传入请求是否存在问题。
B ：关联用户向网关发出的请求数量和队列中订单创建消息的数量，由于订单服务负责发布这些消息，这样可以了解系统是否正常工作以及客户请求是否得到处理。
C ：关联订单下达消息的数量和订单服务的请求数量，以此推断费用服务是否正常工作。

3.2 指标关联示意图

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A[网关]:::process -->|请求| B[订单服务]:::process
    B -->|订单创建消息| C[事件队列]:::process
    C -->|订单下达消息| B
    A -->|请求| D[费用服务]:::process
    B -->|请求| D
    A -->|请求| E[市场服务]:::process
    B -->|请求| E
    F[用户] -->|请求| A
    style A fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    style B fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    style C fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    style D fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    style E fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    style F fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px

    subgraph 指标关联
    direction LR
    A1[网关请求速率]:::process -->|关联| B1[订单服务请求速率]:::process
    A2[用户请求数量]:::process -->|关联| C1[订单创建消息数量]:::process
    C2[订单下达消息数量]:::process -->|关联| B2[订单服务请求数量]:::process
    end

通过将不同的指标组合到新的仪表盘并设置合理的告警，我们可以深入了解整个应用程序。目前我们已经完成了监控和告警的设置，但这只是应用可观测性工作的一部分，还需要进一步投入日志记录和跟踪，以了解系统行为的原因。

4. 利用日志和跟踪理解系统行为

在微服务架构中，仅依靠指标和告警不足以实现全面的可观测性。我们还需要收集日志并跟踪服务之间的交互，这样不仅能了解系统的整体行为，还能回溯每个请求的历史，有助于调试错误和识别瓶颈。

4.1 微服务架构下日志管理的挑战

在基于微服务的架构中，多个服务协同为用户提供功能。由于服务分布在多个节点上，具有临时性且不断部署和扩展，很难通过访问日志来跟踪每个请求。

以卖单用例为例，在单应用程序中，我们可以登录机器并检查硬盘上存储的日志数据。但在微服务应用中，多个服务独立运行，每个服务有多个实例，一个请求可能会流经不同物理机器上的多个 Pod，很难通过访问日志来追踪请求。即使日志数据有持久化机制，跟踪请求也并非易事。

4.2 解决日志管理问题的目标

为了能充分理解系统行为，我们需要做到以下几点：
- 确保日志数据在服务重启和扩展时能够持久化。
- 将多个服务及其实例的所有日志数据聚合到一个中心位置。
- 使存储的数据易于使用，方便搜索和进一步处理。

我们的目标是构建一个基础设施，能够收集所有服务的日志数据，进行聚合，并允许我们进行搜索，以便随时分析系统的行为。利用这些数据，我们可以进行审计、调试或获取新的见解。

4.3 日志管理改进步骤

步骤	说明
持久化	采用合适的存储方案，确保日志在服务变化时不丢失
聚合	使用日志收集工具将分散的日志集中到一处
易用性	建立索引和搜索机制，方便快速查找和分析日志

4.4 日志管理流程图

graph LR
    A[各个服务产生日志] --> B[日志收集器收集日志]
    B --> C[将日志存储到中心位置]
    C --> D[建立索引和搜索机制]
    D --> E[用户可以进行日志搜索和分析]

通过以上的监控、告警、日志和跟踪的综合措施，我们能够更全面地了解微服务系统的运行状态，及时发现并解决问题，确保系统的稳定运行。

5. 构建日志存储与管理基础设施

5.1 日志存储格式

为了使日志数据易于机器读取和处理，我们应将日志以一致且结构化的方式存储。例如，可以使用 JSON 格式来记录日志，这样每条日志记录都具有清晰的键值对结构，便于后续的搜索和分析。

以下是一个简单的 JSON 格式日志示例：

{
    "timestamp": "2024-01-01T12:00:00Z",
    "service": "order_service",
    "level": "INFO",
    "message": "Order created successfully",
    "order_id": "12345"
}

5.2 日志收集工具

为了实现日志的聚合，我们可以使用一些常见的日志收集工具，如 Fluentd、Logstash 等。这些工具可以从各个服务节点收集日志，并将其发送到中心存储位置。

以 Fluentd 为例，其配置文件示例如下：

<source>
  @type tail
  path /var/log/service.log
  tag service.log
  format json
</source>

<match service.log>
  @type elasticsearch
  host elasticsearch_host
  port 9200
  index_name service_logs
</match>

上述配置表示 Fluentd 会从 /var/log/service.log 文件中收集 JSON 格式的日志，并将其发送到 Elasticsearch 中存储。

5.3 中心存储位置

中心存储位置可以选择 Elasticsearch、S3 等。Elasticsearch 是一个强大的搜索和分析引擎，非常适合存储和查询日志数据。S3 则提供了高可用性和可扩展性的存储服务。

以 Elasticsearch 为例，我们可以使用 Kibana 作为可视化界面，方便查看和分析存储在 Elasticsearch 中的日志数据。

5.4 日志管理基础设施构建步骤总结

步骤	操作
确定日志格式	选择 JSON 等结构化格式
选择日志收集工具	如 Fluentd、Logstash 等
配置日志收集	根据工具要求配置收集源和目标
选择中心存储位置	如 Elasticsearch、S3 等
建立可视化界面	使用 Kibana 等工具查看和分析日志

5.5 日志管理基础设施构建流程图

graph LR
    A[各个服务产生日志] --> B[选择日志收集工具（如 Fluentd）]
    B --> C[配置日志收集（设置收集源和目标）]
    C --> D[选择中心存储位置（如 Elasticsearch）]
    D --> E[建立可视化界面（如 Kibana）]
    E --> F[用户可以查看和分析日志]

6. 利用跟踪和关联 ID 理解系统行为

6.1 跟踪的概念

跟踪是一种记录请求在系统中流动过程的技术。通过跟踪，我们可以了解每个请求在不同服务中花费的时间，从而找出性能瓶颈。

6.2 关联 ID 的作用

关联 ID 是一个唯一的标识符，在请求进入系统时生成，并在整个请求流程中传递。通过关联 ID，我们可以将不同服务中与同一个请求相关的日志和跟踪信息关联起来，从而完整地跟踪请求的生命周期。

6.3 实现跟踪和关联 ID 的步骤

生成关联 ID ：在请求进入系统的入口处（如网关）生成一个唯一的关联 ID。
传递关联 ID ：在请求调用其他服务时，将关联 ID 作为请求头传递给下游服务。
记录关联 ID ：每个服务在处理请求时，将关联 ID 记录到日志中。
跟踪请求 ：使用跟踪工具（如 Jaeger、Zipkin 等）记录请求在各个服务中的执行时间和调用关系。

6.4 跟踪和关联 ID 实现步骤示意图

graph LR
    A[用户请求进入网关] --> B[网关生成关联 ID]
    B --> C[网关将关联 ID 放入请求头]
    C --> D[请求调用服务 1]
    D --> E[服务 1 记录关联 ID 到日志]
    E --> F[服务 1 继续调用服务 2 并传递关联 ID]
    F --> G[服务 2 记录关联 ID 到日志]
    G --> H[跟踪工具记录请求在各服务的执行时间和调用关系]

6.5 跟踪和关联 ID 示例代码（Python Flask 服务）

from flask import Flask, request
import uuid

app = Flask(__name__)

@app.before_request
def add_correlation_id():
    correlation_id = request.headers.get('X-Correlation-ID')
    if not correlation_id:
        correlation_id = str(uuid.uuid4())
    request.correlation_id = correlation_id
    print(f"Correlation ID: {correlation_id}")

@app.route('/')
def hello():
    return 'Hello, World!'

if __name__ == '__main__':
    app.run()

上述代码在 Flask 服务中实现了关联 ID 的生成和记录。

7. 总结

通过构建监控、告警、日志和跟踪体系，我们可以实现微服务系统的全面可观测性。具体总结如下：
- 监控：利用 Prometheus 和 Grafana 收集和展示系统指标，设置告警及时发现问题。
- 告警：发出合理且可操作的告警，针对正确的人群，以症状触发告警。
- 日志：解决微服务架构下日志管理的挑战，实现日志的持久化、聚合和易用性。
- 跟踪：利用跟踪和关联 ID 完整地跟踪请求的生命周期，找出性能瓶颈。

通过以上措施，我们能够更好地理解系统行为，及时发现和解决问题，确保微服务系统的稳定运行。

方面	工具/方法	作用
监控	Prometheus、Grafana	收集指标、展示数据、设置告警
告警	Grafana 告警设置	及时通知异常情况
日志	Fluentd、Elasticsearch、Kibana	持久化、聚合和分析日志
跟踪	Jaeger、Zipkin、关联 ID	跟踪请求流程、找出瓶颈