&&国之画&&布布分享&&&& &&&&
版权所有 京ICP备号-2
迷上了代码！微信公众号：centoscn
关于系统运维监控规范的几点建议和思考
& & & & &目前很多企业信息化系统都有自己的监控平台和监控手段，无论是采用哪种手段去实现对系统的实时监控和故障告警，大多采用的方式也只有两种：一、集中式监控和分布式监控。博主根据自身公司监控存在的问题，总结了一些经验并提出一些在监控平台建设建议以供大家参考学习，如有考虑不周的地方还希望大家多多批评指正哦。
& & & & &为了更好、更有效的保障系统上线后的稳定的运行。对于服务器的硬件资源、性能、带宽、端口、进程、服务等都必须有一个可靠和可持续的监测机制，统计分析每天的各种数据，从而能及时反映出服务器哪里存在性能瓶颈、安全隐患等。另外是要有危机意识，就是了解服务器有可能出现哪些严重的问题，出现这些问题后该如何去迅速处理。比如数据库的数据丢失，日志容量过大，被黑客入侵等等。
一、上线之前的准备工作
1.&&&&&&&首先是备份，做好定时备份策略，备份所有你认为重要的数据，并且定期检查你的备份是否有效、全面；
2.&&&&&&&日志轮换，无论你想用哪种轮换方式，控制日志增长避免驱动器已满是你的目的；
3.&&&&&&&做一定的安全措施，如防火墙iptables的访问控制，用denyhosts防止黑客远程暴力破解；
4.&&&&&&&mysql远程登录权限等等；
5.&&&&&&&最后就是服务器、网元设备的监控。
二、监控策略
1.&&&&&&&定义告警优先级策略
一般的监控到的结果是成功或者失败，如Ping不通、访问网页出错、连接不到Socket，发生时这些称之为故障，故障是最优先的告警。除此之外，还能监控到返回的延时、内容等，如Ping返回的延时、访问网页的时间、访问网页取到的内容等。利用返回的结果可以自定义告警条件，如Ping监控的返回延时一般是10-30ms之间，当延时大于100ms时候，表示网络或者服务器可能出现问题，引起网络响应慢，需要立即检查是否流量过大或者服务器CPU太高等问题。
2.&&&&&&&定义告警信息内容标准
当服务器或应用发生故障时告警信息内容非常多，如告警运行业务名称、服务器IP、监控的线路、监控的服务错误级别、出错信息、发生时间等。预先定义告警内容及标准使收到的告警内容具有规范性及可读性。这点对于用短信接受告警内容特别有意义，短信内容最多是70个字符，要在70个字符完全知道故障内容比较困难，更需要预先定义内容规范。如：&视频直播服务器10.0.211.65&在 13:00电信线路监控第到1次失败&，清晰明了的知道故障信息。
3.&&&&&&&通过邮件接收汇总报表
每天收到一封网站服务器监控的汇总报表邮件，花个两三分钟就大致了解网站和服务器状态。
4.&&&&&&&集中监控和分布式监控相结合
主动（集中）监控虽然能不需要安装代码和程序，非常安全和方便，但缺少很多细致的监控内容，如无法获取硬盘大小、CPU的使用率、网络的流量等，这些监控内容非常有用，如CPU太高表示有网站或者程序出问题，流量太高表示可能被攻击等。
被动（分布式）监控常用的是SNMP(简单网络管理协议)，通过SNMP能监控到大部分你感兴趣的内容。大部分操作系统支持SNMP，开通管理非常方便，也非常安全。SNMP缺点是比较占用带宽，会消耗一定的CPU和内存，在CPU太高和网络流量大情况下，无法有效进行监控。
5.&&&&&&&定义故障告警主次
对于监控同一台服务器的服务，需要定义一个主要监控对象，当主要监控对象出现故障，只发送主要监控对象的告警，其它次要的监控对象暂停监控和告警。例如用Ping来做主要监控对象，如果Ping不通出现Timeout，表示服务器已经当机或者断网，这时只发送服务器Ping告警持续监控Ping，因为再继续监控和告警其它服务已经没有必要。这样能大大减少告警消息数量，又让监控更加合理、更加有效率。
本地监控脚本的规范化部署
6.&&&&&&&对在本地部署的监控脚本要进行统一规范的部署并记录到KM系统。
7.&&&&&&&实现对常见性故障业务自我修复功能
实现对常见性故障业务自我修复功能脚本进行统一部署并对修复后故障进行检查告警检查频次不多于3次。
8.&&&&&&&对监控的业务系统进行分级
一级系统实现7*24小时告警，二级系统实现7*12小时告警，三级系统实现5*8小时告警。
9.&&&&&&&监控范围及目标
实现对负载均衡设备、网络设备、服务器、存储设备、安全设备、数据库、中间件及应用软件等IT资源的全面监控管理；同时自动收集、过滤、关联和分析各种管理功能产生的故障事件，实现对故障的提前预警和快速定位；对网络和业务应用等IT资源的性能进行监控，定期提供性能报表和趋势报表，为性能优化及未来系统扩容提供科学依据。
通常情况下，我们可以将监控对象这么来分：
l&&1.服务器监控，主要监控服务器如：CPU&负载、内存使用率、磁盘使用率、登陆用户数、进程
l&&状态、网卡状态等。
l&&2.应用程序监控，主要监控该应用程序的服务状态，吞吐量和响应时间，因为不同应用需要监
l&&控的对象不同，这里不一一列举。
l&&3.数据库监控，只所以把数据库监控单独列出来，足以说明它的重要性，一般监控数据库状态，
l&&数据库表或者表空间的使用情况，是否有死锁，错误日志，性能信息等等。
l&&4.网络监控，主要监控当前的网络状况，网络流量等。
以上四条应该算是最基本的，也是保证网站正常运行必须要知道的几点内容，这样才能实现我们常说的&运筹帷幄之中，决胜千里之外&。
------分隔线----------------------------关于系统运维监控规范的几点建议和思考_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
关于系统运维监控规范的几点建议和思考
上传于||暂无简介
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
下载文档到电脑，查找使用更方便
还剩1页未读，继续阅读
你可能喜欢如果在运维工作中收到非常多的告警信息，影响了本身的运维工作，应该从哪几个方面进行优化和改善？
按投票排序
记住一个原则：如果报警发给了 一个 不能短期内解决问题 的人。 那么应该反思这个报警是否有合理的必要。
告警信息，需要定制，重点关注以下的内容。哪些业务需要告警？哪种故障需要告警？告警等级如何划分？故障依赖关系如何定义？告警信息如何汇集？如何做到精准有效的告警？
最终的目的就是少收告警信息，自动处理故障，自动恢复服务，当然，这是一条漫长的路。如果不解决以上问题，将会被告警信息所淹没，最终如题主所言，影响运维工作。===================================================================
对于监控的告警信息，处理的好，将会提高我们的故障响应速度，处理的不好，会影响我们的工作情绪，适得其反。试想，当一天收到1000封告警信息，是否还会去逐一查看监控告警信息？是否还能分辨是否重大故障，还是一般故障？
对于误报，漏报，会让人对信息的警觉性放松，时间久了，还会导致对接收监控信息有反感。所以，对于监控告警信息的发送，是一件特别慎重的事情。总结一下，对于监控告警信息，我们有以下的需求：基于业务类型，将告警信息发送给相应的业务用户，例如IDC人员，WEB运维，CDN运维，网络运维，不同的人员管理不同的设备，因此需要把故障发送给相关用户处理。基于故障级别，对一个故障，将不同的故障级别发送给不同用户，例如5分钟内的故障发送给运维一线人员，10分钟发送给运维部门主管，30分钟发送给运维部门经理。重特大故障发送部门相关领导。基于时间发送，比如业务维护期，告警无需发送。故障的相关依赖关系，当A服务发生故障时，发送一般告警，当A，B服务故障时候，发送业务故障告警。对出现故障的服务尝试用相关命令或者脚本进进行操作处理，尝试自动恢复，例如重启服务，重启服务器等。
首先，我们要明确告警信息对于运维人员的意义何在？不论是通过摩卡/orin或者开源osa/cacti/nagios这类开源IT监控软件发送的告警信息，都是提供给运维人员当前系统运行遇到什么问题，提供即时甚至带提前量的重要讯息，从而让运维人员有了耳目，不至于一直充当灭火队员角色。我们离不开告警信息，那么题主的问题，常见的处理方式是什么？1.监控软件合理设置告警阀值，如何设置？ 网络设备方面核心设置接收信息以上，接入层设备设置只接收告警以上。服务器方面经常变化数据如（内存/CPU/IO/）取一日/一周/一月监控下来的平均量，最大数值为提示，高于最大数告警。非经常变化的数据如（总硬盘分区大小/网卡/CMDB配置）取能接受的最顶值作为红线告警比如硬盘分区C占用90%提醒，95%告警。2.告警采用邮件和短信结合方式，非直接业务线路走邮件报警
5-10分钟自动收一次邮件起到缓冲作用。直接业务线采用短信报警
邮件备档，以免忽略造成悲剧。3.辅助工具的使用，比如网络交换设备的告警信息刷屏很猛，但是有的时候有必要关注接入交换机端口安全后的mac绑定信息，可以结合orin以及自己搭建的Kibana+Logstash+Elasticsearch日志查询分析系统，出具合理报表及日志过滤。总而言之，言而总之。
不会偷懒的运维不是好厨子。。把筛子架上去，剩下的就是你真正需要的。
直接了当，错都报了就想办法处理该加设备就加设备，该压榨性能就压榨用户量上去了老板都抠门就赶紧找下一份工作
这些多本身如果都是不同类别都需要单独处理的，那就可能是你确实干的很烂，或者报警阈值设的有问题。如果很多是重复的，或者说有连带依赖关系的，看一条后面就不用再收了的，那么你就需要重新去考虑你的报警逻辑设置，nagios的parent啊period啊delay啊escalation啊downtime啊是不是都合理。如果不是nagios或者说监控软件上不合适做这个，那么你可以自己管理好短信猫这边，一般都是插入一个MySQL这样，那么不要让告警直接写库，中间写个小server缓冲一下，类似的报警打个tag做个归并也能省很多事。不过这方面建议用nagios啦~Etsy说过：一切监控软件最终都做成nagios的样子。
告警目的是为保障业务可靠性，我在《运维不容错过的4个关键指标》整理了4个关键性运维指标，懒得敲了，直接copy：告警事件数量如果团队中的事件数量呈现上升趋势，那么很有可能是哪里出了问题：要么是基础设施有故障，要么是监控工具配置错误需要调整。随着公司的发展，组织结构会调整，同时业务产品也会不断升级，配套监控也会同步上线，告警事件数量会急剧增加。「我们浪费了大量时间来关闭冗余报警。」－－相信很多同学都会有类似的体会。告警事件数量是可控的：告警数量可统计，如这周告警数量是多少，与新发布的产品系统有没有关系，发生哪些问题？告警数量是可操作的，意味着每一个告警都是有意义并且是需要处理和操作的，如果仅仅是瞅一眼的数据，请不要通过告警方式。例如100＋机器时，每台机器的「CPU 使用率高」告警是没有啥用的，你知道机器 CPU 使用率高后，你能做什么操作呢？你可能直接忽略掉，当数量大到你把需要处理的告警也忽略掉时，告警就失去了意义。类似指标完全可以通过周报／日报进行数据的性能分析，而不是告警。所以楼上的告警多，是需要优化的。记得我早期在nokia时代，一天收上千短信，基本上不看，就和不告警一样。平均解决时间（ MTTR ）解决时间是衡量业务准备的最佳标准。当事件发生时，你的团队需要多长时间才能解决？ 宕机不仅会影响你的收入，还会伤害客户用户体验和忠诚度，所以确保团队对所有事件可以快速响应极为关键。牛叉如BAT、AWS、google每年都发生多次严重故障（挖掘机立功了），但都能较快（相对严重程度来说）解决掉。全球500强企业平均每周出现严重故障时间长达1.6小时。（有数据跟老板说了，别怪我）平均每小时折合损失$96,000。当然，跟踪解决时间固然重要，但对其进行规范往往很难，根据环境的复杂性、团队和基础设施的责任制、行业及其他因素， MTTR 的有较大差异。但是，规范化的操作手册、自动化的基础设施管理、可靠的告警升级策略都有助于减少事件，和提升 MTTR。优秀的团队减少事件数量，并及时解决（ MTTR ），所以平均解决事件需要和上面告警数量一样，需要记录和统计分析，目前大多监控工具往往不具备类似能力，如果没有精力或者资源自行开发的话，我们就建议使用第三方云告警平台。有关如何减少事件数量，避免告警疲劳的事情，后续将会有独立文章进行发布。平均响应时间（ MTTA ）如果说平均解决时间是结果，那么平均响应时间就是重要的过程指标，这一点往往被大多团队忽略掉。可以理解为告警越快发现，越快有人响应，就能够越快的解决（更好的MTTR）。提升 MTTA 的核心是找对人、找到人。上图中如果02:01能够及时通知到位就可以节省至少4个小时时间。说起来简单，实际上找对人有些工作（只1人运维的请忽略），一般是从职责责任制、协调机制、工作进程透明、工作量和时间可衡量等几点进行，后面针对「有序分派」再补充一篇。除了以上机制，还有一点，就是需要记录谁什么时候确认响应告警，并做了哪些处理，能够持续跟踪，以及统计分析。响应时间非常重要，因为它能帮助你了解哪些团队和个人处于随叫随到的状态。快速响应时间是一个战备文化的代表，你会发现具备快响应观念和工具的团队往往可以更快地修复事件。如果使用像事件管理系统，[升级超时]有助于推进响应目标。例如，如果你希望所有事件都应该在5分钟内回复，可以将超时设置为5分钟，从而确保下一个接收人会收到提醒。再根据团队的整体表现，来决定是否需要调整目标，然后再跟踪升级事件的数量。升级对于大多数使用事件管理工具的组织而言，告警升级是一种异常现象，该迹象表明首次应该响应的时候，无法及时应对事件，或许相关工具和人员技能失效。升级策略是事件管理的必须，各个团队应努力推动升级，实现升级事件数量的下降。优秀的运维团队需要建立起有效的一线、二线、甚至三线响应机制，告警及时通知到一线，如果一线没有及时处理，可以自动升级至二线运维，保障每一个重要事件能够得到及时响应和处理。有些情况下，升级是标准作业实践的一部分。例如，你可能有一个 NOC，一线支持团队或者自动修复工具，可根据内容来升级或分诊输入事件。这种情况下，一线更多像一个路由转发器，可以通过人工＋工具自动化方式实现。示例分析这是某个团队一个月的告警数据剖析：告警数量在11-18前相对稳健，平均在3-5个告警。第3周告警突飞猛进，原因是新的业务上线，引发突增。经过周回顾，优化监控策略，在第4周经过初步优化，告警数量有所降低，运维团队工作初见成效，还需要继续优化。告警响应时间 MTTA ，基本上都能够比较好的响应，基本在5分钟内响应。说明整个团队的响应及时率是不错的。同时也看到在第3、4周六的时候，明显的响应时间延迟较大，说明一个问题，周末的支撑工作有提升空间。恢复时间 MTTR ，基本保持在20分钟左右，说明恢复比较及时，但是也有可能存在事件无需关注，自动恢复。后者需要针对事件的类型、根源进一步分析，后续文章再剖析。升级，目前该团队基本上是5分钟升级，所以会看到在大部分问题能在5分钟内响应完成。小结致力减少告警数量、及时响应 MTTA 、如果不能及时响应，能够升级处理，最终提升解决时间 MTTR，4个核心关键指标是运维支撑工作非常关键的指标。运维是结合管理流程、工具、人员三方面的综合化工作，目前市面上的类似SaaS云告警平台有几个：国外的 PagerDuty , VictorOps , OpsGenie ,国内 ，感兴趣可以去度娘。
我思想很直接，把问题都处理干净了就没有告警了。或者告警就不应该发给对告警短信感觉厌烦，或影响了他正常工作的人。
你看不看这些报警？如果不看的话为什么要让它报？这些报警是应该运维人员看还是对应的应用的负责人看？
个人认为运维是保持环境系统稳定'按照流程规范操作'而楼主遇到系统报警较频繁'可以跟自己的老大沟通'或者和甲方沟通'拉着系统集成商或厂商讨论下这个解决方案'萝卜坑不需要兔子腿填'
已有帐号？
无法登录？
社交帐号登录运维监控平台建设技术需求_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
运维监控平台建设技术需求
上传于||文档简介
&&运​维​监​控​平​台​建​设​技​术​需​求
阅读已结束，如果下载本文需要使用0下载券
想免费下载更多文档？
下载文档到电脑，查找使用更方便
还剩8页未读，继续阅读
你可能喜欢