简介这份资源是一份面向运维工程师与Linux系统管理者的Prometheus宿主机监控实操文档聚焦如何用Prometheus对Linux服务器节点建立从指标采集到告警通知的完整监控链路适合具备一定Linux基础、需要落地主机层监控的技术人员参考。资源包内仅1个docx文档压缩包约10.65MB以图文并茂的文档形式承载两套宿主机192.168.10.91、192.168.10.92的部署配置过程与结果截图便于离线阅读和按步骤对照实践。文档内容围绕node_exporter二进制安装、basic_auth加密认证配置借助htpasswd生成密码、config.yml编写、systemd服务托管与9100端口验证展开同时包含Alertmanager二进制部署、邮箱告警配置以及通过Grafana构建CPU、内存、磁盘I/O等仪表板的思路并提及静态配置与服务发现两种目标接入方式。已有913人学习该资源文档对采集间隔、超时等关键参数与排错细节均有交代可帮助读者较快搭建起可观测的主机监控体系。1. 宿主机监控链路Prometheus 拉模型与 node_exporter 的定位半夜两点 CPU 被某个进程打满业务接口超时但没有任何人收到通知——这是自建监控最典型的触发场景。Prometheus很多人直接叫它普罗米修斯本身并不采集宿主机的 CPU、内存、磁盘、网卡数据它只做三件事按固定周期去 HTTP 端点拉取文本格式的指标、把指标按时间序列落盘、按规则判断要不要触发告警。真正把 Linux 内核态数据翻译成指标的是部署在每台被监控机上的 node_exporter。所以整条链路是分层的node_exporter 只暴露/metrics不存储、不出图、不告警Prometheus 负责拉取与评估Grafana 负责可视化Alertmanager 负责把告警按路由分发到邮箱或 IM。这种设计的好处是被监控端极轻量一个二进制文件加一个 systemd 单元就能跑起来宿主机上不需要装 JVM、不需要开数据库。适合的场景是手里有十几台到几百台 Linux 服务器、想自己掌控监控数据、又不想被商业 APM 按主机数收费的运维团队。2. node_exporter 二进制部署与 basic_auth 认证2.1 为什么给 9100 端口加认证node_exporter 默认无认证任何能连通 9100 的人都能拿到主机名、内核版本、文件系统挂载点、网卡列表、进程数这些信息拼起来足够画出一张内网拓扑图。生产环境里通常不会把 9100 直接暴露到公网但内网横向渗透同样需要防。Prometheus 从 2.x 开始支持在 scrape 侧配置basic_authnode_exporter 从 1.0 之后支持--web.config指定认证文件两边配合就能实现带密码拉取。密码不能明文写进配置文件要用 bcrypt 哈希。CentOS/RHEL 上生成哈希最省事的办法是装httpd-tools借用里面的htpasswd# 安装 htpasswd 工具 yum -y install httpd-tools # -n 输出到标准输出不写文件-B 使用 bcrypt 算法-C 12 指定 cost 因子 # 用户名字段传空串生成后由 tr 去掉冒号和换行只留哈希 htpasswd -nBC 12 | tr -d :\n # 交互式输入两次明文密码例如 123456 # 输出形如$2y$12$vckkSTR4nweF2zMq.GjRzuUNls9Ol5FOws/cMCUn77vY0AvdlUi76参数说明-B强制 bcrypt不写会退化成 MD5 或 SHA1-C 12是 cost 因子每加 1 计算量翻倍12 在安全和启动耗时之间比较平衡调到 14 以上会让 node_exporter 每次启动慢上几秒tr -d :\n是因为htpasswd -n的输出格式是用户名:哈希空用户名会留下一个前导冒号直接粘进 YAML 会把文件搞坏。2.2 config.yml 的写法与文件权限把上一步得到的哈希写进 node_exporter 的 web 配置文件# /data/node_exporter/config.yml basic_auth_users: # 用户名: bcrypt 哈希明文密码是 123456 prometheus: $2y$12$vckkSTR4nweF2zMq.GjRzuUNls9Ol5FOws/cMCUn77vY0AvdlUi76注意 YAML 里$不需要转义但整个哈希必须在一行内中间不能断行。文件权限建议设成600且属主为运行 node_exporter 的用户否则同机器上的普通账号能读到哈希。虽然 bcrypt 抗爆破但没必要给攻击者送材料。解压与目录规划按常规来tar -zxf node_exporter-1.3.1.linux-amd64.tar.gz mv node_exporter-1.3.1.linux-amd64 /data/node_exporter cd /data/node_exporter # 目录下会有 node_exporter、LICENSE、NOTICE 三个文件2.3 手工启动与 systemd 托管先用前台方式验证一次确认配置文件路径没问题/data/node_exporter/node_exporter --web.config/data/node_exporter/config.yml如果配置文件有语法错误进程会直接退出并打印Error loading config这一点比 systemd 里翻 journal 快得多。确认能起来后按 CtrlC 停掉交给 systemd# /usr/lib/systemd/system/node_exporter.service [Unit] Descriptionnode_exporter daemon Afternetwork.target [Service] Restarton-failure RestartSec5 ExecStart/data/node_exporter/node_exporter --web.config/data/node_exporter/config.yml [Install] WantedBymulti-user.targetsystemctl daemon-reload systemctl enable --now node_exporter systemctl status node_exporter netstat -anput | grep 9100Restarton-failure保证进程异常退出后自动拉起但systemctl stop属于正常退出不会触发重启这是排查时手动停服务的正确姿势。Afternetwork.target比network-online.target更宽松node_exporter 本身不依赖外网只监听本地端口等网络就绪反而拖慢启动。部署完成后用 curl 验证认证是否真的生效# 不带凭据期望返回 401 curl -s -o /dev/null -w %{http_code}\n http://192.168.10.91:9100/metrics # 带凭据期望返回 200 并输出指标文本 curl -u prometheus:123456 -s http://192.168.10.91:9100/metrics | head -n 20被监控机按同样步骤逐台部署浏览器访问http://IP:9100/会弹出认证框用户名prometheus、密码123456即可看到指标页面。提示node_exporter 的--web.config参数是 1.0 之后才有的如果用了更早的版本这个参数会被当成未知 flag 直接报错升级二进制即可。组件默认端口作用是否需认证node_exporter9100暴露宿主机指标建议开启Prometheus9090拉取与存储指标视网络环境Alertmanager9093告警路由与去重建议限制来源Grafana3000图表展示首次登录强制改密3. Prometheus 主配置解析静态 target 与 file_sd 服务发现3.1 global 段决定采样节奏prometheus.yml的global段控制全局采集与评估节奏是整份配置里最先要定下来的东西global: scrape_interval: 15s # 单个 target 的采集间隔 evaluation_interval: 15s # 告警规则的评估间隔这两个值不是越小越好。scrape_interval调到 5s单机每秒要处理几百个指标样本磁盘写入和内存占用都会明显上升而宿主机层面的 CPU、内存变化本身就没那么剧烈调到 1m 又会让for: 1m的告警反应迟钝。15s 是社区默认值绝大多数场景下不需要动。真正需要动的是scrape_timeout默认 10s如果目标机器负载高导致/metrics响应慢加长超时比缩短间隔更有效。3.2 static_configs把 target 写死在配置里静态配置适合机器数量少、变动不频繁的场景比如三五台固定的数据库服务器alerting: alertmanagers: - static_configs: - targets: - 192.168.10.92:9093 rule_files: - rules/*.yml scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: nodes basic_auth: username: prometheus password: 123456 static_configs: - targets: [192.168.10.92:9100, 192.168.10.91:9100]job_name会作为job标签附加到该组下所有时间序列上targets里每个地址则会成为一条instance标签形如instance192.168.10.91:9100。后面写告警规则时by (instance)就是按这个维度聚合。basic_auth写在 job 级别而不是 instance 级别意味着同一个 job 下所有 target 必须用同一套凭据如果几台机器的密码不一样就得拆成多个 job。3.3 file_sd_configs改文件不用重启机器数量上去以后每加一台改一次主配置再重启 Prometheus代价太高。基于文件的服务发现把 target 列表拆出来放到独立文件里Prometheus 定期扫描文件变化并热更新scrape_configs: - job_name: node file_sd_configs: - files: [/data/prometheus/sd_config/node.yaml] refresh_interval: 5s被引用的文件内容格式比主配置更宽松一个列表就够# /data/prometheus/sd_config/node.yaml - targets: - 192.168.171.130:9100 - 192.168.171.131:9100 labels: group: webrefresh_interval默认 5m改成 5s 是为了扩容后立刻生效。文件发现还支持在条目里直接挂labels比如按业务线打上group: web、group: db这样在 Grafana 里就能用一个模板变量切换机器分组不用写死 IP。维度static_configsfile_sd_configs变更方式改主配置并重载改独立 YAML 文件生效速度秒级需热加载refresh_interval 内附加标签仅 job 级每条 target 可单独打标适用规模几十台以内数百台按业务分文件3.4 promtool 校验与配置热加载改完配置直接重启是大忌重启期间所有采集中断可能正好错过一次故障。先用自带工具校验语法/data/prometheus/promtool check config /data/prometheus/prometheus.yml # 输出 SUCCESS: ./prometheus.yml is valid prometheus config file syntax校验通过后再触发热加载。需要启动时带--web.enable-lifecycle否则/-/reload接口会被拒绝curl -X POST http://192.168.10.92:9090/-/reload如果没开 lifecycle退而求其次用systemctl reload prometheus或者发SIGHUP信号前提是 systemd 单元里配置了ExecReload/bin/kill -HUP $MAINPID。直接kill -HUP $(pidof prometheus)也能生效但不留痕多人协作时不如前两种方式清楚。注意rule_files里的路径是相对于 Prometheus 启动时的工作目录解析的如果你在 systemd 单元里没写WorkingDirectory用相对路径rules/*.yml可能匹配不到任何文件日志里只会提示no rule files match不报错也不告警很容易埋雷。4. 告警规则文件与 PromQL 阈值编写4.1 规则文件的四层结构一个规则文件从外到内是groups→rules→ 单条规则 →labels/annotations# /data/prometheus/rules/general.yml groups: - name: general.rules rules: - alert: InstanceDown expr: up 0 for: 1m labels: severity: error annotations: summary: Instance {{ $labels.instance }} 停止工作 description: {{ $labels.instance }}: job {{ $labels.job }} 已经停止 1 分钟以上alert的值就是 Alertmanager 里alertname标签的取值命名要能一眼看懂别用Alert1。expr是 PromQL 表达式返回非空结果集就进入 Pending 状态持续满足for指定的时长后才转成 Firing 并推给 Alertmanager。for是压制抖动的第一道闸网络闪断、采集偶发超时都会被它吃掉。labels里的severity后面可以直接在 Alertmanager 的路由树里用来分流比如severityerror走电话、warning走邮件。annotations里的{{ $labels.xxx }}和{{ $value }}是模板变量前者取该条时间序列上的标签值后者取当前表达式的计算结果。写{{ $labels.instance }}而不是硬编码 IP规则文件才能复用到所有机器上。4.2 CPU、内存、磁盘三条生产口径宿主机告警里最常写的就是这三条。CPU 使用率的思路是用空闲率反推- alert: NodeCPUUsage # irate 取 5 分钟内的瞬时增长率avg by instance 把多核聚合成一台机器 expr: 100 - (avg(irate(node_cpu_seconds_total{modeidle}[5m])) by (instance) * 100) 80 for: 5m labels: severity: warning annotations: summary: {{ $labels.instance }}: CPU 使用过高 description: {{ $labels.instance }}: CPU 使用率超过 80% (当前值: {{ $value }})内存使用率要把 cache 和 buffer 减掉否则 Linux 会把空闲内存全拿去做页缓存指标永远显示 90% 以上- alert: NodeMemoryUsage expr: 100 - (node_memory_MemFree_bytes node_memory_Cached_bytes node_memory_Buffers_bytes) / node_memory_MemTotal_bytes * 100 80 for: 5m labels: severity: warning磁盘按挂载点算用fstype过滤掉 tmpfs、overlay 这类不需要关注的伪文件系统- alert: NodeFilesystemUsage expr: 100 - (node_filesystem_free_bytes{fstype~ext4|xfs} / node_filesystem_size_bytes{fstype~ext4|xfs} * 100) 80 for: 5m labels: severity: warning annotations: summary: {{ $labels.instance }}: {{ $labels.mountpoint }} 分区使用过高 description: {{ $labels.instance }}: {{ $labels.mountpoint }} 使用率超过 80% (当前值: {{ $value }})4.3 阈值必须先算对再写进规则许多现成文档里的示例阈值写的是 1那是为了方便演示、一部署就能立刻看到告警效果直接搬到生产会变成灾难——磁盘用到 1% 就发邮件收件箱几分钟就爆。正确流程是把表达式先丢到 Prometheus 的 Graph 页面跑一遍看清楚正常水位在哪再定阈值。指标名含义单位node_cpu_seconds_totalCPU 各模式累计耗时秒Counternode_memory_MemTotal_bytes物理内存总量字节node_memory_Cached_bytes页缓存占用字节node_filesystem_free_bytes分区可用空间字节node_filesystem_size_bytes分区总容量字节判断表达式是否正确有个简单办法把结果集类型切到 Table看每条序列的 instance 和 mountpoint 标签是否齐全缺标签说明聚合函数写漏了by子句。另外注意node_cpu_seconds_total、node_filesystem_free_bytes属于 Counter 或易变 Gauge前者必须套rate/irate直接拿来做减法会得到毫无意义的累计值。5. Alertmanager 路由分组与邮件告警打通5.1 global 段与 SMTP 凭据Alertmanager 的配置分两块global定义默认的发信通道route定义告警怎么分流。邮箱告警最容易踩的坑是把登录密码当成smtp_auth_password实际上 163、QQ 这类邮箱都要求填「授权码」# /data/alertmanager/alertmanager.yml global: resolve_timeout: 5m smtp_smarthost: smtp.163.com:25 smtp_from: your_account163.com smtp_auth_username: your_account163.com smtp_auth_password: 你的授权码 # 注意不是邮箱登录密码 smtp_require_tls: falsesmtp_smarthost用 25 端口时通常要关掉 TLS 校验写成false如果换成 465 端口则要把smtp_require_tls打开或改用smtp_require_tls: true配合 587 端口。授权码在邮箱网页版的「设置 → 账户 → POP3/SMTP 服务」里生成只显示一次丢了只能重新生成。5.2 route 树的四个关键参数route: group_by: [alertname] group_wait: 10s group_interval: 10s repeat_interval: 10s receiver: mail receivers: - name: mail email_configs: - to: your_account163.com send_resolved: truegroup_by: [alertname]会把同一条告警规则触发的所有实例合并成一封邮件。假如 20 台机器同时磁盘告警group_by用alertname就发一封用instance就发 20 封前者更适合运维后者适合需要逐台跟进的场景。group_wait是分组内第一条告警发出前的等待窗口10s 内到达的同类告警会被塞进同一封。group_interval控制同一分组在已有告警未恢复时新告警加入后多久再通知一次太短会被邮件轰炸。repeat_interval是告警一直不恢复时的重复提醒周期测试阶段设 10s 能快速验证链路生产环境建议拉到 4h 以上。send_resolved: true让告警恢复时也发一封否则只能靠邮件的单向通知猜测系统是否已经自愈这个参数默认是关的不开会很别扭。参数默认值生产建议影响group_wait30s30s1m越小越实时越大越少打扰group_interval5m5m同一分组新告警的合并窗口repeat_interval4h4h未恢复告警的重复提醒周期resolve_timeout5m5m多久没收到该告警就视为已恢复5.3 systemd 托管与端到端验证# /usr/lib/systemd/system/alertmanager.service [Unit] Descriptionalertmanager daemon Afternetwork.target [Service] Restarton-failure ExecStart/data/alertmanager/alertmanager --config.file/data/alertmanager/alertmanager.yml [Install] WantedBymulti-user.targetsystemctl daemon-reload systemctl enable --now alertmanager netstat -anput | grep 9093验证告警闭环最直接的办法是在 Prometheus 所在机器上停掉 node_exportersystemctl stop node_exporter然后按顺序观察三个地方Prometheus 的/alerts页面InstanceDown应该在 1 分钟for时间走完后从 Pending 变 FiringAlertmanager 的 9093 页面能看到对应的告警条目和分组最后是邮箱应该收到一封主题里带[FIRING:1]的邮件。如果前两步都正常但邮件没到八成是 SMTP 授权码或端口问题可以看 Alertmanager 日志里有没有authentication failed或connection refused。提示systemd 单元里ExecStart的--config.file建议写绝对路径。写成./alertmanager.yml时systemd 的工作目录是/启动会直接报找不到配置文件而手动执行时因为 shell 的当前目录是/data/alertmanager却能正常跑起来这个差异排查起来很费时间。6. Grafana 看板落地与指标口径校准Grafana 只是最后一公里装起来没什么门槛但几个默认值的坑不小。解压到/data/grafana后直接用-homepath指定安装目录启动[Service] Restarton-failure ExecStart/data/grafana/bin/grafana-server -homepath/data/grafana不带-homepath时会去读默认的/usr/share/grafana/conf你的custom.ini改了也不生效表现为端口、数据库配置全被忽略。3000 端口起来后用 admin/admin 登录第一次会强制改密码。数据源配置里URL填http://192.168.10.92:9090Access选 Server 模式这样浏览器直接访问 Grafana 就能出图不需要浏览器本身能连通 Prometheus。年份跨度大的面板记得把Min step从15s放宽到1m或5m否则查 30 天数据时 Prometheus 要按 15s 粒度返回百万级数据点浏览器会卡死。导入现成看板最省事社区里 Node Exporter Full 这类模板填个 ID 就能加载但导入后一定要核对三件事语言环境时区是否设成浏览器本地时区否则图表时间轴会偏 8 小时模板变量里的instance查询是否写成label_values(up{jobnodes}, instance)job 名跟你的配置对不上就会是空下拉框以及告警阈值线是否还是模板自带的值很多看板把磁盘告警线画在 90% 而你的规则写的是 80%两边对不上会让值班同学产生困惑。最后是口径校准Grafana 面板和告警规则最好复用同一段 PromQL把表达式提到模板变量或者 Recording Rule 里避免出现「看板显示 82% 但没告警」这种扯皮。面板上再挂一条注释线标出告警阈值一眼就能看出离触发还有多远。做完这些之后把告警规则的for从 2m 调到 5m 再观察一轮邮件密度通常比直接调阈值更能压住抖动。本文还有配套的精品资源点击获取
简介这份资源是一份面向运维工程师与Linux系统管理者的Prometheus宿主机监控实操文档聚焦如何用Prometheus对Linux服务器节点建立从指标采集到告警通知的完整监控链路适合具备一定Linux基础、需要落地主机层监控的技术人员参考。资源包内仅1个docx文档压缩包约10.65MB以图文并茂的文档形式承载两套宿主机192.168.10.91、192.168.10.92的部署配置过程与结果截图便于离线阅读和按步骤对照实践。文档内容围绕node_exporter二进制安装、basic_auth加密认证配置借助htpasswd生成密码、config.yml编写、systemd服务托管与9100端口验证展开同时包含Alertmanager二进制部署、邮箱告警配置以及通过Grafana构建CPU、内存、磁盘I/O等仪表板的思路并提及静态配置与服务发现两种目标接入方式。已有913人学习该资源文档对采集间隔、超时等关键参数与排错细节均有交代可帮助读者较快搭建起可观测的主机监控体系。1. 宿主机监控链路Prometheus 拉模型与 node_exporter 的定位半夜两点 CPU 被某个进程打满业务接口超时但没有任何人收到通知——这是自建监控最典型的触发场景。Prometheus很多人直接叫它普罗米修斯本身并不采集宿主机的 CPU、内存、磁盘、网卡数据它只做三件事按固定周期去 HTTP 端点拉取文本格式的指标、把指标按时间序列落盘、按规则判断要不要触发告警。真正把 Linux 内核态数据翻译成指标的是部署在每台被监控机上的 node_exporter。所以整条链路是分层的node_exporter 只暴露/metrics不存储、不出图、不告警Prometheus 负责拉取与评估Grafana 负责可视化Alertmanager 负责把告警按路由分发到邮箱或 IM。这种设计的好处是被监控端极轻量一个二进制文件加一个 systemd 单元就能跑起来宿主机上不需要装 JVM、不需要开数据库。适合的场景是手里有十几台到几百台 Linux 服务器、想自己掌控监控数据、又不想被商业 APM 按主机数收费的运维团队。2. node_exporter 二进制部署与 basic_auth 认证2.1 为什么给 9100 端口加认证node_exporter 默认无认证任何能连通 9100 的人都能拿到主机名、内核版本、文件系统挂载点、网卡列表、进程数这些信息拼起来足够画出一张内网拓扑图。生产环境里通常不会把 9100 直接暴露到公网但内网横向渗透同样需要防。Prometheus 从 2.x 开始支持在 scrape 侧配置basic_authnode_exporter 从 1.0 之后支持--web.config指定认证文件两边配合就能实现带密码拉取。密码不能明文写进配置文件要用 bcrypt 哈希。CentOS/RHEL 上生成哈希最省事的办法是装httpd-tools借用里面的htpasswd# 安装 htpasswd 工具 yum -y install httpd-tools # -n 输出到标准输出不写文件-B 使用 bcrypt 算法-C 12 指定 cost 因子 # 用户名字段传空串生成后由 tr 去掉冒号和换行只留哈希 htpasswd -nBC 12 | tr -d :\n # 交互式输入两次明文密码例如 123456 # 输出形如$2y$12$vckkSTR4nweF2zMq.GjRzuUNls9Ol5FOws/cMCUn77vY0AvdlUi76参数说明-B强制 bcrypt不写会退化成 MD5 或 SHA1-C 12是 cost 因子每加 1 计算量翻倍12 在安全和启动耗时之间比较平衡调到 14 以上会让 node_exporter 每次启动慢上几秒tr -d :\n是因为htpasswd -n的输出格式是用户名:哈希空用户名会留下一个前导冒号直接粘进 YAML 会把文件搞坏。2.2 config.yml 的写法与文件权限把上一步得到的哈希写进 node_exporter 的 web 配置文件# /data/node_exporter/config.yml basic_auth_users: # 用户名: bcrypt 哈希明文密码是 123456 prometheus: $2y$12$vckkSTR4nweF2zMq.GjRzuUNls9Ol5FOws/cMCUn77vY0AvdlUi76注意 YAML 里$不需要转义但整个哈希必须在一行内中间不能断行。文件权限建议设成600且属主为运行 node_exporter 的用户否则同机器上的普通账号能读到哈希。虽然 bcrypt 抗爆破但没必要给攻击者送材料。解压与目录规划按常规来tar -zxf node_exporter-1.3.1.linux-amd64.tar.gz mv node_exporter-1.3.1.linux-amd64 /data/node_exporter cd /data/node_exporter # 目录下会有 node_exporter、LICENSE、NOTICE 三个文件2.3 手工启动与 systemd 托管先用前台方式验证一次确认配置文件路径没问题/data/node_exporter/node_exporter --web.config/data/node_exporter/config.yml如果配置文件有语法错误进程会直接退出并打印Error loading config这一点比 systemd 里翻 journal 快得多。确认能起来后按 CtrlC 停掉交给 systemd# /usr/lib/systemd/system/node_exporter.service [Unit] Descriptionnode_exporter daemon Afternetwork.target [Service] Restarton-failure RestartSec5 ExecStart/data/node_exporter/node_exporter --web.config/data/node_exporter/config.yml [Install] WantedBymulti-user.targetsystemctl daemon-reload systemctl enable --now node_exporter systemctl status node_exporter netstat -anput | grep 9100Restarton-failure保证进程异常退出后自动拉起但systemctl stop属于正常退出不会触发重启这是排查时手动停服务的正确姿势。Afternetwork.target比network-online.target更宽松node_exporter 本身不依赖外网只监听本地端口等网络就绪反而拖慢启动。部署完成后用 curl 验证认证是否真的生效# 不带凭据期望返回 401 curl -s -o /dev/null -w %{http_code}\n http://192.168.10.91:9100/metrics # 带凭据期望返回 200 并输出指标文本 curl -u prometheus:123456 -s http://192.168.10.91:9100/metrics | head -n 20被监控机按同样步骤逐台部署浏览器访问http://IP:9100/会弹出认证框用户名prometheus、密码123456即可看到指标页面。提示node_exporter 的--web.config参数是 1.0 之后才有的如果用了更早的版本这个参数会被当成未知 flag 直接报错升级二进制即可。组件默认端口作用是否需认证node_exporter9100暴露宿主机指标建议开启Prometheus9090拉取与存储指标视网络环境Alertmanager9093告警路由与去重建议限制来源Grafana3000图表展示首次登录强制改密3. Prometheus 主配置解析静态 target 与 file_sd 服务发现3.1 global 段决定采样节奏prometheus.yml的global段控制全局采集与评估节奏是整份配置里最先要定下来的东西global: scrape_interval: 15s # 单个 target 的采集间隔 evaluation_interval: 15s # 告警规则的评估间隔这两个值不是越小越好。scrape_interval调到 5s单机每秒要处理几百个指标样本磁盘写入和内存占用都会明显上升而宿主机层面的 CPU、内存变化本身就没那么剧烈调到 1m 又会让for: 1m的告警反应迟钝。15s 是社区默认值绝大多数场景下不需要动。真正需要动的是scrape_timeout默认 10s如果目标机器负载高导致/metrics响应慢加长超时比缩短间隔更有效。3.2 static_configs把 target 写死在配置里静态配置适合机器数量少、变动不频繁的场景比如三五台固定的数据库服务器alerting: alertmanagers: - static_configs: - targets: - 192.168.10.92:9093 rule_files: - rules/*.yml scrape_configs: - job_name: prometheus static_configs: - targets: [localhost:9090] - job_name: nodes basic_auth: username: prometheus password: 123456 static_configs: - targets: [192.168.10.92:9100, 192.168.10.91:9100]job_name会作为job标签附加到该组下所有时间序列上targets里每个地址则会成为一条instance标签形如instance192.168.10.91:9100。后面写告警规则时by (instance)就是按这个维度聚合。basic_auth写在 job 级别而不是 instance 级别意味着同一个 job 下所有 target 必须用同一套凭据如果几台机器的密码不一样就得拆成多个 job。3.3 file_sd_configs改文件不用重启机器数量上去以后每加一台改一次主配置再重启 Prometheus代价太高。基于文件的服务发现把 target 列表拆出来放到独立文件里Prometheus 定期扫描文件变化并热更新scrape_configs: - job_name: node file_sd_configs: - files: [/data/prometheus/sd_config/node.yaml] refresh_interval: 5s被引用的文件内容格式比主配置更宽松一个列表就够# /data/prometheus/sd_config/node.yaml - targets: - 192.168.171.130:9100 - 192.168.171.131:9100 labels: group: webrefresh_interval默认 5m改成 5s 是为了扩容后立刻生效。文件发现还支持在条目里直接挂labels比如按业务线打上group: web、group: db这样在 Grafana 里就能用一个模板变量切换机器分组不用写死 IP。维度static_configsfile_sd_configs变更方式改主配置并重载改独立 YAML 文件生效速度秒级需热加载refresh_interval 内附加标签仅 job 级每条 target 可单独打标适用规模几十台以内数百台按业务分文件3.4 promtool 校验与配置热加载改完配置直接重启是大忌重启期间所有采集中断可能正好错过一次故障。先用自带工具校验语法/data/prometheus/promtool check config /data/prometheus/prometheus.yml # 输出 SUCCESS: ./prometheus.yml is valid prometheus config file syntax校验通过后再触发热加载。需要启动时带--web.enable-lifecycle否则/-/reload接口会被拒绝curl -X POST http://192.168.10.92:9090/-/reload如果没开 lifecycle退而求其次用systemctl reload prometheus或者发SIGHUP信号前提是 systemd 单元里配置了ExecReload/bin/kill -HUP $MAINPID。直接kill -HUP $(pidof prometheus)也能生效但不留痕多人协作时不如前两种方式清楚。注意rule_files里的路径是相对于 Prometheus 启动时的工作目录解析的如果你在 systemd 单元里没写WorkingDirectory用相对路径rules/*.yml可能匹配不到任何文件日志里只会提示no rule files match不报错也不告警很容易埋雷。4. 告警规则文件与 PromQL 阈值编写4.1 规则文件的四层结构一个规则文件从外到内是groups→rules→ 单条规则 →labels/annotations# /data/prometheus/rules/general.yml groups: - name: general.rules rules: - alert: InstanceDown expr: up 0 for: 1m labels: severity: error annotations: summary: Instance {{ $labels.instance }} 停止工作 description: {{ $labels.instance }}: job {{ $labels.job }} 已经停止 1 分钟以上alert的值就是 Alertmanager 里alertname标签的取值命名要能一眼看懂别用Alert1。expr是 PromQL 表达式返回非空结果集就进入 Pending 状态持续满足for指定的时长后才转成 Firing 并推给 Alertmanager。for是压制抖动的第一道闸网络闪断、采集偶发超时都会被它吃掉。labels里的severity后面可以直接在 Alertmanager 的路由树里用来分流比如severityerror走电话、warning走邮件。annotations里的{{ $labels.xxx }}和{{ $value }}是模板变量前者取该条时间序列上的标签值后者取当前表达式的计算结果。写{{ $labels.instance }}而不是硬编码 IP规则文件才能复用到所有机器上。4.2 CPU、内存、磁盘三条生产口径宿主机告警里最常写的就是这三条。CPU 使用率的思路是用空闲率反推- alert: NodeCPUUsage # irate 取 5 分钟内的瞬时增长率avg by instance 把多核聚合成一台机器 expr: 100 - (avg(irate(node_cpu_seconds_total{modeidle}[5m])) by (instance) * 100) 80 for: 5m labels: severity: warning annotations: summary: {{ $labels.instance }}: CPU 使用过高 description: {{ $labels.instance }}: CPU 使用率超过 80% (当前值: {{ $value }})内存使用率要把 cache 和 buffer 减掉否则 Linux 会把空闲内存全拿去做页缓存指标永远显示 90% 以上- alert: NodeMemoryUsage expr: 100 - (node_memory_MemFree_bytes node_memory_Cached_bytes node_memory_Buffers_bytes) / node_memory_MemTotal_bytes * 100 80 for: 5m labels: severity: warning磁盘按挂载点算用fstype过滤掉 tmpfs、overlay 这类不需要关注的伪文件系统- alert: NodeFilesystemUsage expr: 100 - (node_filesystem_free_bytes{fstype~ext4|xfs} / node_filesystem_size_bytes{fstype~ext4|xfs} * 100) 80 for: 5m labels: severity: warning annotations: summary: {{ $labels.instance }}: {{ $labels.mountpoint }} 分区使用过高 description: {{ $labels.instance }}: {{ $labels.mountpoint }} 使用率超过 80% (当前值: {{ $value }})4.3 阈值必须先算对再写进规则许多现成文档里的示例阈值写的是 1那是为了方便演示、一部署就能立刻看到告警效果直接搬到生产会变成灾难——磁盘用到 1% 就发邮件收件箱几分钟就爆。正确流程是把表达式先丢到 Prometheus 的 Graph 页面跑一遍看清楚正常水位在哪再定阈值。指标名含义单位node_cpu_seconds_totalCPU 各模式累计耗时秒Counternode_memory_MemTotal_bytes物理内存总量字节node_memory_Cached_bytes页缓存占用字节node_filesystem_free_bytes分区可用空间字节node_filesystem_size_bytes分区总容量字节判断表达式是否正确有个简单办法把结果集类型切到 Table看每条序列的 instance 和 mountpoint 标签是否齐全缺标签说明聚合函数写漏了by子句。另外注意node_cpu_seconds_total、node_filesystem_free_bytes属于 Counter 或易变 Gauge前者必须套rate/irate直接拿来做减法会得到毫无意义的累计值。5. Alertmanager 路由分组与邮件告警打通5.1 global 段与 SMTP 凭据Alertmanager 的配置分两块global定义默认的发信通道route定义告警怎么分流。邮箱告警最容易踩的坑是把登录密码当成smtp_auth_password实际上 163、QQ 这类邮箱都要求填「授权码」# /data/alertmanager/alertmanager.yml global: resolve_timeout: 5m smtp_smarthost: smtp.163.com:25 smtp_from: your_account163.com smtp_auth_username: your_account163.com smtp_auth_password: 你的授权码 # 注意不是邮箱登录密码 smtp_require_tls: falsesmtp_smarthost用 25 端口时通常要关掉 TLS 校验写成false如果换成 465 端口则要把smtp_require_tls打开或改用smtp_require_tls: true配合 587 端口。授权码在邮箱网页版的「设置 → 账户 → POP3/SMTP 服务」里生成只显示一次丢了只能重新生成。5.2 route 树的四个关键参数route: group_by: [alertname] group_wait: 10s group_interval: 10s repeat_interval: 10s receiver: mail receivers: - name: mail email_configs: - to: your_account163.com send_resolved: truegroup_by: [alertname]会把同一条告警规则触发的所有实例合并成一封邮件。假如 20 台机器同时磁盘告警group_by用alertname就发一封用instance就发 20 封前者更适合运维后者适合需要逐台跟进的场景。group_wait是分组内第一条告警发出前的等待窗口10s 内到达的同类告警会被塞进同一封。group_interval控制同一分组在已有告警未恢复时新告警加入后多久再通知一次太短会被邮件轰炸。repeat_interval是告警一直不恢复时的重复提醒周期测试阶段设 10s 能快速验证链路生产环境建议拉到 4h 以上。send_resolved: true让告警恢复时也发一封否则只能靠邮件的单向通知猜测系统是否已经自愈这个参数默认是关的不开会很别扭。参数默认值生产建议影响group_wait30s30s1m越小越实时越大越少打扰group_interval5m5m同一分组新告警的合并窗口repeat_interval4h4h未恢复告警的重复提醒周期resolve_timeout5m5m多久没收到该告警就视为已恢复5.3 systemd 托管与端到端验证# /usr/lib/systemd/system/alertmanager.service [Unit] Descriptionalertmanager daemon Afternetwork.target [Service] Restarton-failure ExecStart/data/alertmanager/alertmanager --config.file/data/alertmanager/alertmanager.yml [Install] WantedBymulti-user.targetsystemctl daemon-reload systemctl enable --now alertmanager netstat -anput | grep 9093验证告警闭环最直接的办法是在 Prometheus 所在机器上停掉 node_exportersystemctl stop node_exporter然后按顺序观察三个地方Prometheus 的/alerts页面InstanceDown应该在 1 分钟for时间走完后从 Pending 变 FiringAlertmanager 的 9093 页面能看到对应的告警条目和分组最后是邮箱应该收到一封主题里带[FIRING:1]的邮件。如果前两步都正常但邮件没到八成是 SMTP 授权码或端口问题可以看 Alertmanager 日志里有没有authentication failed或connection refused。提示systemd 单元里ExecStart的--config.file建议写绝对路径。写成./alertmanager.yml时systemd 的工作目录是/启动会直接报找不到配置文件而手动执行时因为 shell 的当前目录是/data/alertmanager却能正常跑起来这个差异排查起来很费时间。6. Grafana 看板落地与指标口径校准Grafana 只是最后一公里装起来没什么门槛但几个默认值的坑不小。解压到/data/grafana后直接用-homepath指定安装目录启动[Service] Restarton-failure ExecStart/data/grafana/bin/grafana-server -homepath/data/grafana不带-homepath时会去读默认的/usr/share/grafana/conf你的custom.ini改了也不生效表现为端口、数据库配置全被忽略。3000 端口起来后用 admin/admin 登录第一次会强制改密码。数据源配置里URL填http://192.168.10.92:9090Access选 Server 模式这样浏览器直接访问 Grafana 就能出图不需要浏览器本身能连通 Prometheus。年份跨度大的面板记得把Min step从15s放宽到1m或5m否则查 30 天数据时 Prometheus 要按 15s 粒度返回百万级数据点浏览器会卡死。导入现成看板最省事社区里 Node Exporter Full 这类模板填个 ID 就能加载但导入后一定要核对三件事语言环境时区是否设成浏览器本地时区否则图表时间轴会偏 8 小时模板变量里的instance查询是否写成label_values(up{jobnodes}, instance)job 名跟你的配置对不上就会是空下拉框以及告警阈值线是否还是模板自带的值很多看板把磁盘告警线画在 90% 而你的规则写的是 80%两边对不上会让值班同学产生困惑。最后是口径校准Grafana 面板和告警规则最好复用同一段 PromQL把表达式提到模板变量或者 Recording Rule 里避免出现「看板显示 82% 但没告警」这种扯皮。面板上再挂一条注释线标出告警阈值一眼就能看出离触发还有多远。做完这些之后把告警规则的for从 2m 调到 5m 再观察一轮邮件密度通常比直接调阈值更能压住抖动。本文还有配套的精品资源点击获取
