监控这个话题你在网上随手一搜就是几百种工具、几十套方案从摄像头安防到服务器性能、再到物联网环境监测方向多得很。但我这几年做运维、巡检和工程类项目最深的一个感受是监控工具永远不缺缺的是把监控和事态流程串起来的那根线——发现异常之后谁来接、怎么接、什么时限内必须处置、处置完怎么复盘。这篇内容就是围绕我们团队沉淀下来的“监控和事态流程手册”来写的。它不是某个软件的使用说明而是一套可以放进团队日常运转的实操框架核心作用很简单让监控从“能看到数字”变成“能推动解决问题”。这套东西适合谁正在搭监控平台的运维、SRE、后端开发以及做嵌入式或物联网设备监控的同学都可以参考。我自己在整理手册时最大的体会是很多故障不是因为监控没发现而是因为发现了之后没人按统一套路去处置。所以下面会把我们怎么设计监控体系、怎么写事态流程、踩过哪些坑一条条拆开讲。1. 为什么监控和事态流程必须写进同一本手册1.1 监控是发现事态流程是处置先讲一个真实场景。去年有一次夜间值班告警群从两点半开始刷屏页面打不开、接口超时、数据库连接数飙升三条告警翻来覆去地弹。结果群里十几个人都没动——不是不想动而是大家都在等别人先说一句“这个归我处理”。第二天复盘时我们发现监控系统本身没问题指标采集正常、告警推送也到了甚至提前半小时就把故障苗头报了出来。真正缺的是一套事态流程告警什么样算紧急、谁负责接、第一响应人做什么、什么时候升级。所以我把这两件事合成一个词来理解监控负责“发现”事态流程负责“处置”。如果只有监控异常被发现了大家还是一脸懵告警就只是噪音。反过来如果只有流程没有监控流程就没有触发源头故障只能等用户来骂才知道。监控触发事态事态反哺监控——每次处置完都要回过去调整监控阈值、补监控项这个闭环才是手册真正的价值。用个生活类比监控像家里的烟雾报警器事态流程像灭火器放在哪、怎么用、要不要打紧急电话。报警器再灵敏没有后手还是可能把房子烧了。很多团队天天折腾监控工具报警器装了一堆灭火器却没人管问题就出在这儿。1.2 这本手册适合谁、覆盖哪些场景我们团队刚开始是纯做服务器运维的后来慢慢接了物联网设备、边缘计算节点再后来连食用菌栽培车间这种物联网环境监控项目也归我们管。所以手册的适用范围被撑得很宽从传统服务器、中间件到嵌入式设备、环境传感器再到边缘AI推理节点都往里装。但我并不建议一上来就做得很庞大。手册适合谁其实取决于你当前的痛点运维/SRE团队日常值班、故障响应、告警治理核心诉求是少被半夜吵醒。后端开发团队接口性能、数据库连接、日志错误率这些研发侧指标需要监控出事还要自己排查。物联网/嵌入式团队设备在线率、环境温湿度、弱网补传、断电恢复这类现场问题监控和处置链路比纯服务器场景更复杂。边缘AI部署团队模型推理的误检率高、帧率抖动、资源占用都需要一套指标监控和排查流程。手册的内容范围我们把它切成三块监控配置基线、事态处置流程、常见故障速查。监控配置基线告诉你怎么选指标、怎么搭平台事态处置流程告诉告警响了之后按什么动作走常见故障速查则是把历史故障沉淀成可直接翻查的卡片。1.3 一本好手册的四个标准写手册最怕写成一本没人翻的文档。我们迭代了几轮之后总结出四个标准可以用来自查第一可执行。手册里的每条处置步骤都要落到具体动作比如“查看某条命令”“打开某个看板”“联系某个接口人”不能停留在“加强监控”“提高意识”这种原则层面。第二可演练。所有流程都应该能拉练一年至少做一两次故障演练把手册当剧本用才知道哪里写得不现实。第三可更新。每次故障复盘后一周内必须把手册改完再发布过期的手册比没有手册更危险。第四可复盘。手册要留出记录时间线的位置每次故障都能在手册基础上做复盘越用越厚。这四条看着简单实践起来特别难。我们手册到现在改了上百个版本每次故障都会发现某条流程跟实际对不上。但正是这种不断修订的过程让团队应对故障越来越熟练。2. 监控体系怎么设计指标、分层与工具选型2.1 先画监控地图别急着装工具很多团队搭监控平台第一步就踩坑上来直接部署Prometheus或者Zabbix装了再说。结果界面花里胡哨看板几十块真正出故障时还是找不着北。我的习惯是反着来先画一张监控地图把要监控的对象分好层再决定用什么工具、配哪些指标。业内常用的分层思路我觉得可以归纳成四层。基础设施层管CPU、内存、磁盘、网络、电源、温度这些物理资源中间件和服务层管Nginx、数据库、消息队列、容器、进程这些软件组件业务层管接口耗时、成功率、吞吐量、订单量这类跟用户体验直接相关的指标还有一层现场环境层管温湿度、设备在线状态、传感器读数、摄像头在线情况这些非IT资源。用表格呈现会更直观层级监控对象典型指标典型工具/手段基础设施层服务器、磁盘、网络、电源CPU使用率、内存余量、磁盘空间、温度node_exporter、Zabbix agent、nmon中间件/服务层Nginx、数据库、Redis、消息队列连接数、QPS、慢查询数、队列积压Prometheus exporter、Druid监控页业务层接口、页面、核心链路成功率、P95延迟、错误率自定义埋点、Grafana看板现场环境层温湿度、设备状态、边缘节点温湿度数值、在线率、推理帧率MQTT上报、边缘采集器画完这张地图你才会发现哪些地方完全裸奔。比如很多团队服务器监控做得很好但现场环境设备的温湿度没有管夏天机房高温把设备烤挂了才发现或者业务层没有任何监控接口慢了一小时都没人知道。2.2 核心指标怎么选USE法和RED法有了监控地图接着要解决“到底测哪些指标”。这里我强烈推荐两个方法论都是业内验证过很多年的。基础设施层用USE法利用率Utilization、饱和度Saturation、错误率Errors。翻译成人话就是资源用了多少、是不是快满了、有没有出错。服务器核心就三个问题CPU打满没有、磁盘还有多少、网络有没有丢包。饱和度尤其重要比如CPU平均80%不一定出问题但运行队列一长说明已经饱和了要开始警惕。服务层用RED法速率Rate、错误Errors、耗时Duration。对应到接口上就是每秒请求数、错误比例、P95延迟。这三个指标能覆盖大多数服务健康度问题。我一般建议新接入一个服务时先只选5到8个核心指标不要贪多。比如接口监控选QPS、P95延迟、错误率服务器选CPU使用率、内存余量、磁盘使用率、TCP连接数。指标选多了看板密密麻麻人反而会漏掉真正重要的变化。选好指标之后无论是Zabbix配置监控项还是Prometheus里写采集规则本质上都是把这张指标清单固化成机器可读的配置。指标清单是设计层面的事工具配置是执行层面的事。我见过不少人一上来就研究Zabbix监控项怎么写结果问他要监控什么业务支支吾吾答不上来方向就反了。2.3 工具选型开箱即用还是定制组合工具选型是另一个容易纠结的点。我们的经验是开箱即用比大而全更重要但也要避免堆工具。当前几个常见的方案我都用过简单聊聊PrometheusGrafana是云原生和容器场景的事实标准灵活、生态丰富、社区模板多适合对性能指标和告警规则要求高的团队。Zabbix更偏传统网络设备和服务器的监控胜在自带告警、自动发现、Agent体系成熟在很多传统行业机房里依然是主力。夜莺监控这类开箱即用的一体化平台国内团队用起来上手快界面和告警管理贴合习惯适合不想从零拼装的团队。单机排查时我会用nmon或者MobaXterm的资源监控页面快速看一眼CPU、内存、网络比登录平台快得多。工具的选择逻辑不是哪个强就用哪个而是哪个能覆盖你80%的场景且大家愿意用。我们有一个项目同时用了Prometheus和Zabbix因为一部分设备只支持SNMP用Zabbix接入最省事另一部分容器化服务则是Prometheus原生支持。两个工具能覆盖就没必要硬凑五个。还有一类特定用途的监控页面比如Druid连接池监控、Drupal状态页、前端Vue项目编译过程的监控甚至开发调试窗口的监控模式不一定都要搬进统一平台。它们只需要一个展示入口即可把这些页面链接汇总到一个导航页比每个都搭一套告警体系更实际。记住工具是服务目标的目标是让监控能覆盖业务地图而不是让监控平台本身变成一个新的大麻烦。2.4 环境监控、嵌入式与边缘AI的特殊指标普通服务器监控讲完了说几个特殊场景。环境监控比如食用菌栽培车间这类物联网项目核心指标和IT监控完全不一样温度、湿度、CO2浓度、光照强度、风机和加湿器开关状态。这类系统通常要求“监控控制”联动湿度超标要自动开加湿器温度偏高要启动风机。所以监控体系里除了采集指标还要留出控制指令的下发通道告警不只是发消息还要触发执行器动作。嵌入式设备监控又不一样资源受限决定了你不能在设备上跑重量级Agent一般用MQTT等方式把数据汇聚到中心端处理。比如基于STM32之类的智能输液监控设备上报的往往是点滴速度、液位状态、阻塞告警这些现场信号网络还不一定稳定。监控平台的重要设计点就变成了弱网补传、断线重连、数据时序对齐——设备端本地缓存数据网络恢复后按时间戳补传。边缘AI部署的监控也很容易翻车。比如用YOLO这类模型做边缘部署经常有人抱怨误检率高上来就想调模型。但你把推理帧率、置信度分布、输入图像分辨率、光照强度这些指标拉出来看往往会发现误检集中在夜间或者低置信度区间。这就不是模型一个问题而是硬件、场景、模型三者的匹配问题。监控系统这时候就得额外统计置信度分布曲线按阈值段统计误检率才能定位到真正的环节。3. 最小可用监控平台搭建实录3.1 采集层Prometheus与node_exporter的最小部署工具和指标都定了就可以动手搭平台。我们内部最常用的组合是PrometheusGrafanaAlertmanager这套配起来快社区物料也多。最小可用的采集层其实就是一台Prometheus服务器加若干node_exporter节点。部署步骤很简单不细说都会在目标服务器上解压node_exporter后台启动默认监听9100端口。Prometheus端在配置文件里的scrape_configs字段加上目标地址重载一下配置就完成采集了。首次接入时可以用如下命令确认采集是否正常# 确认目标exporter指标端点能访问 curl http://目标IP:9100/metrics | head # 确认Prometheus能看到目标节点 # 浏览器打开 Prometheus 的 /targets 页面检查状态是否为 UP这里我要多提一句很多故障其实不在标准指标里而在进程和日志里。进程突然没了、定时任务没跑、日志里疯狂报错这些也要纳入监控范围。Prometheus有exporter可以采集进程状态也可以把定时任务执行结果写进文本文件用textfile collector上报。日志侧我习惯配上Loki或者Filebeat把关键日志集中起来告警触发时直接翻日志定位省得满服务器找线索。3.2 可视化与告警Grafana看板和告警规则配置采集上来之后最直观的工作是配Grafana看板。你可以导入现成的模板比如node_exporter全量监控模板导入后基本能看个大概。但我建议不要只用模板至少要按自己的指标清单改一遍把不关心的面板删掉把关键指标放到最显眼的位置。好的看板不是数据越多越好而是人看到之后能在三秒内判断系统是否健康。告警规则是监控真正起作用的关键。规则设计上要避免“一抖动就告警”。比如CPU使用率我喜欢设置连续5分钟大于90%才触发告警而不是瞬时值。磁盘使用率设置在85%告警但不同分区要分别对待根分区和数据分区的重要性完全不一样。Prometheus里这类规则用PromQL写核心是时间范围窗口加触发条件。看板配好了规则写好了剩下的就是告警通知。3.3 通知路由Alertmanager分级推送与抑制告警通知最怕两件事刷屏和漏报。Alertmanager里可以做两件事来解决——路由和抑制。路由是按照告警标签把不同类型的告警分发到不同接收人。比如基础设施告警发值班群业务告警发业务负责人群P0级别的走电话通道。抑制规则是让同类告警只发一条高优先级告警触发时自动抑制低优先级告警。举个例子磁盘写满之后会导致几十个服务同时报错如果没有抑制规则那一晚上告警群就炸了。配了抑制规则之后磁盘告警会压住那些派生出来的服务告警值班人员只需要处理根因恢复后其他告警自然消失。Alertmanager的配置用路由树表达我贴一个最小示例只有一级路由route: group_by: [alertname, instance] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: default routes: - match: severity: critical receiver: page配置里group_by是聚合维度把所有相同告警名和实例的告警合并成一条group_wait是首次等待时间避免多个告警同时到达时一条条发repeat_interval是重复告警的间隔一般设置成4小时否则同一个问题会反复震铃。这套东西调好了告警体验可以好到让人忘记以前被刷屏支配的恐惧。3.4 长期运行要考虑的存储与高可用最小可用的平台搭好之后运行一两个月就会遇到新问题Prometheus本地存储涨得飞快。默认情况下Prometheus把所有采集数据存在本地磁盘时间长了磁盘直接被打满。我们的做法是给数据分层热数据保留在Prometheus时间久的数据或者聚合后的数据放到对象存储长期保留。如果想减少折腾也可以用VictoriaMetrics这种支持水平扩展和压缩的存储兼容PromQL迁移成本很低。还有一件事必须做监控自身也要监控。Prometheus所在机器磁盘满了、Alertmanager挂了、Grafana连不上数据源这些问题如果不被监控整个监控体系就等于裸奔。我们会在另一个独立节点上部署一个小型探针定时探测监控平台的关键端点挂了就电话通知防止监控平台本身成为故障盲区。4. 事态流程怎么定从告警分级到复盘闭环4.1 告警分级不是所有告警都要半夜爬起来事态流程的第一步是定分级。没有分级所有告警都是最高优先级值班的人要么绷着神经睡不好要么破罐破摔直接忽略。我们采用P0到P3四级分类核心原则是“影响用户和业务的程度决定响应速度”。级别定义示例首次响应时限目标处置时限P0核心业务完全不可用支付链路全挂、主站点宕机15分钟2小时P1主要功能受损有替代方案登录失败率超过50%、接口大面积超时30分钟4小时P2局部功能异常影响有限单个非核心服务报错、某区域设备离线4小时1个工作日P3一般性问题可计划处理监控看板数据延迟、非核心指标异常下一个工作日3个工作日分级定出来之后值班的人看到告警第一眼就知道要不要爬起来。P0和P1必须马上动P2可以在早上处理P3甚至可以放到计划维护窗口。这里还有一个细节分级不是固定的。同一个告警在业务高峰期和凌晨级别应该不一样。比如登录接口错误率在白天和深夜影响面完全不同规则配置时要注意时间维度。4.2 标准处置七步法从确认到记录告警触发之后处置动作必须有标准顺序否则大家各自发挥最容易乱。我们经过几轮故障洗礼沉淀出一套七步法每一步都有明确动作第一步确认告警真实性和影响范围。收到告警先看趋势是刚刚开始还是已经持续了一段时间确认服务真的不可用还是监控误报。第二步指定第一响应人。值班者就是第一响应人不需要等谁批准P0告警值班者直接开始处置。第三步隔离故障。先止损防止影响扩散。比如数据库连接池被打满先重启连接池或摘掉故障节点再慢慢查原因。 第四步排查原因。按“日志→指标→变更记录”顺序找线索看最近有没有发布、有没有改配置。第五步实施恢复。优先让业务先恢复而不是一定要找到根因才能恢复。先重启、回滚或者切换流量让用户能用再说。第六步验证并通知利益相关方。恢复后至少要观察一段时间确认指标稳定然后把结果同步给业务方和管理层。第七步记录时间线。所有操作步骤、时间点、现象变化一条条记下来为复盘留素材。这七步里最容易跳步的是第三步和第七步。新手容易拿到告警直接去翻日志忘了先隔离老手容易在恢复后懒得记录结果复盘时时间线全是模糊的。手册里我会强调记录不是测试题是复盘的唯一依据。4.3 升级机制一线、二线、三线怎么衔接事态流程里必须有清晰的升级机制否则P0一发生一线扛不住也不知道找谁。我们定义了三线结构。一线是当前值班的人负责第一时间接告警、确认影响、执行初步处置比如重启服务、切换流量。二线是各服务负责人一线在限定时间内搞不定就必须升级到二线通常二线有更深的技术背景能分析日志、查代码、调配置。三线是专家或厂商支持一般是疑难杂症、涉及底层框架或硬件设备问题时才启动。升级条件要写死不能靠人情。我们规则是一线收到P0告警后5分钟联系不到二线或者15分钟内没能控制住局面必须升到P0应急小组P1告警超过30分钟未恢复也要升级。写死不等于没有人情味而是避免大家不好意思打电话最终把小事拖成大事。值班交接同样重要。交班文档至少要包含当前告警状态、已做操作、未完成事项、可疑根因。口头交班一定会漏我踩过好几次坑交班后接班的同事说“没人告诉我这个事”后来强制要求写交接单才解决。4.4 复盘闭环让下一次故障更短处置完不是结束复盘是事态流程极度重要的一环。复盘会最容易开成追责会这是大忌。我习惯用时间线法来复盘把故障前后所有关键时间点列出来包括告警时间、响应时间、定位时间、恢复时间然后逐个环节找延迟点。哪一步耗时最长哪一步出现了信息断层哪个环节做得特别好都要有结论。接着用连续追问的方式挖根因。故障的直接原因往往不是根因比如“Nginx挂了”是直接原因“配置里写错了上游地址”是中间原因“发布流程缺少预发验证”才是根因。回答不够深就继续追问直到找到能通过流程改进来消除的环节。复盘产出的改进项必须有负责人和截止时间。没有期限的改进项等于没有改进。我们要求复盘后一周内更新手册把这次故障的处置步骤、排查线索写进手册的故障速查章节。只有这样每次故障才不是白白挨一次打。5. 监控运维常见问题排查与避坑技巧5.1 告警风暴几十条告警如何压成一条告警风暴是每个值班员都会遇到的噩梦。现象很典型磁盘满了然后数据库开始报错接口开始超时前端开始报5xx最后监控平台里冒出一百多条告警。如果Alertmanager没有配置好手机会响一整晚。我们的处理经验有三条。第一条聚合。按告警名和实例分组把同类告警合并成一条加上时间窗延迟不要在30秒内把同源告警全部发出来。第二条抑制。高优先级的告警要能压住低优先级的派生告警磁盘满了引发的服务报错不需要逐条推送。第三条静默。已经确认是已知故障或者正在维护期间直接对该告警设置静默时间段别让它继续刷屏。告警风暴还有一个治理方向是阈值合理性。如果某个告警每周都要响几次但每次都没啥事那不是业务问题是告警规则设计问题。要么调阈值要么把这条告警降级保持告警的“稀缺性”才保证它响了大家会重视。5.2 误报与漏报动态阈值和边缘AI误检固定阈值必然带来两个问题设得低容易误报设得高容易漏报。比如CPU使用率告警设成90%平时没有业务高峰的团队可能一个月都不响但大促期间冲到95%都是正常的瞬间就哗哗一片告警。解决方向是动态基线基于历史数据算出正常波动范围告警规则跟踪相对变化而不是绝对数值。比如周同比、月度环比或者滑动窗口的平均值加减标准差都能一定程减少误报漏报。边缘AI场景的误检问题也可以从监控角度来治理。用YOLO做边缘部署时误检率高不一定是模型参数不好有可能是输入图像质量差、光线变化剧烈、推理帧率过低导致跳帧。我们的做法是在监控看板上同时展示置信度分布、帧率和检测结果的实时同步通过置信度分布曲线能看到误检集中在哪个置信度区间据此调整置信度阈值或者触发夜间模式。监控不是只盯着系统资源业务特征指标一样要盯。误报还有个坏处是“狼来了”。值班员被无意义的告警折腾几次之后看到真告警也会犹豫这种信任损失是非常大的。所以我在手册里专门写了一条原则宁可暂时漏一个告警也不让值班员对告警系统失去信任。不可靠的告警系统比没有告警更危险。5.3 存储成本监控数据膨胀怎么治监控平台运行半年之后注意指标数据的增长。采集频率太高是大忌所有指标都是5秒采集一次数据量可能大到根本存不住。我们内部定了一套数据分级方案核心指标保持15秒采集频率普通指标1分钟低价值指标5分钟。历史数据则通过降采样和聚合来处理超过30天的高精度数据在对象存储归档供查询热库只保留最近30天的数据。如果Prometheus本地存储已经吃紧可以考虑迁移到维多利亚之类的兼容方案它们对压缩和磁盘占用控制更好。还有一个容易被忽略的有些指标压根不需要长期保存比如临时排查用的nmon采集数据导出成文件之后就不需要再进平台。这里说一个实用技巧ARM环境下编译nmon有问题时可以直接下载为准静态编译的二进制或者用系统中的perf和sar工具替代一样能拿到CPU和内存数据。MobaXterm上打开资源监控页面也是临时排查的好帮手。连接上服务器后在工具栏点开资源监控能同时看到CPU、内存、网络、磁盘的实时变化适合快速判断瓶颈又不会对服务器造成额外的存储负担。5.4 环境监控与嵌入式设备的常见坑环境监控和嵌入式场景有自己的一套坑跟纯服务器监控差异很大。第一个坑是弱网断点。现场设备网络不稳定数据传不上来时会丢一段时间如果中心端直接按上报时间入库时间线就会乱。解决办法是设备端本地缓存网络恢复后按时间戳补传中心端的时序数据库要能正确处理乱序写入。第二个坑是设备时钟偏移。很多嵌入式设备没有NTP校准能力时间越跑越偏。如果所有数据都按设备本地时间打点那告警时间线是乱的前后顺序都对不上。我们的办法是网关统一校准时间戳设备上报只作为原始数据入库时以网关收到时间为基准生成时间戳。第三个坑是电源问题。现场设备断电会导致监控数据突然消失但你没法确定是设备故障还是断网。比较好的做法是给关键的监控设备配独立供电并让断电事件本身也能上报。这里可以提一嘴比如基于STM32的智能输液监控设备一旦断电医生那一端必须有告警否则就是安全事故。电源监控不是可有可无的辅助功能在物联网场景里它本身就是核心监控项。环境监控数据还有一个长期难题传感器漂移。温湿度传感器用久了读数会慢慢偏移一开始看不出问题过一个月发现车间实际温度比显示高两三度那整个环境控制逻辑就全错了。所以环境监控的运维流程里必须包含定期校准至少一个季度做一次传感器对比测试。5.5 日常排查技巧速查表最后整理一些日常会用到的排查技巧都是实测下来很顺手的招可以用表格快速查阅。场景推荐手段补充说明单机性能快速摸底nmon、MobaXterm资源监控无需装重型Agent看实时曲线很直观查看端口和连接数ss -s / ss -lntp替代netstat速度快信息更全进程被异常杀死journalctl -u 服务名 或 dmesg -T先看系统日志是否OOM再看应用日志定时任务没执行查看cron日志、/var/spool/cron注意环境变量问题脚本内要写全路径日志快速定位grep -E ERRORException 配合时间窗webhook通知测试curl -X POST 带JSON体告警没收到时先单独测webhook通不通Prometheus抓取异常/targets页面查Up状态很多平台采集不到数据是exporter没起来排查思路比命令本身更重要。我一般按照先看告警趋势、再看变更记录、最后才翻日志的顺序来排查。很多故障的根源是最近一次变更无论是发版还是改配置先顺这个思路查命中率能高不少。监控和事态流程手册这个东西写到今天已经成了我们团队判断故障成熟度的标尺。工具换过模板换过看板样式改了一轮又一轮但“监控发现问题、流程保证处置、复盘促进改进”这个闭环一直没有变。如果你正准备写这么一本手册我的建议是从最小的闭环开始先选三个你最关心的指标配上一条告警再为这条告警写一段处置步骤然后拉上同事演练一遍。这比一次性设计几十个页面、写几十条流程有用得多。等这条最小闭环跑顺了再一步步扩展手册自然会长成你想要的样子。