由 Gemini 2.5 Flash Preview 05-20 生成

概述：为什么需要 Prometheus + Alertmanager + Grafana？

想象一下你的 Kubernetes 集群是一个繁忙的城市，里面有无数的建筑物（Pod）、车辆（Deployment/Service）和居民（Applications）。

  • Prometheus 就像是这个城市的“中央情报局”，它主动去各个角落收集信息（指标数据），并把这些信息有条不理地记录下来，方便以后查阅。
  • Alertmanager 就像是城市的“紧急呼叫中心”，它接收到情报局发来的各种紧急情况（告警），然后根据预设的规则，决定是不是真的紧急，要不要通知谁，怎么通知（电话、短信、邮件）。
  • Grafana 就像是城市的“作战指挥室大屏幕”，它把情报局收集到的数据以图表、仪表盘的形式直观地展示出来，让你一眼就能看出城市的运行状态，甚至还能预测潜在的问题。

它们共同组成了一个强大的监控告警体系，让你能够：

  1. 收集数据 (Prometheus)：知道你的应用和集群在做什么。
  2. 可视化 (Grafana)：直观地看到数据，发现趋势和异常。
  3. 告警 (Prometheus + Alertmanager)：在问题发生时及时通知你，甚至在问题发生前就预警。

1. Prometheus：指标收集与存储的王者

1.1 什么是 Prometheus？

Prometheus 是一个开源的系统监控和告警工具包。它的核心是一个时间序列数据库 (TSDB)，专门用于存储以时间戳标记的度量数据。它最显著的特点是拉取 (Pull) 模型，而不是传统的推送 (Push) 模型。

1.2 Prometheus 的核心组件和工作原理

Prometheus Architecture
(图片来源：Prometheus 官方网站)

  1. Prometheus Server (核心)：

    • Retrieval (抓取)：主动去配置的目标 (targets) 拉取指标数据。
    • Service Discovery (服务发现)：在 Kubernetes 环境中，Prometheus 不会固定地去拉取某个 IP 地址，而是通过 K8s API Server 动态发现要监控的服务、Pod、Node 等，并自动更新抓取目标列表。这是它在 K8s 中强大灵活的关键。
    • Storage (存储)：将拉取到的时间序列数据存储在本地磁盘（也可以配置远程存储）。
    • PromQL (查询语言)：提供了一种功能强大的查询语言 (Prometheus Query Language)，用于对存储的指标数据进行复杂的查询、聚合和分析。
    • Alerting Rules (告警规则)：根据 PromQL 定义告警规则。当查询结果满足特定条件时，Prometheus 会生成告警，并将告警发送给 Alertmanager。

  2. Exporters (数据暴露器)：

    • 由于 Prometheus 是拉取模型，被监控的对象需要将自己的指标数据暴露出来，供 Prometheus 拉取。Exporters 就是干这个的。
    • Exporters 是一些小型服务，它们从不同的系统（如操作系统、数据库、消息队列、自定义应用）收集数据，并将其转换为 Prometheus 可识别的格式（HTTP /metrics 路径上的纯文本）。
    • 在 Kubernetes 中常用的 Exporters：
      • Node Exporter：用于收集 Kubernetes 节点（物理机或虚拟机）的操作系统级别指标，如 CPU、内存、磁盘 I/O、网络 I/O 等。
      • Kube-State-Metrics：这是一个非常重要的 Kubernetes 专属 Exporter。它不监控物理资源，而是监听 Kubernetes API Server，生成有关 Kubernetes 资源对象（Pod、Deployment、Service、Node 等）状态的指标。例如，Pod 的运行状态、Deployment 的副本数、Job 的完成情况等等。
      • cAdvisor：内置于 Kubelet 中。Kubelet 会暴露一个 /metrics 端口，其中包含了由 cAdvisor 收集的容器级别的资源使用情况（CPU、内存、网络、文件系统）指标。Prometheus 可以直接抓取 Kubelet 的这个端口。
      • Pushgateway (特殊情况)：对于短暂的、批处理作业（如 CronJob），它们可能在 Prometheus 来抓取之前就已经执行完毕。Pushgateway 允许这些短暂作业将指标“推送”给它，然后 Prometheus 再从 Pushgateway 拉取。通常不推荐作为主要的数据收集方式，因为它违背了 Prometheus 的核心拉取模型，增加了单点故障和状态管理复杂性。
      • 各种应用的 Exporter：例如 mysql_exporter、redis_exporter、nginx_exporter 等，以及你自己的应用可能通过 Prometheus 客户端库直接暴露的指标。

  3. Alertmanager：Prometheus 发现告警后，将告警发送给 Alertmanager 进行进一步处理（详见下一节）。

1.3 PromQL 简介

PromQL 是 Prometheus 的核心查询语言。它非常强大，可以进行：

  • 选择 (Select)：根据标签选择时间序列。
  • 过滤 (Filter)：过滤特定的标签值。
  • 聚合 (Aggregate)：对多个时间序列进行求和、平均、最大值等操作。
  • 计算 (Calculate)：进行数学运算，如 rate() (每秒增长率)、irate() (瞬时增长率)、sum by()、avg by() 等。

示例 PromQL：

  • node_cpu_seconds_total：获取所有节点 CPU 使用总时间的原始计数器。
  • sum(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)：计算过去 5 分钟内，每个节点空闲 CPU 使用率的变化率，并求和（间接得到忙碌CPU利用率）。
  • kube_pod_container_resource_limits_cpu_cores：获取 Pod 容器的 CPU Limit。
  • kube_pod_status_phase{phase="Running"}：获取所有处于 Running 状态的 Pod。

1.4 Prometheus 在 Kubernetes 中的部署

在 Kubernetes 中部署 Prometheus 最推荐的方式是使用 Prometheus Operator。它大大简化了 Prometheus 及其相关组件的部署和管理，提供了 ServiceMonitor、PodMonitor、PrometheusRule 等 CRD (Custom Resource Definitions)，让你可以通过声明式配置来管理监控目标和告警规则。

2. Alertmanager：告警处理与分发的指挥中心

2.1 什么是 Alertmanager？

Alertmanager 是 Prometheus 生态系统中的一个独立组件，它负责处理从 Prometheus 服务器接收到的告警。它的主要功能是告警的去重、分组、静默、抑制和路由。

2.2 Alertmanager 的核心功能

Prometheus 只是生成告警，而 Alertmanager 才是告警的“管家”和“调度员”。它解决了以下痛点：

  1. Grouping (分组)：

    • 当大量相关告警同时触发时（例如，数据中心断电，导致所有服务器都发出“宕机”告警），Alertmanager 可以将这些告警聚合成一个单一的通知。
    • 这避免了“告警风暴”，防止你的通知渠道被刷屏。
    • 你可以根据标签（如 cluster, severity, alertname）来定义分组策略。

  2. Inhibition (抑制)：

    • 一个告警可能意味着另一个更高级别的告警。例如，如果整个集群都宕机了，那么集群中所有 Pod 宕机的告警就显得多余了。
    • Alertmanager 可以配置抑制规则：当一个特定告警（如ClusterDown）被触发时，它可以自动抑制（阻止发送）相关联的次要告警（如PodDown）。

  3. Silences (静默)：

    • 当你知道某个告警是预期的（比如正在进行维护，或者已知bug），或者正在处理某个问题不想被重复通知时，可以手动设置一个“静默期”。
    • 在静默期内，即使 Prometheus 持续生成该告警，Alertmanager 也不会发送通知。

  4. Routing (路由)：

    • 根据告警的严重程度、源头、类型等标签，将告警发送到不同的接收器 (Receivers)。
    • 例如：severity=critical 的告警发送到 PagerDuty 或电话；severity=warning 的告警发送到 Slack 频道；severity=info 的告警发送到邮件。

  5. Receivers (接收器)：

    • Alertmanager 支持多种通知渠道，包括：
      • Email (SMTP)
      • Slack
      • PagerDuty
      • OpsGenie
      • Webhook (可以集成到自定义的通知系统，如飞书、钉钉、企业微信等)
      • SMS (通过集成第三方服务)
      • ...以及更多

2.3 Alertmanager 的配置示例

Alertmanager 的配置主要通过 alertmanager.yml 文件完成，定义了路由策略和接收器。

# alertmanager.yml 示例
global:
  resolve_timeout: 5m # 告警解决的超时时间

route:
  receiver: 'default-receiver' # 默认告警发送给 default-receiver
  group_by: ['alertname', 'cluster', 'service'] # 告警按这些标签分组
  group_wait: 30s # 首次通知前的等待时间，用于收集更多同类告警
  group_interval: 5m # 同组告警的后续通知间隔
  repeat_interval: 1h # 即使告警未解决，也每小时重复通知一次

  routes:
  - match:
      severity: 'critical'
    receiver: 'pagerduty-receiver' # 严重告警发送给 PagerDuty
    group_wait: 10s # 严重告警尽快通知
    repeat_interval: 30m

  - match:
      severity: 'warning'
    receiver: 'slack-receiver' # 警告告警发送给 Slack

  - match:
      alertname: 'HostDown'
    receiver: 'opsgenie-receiver' # 特定告警发送给 OpsGenie

receivers:
- name: 'default-receiver'
  email_configs:
  - to: 'devops@example.com'
    send_resolved: true # 告警恢复时也发送通知

- name: 'pagerduty-receiver'
  pagerduty_configs:
  - service_key: 'YOUR_PAGERDUTY_SERVICE_KEY'

- name: 'slack-receiver'
  slack_configs:
  - channel: '#alerts-dev'
    api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
    text: '{{ .CommonLabels.alertname }} fired! Severity: {{ .CommonLabels.severity }}' # 通知模板

- name: 'opsgenie-receiver'
  opsgenie_configs:
  - api_key: 'YOUR_OPSGENIE_API_KEY'
    region: 'us' # 或 'eu'

3. Grafana：数据可视化与洞察的利器

3.1 什么是 Grafana？

Grafana 是一个开源的数据可视化和仪表盘工具。它不收集数据，也不存储数据，它只是一个数据展示平台。通过连接各种数据源（如 Prometheus、Elasticsearch、InfluxDB、MySQL 等），Grafana 能够将数据以各种精美、直观的图表形式展示出来，帮助你理解数据、监控系统状态、发现趋势和进行故障排查。

3.2 Grafana 的核心功能

  1. Data Sources (数据源)：

    • Grafana 支持非常多的数据源。对于我们这里，最主要的就是 Prometheus。
    • 配置 Prometheus 为数据源后，Grafana 就可以通过 PromQL 去 Prometheus 查询指标数据。

  2. Dashboards (仪表盘)：

    • 仪表盘是 Grafana 的核心概念。一个仪表盘由多个 Panel (面板) 组成。
    • 你可以创建多个仪表盘，每个仪表盘专注于监控某个特定方面（如“集群概览”、“某个应用的性能”、“节点资源”等）。
    • 有大量的社区贡献的仪表盘模板可以直接导入使用（例如，可以在 Grafana Labs 官网找到很多针对 Kubernetes、Node Exporter、Kube-State-Metrics 的仪表盘）。

  3. Panels (面板)：

    • 每个 Panel 都是一个独立的图表，展示一种类型的数据。可以是折线图、柱状图、饼图、表格、热力图、统计数字等。
    • 每个 Panel 都需要指定一个数据源和查询语句（例如，使用 PromQL 查询 Prometheus）。

  4. Variables (变量)：

    • 允许你在仪表盘中创建可变的参数，比如集群名称、命名空间、Pod 名称等。
    • 用户可以通过下拉菜单选择不同的变量值，仪表盘中的所有 Panel 都会根据选择自动更新，极大增加了仪表盘的灵活性和复用性。

  5. Annotations (注解)：

    • 你可以在时间序列图上标记特定事件，例如部署、版本发布、维护窗口等。
    • 这有助于理解图表中的异常行为是否与某个事件相关。

  6. Alerting (告警)：

    • 虽然主要告警由 Prometheus + Alertmanager 完成，但 Grafana 自身也提供简单的告警功能。
    • 你可以在 Panel 上直接设置阈值，当数据超出阈值时，Grafana 可以发送通知。
    • 何时使用 Grafana 告警 vs. Prometheus 告警？
      • Prometheus + Alertmanager：适用于复杂的告警规则（需要多条查询、聚合、时间窗口），以及需要高级告警处理（分组、抑制、静默、多渠道路由）的场景。这是推荐的通用告警方式。
      • Grafana 告警：适用于基于可视化数据（例如，某个图表上的某个值超过阈值）的简单告警，或者一些不那么核心、不需要复杂处理的告警。

3.3 Grafana 的使用流程

  1. 安装 Grafana：通常以 Deployment 方式部署在 Kubernetes 集群内。
  2. 访问 Grafana Web UI：通过 Service 或 Ingress 暴露。
  3. 添加数据源：配置 Prometheus 作为数据源。
  4. 导入或创建仪表盘：
    • 导入：从 Grafana Labs 官网下载 JSON 配置或 ID，直接导入。
    • 创建：从零开始创建仪表盘，添加 Panel，并编写 PromQL 查询。
  5. 探索数据：通过仪表盘和 Explore 功能进行数据分析。

3.4 Grafana 仪表盘示例（部分常用）

  • Kubernetes Cluster Overview：总览集群的 CPU、内存、网络、Pod 数量、节点状态等。
  • Kubernetes / Kubelet：深入查看 Kubelet 的运行状态和性能。
  • Kubernetes / Compute Resources / Namespace (Pods)：按命名空间查看 Pod 的资源使用情况。
  • Node Exporter Full：详细的节点级指标（CPU、内存、磁盘、网络等）。
  • [Your Application] Overview：针对特定应用的自定义指标和性能展示。

4. 它们如何协同工作？（完整工作流）

  1. 数据收集 (Exporters)：

    • 你的 Kubernetes 集群中的每个 Node 运行 node_exporter，暴露节点指标。
    • Kubelet 内置 cAdvisor，暴露容器指标。
    • 部署 kube-state-metrics，暴露 Kubernetes 资源状态指标。
    • 你的应用暴露自定义业务指标。

  2. 数据拉取与存储 (Prometheus Server)：

    • Prometheus 通过 Kubernetes 服务发现机制，自动发现 node_exporter、kube-state-metrics、Kubelet 的 cAdvisor 端口、以及你的应用暴露的 /metrics 端口。
    • Prometheus 定期（例如每 15 秒）从这些目标拉取指标数据，并存储在其本地 TSDB 中。

  3. 数据可视化 (Grafana)：

    • 你登录 Grafana，配置 Prometheus 为数据源。
    • 你在 Grafana 中创建或导入仪表盘，仪表盘中的 Panel 使用 PromQL 向 Prometheus 查询数据。
    • Grafana 接收查询结果，并将其渲染为漂亮的图表，让你实时监控集群和应用的运行状态。

  4. 告警生成 (Prometheus Server)：

    • 你在 Prometheus 中定义了告警规则 (例如 rules.yml 或 PrometheusRule CRD)。这些规则使用 PromQL 表达式来评估指标。
    • 例如：sum(rate(container_cpu_usage_seconds_total{namespace="my-app", container="my-container"}[5m])) by (pod) > 0.8 (如果 my-app 命名空间下 my-container 的 CPU 使用率在 5 分钟内持续超过 80%)。
    • 当某个规则的条件满足时，Prometheus 会生成一个告警，并将其发送给预配置的 Alertmanager。

  5. 告警处理与通知 (Alertmanager)：

    • Alertmanager 接收到 Prometheus 发来的告警。
    • 它根据配置的规则进行：
      • 分组：将多个相似告警合并成一个。
      • 抑制：根据依赖关系抑制不必要的告警。
      • 静默：如果告警处于静默期，则不发送。
    • 最后，根据路由规则，将处理后的告警发送到合适的接收器（Slack、Email、PagerDuty 等）。

5. Kubernetes 中的部署建议（使用 Prometheus Operator）

对于 Kubernetes 用户，强烈推荐使用 Prometheus Operator。它是一个 Kubernetes Operator，提供了以下 CRD 来管理 Prometheus 组件：

  • Prometheus: 用于部署和管理 Prometheus 服务器实例。
  • Alertmanager: 用于部署和管理 Alertmanager 实例。
  • ServiceMonitor: 定义 Prometheus 应该监控哪些 Service 及其对应的 Pods。通过选择器关联 Service 和 Pod 的标签，Prometheus Operator 会自动配置 Prometheus 的抓取目标。这是在 K8s 中最常用的发现机制。
  • PodMonitor: 类似于 ServiceMonitor，但直接面向 Pod 进行监控，适用于不通过 Service 暴露指标的 Pod。
  • PrometheusRule: 定义 Prometheus 的告警和记录规则，由 Prometheus Operator 自动加载到 Prometheus 实例。
  • ThanosRuler / ThanosSidecar (Thanos): 用于大规模和长期存储的解决方案，通常在生产环境中考虑。

部署流程简述：

  1. 使用 Helm 或直接应用 YAML 安装 Prometheus Operator。
  2. 部署 Prometheus CRD 实例。
  3. 部署 Alertmanager CRD 实例。
  4. 部署 Grafana Deployment 和 Service。
  5. 为你想监控的应用或组件创建 ServiceMonitor 或 PodMonitor 对象。例如，为你的 nginx-ingress 创建一个 ServiceMonitor，让 Prometheus 自动发现并抓取它的指标。
  6. 创建 PrometheusRule 对象来定义你的告警规则。

总结

Prometheus、Alertmanager 和 Grafana 构成了一个现代、强大且灵活的监控告警栈。

  • Prometheus：负责数据收集（拉取模型，通过 Exporters）、存储和 PromQL 查询，以及告警规则的评估。
  • Alertmanager：负责告警的集中处理，包括分组、抑制、静默和多渠道路由。
  • Grafana：负责数据的可视化展示，通过仪表盘和图表让你直观地洞察系统状态。

在 Kubernetes 环境中，它们通过服务发现机制紧密结合，特别是 Prometheus Operator 的引入，极大地简化了部署和管理。理解了这三者的分工与协作，你就能搭建起一套健壮的监控告警体系，确保你的 Kubernetes 集群和应用稳定运行！