企业官网建设流程全解析

Week 1我们把Prometheus跑起来了，监控主机、看曲线，这些都有了。但用过一段时间你就知道，这种状态离“企业级监控平台”还差很远：抓取目标全靠手写IP，加了机器要改配置，出了故障要靠人盯着Grafana才发现，告警基本靠人工转发。Week 2要解决的就是这三件事：让采集目标自动跟随业务变化的服务发现、让异常能第一时间通知到人的告警体系、以及一套能面向不同角色的可视化看板。这篇文章是完整的Week 2实操记录，适合已经完成基础安装、正准备把Prometheus往生产环境推的朋友，不少方案我都标注了自己踩坑后的取舍。

1. 抓取配置与服务发现：告别手写IP清单

1.1 再谈抓取配置：从能跑到跑得规范

第一周我们给的prometheus.yml大概长这样：

global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: 'node' static_configs: - targets: ['192.168.1.10:9100']

这个配置本身没问题，但如果你真把它用在生产环境，很快就会发现两个痛点：一是机器多了以后，targets列表会变得非常长，根本没法维护；二是新增一台机器或者下线一台机器，都得手动改配置再重启Prometheus，这个操作在生产环境里属于“变更”，要过审批、要挑时间窗口，一次变更十几分钟就没了。

个人建议是，无论环境多小，从一开始就养成“配置分文件管理”的习惯。把prometheus.yml只保留全局配置和规则文件引用，抓取目标放到独立目录里，用rule_files和scrape_configs里的file_sd_configs分别引用。这样做的直接好处是，后续加机器、加exporter、加告警规则，都不需要动主配置文件，改完目标文件后Prometheus会在刷新周期内自动感知，不需要重启进程。生产环境里“能不重启就不重启”是铁律，这一条能帮你省掉很多不必要的变更窗口。

global: scrape_interval: 15s evaluation_interval: 15s rule_files: - /etc/prometheus/rules/*.yml scrape_configs: - job_name: 'node' file_sd_configs: - files: - /etc/prometheus/targets/node/*.yml refresh_interval: 30s

1.2 服务发现：让监控自动跟随业务变化

静态配置在机器数量涨到几十台以后，会变成一个体力活。我实际见过一个团队，机房里有一百多台机器，prometheus.yml里堆了三百多行targets，每次有新机器上线，运维就得手工编辑这个文件，然后小心翼翼地执行curl -X POST http://localhost:9090/-/reload。一旦漏改一台，那台机器就没有监控，出问题的时候根本没人知道。

服务发现要解决的就是这个问题。Prometheus支持多种服务发现方式，从最简单的file_sd到Kubernetes的kubernetes_sd、Consul的consul_sd，核心逻辑都是一样的：Prometheus周期性地从一个动态源获取当前应该监控的目标列表，而不是靠手写静态清单。

对于还没有容器化的传统机房，我最推荐的是file_sd。它不依赖任何外部服务，只依赖一个文件目录，Prometheus每隔refresh_interval秒扫描一次。关键玩法是：把生成目标文件这件事交给脚本，脚本负责从配置管理库（或者CMDB、或者资产管理平台）同步机器列表，生成目标文件，Prometheus自动加载。这样机器上下线只需要在CMDB里改状态，脚本跑一次，监控目标就跟着变了。

目标文件内容很简单，每个文件就是一组YAML列表，可以带标签：

# /etc/prometheus/targets/node/prod.yml - targets: - '192.168.10.11:9100' - '192.168.10.12:9100' labels: env: 'prod' role: 'app' - targets: - '192.168.20.31:9100' labels: env: 'prod' role: 'database'

这里给目标打标签非常关键。你可以在告警规则里通过env="prod"区分生产与测试环境，也可以在Grafana看板里按role字段做下拉筛选。没有标签的监控数据是一堆裸的IP，有了标签才是可读的基础架构信息。坦白说，这是Week 1到Week 2我认为最重要的认知转变：监控数据要带业务元数据，否则告警都没法写。

1.3 relabel与metric_relabel：两把容易用混的剪刀

把服务发现配好后，有一个概念必须搞清楚，否则后面配置告警时会被坑到：relabel_configs和metric_relabel_configs不是一回事。

relabel_configs作用在抓取目标上，也就是决定“Prometheus要去抓哪些目标，以及抓目标时给它附加什么标签”。它发生在抓取动作之前。常见的用法是把__address__里的IP拆出来，加上__meta_*标签，或者过滤掉一些不想抓的目标。

metric_relabel_configs作用在抓取到的样本数据上，发生在抓取之后、存储之前。它决定的是“这批指标样本哪些要存、哪些要丢、哪些标签要改”。典型的场景是：某个exporter暴露出来的指标里有高基数标签（比如用户ID、请求URL），这些标签会导致监控数据存储爆炸，这时候就要用它把这些标签删掉。

给一个实际例子。我们用file_sd给不同环境打了env标签，这个标签是挂在目标上的，Prometheus抓数据时会把目标标签带入每个样本。但某个exporter自己暴露的指标里带了一个instance标签，它的格式是IP:9100，我们希望Prometheus默认生成的instance标签也是这个值，保持一致。这时可以通过relabel_configs替换目标标签：

scrape_configs: - job_name: 'node' file_sd_configs: - files: - /etc/prometheus/targets/node/*.yml relabel_configs: - source_labels: ['__address__'] regex: '([^:]+):([0-9]+)' target_label: 'instance' replacement: '$1:$2'

这段配置看起来作用不大，因为默认instance本来就是__address__。但它演示了relabel的运作方式。真正常用的是这种：从__meta_*标签里提取信息，写入可查询的业务标签。比如从文件发现中把env标签保留下来，这是自动完成的，但如果未来接入了Consul，你就需要从__meta_consul_tags里把环境信息提取成独立标签，写法都归relabel_configs管。

metric_relabel的使用场景更偏“数据清洗”。比如某个应用暴露的HTTP请求耗时指标里有个url标签，每个请求URL都不同，直接存储会导致series数量爆炸。用下面的配置把url标签删掉：

metric_relabel_configs: - source_labels: ['url'] regex: '.*' action: labeldrop

这两把剪刀用混的典型表现是：想过滤目标却写在了metric_relabel里，结果目标照样被抓，只是数据没进去，Prometheus日志里还会出现“target was down but metrics were received”之类的奇怪表现。我的经验是遇到这种情况先停下来想清楚：这个操作发生在抓取前还是存储前。

2. Exporter体系与指标采集规划

2.1 常用Exporter选型与适用场景

Prometheus本身不采集数据，数据都是从各种exporter拉过来的。选型这件事很多人觉得简单，实际上很容易踩坑：装错exporter、漏了关键指标、忘记给exporter加认证，都会导致监控数据覆盖不全面。

我列一个常用的exporter选型参考，以主机监控、中间件监控、网络监控、业务监控为维度：

说到选型，我特别想提两点。第一，node_exporter版本差异很大，0.16.0之前和之后采集的指标名有变化，比如CPU指标从node_cpu变成了node_cpu_seconds_total，网上很多旧教程的PromQL直接抄会报错。第二，mysqld_exporter需要数据库账号和权限，不能用root，但也别给太弱的最小权限，至少需要PROCESS、REPLICATION CLIENT、SELECT这三类权限，否则有些关键指标（比如主从状态）采集不到，告警规则写了也没数据。

2.2 用textfile模式把业务指标接进来

中间件exporter覆盖的是通用组件，但业务指标永远需要自己想办法。比如说，你们业务有个“消息队列积压任务数”，这个值是写在你们自己业务系统里的，没有现成exporter。实现办法有两个：用官方客户端库起一个自定义exporter，或者更轻量的方式——用node_exporter的textfile模式。

textfile模式的设计思路非常朴素：node_exporter定期扫描一个指定目录，目录里的.prom文件会被读取并合并到node_exporter的输出里。这些.prom文件格式就是Prometheus的文本格式，一行一行写就行。

# 每分钟生成一次业务指标文件 cat <<'EOF' > /usr/local/bin/export_biz_metrics.sh #!/bin/bash # 假设从业务系统的API或者数据库查询出积压任务数 JOB_QUEUE_DEPTH=$(curl -s http://127.0.0.1:8080/api/queue_depth) # 写入临时文件，再原子性rename，避免node_exporter读到一个写了一半的文件 cat <<METRIC > /var/lib/node_exporter/textfile/biz_metrics.prom.$$ biz_queue_depth $JOB_QUEUE_DEPTH METRIC mv /var/lib/node_exporter/textfile/biz_metrics.prom.$$ /var/lib/node_exporter/textfile/biz_metrics.prom EOF chmod +x /usr/local/bin/export_biz_metrics.sh # 加入crontab，每分钟执行一次 * * * * * /usr/local/bin/export_biz_metrics.sh

然后启动node_exporter时加一个参数：

node_exporter --collector.textfile.directory=/var/lib/node_exporter/textfile

这个方案我用了很长时间，最大的优势是稳定、简单、不引入额外端口和进程。但要提醒的是：脚本输出必须保证原子性，不能直接写到最终文件——如果node_exporter恰好在你写文件的过程中读取，可能读到半截内容，轻则解析报错，重则把整个抓取数据包搞坏。上面的例子用了先写临时文件再mv，这是标准做法。

2.3 快速实现一个自定义Exporter

textfile适合低频、简单的指标，如果业务指标复杂，或者抓取频率要求高，还是直接写一个exporter进程更合理。Prometheus官方为多种语言都提供了客户端库，写起来不复杂。

这里给一个Python版本的极简示例，用prometheus_client库起HTTP服务：

from prometheus_client import start_http_server, Gauge import random import time # 定义指标，Gauge表示当前值型指标，可以增加、减少、设定 current_queue_depth = Gauge('biz_queue_depth', 'Current queue depth') # 业务里实际获取数据的地方，这里用随机数模拟 def fetch_queue_depth(): return random.randint(0, 100) if __name__ == '__main__': # 监听8000端口，暴露 /metrics start_http_server(8000) while True: current_queue_depth.set(fetch_queue_depth()) time.sleep(15)

这个例子已经能跑起来，Prometheus配一个job名指向localhost:8000就能抓到biz_queue_depth这个指标。真实业务里，把fetch_queue_depth()替换成查询数据库、调用内部接口都行。需要注意的坑是：prometheus_client库的Gauge在进程重启后会重置，持久化计数器类指标用Counter更合适，但如果计数语义和业务实际情况对不上，宁可用Gauge每次取绝对值，也不要硬套Counter。

另外，自定义exporter最好加上process_start_time_seconds这类表示进程起止时间的指标，这样它在Grafana里就能用up和process_start_time_seconds关联出“exporter是否重启过”。这个在排障时非常有用。

3. 告警体系搭建：从“看着出问题”到“主动告诉你”

3.1 告警规则：先学会写不滥报警的表达式

Prometheus的告警体系分两层：Prometheus负责计算告警规则，Alertmanager负责把告警消息路由出去、做去重和分组。很多人以为装了Alertmanager就有告警了，其实告警规则的编写才是真正决定这套系统好不好用的部分。

一条好的告警规则，核心是表达式别误报、for时长设置合理。先看一个标准的节点存活告警：

groups: - name: node_alerts rules: - alert: InstanceDown expr: up == 0 for: 2m labels: severity: critical annotations: summary: "实例 {{ $labels.instance }} 不可达"

up == 0表示目标抓取失败，加for: 2m是为了避免瞬时抖动误报：网络闪断几秒、目标短暂重启，如果立刻告警，值班员会被折腾疯。我个人习惯把节点存活告警的for设为2分钟，把CPU、内存这类资源告警的for设到5分钟以上。

CPU使用率告警的经典表达式是这样的：

- alert: HighCPUUsage expr: 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85 for: 5m labels: severity: warning annotations: summary: "实例 {{ $labels.instance }} CPU使用率过高" description: "CPU使用率已超过85%，当前值 {{ $value | humanize }}%"

我拆解一下这个表达式为什么这么写。node_cpu_seconds_total是一个Counter类型指标，表示CPU累计使用时间，带mode标签区分空闲、用户态、系统态等。直接拿这个Counter做判断没有意义，因为数值是累计的、单调递增的。rate(metric[5m])计算的是过去5分钟每秒增加的速率，这样我们拿到的是CPU使用率的一个“瞬时切片”。再求avg是因为有多核心CPU时，要平均掉每核的差异。最后用100减去空闲率，得到的就是使用率。

这个写法几乎可以当作CPU告警的标准范式。内存告警的写法也类似：

- alert: HighMemoryUsage expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 90 for: 5m labels: severity: warning annotations: summary: "实例 {{ $labels.instance }} 内存使用率过高"

磁盘使用率告警有一个重要坑点：node_exporter的node_filesystem_*指标会包含伪文件系统，比如tmpfs、overlay，不排除的话，磁盘使用率告警会莫名其妙触发。正确写法是加fstype过滤：

- alert: DiskUsageHigh expr: (1 - node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|ramfs"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay|ramfs"}) * 100 > 85 for: 5m labels: severity: warning annotations: summary: "实例 {{ $labels.instance }} 磁盘使用率过高"

3.2 Alertmanager：告警的“路由器”

Alertmanager的核心配置是route和receiver。路由的作用是把收到的告警，按照标签匹配规则分发到不同的接收器。比如基础设施告警发给值班组，业务告警发给业务群。一个基础配置示例：

route: receiver: 'default' group_by: ['alertname', 'instance'] group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - matchers: - severity = "critical" receiver: 'critical-group' continue: true receivers: - name: 'default' email_configs: - to: 'ops@example.com' from: 'monitor@example.com' smarthost: 'smtp.example.com:25' auth_username: 'monitor@example.com' auth_password: 'password' - name: 'critical-group' email_configs: - to: 'oncall@example.com' from: 'monitor@example.com' smarthost: 'smtp.example.com:25'

这里面的参数值得逐一说清楚：

group_by是分组维度。如果多个告警的alertname和instance相同，它们会被合并到一条通知里，避免告警轰炸。你想想，一台机器挂了，可能同时触发InstanceDown、HighCPUUsage、DiskUsageHigh好几个告警，如果不分组，跟告警相关的人一个晚上能收到几十条短信，谁也不愿意。group_wait是第一批告警等多久再发，30秒的意思就是“如果30秒内还有同组告警，一起打包发出去”。group_interval是同组新告警再次评估的最小间隔，防止短时间重复发。repeat_interval是已存在的告警，多长时间重复通知一次，4小时是我常用的配置，太频繁变成骚扰，太长则可能漏掉关键告警。

子路由的continue: true比较微妙：它表示告警在匹配了这条子路由后，是否还继续匹配后面的子路由。如果需要一条告警同时发给多个接收者，就要把continue设为true。否则，匹配到第一个子路由就停止，后面的配置不生效。

3.3 接收渠道配置：邮件与Webhook

邮件是最通用的告警接收方式，但实际体验一般：告警值班人员不一定实时看邮件，而且邮件容易被当成垃圾邮件。我建议邮件作为兜底渠道，主要接收渠道用Webhook推到群机器人。

Webhook的配置很简单，Alertmanager里定义一个webhook_configs接收器：

receivers: - name: 'webhook-group' webhook_configs: - url: 'http://127.0.0.1:8000/alert' send_resolved: true

这里一个容易被忽略的细节是send_resolved: true：默认情况下Alertmanager只会发送告警触发（firing）的消息，不会发送恢复（resolved）消息。如果不把恢复消息也发出来，值班人员在群里只会看到“有问题”而永远看不到“已恢复”，一个问题排查解决后群里还挂着红色的告警卡，时间一长就分不清哪些是当前真实故障，哪些是历史消息。建议所有接收渠道都把send_resolved打开。

Webhook的服务端，可以很简单地用FastAPI或Flask实现，Alertmanager POST过来的JSON里包含status、alerts、groupLabels等字段。一个常见实现就是收到消息后，把alerts里的告警摘要和详情格式化一下，POST到群机器人的Webhook地址。这里我不展开业务系统的具体对接，只提醒一点：Alertmanager POST请求会带重试机制，服务端必须幂等处理，接收告警后先落库再推送，避免重启服务或者网络抖动导致重复推送。

3.4 抑制规则：别让告警叠罗汉

抑制规则（inhibit_rules）是最容易忽略但价值极高的配置。它解决的是“一个根因触发多个相关告警”的问题。比如：一台机器宕机了，必然同时触发InstanceDown和HighCPUUsage（因为无法抓取导致CPU指标算出来异常）、可能还有DiskUsageHigh。

如果你不想在凌晨三点因为同一台机器连续收到七八条告警，可以配置抑制规则，让高级别的告警抑制低级别的相关告警：

inhibit_rules: - source_matchers: - severity = "critical" target_matchers: - severity = "warning" equal: ['instance']

这条规则的意思是：如果一个实例上存在severity=critical的告警，那么同一个实例上的severity=warning告警会被抑制，不发送通知。只有更严重的critical告警会推送给值班员。这能让告警总量大幅下降，值班体验也会好很多。

使用时有个细节：不要把抑制看成“丢弃”，被抑制的告警在Alertmanager的网页UI里仍然可以看到，的状态标记为Inhibited。这很重要，因为它意味着抑制只是暂缓通知，不是删掉数据，问题还是可见的。如果你发现某条告警一直被抑制导致没人处理，可以去Alertmanager UI里查，而不是抱怨为什么没收到通知。

4. 可视化与PromQL实战：让数据会说人话

4.1 几个高频PromQL查询写法

这一节不讲语法，直接给查询示例，都是我在真实看板里用了很多次的写法。

查询每台机器的CPU使用率：

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

注意这个加了by (instance)，效果是每个实例单独一行曲线，不搞全局平均。全局平均掩盖了单台机器的问题，你做监控是看病，不是算整体KPI。

查询每台机器的内存可用量（按字节），更直观的写法是转成G或M：

node_memory_MemAvailable_bytes / 1024 / 1024 / 1024

如果你的看板要给人看，最好在Grafana面板的“Unit”里设置为gigabytes，这样数值能直接显示成GB，不用在PromQL里手动除三次。Grafana的Unit设置会在面板渲染时转换单位，比写死除法更灵活。

查询磁盘使用率排名前5的挂载点：

topk(5, 100 - (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|ramfs"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay|ramfs"} * 100))

topk函数适合这种“谁的磁盘快满了”的排序场景，只显示最高的5个，看板不拥挤。

还有一个预测类函数很实用。磁盘空间告警除了看当前值，更应该看趋势：

predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|ramfs"}[6h], 4 * 24 * 3600) < 0

predict_linear基于过去6小时的数据，线性外推4天后的值，如果预测值小于0，说明磁盘可能在4天内耗尽。这是个理论上很漂亮、实际也好用的告警策略，比单纯看当前占用率更能提前发现风险。当然线性外推不完美，如果业务写入波动大，需要调长观察窗口或提高阈值，但它确实解决了我手头“磁盘还没满，但马上要满”的提前预警需求。

4.2 Grafana数据源与看板制作要点

Grafana接入Prometheus作为数据源很简单，重点在于看板规划。企业级看板不应该是所有人看同一个大盘子，而应该是角色化、分层级的。

至少分成三层：总览层，给管理层看，显示整体健康度、服务可用性、资源水位，用百分比和等级颜色，不展示具体服务器IP；中间层，给运维和研发负责人看，按业务或团队拆分，可以下钻到某个模块的资源使用、错误率、依赖状态；明细层，给一线值班和故障排查的人看，展示具体实例的详细指标曲线，用于定位问题根因。

Grafana的变量功能能解决“一套看板适配所有实例”的问题。在Dashboard Settings里定义Variables，例如：

# 查询类型：Query，数据源：Prometheus # 变量名：instance # 查询语句： label_values(node_uname_info, instance)

然后设置一个面板，查询语句写成：

100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

在面板的Legend里加上{{instance}}，或者利用Grafana的模板变量：查询语句用{instance=~"$instance"}引用变量，这样下拉框选择哪台机器，整个看板就联动展示哪台机器的数据。

做看板时我有个习惯：每个面板都加上明确的“Unit”和“Description”。Unit影响数字怎么显示，Description会在鼠标悬停时提醒别人这个指标的含义和阈值建议。看板是给人用的，不是给自己自嗨的，团队里有人接手时，没有描述的面板就像没有注释的代码，很难维护。

5. 常见问题与排查技巧实录

5.1 实战中遇到的三个典型故障

第一个故障是数据断点。某天发现Grafana上所有实例的CPU曲线都出现了规律的“间隙”，每隔一段时间就缺一小段数据。排查后发现问题出在抓取超时：scrape_timeout默认是10秒，而当时某个exporter响应越来越慢，超过10秒时Prometheus放弃这次抓取，标记为失败，数据自然就缺了。

这个问题的隐蔽性在于：它不是完全没数据，而是“部分数据缺失”，看板曲线依然能画出来，但会有规律性的小凹陷。排查思路是去Prometheus的Targets页面看抓取耗时，如果接近scrape_timeout上限，就该优化exporter性能，或者单独给这个job调大超时时间：

scrape_configs: - job_name: 'slow-job' scrape_timeout: 30s

第二个故障是磁盘告警“虚假轰炸”。配置完磁盘告警后，集群里所有机器几乎同时触发DiskUsageHigh，面板上全是红的。查了表达式才明白是伪文件系统导致的：容器节点上overlay和tmpfs使用率虚高，把根分区的真实磁盘掩盖了。解决办法就是表达式里加上fstype!~"tmpfs|overlay|ramfs"过滤，告警立刻安静下来。

第三个故障是数据高基数导致的存储膨胀。某自定义exporter暴露了一个标签为user_id的指标，每个用户一个值，日活用户几十万，series数量直接暴涨，Prometheus内存占用飙到几个G，查询响应也变得很慢。最后用metric_relabel_configs把user_id标签删掉，改成按业务维度聚合后的指标，存储压力马上降下来。这个教训告诉我：不要在监控系统里存高基数的原始标签，业务系统里的明细数据应该留在业务库，监控系统只要聚合结果。

5.2 排查速查表

排查告警问题时，我强烈建议先掌握amtool这个命令行工具。它和Alertmanager一起安装，可以离线校验配置文件，语法没问题再进服务验证。实际排查顺序是：先看Prometheus的Alerts页面，确认规则有没有触发、状态是Pending还是Firing；再看Alertmanager的UI，确认告警有没有进到Alertmanager、有没有被路由匹配、有没有被抑制；最后才去看通知渠道有没有发出。按这个顺序排查，能快速定位问题出在哪一层。

写在最后

从Week 1到Week 2，我把Prometheus从“能跑”推到了“能用”。这周做完后最大的感受是：监控平台真正的成本不在安装部署，而在规则和配置的长期维护。告警规则写多了会误报，写少了会漏报；看板做得花哨但没人看就是废的；服务发现配好了但CMDB数据是脏的，监控目标照样不准。根据我个人的经验，Week 2的核心产出应该是：一套有标签体系的服务发现、一组经过业务校验的告警规则、一个不轰炸人的Alertmanager配置，以及一张让团队愿意打开的大屏。这些东西全部落地，Prometheus才算是融入了你的运维日常，而不是一个偶尔打开看一眼的小玩具。

最后再分享一个小技巧：多利用Prometheus的rules里的record规则，把复杂计算做成预聚合。比如每条告警规则里的CPU使用率表达式，如果多个规则和看板都用它，建议记录为job:cpu_usage:rate5m，这样查询时直接引用这个记录名，既减少Prometheus重复计算的压力，也让告警规则的表达式一眼能看懂。这条建议越早做收益越大，等规则文件写到一百条再去重构，就得加班了。