SRE运维(八)监控数据源

2020年10月8日 发表评论 阅读评论

运维行业有句话:“无监控、不运维”,监控是及时发现现网问题的一种手段,并通过这种手段及时介入进行处理。不过在设备量不多的情况下,监控是比较容易处理的,我们可以配置的尽可能全,现网设备有个风吹草动,就可以让系统报出来,但设备随着1000台、1万台、10万台这样的规模上起来的时候,监控也就变得尤为困难了。

一、监控数据源

按我接触运维的时间线来说,流行的监控工具很多有cacti、Nagios、Ganglia、Zabbix、open-falcon、Prometheus等。不过无轮监控工具怎么变化,监控的数据源和监控的目的基本变化不是太大。监控的常见数据源有日志和指标(metrics)两类。如果把监控再根据所处的环节和功能点来说,我们可以分的更细,如下:

  • 数据中心监控:风火水电
  • 物理监控:CPU温度、风扇转速、硬件故障、电源状态
  • 操作系统监控:CPU、内存、磁盘IO、网络
  • 应用服务:Nginx、Tomcat、Mysql、oracle
  • 业务监控:每分钟订单数、日活、日新增用户数
  • 业务流量监控:PV、UV、访问人员地域分布(百度统计类的JS插件实现)
  • APM:应用性能、端到端的调用链、应用拓扑 (APM【pinpoint、zipkin】、NPM、BPM)
  • 日志监控:错误日志、访问日志、运行日志、设备日志、系统日志(ELK)
  • 安全监控:系统审计、漏洞扫描、webshell扫描
  • 舆论监控:微信、微博、新闻媒体等
  • 网络监控:全国网络链路情况、延迟、丢包 (smartping、smokeping、监控宝等)

除上面列的之外,我们可能还有一些其他类型的监控。这时候会发现我们的系统异常复杂,甚至一些企业的业务负责人还要求配置反向监控 ----- 业务每30分钟或1小时给一条通知业务系统正常的消息信息。

二、监控数据的处理流程

1、监控处理流程

monitor-types

和监控相关的数据,大致会经历上图的一个简单流程。首先从数据源上来说,先通过各种agent或协议的方式将数据收集并存储到一个地方,以ZABBIX为例,存在mysql中,这时候可以通过调用趋势数据,看到某个性能指标的一小时、一天、7天、1月甚至一年的变化情况,同时实时的数据会通过监控规则模块进行处理,通过报警阀值、报警策略的匹配,发送给相应的人员。同时我们的监控平台对外可能提供的还有接口便于调用分析。

再看场景消费这部分,我们在现网应用中可能不同的团队用了不一样的监控工具或者有多套,后面想要统一展示,可能会开发一个新的平台进行展示,也可能会用granfana这种可以接多种数据源的平台来自定义配置统一展示界面。同时像ELK里的事件、zabbix里的事件,还会存到BI系统中,进行分析、消费和考核使用 ---- 本月环比增加多少、同比增加多少、主要问题分布在哪几个类型里。

2、制定有效的监控策略

一个有效的监控策略,基本都需要具体以下几个重要特性:新鲜度、速度、计算、接口、告警。

新鲜度:这个比较好理解,监控系统要能反映当前监控项的情况,我想了解现在的监控状态,结果你给了我昨天的监控数据,显然这个是不行的。随着硬件整体性能提升,如今的监控工具很多在配置采集数据源时,在这一块儿有了比较好的表现,最初很多系统配置时都是5分钟采集一个指标点数据,现在很多都是30s或者1分钟左右一个采集点;

速度:在系统出现问题,需要通过一些指标数据进行辅助定位时,要求数据随时可用,不能查询一个数据,等了10分钟才返回,看这个监控系统就没什么意义了。

计算:可以通过各种计算和处理涵盖各种复杂的使用场景。比如,可以通过一段周期数据的计算,可以得出系统数据的增长率,为容量规划提供依据。一些日志数所可以通过计算进行指标化,得出请求错误率、每秒的请求量变化。同时和告警规则进行匹配也会涉及到比对计算。

接口:一个强大的监控系统应该能够精确地以时间序列的方式提供数据,方便其他系统的调用。 

告警:这项虽然听起来比较简单 ,但也是最难的。告警这块最主要的是要能做到告警抑制,将不必要的噪点去除。使收到的告警事件都是有效的。

三、监控的难点

在机器数量小于100台的小企业里,监控是相对比较简单的,其特点是:部署简单,上手易用(工具可选择性比较高);监控系统稳定,不容易出现性能问题;报警形式可以多样---正向反向、邮件钉钉等。当系统变得庞大时,设备数量增加到5000台以上时,会发现监控项增多,然后配置了各种告警,造成了监控系统可能存在性能瓶颈,收到的告警信息爆发式增长,经常收到上千封告警邮件、几百条的告警短信。这时候你会考虑优化告警系统,例如,对系统负载的监控,可以选择连续N次负载超过阀值,然后持续多久之后才进行告警操作。这时进行告警优化后又可能存在告警不及时、漏告警等情况。

这确实是个复杂的问题,我们留个悬念,下节我们就针对监控的问题,下节讲下解决方法和监控系统的重构思路。




本站的发展离不开您的资助,金额随意,欢迎来赏!

You can donate through PayPal.
My paypal id: itybku@139.com
Paypal page: https://www.paypal.me/361way

分类: 协同敏捷自动化 标签:
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.