1. 被低估的Nagios大型企业里监控底座的真实选择1.1 为什么我们还在用Nagios这两年聊监控十个人里有八个在说Prometheus剩下两个在说ZabbixNagios好像成了一种上古遗产。但我实际接触过的企业运维环境里Nagios的存量远比大多数人想象的大银行的外围系统、连锁零售的门店链路、制造业的产线采集服务器、传统企业的核心应用集群背后都挂着一套Nagios。它们不聊Kubernetes那一套也不会跟风重写监控体系因为系统已经在上面稳定跑了五六年业务没有理由为技术时髦买单。我接手这套Nagios的时候系统里纳管了差不多1100多台设备包括Linux服务器、Windows主机、网络交换机、存储设备外加少量带IPMI的物理机。检查项加起来大概六千多个每分钟产生的被动检查结果上万条。这个规模在有专职监控团队的大厂眼里不算什么但对于一个十来个人的运维团队来说压力是实打实的白天要处理业务需求晚上还要保证告警不要淹没人。先说一个反直觉的结论**Nagios的核心代码已经十年没大变了但这恰恰是它可靠的原因。**Nagios Core从3.x到4.x核心调度逻辑几乎没有伤筋动骨配置格式完全兼容。那些跑在Nagios上的周边生态——NRPE、NSCA、PNP4Nagios、Livestatus、Grafana的Grafana-Nagios插件——也都稳定得离谱。监控系统最怕的不是功能少而是它自己天天要人伺候。Nagios的定位就是一个绝不抢戏的底座它把检查-判断-告警这三件事做到极致剩下的交给脚本和周边工具。1.2 它和Prometheus、Zabbix的边界在哪里我不想回避这个话题因为选型争议在任何一个运维团队里都会碰到。我的看法是**如果从头新建一套系统资源允许Prometheus Alertmanager是更好的选择它有标签体系、有PushGateway、有动态服务发现和云原生生态无缝衔接。**但如果你面对的是几百台传统架构服务器、网络设备、老旧Windows机器Nagios反而是性价比最高的方案它不需要部署采集器集群不依赖服务发现不强制拉取模型一个check脚本走天下。Nagios和Zabbix的对比也经常被提起。Zabbix自带数据库、自带Web UI、自带告警升级开箱即用体验好Nagios则是组件式拼装Core NRPE NSCA Graph UI都是独立选型。但反过来看Zabbix的Agent依赖数据库数据库本身又要监控是一个更重的体系Nagios哪怕数据库挂了监控和告警照跑不误——因为Nagios本身不依赖数据库状态都存在内存和status.dat文件里。这一点在故障时特别重要。我们遇到过监控机磁盘满了、MySQL起不来的情况但Nagios进程依然正常检查、正常发告警这就是它的韧性。很多人犹豫要不要从Nagios迁到Prometheus。我的建议是**迁移的收益评估要放在业务故障平均恢复时间上而不是放在用了什么新框架上。**如果现有Nagios已经把所有关键指标都覆盖了、告警规则也打磨到位了迁移只是成本不是收益。2. 架构设计与容量规划一台机器撑不撑得住2.1 我用的这套Nagios Core NRPE NSCA Livestatus先把我这边的整体结构讲清楚。监控中心是一台双路E5、64GB内存的物理服务器系统盘两块SSD做RAID1数据盘一块SARTA盘专门存RRD图表数据操作系统是CentOS 7。Nagios Core是4.4.5从EPEL安装的周边组件是NRPE 4.0.3跑在每台被监控的Linux主机上负责被动响应Nagios的主动检查请求NSCA 2.9接收客户端主动推送的被动检查结果比如备份结果、临时脚本输出、业务自定义事件Livestatus模块编译进Nagios的broker模块负责把实时状态以MK Livestatus协议暴露给外部我用它对接Thruk的Web界面和自研的仪表盘PNP4Nagios rrdtool负责将check脚本输出的性能数据Perfdata画成趋势图Thruk作为Nagios的现代化Web前端比原生CGI界面好用太多侧边栏、内置报表、历史趋势一应俱全send_nsca 自研HTTP接收端用于异构系统的被动告警接入比如Windows计划任务、RPA机器人、甚至Oracle数据库的触发器都能把结果推过来。这套组合的核心思路是**Nagios Core只做调度和状态判断不做数据存储不做Web界面不做告警升级。**它把自己做成一台引擎周边组件各司其职。这种组件的解耦在排障时能省很多事Web界面挂了不影响检查调度RRD磁盘满了不影响告警发送。2.2 容量规划照着这个公式算基本不出事Nagios的性能瓶颈很少在检查太多而在检查突发。默认配置下Nagios是单进程顺序执行检查的如果900个检查项在同一秒内都到期了调度器就会积压表现为服务检查结果延迟假告警增多。所以容量规划的核心是控制同一时刻的检查数量峰值。我当时遵循的经验公式是检查间隔按实际需求拉长。系统层指标CPU、内存、磁盘、负载用5分钟间隔业务层指标接口状态、进程数、端口连通性用1分钟或2分钟日志告警类用30秒间隔但要控制总量。理论上的并发峰值 所有检查数 ÷ 最小时间间隔实际并发峰值要再乘以1.5的突发系数。按照这个公式我这边一千多台主机的六千多个检查项分配下来的并发峰值大约在600-800个/分钟。一台8核16G的机器叠加Livestatus和PNP的负载CPU峰值能压到50%以内内存还剩一半多。如果你管理的规模更大记住一个硬指标**单机检查项总数不要超过15000主动检查的并发请求不要超过1000/分钟。**超过这个量优先考虑拆站或引入Mod-Gearman分布式调度而不是硬撑。2.3 分布式节点划分按机房而不是按业务规模过了单机能力之后就要考虑分布式。Nagios官方支持的方式是中心-分布式架构每个分中心跑一个完整的Nagios实例中心实例通过NSCA被动接收分中心的检查结果。我这边虽然没有拆到那个程度但给同行的建议是分布式划分的第一原则是网络故障域隔离按机房切分不要让中心到某个机房的链路抖动把整个机房的监控全搞挂。每个分中心的Nagios只负责本机房的检查中心Nagios只保留跨机房的链路检查、全局VIP检查、备份状态检查。分中心的检查结果通过NSCA推送到中心中心不做重复检查。这样即使某个机房网络全断中心只会收到NSCA数据源超时这一条告警而不是几百条服务DOWN。很多人忽略的一点**分布式架构下分中心的时间必须用NTP严格校准。**NSCA被动结果带时间戳中心端会对比结果到达时间vs结果产生时间来判断结果是否过期。如果两端时钟漂移超过check_service_freshness设置的时间窗大批结果会被判为STALE然后触发一连串假告警。我们为此专门给所有Nagios服务器加了独立的NTP配置并写了一个定时任务校验每台监控机的时钟偏差偏差超过500ms就报警。3. 配置管理的核心痛点与自动化改造3.1 模板三层体系从一千行废纸到五页核心配置Nagios的配置语法很简单但它最大的坑也在这里**简单意味着自由自由意味着混乱。**我接手时那套Nagios的hosts.cfg和services.cfg合计超过两万行大量重复定义同一个监控项有7种写法模板继承关系混乱到无人敢动——改一个模板可能波及三百个主机。当时团队对Nagios的态度是能不动就不动因为没人能说清全局的影响面。我做的最重要的一件事是重构配置目录建立三层模板体系底层command模板层。只定义check命令不含任何主机或服务逻辑全局唯一。中层服务模板层。按监控类型分类比如linux-basic模板里预置了CPU、内存、磁盘、负载、进程数这五项标准服务参数全部用宏变量占位由主机定义填充。上层主机定义层。每台主机只写自己特有的属性比如IP、机柜位置、业务负责人以及它需要继承哪些服务模板。重构完之后新增一台Linux服务器的流程从写五十行配置变成了写五行配置加一条继承声明。举个例子一台新的Web服务器的配置是这样的define host{ use linux-server-template host_name web-117 alias web frontend 117 address 10.20.31.117 hostgroups web-servers,production }linux-server-template这个模板里预先定义了基础检查、磁盘检查、NTP检查、端口检查这些服务全部继承出来。磁盘检查的阈值我做成宏变量define service{ use generic-service host_name web-117 service_description Disk /data check_command check_nrpe!check_disk!/data!20%!10% }用宏而非写死的阈值好处是不同分区、不同重要级别的系统可以各自调整而不需要新建命令模板。我们后来把关键业务的数据盘阈值设成15%告警、5%严重而普通日志盘是5%告警、2%严重差距很大但配置结构完全一致。3.2 用Git和脚本管好上千条服务定义配置重构之后我紧接着做了第二件事把Nagios配置目录纳入Git管理并且建立了改配置必须走提交的流程。这个习惯在后期救了我们很多次——任何一次误操作都能快速回退到上一个可用版本。但Git只能解决版本问题不能解决一致性问题。两千台主机里如果某台机器的某个服务定义里漏了一个参数Nagios完全不会报错只会静默地不检查。为此我写了几个校验脚本按月跑一次主机名一致性检查hosts.cfg里的host_name必须与NRPE客户端本机的hostname一致否则check_nrpe会连不上命令参数完整性检查所有引用check_command的服务定义其参数数量必须与命令模板的定义匹配重复定义检查同一个host service_description只能出现一次用awk排序后查重模板引用检查检查所有use引用的模板名必须在模板目录中存在避免静默的继承断裂。其中最有价值的检查是最后一个。有一次一个大版本升级后某模板文件名被改了但services目录下还有十几个服务定义引用了旧模板名Nagios启动时给了警告但没报错结果那些服务全部消失了。如果没有这个脚本这种问题可能直到业务方反馈怎么看不到我们的监控了才会被发现。3.3 配置校验与灰度发布Nagios自带-v校验参数nagios -v /etc/nagios/nagios.cfg能检查全部配置文件的语法和逻辑错误。但注意**-v只校验格式和逻辑引用关系不校验配置是否符合真实环境。**比如你写了一个check_nrpe!check_disk!/data!20%!10%只要参数个数对-v就认为没问题但目标主机上是否真的有/data分区它完全不管。要验证这一点只能靠发布后观察Nagios自己跑出来的结果。我的发布流程是这样的在Git分支上改配置本地跑nagios -v确认无错合并到master在监控机上nagios -v /etc/nagios/nagios.cfg再做一次校验执行service nagios reload注意是reload不是restartreload不中断正在执行的检查reload后一小时内人工抽查20%新增或变更的服务状态确认返回状态码有意义而不是UNKNOWN观察PNP图表是否正常出图没有出图说明Perfdata格式又写错了。这套流程现在已经成为标准动作。如果哪次改配置不经过这套流程我会比监控报警还难受——因为我知道Nagios的静默失败特性语法校验通过但实际逻辑完全跑不通的例子实在太多了。4. 自定义插件真正让Nagios贴合业务的切入点4.1 插件开发的三个基本约定Nagios本身不监控任何具体指标所有检查动作都靠脚本完成也就是插件。插件开发的规则简单到不可思议但恰恰因为太简单很多人写出了看起来能跑但实际不可维护的插件。我总结的三个约定是退出码必须严谨0正常(OK)1告警(WARNING)2严重(CRITICAL)3未知(UNKNOWN)。任何异常路径都要有明确的退出码尤其是脚本自身报错不能返回0必须返回3。输出格式要含性能数据Nagios只展示输出文本但PNP4Nagios和Grafana依赖的是|符号之后的Perfdata。格式是labelvalue;warn;crit;min;max。举个例子check_disk: /data used 45% of 800GB | /data_used45%;80;90;0;100。超时必须有兜底Nagios的service_check_timeout默认60秒插件的脚本执行时间应该设计在10秒以内。带网络请求的检查如HTTP探测、数据库连接检测必须用timeout命令包裹防止挂在网络黑洞上。我见过太多反面案例备份结果脚本异常直接退出返回0然后Nagios以为一切正常直到三天后才发现备份早就失败了。正确的做法是脚本最后一定要检查所有关键步骤是否成功任何一步失败都返回2并输出具体的失败原因。4.2 三个高频业务场景的插件写法**场景一进程数监控。**NRPE自带的check_procs只能统计进程数量但业务进程更关心的往往是主进程是否在、子进程数量是否稳定。我写过一个针对Java应用的进程检查脚本逻辑是#!/bin/bash # check_app_procs.sh - 检查指定应用的主进程存在且子进程数不低于阈值 APP_NAME$1 MIN_PROCS${2:-1} main_pid$(pgrep -f ${APP_NAME}.*Bootstrap | head -1) if [ -z $main_pid ]; then echo CRITICAL: ${APP_NAME} main process not found exit 2 fi proc_count$(pgrep -f ${APP_NAME} | wc -l) if [ $proc_count -lt $MIN_PROCS ]; then echo CRITICAL: ${APP_NAME} process count ${proc_count} below threshold ${MIN_PROCS} exit 2 fi echo OK: ${APP_NAME} running, ${proc_count} processes | procs${proc_count} exit 0这个脚本的关键点在于pgrep -f匹配的是完整命令行能精确匹配到JVM的启动参数。但要注意pgrep -f这可能匹配到你自己所以脚本里最好用grep -v grep或者精确写模式。**场景二日志关键字检查。**很多业务问题从日志里先爆发但Nagios没有默认的日志监控能力。我写过一个通用的check_log_keyword.sh核心思路是记录上次读取的日志文件偏移量然后检查新增日志中的关键字。用stat或wc -c获取文件大小用sed截取新增部分再grep关键词。这个脚本要特别注意日志轮转logrotate如果文件大小比上次记录的小说明发生了轮转偏移量需要重置为0。我踩过这个坑——日志一轮转脚本就漏报直到业务方自己发现日志里有错误才反馈给我们。**场景三HTTP接口接口状态检查。**纯硬编码的check_http只能判断HTTP状态码但很多接口返回200时body里其实是错误信息。这个情况在网关类服务上尤其常见。我的做法是用curl把返回值落盘然后用grep去匹配预期关键字#!/bin/bash # check_api_health.sh URL$1 EXPECT$2 resp$(curl -s -m 10 -o /tmp/api_resp.txt -w %{http_code} $URL) http_code$? if [ $http_code ! 200 ]; then echo CRITICAL: HTTP ${http_code} from ${URL} exit 2 fi if ! grep -q $EXPECT /tmp/api_resp.txt; then echo CRITICAL: HTTP ${http_code} but body missing expected keyword exit 2 fi echo OK: ${URL} healthy exit 0这类插件比通用检查多了业务语义这才是监控系统真正有价值的地方。同样的原理可以扩展到数据库连接池检测、消息队列消费延迟检测、定时任务执行结果检测。4.3 Perfdata格式的坑排了一天错是冒号少了一个PNP4Nagios不出图是新手最常遇到的问题九成原因是Perfdata格式不对。Nagios对Perfdata的解析很严格必须以|分隔label后面不能有空格多个性能数据之间用一个空格分隔。我犯过一个特别低级的错误——在label后面加了个冒号导致RRD文件名全部异常图表全部白屏。正确的做法是写一个check_template.sh里面固定了Perfdata输出格式所有插件都基于这个模板去改。这样格式问题只会在模板里出现一次而不是在每个脚本里各错各的。另一个经验是RRD文件名是根据主机名服务名标签名哈希出来的如果服务名里带了特殊字符很容易生成超长文件名。建议在service_description里避免奇怪的符号只用字母、数字、下划线、斜杠斜杠会自动转义但冒号会被当成分隔符。5. 告警治理从告警风暴到精准告警5.1 依赖关系这是Nagios最被低估的功能做过监控的人都知道告警风暴比没有告警更可怕。最典型的场景核心交换机出了问题底下几十台服务器的网络检查全挂每台机器触发三条告警一晚上收到两百条。当时值班的同学直接选择沉默真正重要的告警反而被埋没了。Nagios的parents指令就是用来治这个病的。我给每台服务器定义了它的父节点——接入交换机或上联交换机然后在主机定义里加上define host{ use linux-server-template host_name web-117 address 10.20.31.117 parents sw-access-03 }这样配置之后如果sw-access-03DOWN了Nagios不会把web-117标成DOWN而是标成UNREACHABLE并且默认不发送服务告警。告警量从两百条降到一条值班的人能立刻定位到真正的根因。但要注意parents依赖关系也不能乱设。我见过一个团队把父节点设成了业务链路的上游服务结果上游服务一抖动下游十几个服务的告警全被吞掉了反而掩盖了真正的故障。**parents只应该表示网络可达性的依赖关系而不是业务调用关系的依赖。**业务依赖应该靠告警路由和分级去处理不能混在主机状态判断里。5.2 告警升级策略按故障时间而不是按次数Nagios自带的escalations指令可以定义告警升级链。很多人只是简单设置重复告警几次后发给经理但我觉得更合理的是故障持续时间到达某个阈值后升级到下一级。前者的问题是如果恢复时间很长但不到重复次数故障就没人关注后者的问题是重复次数和间隔不统一难以推断故障持续了多久。我的设计是0-15分钟仅通知业务负责人oncall15-60分钟同时通知业务负责人和技术组长超过60分钟通知运维负责人和研发负责人并在故障群同步一条汇总消息。配置大概是define serviceescalation{ host_name web-117 service_description HTTP service first_notification 1 last_notification 0 notification_interval 10 contact_groups oncall } define serviceescalation{ host_name web-117 service_description HTTP service first_notification 4 last_notification 0 notification_interval 5 contact_groups tech-leads }这里first_notification 4指的是第4次通知之后切换到第二个级别配合我的通知间隔5分钟相当于故障持续20分钟后升级。notification_interval是升级之后的再次通知间隔需要比初始通知间隔更短因为故障越久越需要频繁同步。Nagios的escalations功能默认是严格按照通知次数来算的你要保证notification_interval的设置足够密才能让告警在预期时间内触发升级。5.3 静默窗口的正确打开方式日常变更操作期间最烦的就是Cherry-Pick式的某个服务在检查时正好在维护告警误报。Nagios的scheduled_downtime功能可以精确指定某台主机的某个服务在某个时间段内不告警。很多人图省事直接整机静默这是非常危险的——变更期间如果有其他指标异常也一起被静默了故障发现就被推迟到变更结束之后。我的建议是**变更窗口静默的服务列表越具体越好。**比如重启MySQL就只静默MySQL服务切换网络设备就只静默网络相关的检查磁盘、CPU这些基础检查保持活性。Nagios web界面里的Schedule Downtime选项在Thruk里更好用直接勾选服务填入开始和结束时间。还有一个细节**静默窗口的时间要比变更预估值多留30分钟。**我们遇到过变更脚本卡住实际维护时间比预期多了一个小时但静默窗口提前结束于是变更还没完成就开始刷告警值班同事误以为业务已经故障。5.4 把可能误报的告警和确定故障的告警分等级Nagios的告警等级只有OK/WARNING/CRITICAL/UNKNOWN四个合理利用它们能大幅降低噪音。我的经验是**不确定的东西一律用WARNING宁可我心中有数不要随便CRITICAL。**比如磁盘空间用了82%、但还在可接受范围用WARNING再比如某个接口响应时间超过1秒但业务还能用用WARNING。CRITICAL只留给业务已经不可用或很快就要不可用的情况——比如进程没了、端口不通、备份失败、磁盘满了。刚开始接手的时候前同事把很多检查的阈值都设得很激进结果就是告警不断、麻痹人心。我花了两个星期逐条整理了所有服务的阈值和告警级别把所有疑似但不确定的情况全部降级为WARNING结果值班同事的响应质量明显提高——他们知道响一声的是真事响三声的是大事。6. Nagios性能调优与故障排查实录6.1 调度器与Worker超时参数先搞懂再动手Nagios 4.x引入了check_workers参数允许并行执行多个检查。这个参数的设置直接决定了检查突发时的吞吐能力。官方文档建议值是CPU核心数的1.5到2倍我这边是8核设的是16。但这里有个很多人不知道的陷阱check_workers设太大不一定是好事。如果同时执行数百个NRPE远程检查监控机到目标机的网络连接数会骤然上升如果中间有防火墙或有SNAT限制可能会触发连接风暴。更稳妥的做法是把max_concurrent_checks和check_workers配合使用。max_concurrent_checks是硬上限check_workers控制并行度。我这边的配置是check_workers16、max_concurrent_checks30实测下来在600个检查项的突发下检查积压量基本为零。还有一个非常关键的参数是service_check_timeout默认60秒。如果目标主机网络很慢NRPE连接经常要30秒以上就很容易触摸到超时阈值Nagios会把该检查标为CRITICAL并终止线程。这种情况导致的误报非常隐蔽——你看日志只会看到Check timed out after 60 seconds根本不会联想到是网络延迟的问题。我的处理是把service_check_timeout调成120秒同时给每个check脚本加timeout 30的命令级超时在NRPE端提高command_timeout为90秒并开启allow_bash_command_substitution但仅限信任的脚本对网络检查类如check_ping、check_http单独设置更短超时因为这类检查本身就应该是秒级的。6.2 三个让我折腾到半夜的Nagios故障**故障一检查结果延迟越来越严重。**表现为Web界面里大量服务处于PENDING状态告警延迟到达。排查过程先看/var/log/nagios/nagios.log发现大量的EXTERNAL COMMAND排队再看系统负载发现有个Java进程占了30%的CPU——那是我们自己做的一个性能数据采集客户端它每30秒POST一次数据到PNP。这个客户端写得太烂每次POST都是全量数据导致PHP进程堆积拖垮了整个Nagios的检查调度。解决方式是重写采集客户端改为增量推送并且让PNP的process_perfdata.pl使用spool目录批处理而不是每一条都即时处理。**故障二NRPE握手失败但网络是通的。**排查check_nrpe返回Connection refused但目标机上NRPE服务确实在运行。后来用telnet 目标机 5666一测能连上但输出Remote command execution failed。真相是目标机的nrpe.cfg里配置了错误的allowed_hosts只允许了监控机的旧IP。这个案例告诉我们NRPE的allowed_hosts配置错误时错误表现非常像网络不通一定要用telnet测一下端口再用--version验证协议版本。**故障三同一台主机部分服务检查正常、部分服务一直UNKNOWN。**排查发现那些UNKNOWN的检查都用了一个我在某个脚本里引用的perl模块而这个模块只装在了部分主机上。Nagios的check_nrpe执行远程命令时如果远端命令返回非零、且stderr有输出Nagios往往会把它显示成UNKNOWN而不是CRITICAL。这里要给个大教训**任何一个NRPE远端脚本都要先在目标主机上手动执行一遍。**用NRPE执行与手动执行的环境差异很大——特别是PATH、shell环境、依赖库。我后来在nrpe.cfg里把所有check命令都改为绝对路径并在脚本第一行固定了export PATH/usr/local/bin:/usr/bin:/bin。6.3 数据库与历史数据的生命周期管理Nagios自己的状态文件status.dat、retention.dat、objects.cache需要定期清理。虽然Nagios自身不依赖数据库但status.dat在6000多个服务项的情况下会有几十MB每5分钟写一次如果磁盘IO不够可能影响检查的实时性。我这边把Nagios的状态目录挂到了SSD上并且设了定时任务每周压缩归档旧的nagios.log。nagios.log的膨胀也很恐怖。默认情况下每条检查结果都写日志一天下来就是几十万行。我调低了日志等级只记录状态变化log_initial_states0、log_service_retries0把日志保留策略改成按周切割并且用logrotate做7天轮转压缩。另外我把nagios.log里的EXTERNAL COMMAND单独抽出到一个独立文件方便排查谁动了什么。如果装了PNP4Nagios还要定期清理RRD文件。RRD文件即使没有新数据写入也会持续增长但增长速度会放缓。我写了一个cron脚本超过90天没有更新的主机对应的RRD目录会被标记超过180天直接删除避免磁盘被历史数据慢慢占满。这个爪子在设备下线审计时也很有用——RRD最后更新时间基本等同于该主机的最后在线时间。7. 一些实际操作中的体会Nagios不是那种让人一见倾心的工具它的界面老、配置繁琐、概念多但它有一个很多现代监控工具比不了的优势**它把确定性拉满了。**每一条告警背后都有一条确定的检查、一个确定的退出码、一段确定的输出。它没有什么机器学习驱动的异常检测没有智能聚合弹窗一切都是白纸黑字可以复盘的。在企业环境里这种确定性比炫酷重要得多。如果你也在维护一套老Nagios我最后的几点建议是**先做配置治理再谈扩监控项。**把模板体系理清楚、把重复定义清干净比你新增一百个检查项更有价值。配置混乱的老Nagios每改一次都是在往雷区里踩。**告警的最终目标是少而准不是全而多。**宁可漏掉几个无关紧要的告警也不要让值班的人习得性麻木。**多写业务层的自定义检查。**Nagios自带的标准检查只是体检报告真正能救命的往往是接口返回了200但业务其实是失败这类业务语义判断。**监控机本身也要被监控。**Nagios不监控自己我从第二年起就把监控机自身的CPU、磁盘、NRPE状态、日志膨胀速度全纳入了另一套独立监控避免监控挂了没人知道的窘境。最后分享一个小技巧**每次在Nagios上做完一个重要变更把当时的nagios -v输出和变更前后各30分钟的nagios.log片段存成一个变更记录文件。**三个月后再回看你会发现这个习惯帮你节省了无数回忆和排查时间。Nagios这个系统很老但它值得我们用新的方法去运营——配置代码化、变更可追溯、告警有零有整。这些习惯比更换一套新监控系统带来的收益更大。