场景目标
为纳管清单内的每台 Linux 主机建立可追溯的指标、看板与告警;完成一轮测试通知和恢复验证,并记录采集覆盖率、延迟及监控资源开销。
监控与可观测 · 进阶
从主机清单和指标基线出发,建立 CPU、内存、磁盘、网络与采集链路的可验证监控闭环。
为纳管清单内的每台 Linux 主机建立可追溯的指标、看板与告警;完成一轮测试通知和恢复验证,并记录采集覆盖率、延迟及监控资源开销。
适用于维护期内的 Linux 发行版与组织选定的 node_exporter、Prometheus、Grafana、Alertmanager 兼容版本;先登记版本和 CPU 架构,不默认使用最新镜像。部署需主机服务管理权限,采集账号按采集器最小授权,指标端口仅对监控网络开放。实施前约定每台采集器的 CPU/内存预算、时序数量及存储保留配额,备份服务和监控配置,并保留旧监控链路。估时 180 分钟为小批主机接入与短时验证,不含采购、全网铺开或长期基线观察。
node_exporter 暴露受控主机视角,Prometheus 主动抓取与计算规则,Grafana 查询看板,Alertmanager 按稳定资产标签通知值班人员。
点击组件,在图下方查看职责;连线编号对应流向解读。小屏可横向滚动,或直接展开文字说明。
提供 CPU、内存、挂载点、inode 与网络等资源事实;主机身份、角色和特殊挂载应在接入前登记。
exporter 从当前可见的操作系统接口读取指标,额外采集器权限按最小需要授予。
请求由 Prometheus 发起,exporter 返回指标;不要将图解释为主机主动推送到 Prometheus。
表示实施前的资产核对关系,不是自动修改主机身份的服务。
由审阅后的发现配置关联责任和环境,避免重复目标和无界标签。
面板查询需解释计数器速率、内存口径及挂载过滤,无数据与零值分开显示。
Prometheus 按持续条件生成告警,后续分组和静默不应隐藏无关主机的真实故障。
按资产责任路由送达并测试恢复消息,实际时限需要端到端记录。
exporter 能读取的挂载和命名空间决定指标含义,容器内端点正常不能证明其反映整机;指标需与资产基线抽样比对。
资源水位不能替代业务请求、进程和日志证据;采集链路中断也不等于主机已宕机,故障分类与责任路由应分别处理。
图解是本站基于官方资料整理的逻辑参考;实施前仍需核对实际部署版本、组件支持范围与变更审批。
建议由 node_exporter 暴露主机指标,Prometheus 定时采集,Grafana 展示业务分组看板,Alertmanager 分发分级通知。主机身份以受控资产标识关联负责人,避免把临时地址或业务请求参数当作长期标签。
适用于已有受控 Linux 主机和管理网络的指标监控建设。主机指标不能替代应用探测、进程级定位或日志分析;容器视角与宿主机视角应分别标明。以下内容是实施建议,未声称关联工具已部署。文中 <...> 均为必须替换的占位符,示例预检不负责安装或修改主机。
验收对象清单内的主机均有唯一标签,连续至少 30 分钟可查询 CPU、可用内存、磁盘空间与 inode 指标;采集超时低于所设周期,监控进程资源在约定预算内。测试通知应在约定时限送达正确值班组,恢复后关闭,告警中附有主机、责任人与排查入口。阈值和时限是本方案的验收目标,需按实际环境确认。
按业务、环境和机房整理主机清单,记录地址、负责人、系统版本、CPU 架构和挂载点;区分物理机、虚拟机与容器宿主机。以下命令在已授权的目标主机本地只读执行,输出供基线比对,不自动上报外部服务。将临时挂载、只读卷和离线备份盘单列,提前约定哪些对象需要告警,避免统一阈值覆盖业务差异。
uname -srmo
free -b
df -PT
df -Pi逐台核对资产数量、主机标识和挂载清单,关键主机均有责任人及采集窗口。保存命令输出时间和实施前资源水位;未知系统版本、特殊文件系统和不可访问主机应列为待处理项。
该步骤只读取主机状态,不需要恢复系统。若发现资产归属不明或存在维护冲突,暂停该主机接入,保留只读记录并撤销尚未使用的临时访问授权,待责任人确认后继续。
确认 Prometheus 到主机指标端口的路由,限制来源网段并按环境配置 TLS 或可信代理。为 node_exporter 使用专用服务身份,仅为实际启用的采集器补充读取权限;不要为省事授予任意命令权限。估算主机数、采集周期、序列数量和保留天数,单独评审 textfile 等扩展采集方式,并禁止用户名、请求 ID 等高基数值成为标签。
从监控网段确认计划端点可达,从非授权来源确认访问受限;安全配置和容量预算已记录。每个额外采集器都有用途、权限说明、采集耗时上限以及可停用的配置入口。
若网络或权限设计未通过检查,不开放采集端口。恢复本次新增的访问规则和专用身份授权,保留原有业务通信;容量不足时缩小试点范围,不直接缩短既有数据的保留期限。
选取一台非关键且具有代表性挂载结构的主机,使用固定版本和已核对来源的软件包建立服务;记录配置、启动参数与资源限额。先检查本机端点,再从采集端验证授权路径。下例只读取本地指标,端口如经变更应同步替换;若部署在容器中,需明确宿主机挂载路径和命名空间视角,防止把容器指标误当整机数据。
curl --fail --silent --show-error http://127.0.0.1:9100/metrics端点持续返回指标,CPU 数量、内存总量和关键文件系统可与第一步基线对应。观察至少三个采集周期,确认采集器无权限失败、异常耗时或高资源占用,敏感标签没有被意外暴露。
停止试点新增服务并恢复其配置备份,收回专用网络入口;只清理由本次建立且已确认无引用的服务定义。保留原有监控服务和采集日志,定位权限或视角差异后再重新试点。
为主机发现配置稳定的环境、业务组和资产标识,统一重复目标的去重规则;采集超时应小于采集周期。把新增 job 与原有监控配置分开审阅,加载前先执行语法检查。下例 <PROMETHEUS_CONFIG> 是已准备的候选配置文件绝对路径,仅检查文件,不重新加载服务。检查通过后再按现有发布流程应用,并观察目标状态与时序增长。
promtool check config '<PROMETHEUS_CONFIG>'配置检查成功,纳管目标无重复身份且预期 job 的 up 持续为 1;查询时间戳按周期更新。比对接入前后的活跃序列数、抓取耗时和存储增长,对超出预算的标签或采集器给出处置记录。
恢复上一版 Prometheus 配置并按既定机制重新加载,仅撤销本次新增的发现对象。不要删除历史时序或改写既有标签;若新规则影响其他 job,先停止扩容,再根据差异逐项恢复。
按环境和业务建立总览,再提供单机 CPU、内存、磁盘空间、inode、网络吞吐与磁盘活动面板;每张图标注单位、采样窗口和过滤条件。CPU 使用率以计数器变化率计算,避免直接绘制累计值;可用内存与已用内存的口径需写清楚。为采集失败设置独立面板,区分主机无数据与资源正常,保留到资产和知识文档的定位入口。
选择两台负载不同的主机,将面板结果与同一时间窗口的系统观测对照。确认单位、图例和环境筛选正确,缺失数据能明确显示;值班人员可从总览进入单机并找到负责人和下一步检查说明。
将新看板退回草稿或恢复上一修订版,保留原监控入口。若指标口径有误,先标明不可用于告警决策并停用关联新规则,修正查询后用保存的基线重新比对,不修改原始采集数据。
将采集失联、磁盘空间逼近下限、inode 不足和持续资源压力分开治理,阈值由历史基线和业务峰值确定,并设置持续时间抑制短时抖动。磁盘告警应排除无运维意义的临时挂载,同时关注增长趋势;通知包含主机、环境、挂载点、级别及排查链接。根据资产责任组路由,制定维护静默到期时间,避免失联告警把同一事件放大为多条资源告警。
评审每条新告警的触发、持续、恢复和路由条件,测试规则覆盖正常值、越界值及缺失数据。通知接收人能确认责任对象,静默有明确过期时间,分组行为不会合并不同业务的独立故障。
停用本批新规则并恢复原通知路由,保留测试结果与待修正阈值。若通知已进入值班队列,补充测试标识并关闭相应测试事件;不要通过全局静默掩盖原有真实告警。
在隔离测试目标上使用受控测试规则验证通知和恢复,不通过填满磁盘或压垮生产 CPU 制造信号。记录发现、发送、接收和关闭四个时间点,检查值班操作是否能按链接完成定位。试点通过后按业务组逐批接入,每批复核资源预算、覆盖率与例外;交付配置版本、对象清单、看板入口、告警责任表以及停止接入的条件。
验收清单逐项附有时间、截图或查询证据,全部试点主机满足至少 30 分钟连续采集目标,测试通知和恢复均完成。新增批次无重复目标和不可解释缺口,未通过项明确标为待验证并指派负责人。
结束测试规则并确认测试告警关闭,出现采集负载或通知异常时停止后续批次。按最近一批清单撤销新增目标和采集服务,恢复已保存配置;保留前批已通过的对象及历史数据供继续排查。