监控经验分享

监控的工具和方式太多,就不列举了,适合自已的,才是最好的。

因业务需求,运维工作的必要,我们需要在监控上做到位。

经常会有人讲,“运维主动发现问题,变被动为主动”,说得在理,不能说100%主动,但监控总能帮助我们更好地发现问题,定位问题。

那监控做得好不好,就很重要了,要用好的监控工具,要会用,熟练使用,有时间去研究、测试、验证,规划好,自动化好,监控配置合理,报警有效率高,发送给该发送的人,不紧要的就发邮件,紧要的那就发邮件和短信、甚至电话同时报警,不该报的不要报,不该发送的人不要发送,很啰嗦吧,是啊,要做到这些,是要花很多时间和精力的,尤其是业务变动频繁,变动量大时,不但要承担业务的设备、服务等资源的调整,并且监控项、阈值,也要按需调整,你敢保证这次调整的就一定合理吗?那过两天很可能需要再调整。

废话真多,直接说下我们是怎么做的吧,(我们就做得完美吗?难讲)
最初,采用了监控宝,用了很多年,
后来监控需求越来越多,就写脚本监控,不过比较分散,管理不方便,
然后网上搜了一把,发现以前用过的监控工具也没太多新花样,决定采用zabbix,它好像很火啊,先用着吧,
一用才感受到它的灵活、稳定、有效、性能好、功能强大。
对zabbix没有认真地去阅读它的帮助,全英文,好累,就是全翻译成中文,看着也头大,因业务变动频繁,变动量大,只好一边用一边摸索,有特别需求时,去找官方文档相关的部分,或百度搜搜,下面说说总体思路。

模板
首先,监控这么庞大的量,一个一个去添?不可能,建立模版很重要,模版只有一套不行,我们的服务器类型、配置,所在运营商,很多,项目也多,建立多套模版很有必要,有共性的监控项,可使用同一套模版,按需关联即可。
这样,批量调整成为可能,比如调某个阈值,至少不用一台一台去改了吧。
个别主机有少量不同的地方,比如它的磁盘就只有50GB,CPU核就1个,或者它的带宽高达500Mbps,模板不适用了,单独做模板不太好,就把由模板关联进来的相关触发器停用,克隆一个,重调阈值即可。

主机
主机按项目或运营商,进行交叉分组,方便查找。
主机的命名非常讲究,直接和“动作”(触发报警后发送给那些人)有关系,根据关键字关联,同一项目的主机(设备)使用同一关键字打头。

触发器
触发器的名称包含主机名称即可,在模版中统一配置。

动作
动作即把哪些报警发送到哪儿,根据问题的严重性,匹配名称,发送给对应的项目组运维岗的邮箱,或短信,或电话告警。
比如某个项目的动作截图:
zabbix监控触发器

对了,把{ITEM.VALUE}包含到警报信息中,在非工作时间收到报警,具体监控值也许对你有帮助。

用户和用户组
动作只把告警发给用户组,我们用户组按项目建立,用户添加到组中,方便批量管理。

示警媒介
自编脚本,自建邮件系统,触发告警发邮箱,为什么自建邮件系统呢,因为第三方邮件系统大多有限制,还不便宜。
重要告警,结合飞信、微信、139邮箱,189邮箱,发送告警,或者喜欢手机长期连网的同事,直接通过互联网接收公司邮箱的告警也行,这个说到细节了,也尊重每个人的习惯、选择,人性化一点嘛,在非上班时间接收告警和要求应急响应,毕竟是对人家私人时间的侵占。
严重故障,触发电话告警,给合第三方服务完成。

自动发现(探索)
某些监控可以做成自动发现,比如某些主机的进程,重要端口,其监控量和维护量十分庞大,我们的估约有几千项的,所以按json格式自动生成,增减自动完成(shell或python实现),zabbix服务端做一模版,配置自动发现,有需要的主机关联下模版即可,监控内容也自动增删,触发阈值统一配置,全程高度自动化。

重要业务监控
举例一:比如网站,从玩家发起请求,到最终成功响应正确内容,期间要经过DNS、边缘节点、父层节点、前端nginx服务、php服务、haproxy、mysql,我们就做一个连接数据库并查询必要字串的php程序,zabbix本来就故意部署在异地的,这样,由zabbix开始,公网解析后,从边缘节点监控起,获取到查询的正确字符串,并且响应时间不长,来完成这一连串监控,哪一层有问题,报警都不会恢复。
举例二:模拟网站登陆过程,网站正不正常,其功能那么多,能监控到的总是有限,我们就监控经常有问题的,重要的地方,网站登陆过程经常出问题,好,我们结合第三方控件,在异地自动模拟登陆过程。
举例三:太多监控都是从运维角度去监控的,想想这场景,我们所有监控都没有发现问题,但有业务部门反馈,在线量就是下降了,最后查出来还真是运维的问题,没有监控到啊,你能保证你什么都监控到了吗?如果你能主动向业务部门反馈,现在在线量下降了,注意一下,也许同时咱们就发现问题了并解决了,或者即使没解决,业务部分对运维的印象还是有的。我们能监控到业务数据就最好,幸好,我们的在线人数写在了数据库中,就直接取出来,配置触发器,还做成图,有异常,很容易发现,比如某台DB的监控:
在线人数监控

总览图
想一眼直观地看到想关注的监控图吗,这是由zabbix的筛选和总览来实现的,
其中总览可以按主机来查看,当然也不用一个一个去添,在主机模版中配置好筛选即可。
筛选就是比较灵活的了,和监控宝的视图类似,可以组织任意你想观察的图表在一个界面中来,
监控总览图

各类应用监控
zabbix监控内容很容易扩展,默认的如果没有,可以去网上找模板,或者自主编写监控脚本,我们找了些模板,也自主编写或完善了一些,nginx,memcache,redis,mysql,varnish,想关注的可用性或性能趋势,都做了上去,但说实话,如果业务量不大的话,这些真没多少用,但是业务量很大的时候,这些应用服务有出现性能瓶颈的可能,或者出错率上升,值得观注,做到心中有数。

大屏展示
Grafana可以从zabbix中取数据,图形展示非常好,定制灵活,可做大屏展示,领导嘛,都喜欢看图表,一目了然,这个可以用起来。
只是它有个缺点,查询时间跨度太大,甚至超过半个月,就会造成zabbix数据库极大的压力,并且大流量,所以开放给非运维岗的同事查询太不明智了,看看就行了。

可用性监控
收到可用性报警了,但也许是zabbix和被监控点之间的网络问题,zabbix的分布式监控还是比较弱的,并且即使好用,其成本投入也不是小数,能做到监控宝这么全吗?还国内国外到处都是,如果有部分服务器在境外,那监控宝更是推荐的第三方监控服务。
如果要关心任意地区的网络情况,监控宝是很容易做到的。
这个功能非常好:
监控宝插图
如果有很多边缘节点,又不愿花钱买更多的监控宝“网站监控项”服务,那就针对分布式监测点设置为1~2个,几乎就能监控到各个边缘节点了。如果设置了好几个,居然都报警了,业务部门问起来,你就有分析参考的依据了,和同运营商的其它监控,以及不同运营商的监控,一对比,几乎就能明白发生什么事儿了,如果骨干网的事,也许可以提前松口气说,“还好不是我的事儿”。
当然这只是监控宝最具价值的地方之一,短信告警、语音告警、用户体验监控都是其核心功能,其它监控服务商或自建监控平台难以替代的,这是老实话。
有的人还在提免费监控,也许吧,免费监控很长一段时间好像还可以用,但过去两年的经验告诉咱们,可靠率确实不高。
对于不想在监控方面投入太多人力物力的,或者技术能力达不到的,或者监控量不大的,均可以考虑监控宝,省事还好用。

楼主干得不错,打赏!

Share

7 Comments

  • zengda 回复

    研究研究,学习学习。

  • 蒂欧娜 回复

    您的博客拥有旺盛的生命力!!

  • 米表 回复

    随便看看,随便转转!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">