当前位置：首页 > news >正文

基于Docker Compose的Prometheus+Grafana监控告警体系实战部署指南

news 2026/7/10 2:40:31

1. 项目概述：为什么我们需要一个现代化的监控告警体系？

在运维和开发领域，有一句话流传甚广：“没有监控的系统，就像在黑暗中驾驶一辆没有仪表盘的汽车。” 你完全不知道车速、油量，甚至不知道引擎是否还在运转，直到它一头撞上墙壁。我经历过太多因为一个看似微小的服务抖动，最终演变成全站瘫痪的“惊魂夜”。事后复盘，往往发现如果有及时的告警，问题在萌芽阶段就能被解决。这就是为什么我们需要一个像Prometheus + Grafana这样的组合。

简单来说，这个项目就是搭建一套从数据采集、存储、可视化到告警的完整监控解决方案。Prometheus负责“抓取”和“存储”各种指标数据，比如服务器的CPU使用率、内存占用、网络流量，或者你自定义的业务指标（比如订单创建成功率）。它就像一个不知疲倦的数据收集员，定时去各个目标点抄表。而Grafana则是一位顶尖的数据可视化设计师，它从 Prometheus 那里拿到原始数据，然后绘制成直观、炫酷的图表和仪表盘，让你一眼就能看清系统的全貌和健康状况。

更关键的是，这套组合的“告警”能力。当某个指标（比如错误率超过5%）达到你设定的阈值时，Prometheus 的告警管理器（Alertmanager）会立刻被触发，然后通过邮件、钉钉、企业微信、Slack 等渠道，把告警信息精准地推送到你面前。这相当于给你的系统装上了“烟雾报警器”。

选择Docker来部署，则是为了极致简化环境依赖和部署流程。无论你的开发机是 Windows、macOS 还是 Linux，无论生产环境是物理机、虚拟机还是云主机，Docker 都能提供几乎一致的环境，避免了“在我机器上好好的”这类经典问题。从 Docker 单机部署开始，逐步扩展到支持多节点、高可用的企业级配置，正是这条实战路径的核心价值。它适合所有希望构建或升级自身监控能力的开发、运维、SRE 工程师，无论你是想监控几个个人项目，还是为一个成规模的企业服务集群搭建中枢神经。

2. 核心组件深度解析与选型逻辑

在动手之前，我们必须彻底理解手中的“工具”。Prometheus 和 Grafana 并非简单的“采集+展示”关系，它们各自有一套精妙的设计哲学和适用场景。盲目照搬配置往往事倍功半，理解其内核才能灵活运用。

2.1 Prometheus：基于拉模型的时序数据库与监控系统

Prometheus 的核心设计理念是Pull（拉取）模型。这与传统的 Push（推送）模型（如 Zabbix Agent）有本质区别。在拉模型中，Prometheus 服务器主动向配置好的目标（Targets）发起 HTTP 请求，来获取监控数据。这种设计带来了几个显著优势：

控制权集中：监控的频率、超时、重试策略全部由 Prometheus 服务器掌控，避免了因大量客户端同时推送导致的服务器雪崩。
目标发现灵活：除了静态配置，Prometheus 可以无缝集成 Kubernetes、Consul 等服务发现机制，自动发现并监控动态变化的服务实例。
数据模型强大：所有监控数据都以时间序列（Time Series）的形式存储。一个时间序列由指标名称（Metric Name）和一组标签（Labels）唯一标识。例如，http_requests_total{method="POST", handler="/api/v1/order", status="200"}这个序列，清晰地记录了访问/api/v1/order接口的 POST 请求且返回 200 状态码的总数。标签提供了强大的多维查询能力。

它的架构主要包含以下组件：

Prometheus Server：核心服务器，包含抓取器、时序数据库和 HTTP 查询接口。
Exporters：数据导出器。对于不支持 Prometheus 格式的应用（如 MySQL、Linux 主机），我们需要运行对应的 Exporter，它将原生指标转换为 Prometheus 格式并暴露 HTTP 端点。例如，node_exporter用于采集主机指标。
Pushgateway：一个特殊的网关，用于接收短生命周期任务（如批处理作业）推送的指标，作为拉模型的补充。
Alertmanager：独立的告警处理组件。Prometheus Server 根据规则计算告警并发送给 Alertmanager，由后者负责去重、分组、静默，并通过不同路由发送通知。

注意：Prometheus 默认是单节点的，其时序数据库设计为单机高性能。对于海量数据（千万级活跃序列以上）或超高可用性要求，需要考虑使用 Thanos 或 Cortex 等方案进行联邦集群或长期存储，这是企业级配置中会涉及的高级话题。

2.2 Grafana：可视化领域的“瑞士军刀”

如果说 Prometheus 是强大的数据引擎，那么 Grafana 就是与之完美匹配的豪华仪表盘。它的定位是一个通用的、开源的数据可视化平台，支持数十种数据源，Prometheus 只是其中最流行的一个。

Grafana 的核心价值在于：

丰富的面板（Panel）类型：除了折线图、柱状图、仪表盘（Gauge）、状态图（Stat），还支持热图、日志面板、表格等，几乎能满足所有监控可视化需求。
灵活的仪表盘（Dashboard）管理：可以创建、组织、分享包含多个面板的仪表盘。支持模板变量（Template Variables），实现动态筛选（例如，按主机名、服务名筛选视图）。
强大的告警引擎：Grafana 8.0 之后内置了全新的告警引擎，支持基于面板查询结果的告警规则配置，可以作为 Prometheus Alertmanager 的补充或替代（对于简单场景）。它支持在同一界面管理可视化与告警，体验更统一。
活跃的社区：Grafana Labs 官方和社区提供了海量的预制仪表盘模板，你可以在 Grafana Dashboards 网站找到几乎任何常见系统（如 Linux主机、MySQL、Redis、K8s）的模板，一键导入，极大提升效率。

2.3 Docker：为什么它是现代部署的首选？

在这个项目中，我们使用 Docker 和 Docker Compose 来部署所有组件。理由如下：

环境一致性：Docker 镜像包含了应用运行所需的所有依赖（库、二进制文件、配置），确保了从开发到生产环境的行为完全一致。
隔离性：每个服务运行在独立的容器中，互不干扰，避免了端口冲突、依赖库版本冲突等问题。
快速部署与扩展：通过一个docker-compose.yml文件，可以一键启动、停止、重建整个监控栈。扩容时，只需调整 Compose 文件或结合编排工具即可。
资源可控：可以方便地为每个容器限制 CPU、内存使用量，防止某个组件异常拖垮宿主机。
学习与实验成本低：对于初学者，无需在本地安装各种二进制包、处理复杂的依赖关系，几分钟内就能拥有一个全功能的监控环境。

3. 从零开始：基于 Docker Compose 的一键部署实战

理论说得再多，不如动手搭一遍。下面我将带你完成一个最小化但功能完整的监控栈部署，涵盖 Prometheus、Grafana、Node Exporter 和 Alertmanager。

3.1 环境准备与目录结构规划

首先，确保你的机器上已经安装了 Docker 和 Docker Compose。可以通过docker --version和docker-compose --version命令验证。

创建一个项目目录，例如monitoring-stack，并规划好以下子目录结构。清晰的目录结构是后续维护的基础。

monitoring-stack/ ├── docker-compose.yml # 核心编排文件 ├── prometheus/ │ ├── prometheus.yml # Prometheus 主配置文件 │ └── alerts/ # 告警规则文件目录 │ └── host.rules.yml ├── grafana/ │ ├── provisioning/ # Grafana 预配置目录（关键！） │ │ ├── datasources/ │ │ │ └── prometheus.yml │ │ └── dashboards/ │ │ ├── dashboards.yml │ │ └── host.json # 可以放预导入的仪表盘 │ └── config/ # 可选的 Grafana 自定义配置 │ └── grafana.ini ├── alertmanager/ │ └── alertmanager.yml # Alertmanager 配置文件 └── node_exporter/ # 通常无需配置，这里仅为逻辑划分

3.2 编写核心配置文件

1.docker-compose.yml

这个文件定义了所有服务、网络和卷。

version: '3.8' services: prometheus: image: prom/prometheus:latest container_name: prometheus restart: unless-stopped volumes: - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml - ./prometheus/alerts/:/etc/prometheus/alerts/ - prometheus_data:/prometheus command: - '--config.file=/etc/prometheus/prometheus.yml' - '--storage.tsdb.path=/prometheus' - '--web.console.libraries=/etc/prometheus/console_libraries' - '--web.console.templates=/etc/prometheus/consoles' - '--storage.tsdb.retention.time=30d' # 数据保留30天 - '--web.enable-lifecycle' # 启用生命周期API，支持热重载配置 ports: - "9090:9090" networks: - monitoring alertmanager: image: prom/alertmanager:latest container_name: alertmanager restart: unless-stopped volumes: - ./alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml - alertmanager_data:/alertmanager command: - '--config.file=/etc/alertmanager/alertmanager.yml' - '--storage.path=/alertmanager' ports: - "9093:9093" networks: - monitoring grafana: image: grafana/grafana-enterprise:latest # 使用企业版（包含所有功能），或 grafana/grafana container_name: grafana restart: unless-stopped environment: - GF_SECURITY_ADMIN_PASSWORD=admin123 # 强烈建议首次登录后修改！ - GF_INSTALL_PLUGINS=grafana-piechart-panel # 可选：安装额外插件 volumes: - ./grafana/provisioning/:/etc/grafana/provisioning/ - grafana_data:/var/lib/grafana ports: - "3000:3000" networks: - monitoring node_exporter: image: prom/node-exporter:latest container_name: node_exporter restart: unless-stopped volumes: - /proc:/host/proc:ro - /sys:/host/sys:ro - /:/rootfs:ro command: - '--path.procfs=/host/proc' - '--path.rootfs=/rootfs' - '--path.sysfs=/host/sys' - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)' ports: - "9100:9100" networks: - monitoring networks: monitoring: driver: bridge volumes: prometheus_data: alertmanager_data: grafana_data:

关键点解析：

volumes：将本地配置文件目录挂载到容器内，实现配置持久化和外部管理。数据卷（*_data）用于持久化应用数据（如时序数据、Grafana 数据库）。
command：覆盖容器的默认启动命令，传递关键参数。例如，为 Prometheus 设置了数据保留策略和启用配置热重载。
networks：所有服务加入同一个自定义网络monitoring，这样它们可以通过服务名（如prometheus:9090）相互访问，无需暴露宿主机IP。
node_exporter挂载了宿主机系统目录，以只读（ro）方式采集主机指标。

2.prometheus/prometheus.yml

这是 Prometheus 的主配置文件，定义抓取任务和告警规则关联。

global: scrape_interval: 15s # 默认抓取间隔 evaluation_interval: 15s # 告警规则评估间隔 # 告警规则文件路径 rule_files: - "/etc/prometheus/alerts/*.rules.yml" - "/etc/prometheus/alerts/*.yml" # 支持两种后缀 # 抓取配置 scrape_configs: # 监控 Prometheus 自身 - job_name: 'prometheus' static_configs: - targets: ['localhost:9090'] # 监控 Node Exporter (主机) - job_name: 'node' static_configs: - targets: ['node_exporter:9100'] # 可以添加额外的标签，用于在 Grafana 中分组筛选 relabel_configs: - source_labels: [__address__] target_label: instance replacement: 'host-${1}' # 示例：将地址转换为实例名 # 告警管理器配置 alerting: alertmanagers: - static_configs: - targets: ['alertmanager:9093']

3.prometheus/alerts/host.rules.yml

定义一个简单的主机内存告警规则。

groups: - name: host_alerts rules: - alert: HostOutOfMemory expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 < 10 for: 1m # 持续1分钟满足条件才触发 labels: severity: warning annotations: summary: "主机内存不足 (实例 {{ $labels.instance }})" description: "可用内存比例低于10%，当前值：{{ $value | humanize }}%"

4.alertmanager/alertmanager.yml

配置 Alertmanager，这里以最简单的控制台输出和邮件为例。生产环境需配置更可靠的接收器。

global: smtp_smarthost: 'smtp.qq.com:587' # 以QQ邮箱为例 smtp_from: 'your-email@qq.com' smtp_auth_username: 'your-email@qq.com' smtp_auth_password: 'your-auth-code' # 注意是授权码，非登录密码 smtp_require_tls: true route: group_by: ['alertname', 'severity'] # 按告警名和严重程度分组 group_wait: 10s # 同一组告警等待多久发送 group_interval: 10s repeat_interval: 1h # 重复告警的间隔 receiver: 'default-receiver' receivers: - name: 'default-receiver' email_configs: - to: 'your-target-email@example.com' headers: subject: '[监控告警] {{ .GroupLabels.alertname }}' # 可以同时配置多个接收器，如 webhook 到钉钉 # webhook_configs: # - url: 'https://oapi.dingtalk.com/robot/send?access_token=xxx'

5.grafana/provisioning/datasources/prometheus.yml

这是 Grafana 的“基础设施即代码”配置。通过 Provisioning，我们可以在 Grafana 启动时自动创建数据源，无需手动在界面添加。

apiVersion: 1 datasources: - name: Prometheus type: prometheus access: proxy url: http://prometheus:9090 isDefault: true editable: false # 设置为 false 可防止在界面被修改

6.grafana/provisioning/dashboards/dashboards.yml

配置自动导入仪表盘。

apiVersion: 1 providers: - name: 'default' orgId: 1 folder: '' type: file disableDeletion: false updateIntervalSeconds: 10 allowUiUpdates: true options: path: /etc/grafana/provisioning/dashboards

3.3 启动与验证

所有配置文件就绪后，在monitoring-stack目录下执行一条命令：

docker-compose up -d

-d参数表示后台运行。Docker Compose 会自动拉取镜像（如果本地没有）并启动所有容器。

使用docker-compose ps查看服务状态，确保所有容器都是Up状态。

现在，打开浏览器访问：

Prometheus:http://localhost:9090。在 “Status” -> “Targets” 页面，应该能看到prometheus和node两个 job 的状态都是UP。
Grafana:http://localhost:3000。使用默认账号admin和你在 Compose 文件中设置的密码（如admin123）登录。进入后，在 “Configuration” -> “Data Sources” 中应该能看到已自动配置好的 Prometheus 数据源。
Alertmanager:http://localhost:9093。可以查看告警和静默规则。

实操心得：第一次启动时，务必检查各个容器的日志docker-compose logs -f [service_name]，排查常见的配置错误，如 YAML 格式错误、文件路径不对、端口冲突等。Grafana 的 Provisioning 配置如果出错，日志里会有明确提示。

4. 企业级配置进阶：高可用、安全与生产优化

单机部署适合学习和测试，但生产环境需要更高的可靠性、安全性和可维护性。下面我们探讨几个关键的企业级配置方向。

4.1 高可用与联邦集群部署

Prometheus 本身是单节点，存在单点故障风险。企业级方案通常采用以下两种模式：

1. 双活 Prometheus + Alertmanager 集群部署两个完全相同的 Prometheus Server，同时抓取所有目标。Alertmanager 本身支持集群模式，多个实例通过--cluster-*参数组成集群，实现告警的去重和高可用。在 Grafana 中，可以配置多个 Prometheus 数据源，或者使用 Grafana 的 “HA Data Source” 特性（企业版功能）。

2. 联邦集群（Federation）适用于监控大规模、多区域集群。架构分为两层：

下层 Prometheus：部署在各个数据中心或K8s集群中，负责采集本地目标的详细指标。
上层 Prometheus：部署在全局，通过联邦（Federation）功能，从下层 Prometheus 中抓取聚合后的、汇总性的关键指标（如各服务的总QPS、错误率）。

在prometheus.yml中配置联邦抓取示例：

scrape_configs: - job_name: 'federate-dc-east' honor_labels: true metrics_path: '/federate' params: 'match[]': - '{job="prometheus"}' # 只拉取下层Prometheus自身的指标 - '{__name__=~"job:.*"}' # 拉取所有以`job:`开头的聚合指标 static_configs: - targets: ['prometheus-dc-east:9090']

4.2 安全加固配置

直接暴露服务端口到公网是极其危险的。生产环境必须考虑安全。

网络隔离：将监控组件部署在内网，通过跳板机或 VPN 访问。在 Docker Compose 中，谨慎映射端口到宿主机（ports），优先使用内部网络通信。
反向代理与认证：使用 Nginx 或 Traefik 作为反向代理，对外暴露 Grafana 和 Prometheus（如需）的访问入口。在代理层配置 HTTPS（SSL/TLS）和基础认证（Basic Auth）或集成 OAuth2、LDAP 等统一认证。
Grafana 安全：
- 强制修改默认admin密码。
- 在grafana.ini中配置[security]部分，加强 Cookie、密码策略。
- 使用[auth.*]配置外部认证源。
- 通过[users]部分禁止自动注册。
Prometheus 与 Alertmanager 安全：两者都支持通过--web.config.file参数加载基于 TLS 和基础认证的配置文件。可以为它们生成自签名或受信任的证书，并配置认证。

4.3 监控数据长期存储与降采样

Prometheus 的本地 TSDB 默认不是为无限期存储设计的。通常保留 15天到几个月。对于需要长期（数月甚至数年）存储监控数据用于趋势分析、容量规划的场景，需要引入远程存储。

远程存储集成：Prometheus 支持将数据写入远程的适配器。常见的后端有：
- Thanos：云原生方案，提供全局查询视图、无限存储、降采样和压缩。
- Cortex/Mimir：水平可扩展、多租户的长期存储方案（Grafana Mimir 是 Cortex 的继任者）。
- 时序数据库：如 InfluxDB、TimescaleDB。

配置远程写：在prometheus.yml中添加：

remote_write: - url: "http://thanos-receive:19291/api/v1/receive"

降采样（Downsampling）：对于长期存储的数据，存储原始数据粒度（如15秒一点）成本极高且查询慢。降采样是指按更粗的时间粒度（如5分钟、1小时）预先计算并存储聚合数据（如平均值、最大值、分位数）。Thanos Compactor 组件和 Mimir 都自动处理降采样。

4.4 告警路由、静默与抑制

Alertmanager 的强大之处在于其灵活的告警处理流程。

路由树（Route Tree）：在alertmanager.yml的route部分，可以定义复杂的路由规则，将不同标签（如team=frontend,severity=critical）的告警路由到不同的接收器（Receiver）。例如，将数据库相关的严重告警发送给 DBA 团队，将前端服务告警发送给前端团队。
静默（Silence）：对于计划内的维护（如服务器重启、应用发布），可以预先在 Alertmanager Web 界面创建静默规则，指定匹配的标签和静默时间，在此期间相关的告警将不会发送通知。
抑制（Inhibition）：定义告警之间的抑制关系。例如，当“整个机房网络故障”的告警触发时，可以抑制所有来自该机房服务器的“主机宕机”、“服务不可用”等低级告警，避免告警风暴，让运维人员专注于根因问题。

一个进阶的route配置示例：

route: receiver: 'default-receiver' group_by: ['alertname', 'cluster'] routes: - match: severity: 'critical' receiver: 'critical-team-pager' - match: service: 'mysql' receiver: 'dba-team' continue: true # 继续匹配后续路由 - match: service: 'frontend' receiver: 'fe-team-slack'

5. 实战：构建一个业务应用监控仪表盘与告警

监控基础设施只是第一步，更重要的是监控你的业务应用。下面以监控一个假设的 Web API 服务为例。

5.1 在应用中暴露 Prometheus 指标

如果你的应用是 Go、Java、Python 等语言编写，通常有成熟的 Prometheus 客户端库。以 Python Flask 应用为例，使用prometheus-flask-exporter库：

from flask import Flask from prometheus_flask_exporter import PrometheusMetrics app = Flask(__name__) metrics = PrometheusMetrics(app) # 定义一个自定义的业务指标：订单创建计数器 orders_created = metrics.counter( 'orders_created_total', 'Total number of orders created', labels={'status': lambda: request.status_code} # 动态标签 ) @app.route('/create_order', methods=['POST']) def create_order(): # ... 业务逻辑 ... orders_created.inc() # 计数器+1 return 'Order created' if __name__ == '__main__': app.run(host='0.0.0.0', port=5000)

应用启动后，会默认在/metrics端点暴露 Prometheus 格式的指标。

5.2 配置 Prometheus 抓取

在prometheus.yml中添加新的抓取任务：

scrape_configs: - job_name: 'my-flask-app' metrics_path: '/metrics' static_configs: - targets: ['host.docker.internal:5000'] # Docker Desktop 访问宿主机服务 labels: app: 'order-service' env: 'dev'

注意：在 Docker 容器内访问宿主机的服务，在 macOS/Windows 的 Docker Desktop 上可以使用host.docker.internal这个特殊域名。Linux 环境下可能需要使用宿主机的桥接 IP 或配置为host网络模式。

5.3 在 Grafana 中创建业务仪表盘

登录 Grafana，点击左侧 “+” 号 -> “Dashboard”。
添加面板：点击 “Add new panel”。
配置查询：
- 数据源选择 “Prometheus”。
- Metrics browser 中输入orders_created_total，可以看到这个计数器。你可以使用 PromQL（Prometheus 查询语言）进行聚合计算，例如：
  - 最近5分钟订单创建速率：rate(orders_created_total[5m])
  - 按状态码统计的订单数：sum by (status) (orders_created_total)
设置可视化：在右侧选择图表类型（如 Stat、Graph），设置标题、单位等。
设置告警（在面板内）：在 “Alert” 标签页，可以创建基于该查询的告警规则。例如，设置当订单创建速率持续2分钟为0时（可能服务挂了）触发告警。这里配置的告警会由 Grafana 的内置告警引擎管理。
保存仪表盘。

5.4 配置 Prometheus 告警规则

对于更复杂的告警逻辑，或者希望统一由 Alertmanager 管理，则应在 Prometheus 中定义规则。在host.rules.yml同级目录创建business.rules.yml：

groups: - name: business_alerts rules: - alert: OrderServiceHighFailureRate expr: | sum(rate(orders_created_total{status=~"5.."}[5m])) by (app, instance) / sum(rate(orders_created_total[5m])) by (app, instance) * 100 > 5 for: 2m labels: severity: critical team: backend annotations: summary: "订单服务失败率过高 (实例 {{ $labels.instance }})" description: "过去5分钟，HTTP 5xx错误率超过5%，当前值：{{ $value | humanize }}%"

这个规则计算订单服务中状态码为5xx（服务器错误）的请求比例，如果超过5%持续2分钟，则触发严重告警。

6. 运维、排错与性能调优经验谈

系统跑起来只是开始，稳定高效运行才是挑战。分享一些我踩过的坑和总结的经验。

6.1 日常运维命令与监控自查

查看服务状态：docker-compose ps,docker-compose logs -f [service]
Prometheus 配置热重载：当修改了prometheus.yml或告警规则文件后，无需重启容器，可以发送 POST 请求触发重载：curl -X POST http://localhost:9090/-/reload（需在启动时加了--web.enable-lifecycle参数）。
检查抓取目标：访问 Prometheus 的/targets页面，确保所有job的状态都是UP。DOWN状态通常意味着网络不通、端口不对或 Exporter 未正常运行。
检查告警规则：访问/rules页面，查看定义的告警规则是否加载成功，以及其当前状态（Inactive, Pending, Firing）。
Grafana 数据源测试：在 Grafana 的数据源配置页面，点击 “Save & Test”，确保能成功连接到 Prometheus。

6.2 常见问题与排查思路

问题1：Prometheus 抓取目标显示DOWN

排查：
1. 在 Prometheus 容器内执行curl -v http://target-ip:port/metrics，看是否能获取到指标数据。
2. 检查prometheus.yml中的targets地址和端口是否正确。在 Docker Compose 网络中，应使用服务名而非localhost。
3. 检查目标服务的防火墙或安全组规则。
4. 查看 Prometheus 日志，通常会有具体的连接错误信息。

问题2：Grafana 中查询不到数据，但 Prometheus 有数据

排查：
1. 检查 Grafana 中数据源配置的 URL 是否正确（应是http://prometheus:9090）。
2. 检查查询的 PromQL 是否正确，时间范围是否匹配。
3. 在 Prometheus 的 Graph 页面尝试相同的查询，验证 PromQL。
4. 检查数据源是否被设置为默认（isDefault: true）。

问题3：告警没有发送

排查：
1. 访问 Alertmanager (http://localhost:9093)，查看 “Alerts” 页面，告警是否已到达 Alertmanager 并处于 “Active” 状态。
2. 检查 Alertmanager 日志docker-compose logs alertmanager，看是否有发送失败的错误（如邮件服务器连接失败、Webhook URL 错误）。
3. 检查 Prometheus 的/alerts页面，确认告警规则是否已触发（状态为Firing）。
4. 检查alertmanager.yml中的路由和接收器配置，特别是邮箱的 SMTP 配置和授权码。

问题4：Prometheus 容器内存/磁盘占用快速增长

原因与解决：
- 抓取目标过多或频率过高：调整scrape_interval，对于不重要的目标可以拉长间隔。
- 指标基数爆炸：检查是否有指标标签值过多（例如，将用户ID作为标签），这会导致时间序列数量激增。应避免将高基数维度作为标签。使用 Prometheus 的tsdb接口（/api/v1/status/tsdb）分析序列数量。
- 数据保留时间过长：根据需求调整--storage.tsdb.retention.time（如30d）。
- 启用数据压缩：Prometheus 会自动压缩旧数据，确保其正常运行。

6.3 性能调优要点

Prometheus Server：
- 内存：所需内存与活跃时间序列数大致成线性关系。一个经验公式：所需内存 ≈ 活跃序列数 * 2KB。百万级序列可能需要数GB内存。监控process_resident_memory_bytes指标。
- 磁盘：TSDB 写入性能要求高，建议使用 SSD。监控prometheus_tsdb_storage_blocks_bytes。
- 抓取优化：适当增加scrape_timeout，对于响应慢的 Exporter 可单独配置。
Grafana：
- 对于大型仪表盘或复杂查询，可能增加 Grafana 后端负载。可以考虑：
  - 优化 PromQL 查询，避免全量扫描（使用聚合、子查询）。
  - 在 Grafana 中设置查询的Min interval，降低查询频率。
  - 对历史数据仪表盘，使用 Grafana 的 “Snapshot” 功能生成静态快照。
整体架构：
- 随着规模增长，尽早规划联邦集群或 Thanos/Mimir 方案，将数据采集和全局查询分离。
- 考虑使用 Prometheus Operator 在 Kubernetes 环境中管理 Prometheus，它能自动化大部分配置工作。

监控体系的建设是一个持续迭代的过程。从最简单的 Docker Compose 单机部署开始，理解每个组件的工作原理，然后根据实际业务规模、团队结构和运维能力，逐步向高可用、安全、长期存储的企业级架构演进。最关键的是，让监控真正用起来，让告警能够驱动问题的发现和解决，而不是成为“告警疲劳”的噪音来源。这套 Prometheus + Grafana 的组合，以其强大的灵活性、活跃的社区和云原生亲和力，无疑是当前构建现代化监控告警平台最坚实的选择之一。

查看全文

http://www.jsqmd.com/news/1158075/