做好监控,不做盲人

losetowin 发布于:2016-7-9 20:48  有 4435 人浏览,获得评论 0 条 标签: 监控 

本文地址:http://www.dutycode.com/jiankongsiwei_zuohaojiankong.html
除非注明,文章均为 www.dutycode.com 原创,欢迎转载!转载请注明本文地址,谢谢。

1. 为什么要做监控

“不要让自己成为最后一个知道系统出现问题”

不管在大公司还是小公司里面,在线上运行的项目不止一个,一个人可能同时需要维护多个新老系统,并且可能还有新的项目需求,所以不可能这个人去隔三差五的到服务器上看下服务是否正常。一方面,反馈不及时。另外一方面,没有这么多的精力去做这件事情,而且项目多的时候,精力就更不够了。

这时候,监控就相当于自己的眼睛,能够帮自己及时发现系统中的问题,及时解决,尽量避免出现重大线上事故。

2. 设计思路

1. 分层监控 

主要包含三部分:

  • 系统类监控:比如CPU、IO,磁盘、网络等监控。
  • 应用类监控:比如Mysql,Redis,jvm等监控
  • 服务类监控:服务可用性,站点存活,服务性能、异常日志统计、成功率、响应时间、调用量等监控

2. 数据存储 

几个原则:

  • 异常情况日志不做加工处理,目的在于能够反馈当时异常的原因,便于查找问题。
  • 定期删除报警日志,目的在于清理存储空间,减少资源占用。
  • 统一存储,一方面便于查找问题,另外一方面便于管理监控信息。

3. 报警策略

  • 分级报警
  • 报警方式主要有两种:短信报警和邮件报警。分别对应的级别不同,短信报警适合于需要人工立即干预。而邮件报警适合于不需要人工立即干预,起到预警作用,有一定的时间去处理。
  • 触发式和定时式报警
  • 触发式报警是指符合某种设定的报警阀值产生的报警,时间不定,一般短信报警属于触发式报警,部分邮件报警也属于触发式报警。比如磁盘空间到达80%时触发邮件报警,但到达90%时触发短信报警。 定时式报警是指固定时间产生的报警信息,时间固定,一般主要用于定时性的监控,重要但不紧急类型的监控,比如数据库单表数据量监控就属于定时式报警。

4. 配置化

配置化可以让监控更加灵活,可以方便接入到不同的系统中,减少接入成本。

3. 一些实践

基本的思路如下:


客户端负责上报数据到服务端,服务端负责数据存储并做报警处理。

举几个栗子:

  1. 磁盘监控
每台服务器每隔15分钟上报一次当前服务器的磁盘空间到服务端,服务端记录下这些数据之后,与我们设定的可用空间占比阀值(目前是80%)相比较,如果大于则相应的做邮件报警(可用磁盘占比大于80%小于等于90%)或者短信报警(可用磁盘占比大于90%),如下图: 

  1. redis监控
基本思路类似(此类监控不需要客户端上报,只需要在服务端做处理即可),同样根据设定的阀值不同,触发的报警方式也不一样,主要包含的指标有:
    • 连接数及连接状态:连接状态、正常连接数和堵塞连接数,具体数值设定需要根据具体的业务场景来看,比如我们的设定阀值分别为1000和10.
    • 内存监控:内存峰值和碎片比率(系统分配内存/redis实际分配内存),如果超出设定阀值,则需要关注是否存在无用的key值或者是否需要做数据拆分等操作。
    • 持久化监控:监控上次持久化后的变化量,如果变化量过大,则需要关注数据是否有大幅增长以及持久化时间设置是否合理。
    • 主从复制情况监控

  1. 错误日志监控
此类监控属于定时式的监控,客户端每天上报异常信息到服务端,服务端做数据统计及邮件发送服务。目的在于能够告知RD项目中潜在的异常部分,不管是测试还是开发,都不可能覆盖到程序中的所有的点,因为用户的操作路径不一定按照我们设定的来。通常,上线后的第二天能够根据异常的增长及下跌情况来判断程序是否需要去修复,保证能够提供稳定的服务。
报警情况如下图:

  1. 调用量及相应时间的监控

下面是公司对站点的监控web管理平台。 

4. 补充

  1. 现在有很多监控的工具,比如Metrics、uptime(根据网页心跳数据获取网页的可用性)等都可以拿过来用。


版权所有:《攀爬蜗牛》 => 《做好监控,不做盲人
本文地址:https://www.dutycode.com/jiankongsiwei_zuohaojiankong.html
除非注明,文章均为 《攀爬蜗牛》 原创,欢迎转载!转载请注明本文地址,谢谢。