服务器状态监测办法

服务器状态监测办法做了快十年的运维工作，我见过太多因为服务器状态监测不到位，把小隐患拖成大故障的例子：有电商平台大促当天核心服务器磁盘占满宕机，两个多小时才排查出问题，直接损失几十万营收；也有中小企业的官网服务器出问题停了三天，才因为客户打电话投诉才发现，对品牌口碑造成了很难挽回的影响。在我看来，服务器状态监测从来不是运维工作里可有可无的附属环节，而是保障整个业务系统稳定运行的生命线，容不得半分马虎。我把我们团队多年来实际使用、经过无数次故障打磨出来的这套服务器状态监测办法整理出来，都是实打实踩坑踩出来的经验，希望能给同行们做个参考。1监测的核心目标与适用范围明确做这件事的目标和覆盖范围，是开展所有工作的前提，不然很容易做着做着就偏离方向，该抓的重点没抓住，做了很多无用功。1.1监测的核心目标很多刚入行的运维朋友觉得，服务器监测就是出问题了发个警报就行，其实远远不止。我们做监测的第一个核心目标，就是防患于未然，在隐患还没发展成故障、用户还没感觉到异常的时候，就把问题解决掉，而不是等故障发生了再忙着救火。第二个目标是故障发生后快速定位，减少排查时间，只要监测数据全，出问题之后一看指标曲线，就能很快知道是CPU负载高了还是磁盘满了，不用像没头苍蝇一样到处试，能极大缩短故障处理时间。第三个目标是为容量规划提供数据支撑，我们能根据几个月的资源使用走势，提前知道什么时候需要加服务器、什么时候需要扩容，不会等到资源不够了才手忙脚乱乱扩容，浪费成本或者耽误事。我刚入行的时候就吃过没持续监测的亏，当时有个应用出了内存泄漏，每天内存涨个几百兆，半个月之后才把内存占满宕机，要是那时候我们有持续的内存走势监测，早就能发现异常定位到问题了，也不至于停服务那么久。1.2办法适用范围这套监测办法适用于绝大多数企业的场景，不管是企业自建机房的物理服务器，还是云厂商提供的云服务器，不管是跑对外业务的生产服务器，还是企业内部用的OA、文件服务器，甚至是测试环境的测试服务器、灾备备用的闲置服务器，都可以用这套办法做监测，只需要根据服务器的重要程度调整监测密度和告警规则就可以，不用重新搭建一套体系，灵活性很高，中小团队也能落地，不需要太大的投入。明确了监测的目标和适用范围，第一步要做的就是搭好整个监测体系的框架，做好基础准备工作，不然监测就会变成一团乱麻，该盯的没盯住，没用的信息堆一大堆，反而影响正常工作。2监测体系的前期准备与整体架构搭建监测体系的核心是理清楚轻重缓急，不能对所有服务器一视同仁，我们踩过这个坑，所以对这一步的重要性感受特别深。2.1先给服务器做好分级分类我们最开始做监测的时候，就是没做分级，所有服务器不管重要程度，都用一样的监测频率和告警规则，结果就是闲置服务器的一点点波动都往值班群里发，一天几百条告警，真的核心服务器的紧急告警反而被刷没了，还出过因为没看到告警耽误事的情况，所以分级分类是监测工作的第一步，一定要先做好。2.1.1一级核心生产服务器凡是直接支撑对外核心业务的服务器都归到这一类，比如电商的订单系统服务器、企业的核心客户数据库、官网的前端应用服务器，这类服务器出问题直接影响营收和品牌，是我们监测的重中之重，所有规则都按最高标准配置。2.1.2二级非核心业务服务器这类就是不直接影响对外业务的服务器，比如企业内部的OA办公系统、内部文件共享服务器、测试环境的测试服务器，就算出问题，一般也只会影响内部员工，不会造成直接的业务损失，所以标准可以适当放宽松一点，不用占用太多核心资源。2.1.3三级闲置备用服务器这类就是暂时没有跑业务，用来做灾备切换或者待上线的服务器，平时不会有流量，只需要保证它能正常启动就行，监测标准最低，不用实时占用资源。2.2监测工具的选型与基础部署工具不用追求最时髦的，适合自己的就是最好的，不用为了用新技术强行上复杂的架构，能满足需求就行。现在开源的工具比如Zabbix、Prometheus都很成熟，功能足够绝大多数企业用，要是用云服务器的话，云厂商自带的监测工具也很好用，我们一般是云厂商监测加自建监测双重保险，之前就碰到过一次云厂商那边网络波动，自带的监测没测出问题，我们自己的拨测提前发了告警，很快就处理了，避免了影响业务。2.2.1监测节点的部署要合理如果是自建机房的物理服务器，一定要在内网部署监测节点，这样延迟低，监测结果不会受外网波动影响，不会把网络波动误判成服务器宕机。如果是跨区域部署的服务器，就在每个区域都放监测节点，保证监测的准确性，不会因为跨网延迟导致误判。2.2.2监测权限要划分清晰监测系统涉及整个业务的核心状态，权限一定要管控好，普通运维人员只能查看监测数据和告警，修改告警规则、增减监测节点这种操作，只能给负责的核心管理人员，避免误操作把整个监测体系弄崩，也防止无关人员看到核心业务的状态数据，保障数据安全。体系框架搭好了，接下来就是整个办法的核心内容，也就是日常监测具体要做什么、怎么做，我们把监测从底层硬件到上层业务分成了三个层面，每个层面都有明确的监测要点和执行标准。3日常分级监测的具体实施办法监测不是只有自动工具就够了，要结合自动采集和人工巡检，从底层到上层全覆盖，不能留监测盲区。3.1底层硬件与系统基础指标监测这是最基础的监测内容，不管服务器跑什么业务，这些指标都必须监测，大部分故障都会先体现在这些基础指标的异常上。3.1.1CPU状态监测我们主要监测四个点：实时使用率、15分钟平均负载、核心温度，还有异常占用。这里要注意，不能设置成CPU使用率一超过80%就报警，因为有时候有人跑批量处理任务，几分钟就完成了，属于正常波动，我们一般设置成持续五分钟超过80%才触发告警，能避免大部分误报。物理服务器一定要加CPU温度监测，我之前夏天碰到过一次，机房一个机柜的空调出风口被杂物堵了，CPU温度一路升到八十多度，监测提前告警，我们过去清了杂物，不然整机柜的服务器都可能因为温度过高宕机甚至硬件损坏，后果不堪设想。3.1.2内存状态监测除了看已用内存和剩余可用内存，一定要关注交换分区的使用率，要是交换分区占用率超过30%，就说明内存已经不够用了，系统开始变慢了，提前预警就能提前扩容。另外还要看内存的长期走势，如果内存每天都稳定上涨，好几天都不回落，基本就能确定是应用有内存泄漏，这个时候就能提前重启应用或者修复bug，不用等内存占满宕机了才处理。3.1.3磁盘存储状态监测这是我见过出问题最多的地方，少说有一半的服务宕机都是磁盘满了导致的，所以一定要重点盯。我们一般设置磁盘使用率到70%发提醒，到85%触发告警，除了使用率，还要监测磁盘IO的等待时间和IOPS，如果IO等待时间一直很高，说明磁盘已经成为瓶颈了，要么是有程序疯狂读写打日志，要么是磁盘本身出问题了，提前处理。另外物理服务器一定要监测硬盘的SMART健康信息，提前发现坏道等硬件问题，提前换盘，避免数据丢失，那可是没法挽回的损失。3.1.4网络状态监测主要监测带宽使用率、丢包率、延迟，还有端口状态。要是带宽使用率突然比平时高好几倍，要么是遭受到流量攻击了，要么是配置错了，有程序在疯狂同步数据，能很快发现。另外所有对外开放的端口，要定期监测是不是正常，还要扫描有没有开异常的陌生端口，要是有陌生端口开着，很可能是服务器被入侵种木马了，能提前发现处理，把风险掐灭在萌芽里。3.2上层服务与业务层面监测基础硬件指标正常不代表服务就正常，很多时候硬件好好的，服务已经用不了了，所以这一层监测必不可少，也是很多团队容易漏掉的部分。3.2.1系统进程监测核心服务的进程一定要做持续监测，比如Nginx、MySQL这些核心服务，要是进程意外退出了，立刻触发告警，不用等用户发现。同时还要监测进程的资源占用，如果一个陌生进程突然占了百分之七八十的CPU和内存，很大概率是被种了挖矿木马，立刻就能排查处理，不会让挖矿木马跑几个月才发现，白白浪费资源。3.2.2服务可用性拨测这个真的太重要了，我之前碰到过一次，所有基础指标都正常，进程也在，但是应用出现了死锁，外部用户根本访问不了，就是因为没做拨测，半个多小时之后才被用户投诉发现，后来我们就给所有核心服务都加了拨测，就是模拟用户的访问请求，一分钟访问一次，要是返回不正常就立刻告警，不管硬件怎么样，只要用户访问不了就报警，从那之后再也没出过这种问题。3.2.3业务指标监测这是更高一级的监测，就是结合业务本身的指标来监测，比如核心业务的每秒请求数、订单创建量，要是本来平峰时候每秒都有几百请求，突然掉到个位数，哪怕服务没宕机，肯定也是哪里出问题了，这种监测能发现很多常规监测发现不了的隐性问题，比如流量被拦截、入口路由出问题这种，从基础指标根本看不出来。3.3日常监测的频次要求我们除了自动监测，还有人工巡检的要求，自动监测不是万能的，人工定期过一遍能发现很多自动告警漏过的隐患。3.3.1自动监测的频次一级核心服务器所有指标1分钟采集一次，二级非核心服务器5分钟采集一次，三级备用服务器1小时采集一次，这样既保证了核心服务器的监测精度，也不会浪费太多监测资源，不会因为采集太频繁占用服务器本身的资源。3.3.2每日人工巡检每天早上上班，值班运维都要花十到十五分钟，过一遍所有核心服务器的监测面板，看看有没有未处理的告警，有没有异常的指标波动，哪怕是误报也要确认一下，没事最好，有事就能早早处理，把问题解决在上班前，不影响白天的业务使用。3.3.3每周全面巡检每周抽一个下午，把所有服务器的状态都整体过一遍，重点看磁盘的增长趋势、资源的长期使用情况，比如核心服务器的剩余磁盘还有15%，按照现在的增长速度，不到一周就会到告警阈值，那我们就可以提前清理日志或者扩容，不用等磁盘满了再手忙脚乱，影响业务。监测做好了，碰到异常之后怎么处理也是很关键的，要是告警发出去没人管，或者处置乱了顺序，还是会出问题，所以我们也整理了明确的异常处置流程，保证出了问题能有序处理。4异常告警分级与处置流程我一直觉得，告警的设计最能体现一个运维团队的人性化，不能为了不漏告警就滥发，搞得所有人休息不好，最后反而对告警麻木，所以我们明确了分级告警的规则，兼顾安全和人性化。4.1告警要按严重程度分级我一直跟团队里的年轻人说，告警的核心是让该收到的人在正确的时间收到正确的信息，不能滥发告警，滥发告警的结果就是所有人都对告警麻木了，真的出问题反而没人理。我们现在把告警分成三级：4.1.1一级紧急告警只要是核心服务器宕机、核心服务不可用这种会直接影响业务的异常，都归到一级紧急告警，收到之后要立刻通过电话、短信加企业微信@值班人员，必须要求十分钟以内响应，不管是工作日还是半夜，都得起来处理，毕竟业务停了就是实打实的损失。4.1.2二级预警告警就是还没影响业务，但是需要处理的隐患，比如磁盘使用率到85%、CPU持续负载偏高，这类告警发到值班群就行，要求工作时间八个小时以内处理，非工作时间第二天上班处理就行，不用半夜叫醒人，给大家留够休息时间。4.1.3三级提示告警就是测试服务器重启、闲置服务器资源波动这种完全不影响业务的异常，每天汇总一次发邮件就行，不用实时打扰任何人。这点真的太人性化了，我刚入行那会半夜被测试服务器的告警叫起来好几次，跑过去一看就是测试同事重启了一下服务，真的又气又累，所以分级告警不仅是对工作负责，也是对兄弟们的休息负责。4.2异常处置的标准流程出了问题不能乱，按流程走就能最快解决问题。4.2.1第一步先确认问题收到告警之后，先不要慌，第一时间远程登录服务器，或者从多个节点确认异常，排除掉监测节点网络波动导致的误报，确认问题的严重程度，再决定下一步怎么做，不要一收到告警就动服务器，反而把正常服务搞出问题。4.2.2第二步先抢通再排查我一直跟团队强调，只要是影响业务的紧急问题，第一件事就是先把业务抢通，比如核心服务器出问题，先切流量到备用节点，让用户能正常用，再慢慢排查根因，不要上来就钻到细节里查原因，业务停一分钟都可能造成不小的损失，保业务永远是第一位的。4.2.3处置完做好记录不管问题大小，处理完之后都要把问题发生的时间、异常表现、处理过程、最终结果都记录下来，方便后面复盘，也能给后面碰到类似问题做参考，攒多了就是团队自己的故障处理手册。这套监测办法不是一成不变的，我们每次碰到问题都会优化，所以监测工作也要持续复盘升级，才能跟上业务变化的需求，不会出现新的盲区。5监测工作的复盘与持续优化没有完美的监测体系，业务在变，架构在变，风险也在变，所以持续优化是必须的。5.1每次故障之后都要复盘优化只要发生了影响业务的故障，不管大小，我们都会开复盘会，首先就要看监测体系有没有问题：为什么没有提前发现隐患？是我们没加这个监测指标，还是告警规则设得不对？比如说之前我们有一次被入侵，挖矿木马跑了两天才发现，就是因为我们没做未知进程的监测，复盘之后我们就加了未知进程资源占用的告警规则，从那之后再碰到这种情况，一天就能发现，不会再让风险藏那么久。5.2定期调整监测规则每个季度我们都会整体梳理一遍所有的告警规则，把经常误报的规则调整一下阈值，把没用的告警删掉，还要根据业务的增长调整阈值，比如说业务涨了之后，核心服务器的CPU平时负载都到60%了，原来的80%告警阈值就不合适了，容易出问题，适当调整才能减少误报，保证告警的准确性。5.3持续升级监测能力随着业务发展，服务器数量越来越多，原来的工具可能不够用了，也会有新的风险出现，我们就要及时升级监测能力，比如说现在容器化越来越多，我们就给容器也加了对应的资源监测，跟