做 SRE 这几年我踩过最深的坑就是“服务挂了半天居然没人知道”。等用户投诉过来日志翻了几百兆才发现某个节点的磁盘早就满得连日志都写不进去了。从那以后我把 Prometheus Grafana AlertManager 这套组合当成了运维体系的底座无论业务多赶监控告警必须是第一优先级。今天这篇文章就把我从零搭建这套企业级监控告警平台的全过程、踩坑记录和排障心得一次讲清楚希望能帮你少走弯路。先说清楚这套东西是干什么的Prometheus 负责采集和存储指标Grafana 负责把指标变成看得懂的图表AlertManager 负责在指标异常时把告警发出去邮件、钉钉、企业微信都行。三兄弟各司其职串起来就成了一条完整的“观测 → 可视化 → 告警”链路。适合谁看刚接手运维或 SRE 岗位的新人、准备给团队做监控体系建设的工程师甚至想给自己项目搭一套轻量级监控的个人开发者都可以照着这套思路落地。1. 监控告警体系的核心设计思路1.1 先想清楚要监控什么再动手装组件我见过太多人一上来就装 Prometheus装完发现除了机器 CPU 和内存啥都监控不了。这不是工具的问题是设计出了问题。搭建监控平台的第一步不是选工具而是梳理清楚业务的监控对象。对于企业级场景我习惯把监控对象分成四层基础设施层CPU、内存、磁盘 IO、网络带宽、文件系统使用率。中间件层MySQL 连接数、慢查询、Redis 命中率、Kafka 消费堆积、Nginx 请求量。应用层接口 QPS、P99 延迟、错误率、JVM 堆内存、GC 次数。业务层订单量、支付成功率、注册转化率等核心业务指标。每层需要不同的 exporter 或采集器。基础设施层用 node_exporterMySQL 用 mysqld_exporterRedis 用 redis_exporter应用层如果走 Java 就用 JMX exporter 或者直接埋点 Prometheus SDKNginx 可以用 nginx_exporter 或者 nginx-vts-module。先把这些梳理清楚后面配置采集规则才不会手忙脚乱。注意监控不是指标越多越好。太多指标会带来存储成本、查询变慢和告警噪音三座大山。我的原则是每个组件选 10~20 个关键指标宁可少而精不要多而杂。1.2 三组件的分工边界别把职责搞混很多新人容易把 Prometheus 和 Grafana 当成一回事其实它们之间是有明确边界的。Prometheus 是一套完整的监控系统包含时序数据库、数据采集拉模型 Pushgateway、查询语言 PromQL、告警规则计算。也就是说Prometheus 本身就能触发告警只是它做不到“把告警发出去”这件事。AlertManager 补齐的就是“告警通知”这一段接收 Prometheus 发来的 Alert然后做去重、分组、抑制、静默最后通过邮件、Webhook、钉钉、企业微信等渠道推送给对应的人。而 Grafana 是纯粹的可视化层它不负责采集和存储只是通过数据源接口把 Prometheus 里的指标拉出来渲染成图表顺便也能展示 Loki 日志、Jaeger 链路追踪、MySQL 数据等。把职责分清楚以后你会发现排查问题也变得简单了指标不对查 Prometheus图不对查 Grafana收不到告警查 AlertManager定位起来非常顺。1.3 为什么选 Prometheus 而不是 Zabbix 或 OpenFalcon聊方案的时候总有同事问“公司不是有 Zabbix 嘛为啥还要折腾 Prometheus”这问题我问过自己很多遍答案是场景不一样。Zabbix 的强项是传统基础设施监控它有成熟的 agent、自动发现、模板体系适合网络设备、服务器数量特别多的传统 IDC 场景。但它的短板也很明显对云原生、容器、微服务的支持不够原生指标模型不够开放二次开发成本高。Prometheus 是 Kubernetes 官方推荐的监控方案天生适合云原生环境采用的是拉模型Pull配合服务发现可以做到“新实例上线自动纳入监控”。此外 PromQL 这套查询语言非常灵活能在一个表达式里完成多指标关联计算比如“过去 5 分钟内订单量环比下降了 20% 且错误率超过 1%”在 Prometheus 里只是一条 PromQL 的事在 Zabbix 里写起来就很痛苦。我并不是说 Zabbix 一无是处而是说如果你从零开始做一个面向未来的企业级监控体系Prometheus 这套栈是更值得投入的方向。这也是我最终选择它的核心原因。2. 基础环境准备与组件版本规划2.1 服务器与目录规划先说环境我这里以最经典的三台机器搭配为例生产环境可以按角色拆分更多节点给读者们一个参考机器角色建议配置部署组件监控主节点4C8G / 200G SSDPrometheus、Grafana、AlertManager目标节点12C4G / 100Gnode_exporter 业务 exporter目标节点22C4G / 100Gnode_exporter 业务 exporter生产环境建议把 Prometheus 的存储目录单独挂一块 SSD因为 Prometheus 的时序数据写入频率很高机械盘和网络盘容易拖后腿。我的经验是磁盘类型对查询性能的影响比 CPU 和内存还明显。目录规划我习惯统一放到/data下面/data/prometheus/data # 时序数据 /data/prometheus/config # 规则文件 /data/alertmanager/config # 告警配置 /data/grafana/data # Grafana 元数据这样备份、迁移、找日志都非常清爽不会出现装完软件到处找不到配置的尴尬。2.2 版本选择的原则版本选择上我不是无脑追求最新版。Prometheus 和 Grafana 的迭代速度很快新特性固然香但生产环境求的是稳定。我个人的原则是选择当前主版本的次新版本。比如 Prometheus 2.x 系列选最近两个 minor version 里更稳定的一个避免刚发布就踩雷。注意 Prometheus 和 Grafana 的兼容性。Grafana 版本太新或太旧都可能出现数据源插件不兼容尤其是用了第三方插件时更要注意。官方建议下载二进制安装包时直接从 GitHub Releases 拿官方发布版本不要从第三方博客的网盘下载防止供应链风险。截至我写这篇文章时Prometheus 2.53 系列、Grafana 11 系列在日常项目中表现都比较稳定。如果你项目的依赖环境比较老用 Prometheus 2.45 左右也完全够用核心功能基本一致。2.3 安装方式选型二进制还是 Docker这里我给个直白的建议具体看你团队的情况如果监控服务跑在物理机或传统 VM 上推荐用二进制包方式安装配合 systemd 管理。好处是链路简单、占用资源小、排障直接不会被容器网络、存储卷搞晕。如果监控服务本身跑在 K8s 集群里那直接用官方 Helm Chart 部署 Prometheus Operator 更合适能利用 K8s 的服务发现和自动伸缩能力。如果只是个人学习或测试环境Docker Compose 最省心一条命令拉起整套平台。下面我会先讲二进制方式因为这种方式最直观把每一个配置的细节都暴露出来非常适合理解原理。生产环境我目前多数项目也是二进制这种方式为主稳定性非常有保证。3. Prometheus 接入与采集配置全流程3.1 Prometheus 安装与初始化下载和解压是有标准动作的wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz tar xvf prometheus-2.53.0.linux-amd64.tar.gz mv prometheus-2.53.0.linux-amd64 /opt/prometheus注意这里下载地址的版本号会变建议去 GitHub Releases 页面对应找到最新的稳定版本替换。解压后你会发现目录里有prometheus.yml、promtool、tsdb等关键文件。promtool这个工具很多人忽略其实它是检查配置合法性和规则文件准确性的利器后面我会讲怎么用。然后创建 systemd 服务让 Prometheus 作为守护进程常驻后台[Unit] DescriptionPrometheus Server Documentationhttps://prometheus.io Afternetwork-online.target [Service] Userprometheus Groupprometheus ExecStart/opt/prometheus/prometheus \ --config.file/opt/prometheus/prometheus.yml \ --storage.tsdb.path/data/prometheus/data \ --web.listen-address0.0.0.0:9090 \ --web.enable-lifecycle [Install] WantedBymulti-user.target这里有一个很多人没注意到的参数--web.enable-lifecycle。加了它以后修改完 prometheus.yml 不用重启服务只需要执行curl -X POST http://localhost:9090/-/reload就能热加载配置。在不能随便重启监控服务的生产环境这个参数非常实用。启动之后浏览器访问http://服务器IP:9090如果能看到 Prometheus 自带的 UI并且 Status → Targets 里面有本机的prometheus目标状态为 UP说明服务已经跑起来了。3.2 配置抓取任务与 job 设计接下来是重点配置采集目标。先看一个基础的prometheus.yml结构global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: node-metrics static_configs: - targets: - 10.0.1.11:9100 - 10.0.1.12:9100 relabel_configs: - source_labels: [__address__] regex: ([^:]):.* target_label: instance replacement: ${1}这里我说说几个设计细节。scrape_interval指的是 Prometheus 每隔多久去目标机器抓一次数据。15s 是一个比较通用的配置如果你想对某些高敏感指标如交易成功量缩短到 5s可以在 job 级别单独加scrape_interval覆盖全局配置。但注意抓取间隔太短会对目标和 Prometheus 本机造成双重压力间隔太长又会延迟告警发现时间。我的建议是默认 15s核心业务 job 用 10s基础设施用 30s 都行关键是要在成本和灵敏度之间找平衡。relabel_configs这段可能很多新人看不懂它的作用是把抓取地址里的10.0.1.11:9100处理成10.0.1.11然后写入instance标签。这样在 Grafana 上显示节点名时不会带着端口号一起显示界面干净清爽。生产环境如果用服务发现配合 labelmap 和 replace 动作能实现非常灵活的标签控制这个值得深入研究。3.3 常用 Exporter 的部署与验证有了 prometheus.yml 和 systemd 服务最基础的自监控就起来了。但要真正做到企业级必须把基础设施、中间件的指标都接进来。部署 node_exporterwget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz tar xvf node_exporter-1.8.2.linux-amd64.tar.gz mv node_exporter-1.8.2.linux-amd64 /opt/node_exporter同样用 systemd 管理[Unit] DescriptionNode Exporter [Service] Userprometheus ExecStart/opt/node_exporter/node_exporter \ --web.listen-address:9100 \ --collector.systemd \ --collector.processes [Install] WantedBymulti-user.target启动后用浏览器或 curl 访问http://节点IP:9100/metrics如果能返回一串以node_cpu_seconds_total、node_load1、node_filesystem_avail_bytes等开头的文本说明 exporter 正常工作。MySQL 监控mysqld_exporter 需要给监控账号授权。在 MySQL 里创建一个专用账号只授予 PROCESS、SELECT、REPLICATION CLIENT 权限就行CREATE USER mysql_monitor% IDENTIFIED BY your_password; GRANT PROCESS, SELECT, REPLICATION CLIENT ON *.* TO mysql_monitor%;然后通过下面的方式传入数据源信息export DATA_SOURCE_NAMEmysql_monitor:your_password(10.0.1.21:3306)/ mysqld_exporter --web.listen-address:9104我特别想提醒不要把 MySQL 的 root 账号拿给 mysqld_exporter 用这是典型的“监控把自己变成了安全隐患”。为监控单独建独立账号权限够用就好。验证习惯每个 exporter 接入后我都要去 Prometheus UI 的 Status → Targets 页面确认新 target 是 UP 状态。然后再到 Graph 页面跑up{jobmysql}看看这个指标的值是不是 1。这一步虽然简单但能避免数据没进来傻傻等半天的尴尬。3.4 配置热加载与 promtool 验证每次修改 prometheus.yml 后动手重启之前先跑一下 promtool 做合法性检查/opt/prometheus/promtool check config /opt/prometheus/prometheus.yml如果输出类似SUCCESS的话再执行热更新curl -X POST http://localhost:9090/-/reload这个流程是我每次改配置固定的动作。尤其在频繁调整抓取规则或者增加 job 时这个流程能防止把整个监控搞挂。有一次我手误在 yaml 里多敲了个 Tab直接导致 Prometheus 启动失败当时要是忘了 promtool 检查线上监控就得断很久。提醒--web.enable-lifecycle虽然支持热更新但像修改全局scrape_interval、存储配置等参数仍然建议重启服务生效。此外如果你通过 systemd 管理在改配置后重启会导致短暂监控中断最好挑业务低峰期操作。4. Grafana 可视化平台接入4.1 安装与数据源配置Grafana 安装方式很多这里用最简单的 RPM 或 DEB 方式wget https://dl.grafana.com/oss/release/grafana-11.1.0-1.x86_64.rpm yum localinstall grafana-11.1.0-1.x86_64.rpm systemctl start grafana-server systemctl enable grafana-server启动后访问http://服务器IP:3000初始账号密码是 admin / admin登录后系统会强制你修改密码。这一步别跳过尤其生产环境如果 grafana 暴露在公网不改默认密码等于把监控大屏送给路人看。接下来是配置数据源左侧菜单找到 Connections → Data sources → Add data source。选择 Prometheus。在 URL 栏填http://localhost:9090这里按你的实际部署地址填。点击 Save Test看到绿色的 “Successfully queried the Prometheus API” 就连接成功了。一个容易被忽略的问题Grafana 服务器和 Prometheus 服务器如果不同机要确认防火墙放行了 9090 端口并且 Prometheus 的--web.listen-address没有只绑到 127.0.0.1。否则 Grafana 这边永远报 “Bad Gateway”。4.2 大屏设计原则与常用 Panel 技巧Grafana 能不能用得好七分在设计三分在查询。我见过有人把所有指标塞进一个 Dashboard结果满屏的线什么也看不清。我的设计经验可以归纳为三条第一按职责拆 Dashboard。一个 Dashboard 只关注一个场景主机总览、MySQL 性能、应用接口、K8s 集群各自分开。不要混在一起。第二每个 Panel 必须有明确标题、单位和阈值。标题写“订单 QPS”单位就设置成“req/s”阈值线画到“5000”这样瞄一眼就知道有没有问题。第三善用变量。在 Dashboard 设置里定义$instance变量数据源类型选 PrometheusQuery 写成label_values(node_uname_info, instance)然后顶部会出现下拉框可以切换不同节点。这样不用为每台机器单独建面板一套面板通吃所有机器。下面给几个最常用的 Panel 查询CPU 使用率按 % 展示100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)内存使用率按 % 展示(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100磁盘根分区使用率(1 - (node_filesystem_avail_bytes{mountpoint/} / node_filesystem_size_bytes{mountpoint/})) * 100这里插一个新手特别常见的困惑为什么 CPU 要用rate包一层因为node_cpu_seconds_total是一个计数器型指标它只增不减要得到“每秒使用率”必须计算它在一段时间内的增长率rate干的就是这件事。同理MySQL 的 QPS、Nginx 的请求数都要用rate或者irate处理。这个思维转换不过来的话Grafana 面板上数字会完全看不懂。4.3 从官方模板到自建面板Grafana 社区有非常丰富的大屏模板官网 https://grafana.com/grafana/dashboards 上有现成的 node_exporter 主机监控模板最典型的是 ID 1860、8919 等导入方式很简单Dashboards → Import → 输入 ID → Load → 选择数据源 → Import。不过官方模板只适合快速起步我建议你至少改一处调整阈值颜色和单位。因为模板里的阈值如 CPU 80% 告警是针对通用 SRE 场景的不一定符合你们业务的容忍度。我之前就吃过亏信任了模板里默认的 99 分位延迟阈值结果业务侧还没到那个值监控已经红了一片。阈值这事情不要偷懒一定要和业务方对齐后再写进去。面板建好之后记得通过 Dashboard settings → JSON Model 做备份或者直接导出 JSON 文件提交到 Git。这个习惯能在你误删大屏、机器迁移、环境重建时救你一命。5. AlertManager 告警闭环搭建5.1 Prometheus 告警规则编写告警链路的第一步是在 Prometheus 里写规则。我习惯把规则文件独立出来在 prometheus.yml 里统一引用rule_files: - /opt/prometheus/config/rules/*.yml然后写一个基础的主机告警规则文件/opt/prometheus/config/rules/node.ymlgroups: - name: node_alerts rules: - alert: NodeDown expr: up{jobnode-metrics} 0 for: 2m labels: severity: critical annotations: summary: 节点 {{ $labels.instance }} 已离线 description: 实例 {{ $labels.instance }} 已经超过 2 分钟无法访问。 - alert: HighCpuUsage expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 85 for: 5m labels: severity: warning annotations: summary: 节点 {{ $labels.instance }} CPU 使用率过高 description: 当前使用率超过 85%持续 5 分钟请关注是否存在异常负载。这里有两个关键点要说透。for: 2m表示这个条件必须持续满足 2 分钟才会触发告警。这个“持续多久”的参数极其重要它能把偶发的瞬时抖动过滤掉避免五分钟一次告警轰炸。生产环境我一般会为不同等级设置不同的 forcritical 级别 1 分钟warning 级别 5~10 分钟。{{ $labels.instance }}这种模板字段会在告警消息拼接时自动替换成实际的实例地址。不写模板的告警消息往往千篇一律收到告警还要人工去猜是哪台机器这是很大的效率损耗。写完规则后建议先用 promtool 验证一下规则文件格式/opt/prometheus/promtool check rules /opt/prometheus/config/rules/node.yml只有校验通过再执行热加载到 Prometheus 的 Status → Rules 页面检查规则是否全部加载成功。5.2 AlertManager 安装与路由配置AlertManager 下载安装方式和 Prometheus 很相似这里直接放 systemd 配置ExecStart/opt/alertmanager/alertmanager \ --config.file/opt/alertmanager/alertmanager.yml \ --storage.path/data/alertmanager/data \ --web.listen-address:9093AlertManager 的核心配置是路由和接收器。一个基础但合理的配置长这样route: group_by: [alertname, instance] group_wait: 10s group_interval: 2m repeat_interval: 4h receiver: default receivers: - name: default webhook_configs: - url: http://localhost:8080/alert/hook send_resolved: true很多新手会问Prometheus 算出来的告警不是直接推给 AlertManager 就能发出去了吗为什么还要这些参数我来解释一下AlertManager 收到的所有告警不会立刻发送它会有几层“加工”。比如group_by: [alertname, instance]表示按告警名称和实例分组。假设同一台机器同时触发了 CPU 高和磁盘满两个告警会对 CPU 高告警和磁盘满告警分别发送一个通知如果 10 台机器都同时 CPU 高那这些通知会按告警名聚合到一起一次性发出来而不是 10 封邮件把你邮箱塞爆。repeat_interval: 4h表示如果同一个告警一直没恢复4 小时后再通知一次。这个参数很值得调优因为默认情况下一个持续未解决的告警会很频繁地重复提醒容易让人产生“告警疲劳”最后收到通知也不看了。send_resolved: true表示故障恢复后也发一条“已恢复”的消息。这条消息的价值在于形成闭环收到告警 → 处理问题 → 看到恢复消息 → 确认闭环。没有恢复消息的告警体系会让 SRE 陷入“不知道到底恢复了没有”的焦虑。5.3 对接钉钉/企业微信/邮件实战AlertManager 原生支持 email、webhook 等。如果要发到钉钉、企业微信最灵活的方式是用 webhook 接一个中间转换服务也可以直接使用钉钉/企业微信的 webhook 机器人如果你用的接收端支持直接接受 JSON。先讲最简单的邮件receivers: - name: email email_configs: - smarthost: smtp.example.com:465 auth_username: alertexample.com auth_password: your_password from: alertexample.com to: sre-teamexample.com require_tls: true钉钉机器人的 webhook 方式配置如下receivers: - name: dingtalk webhook_configs: - url: https://oapi.dingtalk.com/robot/send?access_token你的token send_resolved: true配好之后建议发一条测试告警验证链路而不是等真实故障来检验。测试方法临时在 Prometheus 规则里加入一条expr: vector(1)的告警这会立刻触发确认收到通知再删掉。等到以后排障你会发现提前验证和临时临场验证心态完全不同。注意由于 AlertManager 的告警通知模板默认是英文需要给不同接收器配置title和text的中文模板才能有更好的阅读体验。模板文件里可以使用 Go template 语法里面可以引用告警名、severity、description 等字段。5.4 告警抑制与静默实战当某台机器宕机时它上面的所有服务比如 MySQL、Nginx、应用可能同时失联此时 Prometheus 会产生一堆告警NodeDown、MySQLDown、NginxDown、AppDown……这就是典型的“告警风暴”。AlertManager 提供的抑制机制inhibit_rules可以解决这个问题。当一台机器宕掉后只需要知道 NodeDown 就够了下游的 MySQLDown 这些告警可以自动被抑制inhibit_rules: - source_match: severity: critical target_match: severity: warning equal: [instance]这个配置的意思是如果同一 instance 上已经有 critical 级告警那所有 warning 级告警都先不发了。这招在主机宕机场景极其有效能直接拦住 90% 以上的无效告警轰炸。静默Silence则是另一种场景比如你提前知道明天 2 点到 4 点要对某台机器做维护可以提前在 AlertManager UI 界面上创建一个静默指定该实例的告警在维护期间不发送。别忘了在运维窗口结束后移除静默不然告警会真的“静默”到无人知晓。6. 常见问题与排障技巧实录6.1 数据采集异常Target 状态不是 UP你能想象吗我见过最多的求助帖就是“Prometheus 的 targets 全红了怎么办”。这类问题基本集中在这几个原因。第一exporter 进程没起来或端口没监听。先在目标机器上ss -ltnp | grep 9100确认端口存在再curl http://localhost:9100/metrics看返回值。通不通一步就能定位。第二防火墙或安全组没放行。云服务器要检查安全组规则物理机要检查 firewalld / iptables不然 Prometheus 在远端怎么抓都抓不到。第三网络不通。Prometheus 和目标机之间如果有跳板机、专线要 su 管理员确认端口是否可达。可以用telnet 目标IP 端口从 Prometheus 本机测试。第四relabel 配置错误导致 target 地址被改写。如果是在配置里加了 relabel 后 target 变成 UP 不了就要回顾一下标签的替换逻辑是否正确必要时用 promtool 先验证再加载。排障路径总结一句话先本地、再网络、后配置。从目标机自身状态检查起再走链路最后查 Prometheus 的配置。6.2 告警没触发或告警风暴告警没触发常见的根源有三个规则文件没加载。去 Prometheus 的 Status → Rules 页面看alerting rule有没有在列表里。没有的话检查 rule_files 路径和文件格式。for时间太长。比如一核 CPU 峰值持续不到 2 分钟规则却要求持续 5 分钟才告警自然一直“触发不了”。可以先把for设小一点观察再调整到合理值。表达式返回的结果不对。直接在 Graph 页面手动执行那条 expr看看有没有数值输出。如果表达式返回空那规则再正确也不会触发。比如up 0前提是你查的 job 里确实存在up这个指标。告警风暴的问题多半是分组、抑制、静默配置不到位。我的建议是上线初期宁可先选择按 alertname 严格分组把 repeat_interval 调大配合 inhibit_rules 使用观察几周再慢慢放宽阈值不要一上来就把所有告警开关全打开。6.3 存储与性能调优心得Prometheus 的本地存储TSDB不擅长无限水平扩展数据量大到一定程度查询和写入都会变慢。遇到这种瓶颈我的处理顺序是这样的。第一检查指标量和抓取频率。打开 Prometheus 自带的/api/v1/status/tsdb接口可以看到head_stats里 head series 的数量。如果 series 数量超过百万级别或者每秒摄入样本数很高就要考虑减少不必要的指标采集比如有些 exporter 默认会开一大堆 collector实际用不到几个。第二为高频指标单独设置抓取间隔。一个被我验证有效的方案是把低频基础设施指标如node_filesystem_avail_bytes的抓取间隔调整到 30s 或者 60s把核心业务指标的频率保持在 10s从源头降低 TSDB 的写入负载。第三考虑远端存储。等数据量再上去比如需要保留一年的历史数据可以考虑接入 Thanos 或 VictoriaMetrics 来扩展存储和查询能力。这不是必须的但如果你方向是做企业级、超大规模集群监控可以提前了解。关于调优踩过坑的人都有共鸣监控平台本身也是系统也有性能和容量规划问题。不要只顾着目标服务忘了给 Prometheus 本身做容量评估和监控。6.4 安全加固与日常巡检企业级监控平台本身握有全业务的核心元数据安全上不能掉链子。我通常会做以下几件事Prometheus 和 Grafana 的 Web 服务加上访问认证。Grafana 自带登录认证Prometheus 可以落一个 nginx 反向代理做 Basic Auth 或对接公司 SSO 统一登录。AlertManager 的 Web 端口不要直接暴露公网。它的静默管理界面如果被外人访问任何人都能静默告警这太危险了。exporter 端口只对 Prometheus 所在网段开放。除了监控抓取需求外网没理由能访问9100这类端口。定期巡检每周看一次 Targets 是否有红点、告警规则是否正常加载、磁盘空间使用率Prom 存储膨胀较快。这些巡检可以做成脚本通过 cron 每天给我发一封汇总邮件。日常巡检还有个很实用的技巧在 Grafana 建一个总览 Dashboard把所有 exporter 的up状态和 Prometheus 自身的scrape_duration_seconds放一块每早瞄一眼基本能提前发现大半隐患。这套 Prometheus Grafana AlertManager 体系我从半信半疑到完全依赖最大的感受是监控系统的价值不在“装完那一刻”而在后面每一次“坏了能早知道、定位快、不误报、不哑火”的瞬间。数据驱动决策的底气本质上就是监控告警平台给过来的。写这篇文章也是希望你把每一步的基础打牢踩着我趟过的坑直接往前走把真正的时间留给熟悉业务和优化服务。