Prometheus 加 Grafana 的监控思路

拉模型的直觉一句话就能讲清：服务端定时来抓数据，被监控端只负责把指标挂在 HTTP 地址上。理解了这一点，排错的方向感就有了：抓不到数据先查网络和端口，而不是重启被监控端。 一、这套组合怎么分工 Prometheus（开源时序数据库与监控系统）按 scrape_configs 里配置的间隔（默认 15 秒）去抓每个目标的 /metrics 接口，数据存在本地，默认保留十五天，可用 --storage.tsdb.retention.time 调整。防火墙要放行服务端到目标 9100 端口的方向，方向搞反是最常见的错误。保留期太长磁盘吃不消，需要长期数据就配远程存储，本地只留近期。Grafana（开源可视化面板）读它的数据画图。Alertmanager 独立负责告警的分组与路由。抓取失败会在 UI 的 Targets 页标红，上手第一件事就是把这一页看完。 二、exporter 挑常用的装 exporter 是暴露指标的探针程序，装一个管一类：node_exporter 管主机，mysqld_exporter 管数据库，blackbox_exporter 管 HTTP 与 TCP 拨测，nginx 也有对应组件。不必一次装全，从 node_exporter 起步，业务用到什么再加。业务自研服务也能自己暴露 /metrics，各语言都有现成的客户端库。指标命名有统一规范，同一个指标在不同机器上名字一致，聚合查询才方便。 三、大盘分层 Grafana 面板按三层组织：第一层全局概览，所有机器的存活、负载、磁盘余量一屏放下；第二层单机详情，出问题时下钻；第三层业务专项，QPS、错误率、响应时间。分层的价值是告警来了知道往哪层点，不用每次从零翻图。把变量和模板做进大盘，切机器不用改面板。面板不必从零画，社区有现成模板，导入后微调即可，模板 ID 记在文档里。 四、和已有系统的关系 机器几十台以内、想要轻量，这个组合很省心；已经有 Zabbix 的也不必推倒重来，两套并行，Prometheus 管容器和细粒度指标，Zabbix 管传统主机，互补即可。两套系统的告警要统一出口，值班的人只看一个渠道。 监控的价值在告警准不在图好看，先配告警再美化大盘。