1. 为什么监控这件事绕不开Prometheus搞过线上服务的人都有一个共识系统不出问题的时候监控就是个摆设一旦出问题没有监控就是睁眼瞎。我最早做运维那会儿排查故障全靠SSH登机器、top、tail -f看日志一台两台还能应付上了十台二十台就彻底抓瞎了。后来开始接触Prometheus才算是真正把监控这件事从“人肉巡检”变成了“体系化观测”。Prometheus本质上是一套开源的监控告警系统核心思路是主动拉取Pull指标数据然后存储为时间序列再通过灵活的查询语言做分析和告警。它最早受启发于Google内部的Borgmon系统后来在云原生社区里迅速成为事实标准。现在你去看任何一个Kubernetes集群默认的监控方案几乎都是Prometheus加Grafana这套组合。这篇文章主要面向两类人一是刚接触Prometheus、准备从零搭建一套监控系统的运维或后端开发二是已经用过但想系统梳理部署细节、避免踩坑的从业者。我会从架构选型讲到具体部署再到常见问题排查把“Prometheus部署”这件事拆开了揉碎了讲清楚。你跟着走一遍基本能独立完成一套可用的监控环境搭建。2. 部署之前必须搞清楚的架构逻辑2.1 Pull模型到底好在哪Prometheus最核心的设计决策就是采用Pull模型——由Prometheus Server主动去目标端拉取指标而不是目标端推送到Server。这个选择背后有很实际的考量。Push模型的问题在于当目标端数量多、推送频率高的时候Server端的接收压力不可控而且目标端一旦挂了你根本不知道它是“没数据推”还是“挂了所以没推”。Pull模型天然解决了这个问题——Server定期去拉拉不到就说明目标端有问题up指标直接变成0告警立刻触发。另外Pull模型让目标端的配置更简单被监控的服务只需要暴露一个HTTP接口不需要关心Server在哪里。当然Pull模型也有它的局限。短生命周期任务比如定时脚本、批处理Job还没来得及被拉取就结束了这时候就需要Pushgateway来做中转。这个后面会细说。2.2 核心组件拆解一套完整的Prometheus监控体系通常包含以下几个组件我按重要性排个序Prometheus Server核心中的核心负责服务发现、指标抓取、时序存储和查询计算。它自带一个TSDB时间序列数据库本地存储。Exporter被监控端的“翻译官”把各种系统的内部状态翻译成Prometheus能识别的指标格式。常见的有Node Exporter主机指标、MySQL Exporter、Redis Exporter等。Alertmanager独立于Server的告警组件负责告警的去重、分组、静默和路由。Prometheus Server只负责触发告警规则具体怎么发、发给谁由Alertmanager决定。Grafana可视化面板虽然Prometheus自带的Web UI也能查数据画图但Grafana的仪表盘能力和美观度完全不是一个量级。Pushgateway专门接收短生命周期任务的推送数据让Prometheus也能拉到这些“一闪而过”的指标。理解这几个组件的职责边界很重要。我见过不少人把告警规则写在Alertmanager里或者试图让Prometheus Server直接发邮件——这都是搞混了组件分工。记住一句话Server管采集和规则判断Alertmanager管告警分发Grafana管展示。2.3 存储方案怎么选Prometheus自带的本地TSDB在单机场景下性能相当能打每秒摄入几十万条样本没问题。但它有两个硬伤一是数据不持久化到远端的话容器重启就丢了二是单机存储容量有上限长期数据保留成本高。常见的存储方案有这么几种方案适用场景优点缺点本地TSDB中小规模、短期保留零依赖、性能好容量有限、不持久远程写入对象存储大规模、长期保留成本低、容量无限查询延迟高远程写入时序数据库大规模、高频查询查询快、可扩展运维复杂度高我的建议是刚开始部署先用本地TSDB设置合理的保留时间比如15天等数据量真的上来了再考虑远程存储。一上来就搞分布式存储纯属给自己找麻烦。3. 手把手部署Prometheus Server3.1 环境准备与二进制安装我习惯用二进制方式部署Prometheus因为可控性最强出问题好排查。Docker方式虽然简单但网络模式和存储挂载有时候会带来额外的调试成本。这里以Linux环境为例。首先创建专用用户和目录结构。Prometheus不应该用root跑这是基本的安全意识useradd --no-create-home --shell /bin/false prometheus mkdir -p /etc/prometheus /var/lib/prometheus chown prometheus:prometheus /etc/prometheus /var/lib/prometheus下载对应版本的二进制包解压后把可执行文件放到/usr/local/binwget https://github.com/prometheus/prometheus/releases/download/v2.48.0/prometheus-2.48.0.linux-amd64.tar.gz tar xvf prometheus-2.48.0.linux-amd64.tar.gz cd prometheus-2.48.0.linux-amd64 cp prometheus promtool /usr/local/bin/ chown prometheus:prometheus /usr/local/bin/prometheus /usr/local/bin/promtool配置文件和控制台模板也要放到位cp -r consoles console_libraries /etc/prometheus/ cp prometheus.yml /etc/prometheus/ chown -R prometheus:prometheus /etc/prometheus注意版本号要根据实际情况选择建议选最新的稳定版。下载地址如果访问不畅可以找国内镜像源。3.2 配置文件逐项拆解Prometheus的配置文件是YAML格式核心结构就四块global、alerting、rule_files、scrape_configs。我把一个生产可用的配置模板贴出来然后逐项解释global: scrape_interval: 15s evaluation_interval: 15s scrape_timeout: 10s alerting: alertmanagers: - static_configs: - targets: - localhost:9093 rule_files: - rules/*.yml scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: node static_configs: - targets: [localhost:9100]scrape_interval是抓取间隔默认15秒。这个值怎么定取决于你的监控精度需求和存储成本。间隔越短数据点越密存储压力越大。一般业务监控15秒够用核心交易系统可以调到5秒。evaluation_interval是告警规则的计算频率通常和抓取间隔保持一致。scrape_timeout必须小于scrape_interval否则会出现上一次还没抓完下一次就开始了的尴尬情况。我一般设成抓取间隔的三分之二左右。rule_files指定告警规则文件的位置支持通配符。建议按业务模块拆分成多个文件别全堆在一个文件里不然改起来容易出错。scrape_configs是重点每个job_name代表一组抓取目标。static_configs是最简单的服务发现方式直接写死目标地址。生产环境更推荐用file_sd_configs或者基于Consul、Kubernetes的服务发现这样增删节点不用改配置文件。3.3 Systemd托管与启动验证用Systemd来管理Prometheus进程保证开机自启和异常重启[Unit] DescriptionPrometheus Wantsnetwork-online.target Afternetwork-online.target [Service] Userprometheus Groupprometheus Typesimple ExecStart/usr/local/bin/prometheus \ --config.file/etc/prometheus/prometheus.yml \ --storage.tsdb.path/var/lib/prometheus/ \ --storage.tsdb.retention.time15d \ --web.listen-address0.0.0.0:9090 \ --web.enable-lifecycle [Install] WantedBymulti-user.target这里有几个参数值得说明。--storage.tsdb.retention.time15d设置数据保留15天根据磁盘容量调整。--web.enable-lifecycle开启热加载改完配置文件后可以直接curl -X POST http://localhost:9090/-/reload重载不用重启进程这个在调试阶段特别方便。启动并验证systemctl daemon-reload systemctl start prometheus systemctl enable prometheus systemctl status prometheus浏览器访问http://服务器IP:9090能看到Prometheus的Web UI就说明启动成功了。在顶部的Graph页面输入up如果能看到{jobprometheus} 1这样的结果说明自监控已经正常工作了。4. Exporter部署与指标采集实战4.1 Node Exporter采集主机指标Prometheus Server自己只能采集自身的指标要监控主机CPU、内存、磁盘、网络这些必须部署Node Exporter。它跑在被监控主机上暴露一个/metrics接口Prometheus定期来拉。部署方式和Prometheus类似也是二进制加Systemdwget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz tar xvf node_exporter-1.7.0.linux-amd64.tar.gz cp node_exporter-1.7.0.linux-amd64/node_exporter /usr/local/bin/Systemd配置[Unit] DescriptionNode Exporter Afternetwork.target [Service] Userprometheus ExecStart/usr/local/bin/node_exporter \ --collector.systemd \ --collector.processes [Install] WantedBymulti-user.target--collector.systemd和--collector.processes是额外开启的采集器默认没开。Node Exporter支持的采集器很多但不是开得越多越好每个采集器都会消耗资源。建议按需开启用--no-collector.xxx关掉不需要的。启动后在Prometheus的配置文件里加上对应的job- job_name: node static_configs: - targets: [192.168.1.10:9100, 192.168.1.11:9100] labels: env: production role: weblabels是Prometheus的精华所在。同样的指标名通过不同的label区分不同主机、不同环境、不同角色。查询的时候用node_cpu_seconds_total{envproduction}就能精确过滤。label设计得好后面的查询和告警会轻松很多。4.2 常用Exporter选型对照不同中间件和数据库都有对应的Exporter我整理了一份常用清单监控对象Exporter名称默认端口关键指标Linux主机node_exporter9100CPU、内存、磁盘、网络MySQLmysqld_exporter9104连接数、QPS、慢查询Redisredis_exporter9121内存、命中率、连接数Nginxnginx-prometheus-exporter9113请求数、连接数、状态码黑盒探测blackbox_exporter9115HTTP/TCP/ICMP探测选Exporter有个原则优先用官方或社区维护活跃的别用那种几年没更新的。另外要注意Exporter本身的资源消耗有些Exporter采集频率高了会拖慢被监控服务这个要在测试环境验证。4.3 抓取配置的进阶技巧当目标数量多了以后static_configs就不够用了。这时候可以用file_sd_configs把目标列表放到独立的JSON文件里Prometheus会自动监听文件变化- job_name: node file_sd_configs: - files: - /etc/prometheus/targets/node_*.json refresh_interval: 30s对应的JSON文件格式[ { targets: [192.168.1.10:9100], labels: { env: production, role: web } } ]这样增删节点只需要改JSON文件不用动主配置也不用重载Prometheus。再配合配置管理工具自动生成这个文件就能实现半自动化的服务发现。还有一个实用技巧是metric_relabel_configs可以在抓取后对指标做过滤和重命名。比如有些Exporter暴露了大量无用的指标可以用drop动作丢掉减少存储压力metric_relabel_configs: - source_labels: [__name__] regex: go_.* action: drop上面这个配置会丢弃所有以go_开头的指标因为Go运行时指标对业务监控通常没什么用。5. 告警规则与Alertmanager配置5.1 告警规则怎么写才靠谱告警规则写在rule_files指定的文件里核心结构是groups包含多个rules。每条规则由alert、expr、for、labels、annotations组成groups: - name: host_alerts rules: - alert: HostHighCpuLoad expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 80 for: 5m labels: severity: warning annotations: summary: 主机CPU负载过高 (实例: {{ $labels.instance }}) description: CPU使用率已超过80%持续5分钟。当前值: {{ $value }}%expr是PromQL表达式上面这条的意思是计算5分钟内CPU空闲率的平均值用100减去得到使用率超过80就触发。for: 5m表示持续5分钟满足条件才真正告警避免毛刺误报。这个for参数非常关键我见过太多人忘了设结果一个瞬时抖动就收到一堆告警。annotations里的{{ $labels.instance }}和{{ $value }}是模板变量告警发出时会替换成实际值让告警信息更有针对性。5.2 Alertmanager的 routing 逻辑Alertmanager的配置文件核心是route树决定告警往哪里发route: receiver: default group_by: [alertname, instance] group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - match: severity: critical receiver: critical repeat_interval: 1h receivers: - name: default webhook_configs: - url: http://localhost:5001/webhook - name: critical webhook_configs: - url: http://localhost:5002/webhookgroup_by决定哪些告警会被合并成一条。比如同一台机器的多个告警按instance分组后就只发一条通知避免告警风暴。group_wait是首次告警的等待时间给同一组的其他告警一点时间凑齐。repeat_interval是重复告警的间隔设太短会被骚扰设太长又怕漏掉。实操心得group_wait和group_interval这两个参数需要根据告警量反复调优。告警量大的环境group_wait可以设到1分钟让更多告警合并告警量小的环境30秒就够了免得延迟太久。5.3 告警分级与静默策略告警一定要分级不然所有告警都一个优先级时间长了人就麻木了。我一般分三级critical影响线上服务必须立即处理比如服务不可用、磁盘写满。warning有隐患但不影响服务比如CPU持续偏高、连接数接近上限。info仅记录不需要人工介入比如证书还有30天过期。静默Silence是Alertmanager很实用的功能。做维护、发版的时候提前创建一条静默规则指定时间窗口和匹配标签这段时间内的相关告警就不会发出来。比临时去改配置文件优雅多了。6. 部署踩坑实录与排查技巧6.1 常见问题速查表现象可能原因排查方法目标状态为DOWN网络不通/端口未监听/防火墙拦截curl目标/metrics接口指标缺失Exporter未开启对应采集器查看Exporter启动参数数据写入慢磁盘IO瓶颈/抓取目标过多检查磁盘IO和抓取耗时告警不触发规则表达式错误/for时间未到在Web UI的Alerts页面查看状态内存持续增长高基数指标/label设计不当用promtool tsdb analyze分析6.2 高基数问题最隐蔽的性能杀手高基数High Cardinality是Prometheus部署中最容易踩的坑没有之一。什么叫高基数就是某个label的取值太多了。比如你把用户ID、请求ID、URL全路径作为label那指标数量会爆炸式增长内存和存储瞬间被吃光。我踩过一次典型的坑给HTTP请求指标加了个path标签结果因为URL里带了参数每个不同的参数组合都成了一个独立的时间序列几天时间序列数量从几千涨到了几百万Prometheus直接OOM。判断方法很简单在Prometheus Web UI里查prometheus_tsdb_head_series看看当前时间序列总数。正常应该稳定在一个区间如果持续快速增长就要查是哪个指标贡献的。用这个查询可以定位topk(10, count by(__name__)({__name__~.}))它会列出时间序列数量最多的10个指标名。找到元凶后用metric_relabel_configs把那个高基数的label drop掉或者用hashmod做分片。6.3 时间不同步导致的诡异问题Prometheus对时间敏感如果服务器时间不同步会出现各种奇怪现象指标时间戳错乱、告警延迟触发、Grafana图表断点。部署前务必确认NTP服务正常运行timedatectl status看到System clock synchronized: yes才放心。我遇到过一台机器时间慢了3分钟结果那台机器上的所有告警都比别的机器晚3分钟触发排查了半天才发现是时间问题。6.4 存储容量估算与保留策略本地TSDB的磁盘占用和几个因素有关时间序列数量、抓取间隔、保留时长。有个粗略的估算公式磁盘占用 ≈ 时间序列数 × 样本大小(约1-2字节压缩后) × (86400 / 抓取间隔) × 保留天数举个例子10000个时间序列15秒抓取间隔保留15天10000 × 1.5 × 5760 × 15 ≈ 1.3GB。实际会因为有压缩和索引开销略高一些但量级差不多。设置保留时间的时候要留足磁盘余量别把磁盘写满。Prometheus磁盘写满后行为不可预测可能直接崩溃。建议磁盘使用率超过70%就考虑清理或扩容。7. 部署完成后的验证清单部署完别急着上生产按这个清单过一遍访问Prometheus Web UI确认Status - Targets里所有目标都是UP状态。在Graph页面查询up确认所有job都有数据返回。查询rate(node_cpu_seconds_total[5m])确认能拿到主机CPU数据。检查Status - Configuration确认配置加载正确。检查Status - Rules确认告警规则已加载且表达式无语法错误。手动触发一个测试告警确认Alertmanager能收到并正确路由。用promtool check config /etc/prometheus/prometheus.yml做配置语法校验。检查Prometheus自身的内存和磁盘占用确认在合理范围。这套流程走下来一套可用的Prometheus监控环境就算搭好了。后面还可以继续扩展接入Grafana做可视化、配置远程存储做长期保留、用Thanos或VictoriaMetrics做集群化。但那是下一步的事了先把单机这套跑稳比什么都重要。我个人在实际操作中的体会是Prometheus部署本身不难难的是label设计和告警规则的打磨。这两件事没有标准答案得根据自己的业务特点反复调。刚开始宁可告警少一点、粗一点也别搞一堆噪音告警不然用不了多久整个团队就都对告警免疫了那监控就白做了。