监控ui_做了10年监控系统，有些经验想和你分享

前言

都说监控系统是运维的第三只眼睛&＃xff0c;因此一旦线上出问题&＃xff0c;业务方第一反应是&＃xff0c;监控系统有没有提前告警&＃xff1f;是不是告警太多被淹没了&＃xff1f;为啥没有把根因报出来&＃xff1f;上面的三个质疑&＃xff0c;相信做过监控的同学都会深有体会。我做了10年的监控&＃xff0c;背锅不少&＃xff0c;在2021年的第一天&＃xff0c;我想跟你聊一聊我的一些心得。

什么是监控

做监控前&＃xff0c;先问自己一个问题。监控的本质是什么&＃xff1f;我的理解是监测并实施控制&＃xff0c;监测并告警只是第一步&＃xff0c;有效的控制才是根本。

• 数据采集&＃xff1a;采集的方式有很多种&＃xff0c;包括日志埋点进行采集(通过Logstash、Filebeat等进行上报和解析)&＃xff0c;JMX标准接口输出监控指标&＃xff0c;被监控对象提供RESTAPI进行数据采集(如Hadoop、ES)&＃xff0c;系统命令行&＃xff0c;统一的SDK进行侵入式的埋点和上报等。

• 数据传输&＃xff1a;将采集的数据以TCP、UDP或者HTTP协议的形式上报给监控系统&＃xff0c;有主动Push模式&＃xff0c;也有被动Pull模式。

• 数据存储&＃xff1a;有使用MySQL、Oracle等RDBMS存储的&＃xff0c;也有使用时序数据库RRDTool、OpentTSDB、InfluxDB存储的&＃xff0c;还有使用HBase存储的。

• 数据展示&＃xff1a;数据指标的图形化展示。

• 监控告警&＃xff1a;灵活的告警设置&＃xff0c;以及支持邮件、短信、IM等多种通知通道。

所以做监控的最终目的是先于用户发现问题&＃xff0c;提供有价值的告警&＃xff0c;并闭环解决。

监控1.0

08年刚到WS的时候&＃xff0c;CDN业务规模还很小&＃xff0c;公司就几百台机器&＃xff0c;监控项不到20种。当时过去的时候&＃xff0c;阿贤已经把监控系统都搭得差不多了&＃xff0c;基本能满足业务初期的监控需求&＃xff0c;监测服务器的死活&＃xff0c;服务状态异常squid/lighttpd/rsync/snmp。

架构说明&＃xff1a;

• pingServer服务端部署在内网&＃xff0c;它从CDN平台获取监控组及组对应的监控机&＃xff0c;为监控机分配监控测试任务

• wsPoller对测试任务进行远程测试&＃xff0c;并根据测试结果产生报警发送至告警平台

• 通过SNMPOID扩展增加监控的采集项

存在的问题&＃xff1a;

• 单点策告警&＃xff0c;容易误报

• wsPoller无法根据自身的网络、负载自动踢除

• 机器性能监控缺失

• 不支持本地采集

监控2.0

随着客户对服务质量的要求变高&＃xff0c;监控1.0的弊端开始显露。09年初&＃xff0c;我们决定开发监控2.0。

团队在研究完Nagios、Cacti、Zabbix开源系统后&＃xff0c;发现这些系统在扩展性方面&＃xff0c;告警运维值班便捷性上满足不了我司的运维需求。

苗辉是当时的leader&＃xff0c;这家伙就喜欢自己折腾个东西出来&＃xff0c;而我当时心里挺犹豫&＃xff0c;有开源的不用&＃xff0c;为啥要从0到1自己搞。只是这个家伙"吹牛"还是可以的&＃xff0c;把老板说服了&＃xff0c;带着4~5个应届生&＃xff0c;我们就开干了。单单设计文档我们就整了100多页&＃xff0c;方案来回讨论了有1个月&＃xff0c;团队苦逼的搞了大半年&＃xff0c;alpha版本终于上线了。

架构说明&＃xff1a;

• wsmsagent——wsMS的数据收集接口&＃xff1b;

• MI——wsMS的数据中转加工站&＃xff1b;

• AL——wsMS的告警分析&＃xff1b;

• RRDS——wsMS的监控数据绘图引擎&＃xff1b;

• SCHEDULER——wsMS自动均衡的决策中心&＃xff1b;

• SCADA——wsMS的通用采集监测组件&＃xff1b;

• UI——展示界面。

监控3.0

这个系统线上运营了2年&＃xff0c;2011年随着机器规模迅速增加到7K&＃43;&＃xff0c;平台开始爆发出各种问题&＃xff1a;

• 机器增加到2万的时候&＃xff0c;监控数据单表1天超过5亿条数据&＃xff0c;复杂的SQL告警规则查询耗时太长&＃xff1b;

• 原始告警移到历史告警通过Insert和Delete&＃xff0c;性能太低&＃xff1b;

• 通过数据持久化再分析生成告警&＃xff0c;已经满足不了实时性的要求&＃xff1b;

• 复杂的告警规则通过SQL已经无法支持&＃xff1b;

• 新增一种采集类型的数据&＃xff0c;都需要二次开发&＃xff0c;成本较高&＃xff1b;

• 每天有2W&＃43;的告警&＃xff0c;运维根本处理不过来&＃xff1b;

• 监控和告警数据很多&＃xff0c;为什么还是有不少故障监控没有发现&＃xff1f;

这个时候苗辉跑去百度了&＃xff0c;我一个人压力山大。当时外部对监控不是很满意&＃xff0c;告警刷屏时有发生。

2015年底我决定搞监控3.0&＃xff0c;以构建立体化的监控体系为目标&＃xff0c;将告警分层&＃xff0c;覆盖从基础设施->组件->产品服务->客户业务的四层告警。自上而下做告警定位&＃xff0c;由下而上确定告警影响范围。建立告警间的相互关联关系&＃xff0c;当出现一个严重级别的告警时&＃xff0c;能展示告警的影响范围。

架构图

调度系统

UI层&＃xff1a;提供任务类型配置、任务分配结果查询&＃xff0c;任务状态查询&＃xff0c;组件状态查。2)由UI-master,UI-slave组成&＃xff0c;利用LVS或NGNIX做主从。

任务调度层&＃xff1a;根据原始任务状态&＃xff0c;监控机状态&＃xff0c;任务配置状态决策是否进行任务分配&＃xff0c;通过zeroMQ向任务分配层发送分配任务2)同时定时向任务加载层发送任务加载任务3)有core-master&＃xff0c;core-slave组成&＃xff0c;利用zk或hzelcast做主从。

任务加载层&＃xff1a;负责接收Core-master的加载任务&＃xff0c;向外部系统获取原始任务&＃xff0c;写入mysql

任务分配层&＃xff1a;负责接收Core-master的分配任务&＃xff0c;执行分配策略&＃xff0c;将数据写入memcache

数据缓存层&＃xff1a;memcahe缓存任务分配结果&＃xff0c;cachedump定时将分配结果快照写入mysql

任务分发层&＃xff1a;负责接收scada或其他采集客户端的请求&＃xff0c;将任务分发给采集端

ZeroMQ&＃xff1a;zeroMQ&＃xff0c;消息队列&＃xff0c;可自动实现负载均衡

Monitor&＃xff1a;负责调度平台可视化数据维护&＃xff0c;包含各组件的运行状态&＃xff0c;任务加载&＃xff0c;调度&＃xff0c;分配&＃xff0c;分发状态

ZK/hazelcast&＃xff1a;分布式协调系统&＃xff0c;用于core组件进行主备选举&＃xff0c;机房内部署集群&＃xff0c;设置iptable只允许同机房访问。

告警决策

NodeCluster

消息生产集群&＃xff0c;接入不同的数据源类型&＃xff0c;生产待计算的原始消息。如接收sdn推送的监控采集数据&＃xff0c;以每一行为一条计算数据提交。

MessageCluster

使用kafka消息中间件&＃xff0c;暂存计算消息。实现数据的流式输入。

JstormCluster

核心计算集群&＃xff0c;基于storm的java版本&＃xff0c;改进HA问题和计算性能优化。

MonitorCluster

集群状态监控&＃xff0c;负责进行集群内部的组件状态、topology计算状态的监控报警

ThorUI

UI作为实时计算平台的运营界面&＃xff0c;主要任务是各个组件的运行状态收集、消息任务配置、监控报警展示、系统配置等。

数据库性能调优

在监控2.0阶段&＃xff0c;监控数据是存储在MySQL&＃xff0c;监控数据每天达到750G&＃43;&＃xff0c;单表每天数据量10亿条&＃xff0c;数据查询非常慢。我们对监控表做读写分离和水平分表看下测试的效果&＃xff0c;但测试的结果让我们大失所望。

• 读写分离和单实例的查询和更新响应时间没有太大的区别&＃xff1b;

• 通过mycat的水平分表&＃xff0c;在大量数据下有优势&＃xff0c;但小量数据则无优势。所谓大量数据&＃xff0c;表内数据最好在千万级别以上&＃xff0c;插入量最好在百万级别以上。

上述两个方案行不通&＃xff0c;我们决定采用第3种方案&＃xff0c;表分区方案。即以5分钟为一分区&＃xff0c;根据每个监控对象实际需求创建分区数&＃xff0c;由crontab脚本定时执行&＃xff0c;执行时根据总时长、监控数据保留时长、当前时间&＃xff0c;数据计算出要删除的分区&＃xff0c;truncate分区数据。表分区方案将delete和load、select隔离在不同分区&＃xff0c;减少delete对load、select的影响。通过一段时间的测试&＃xff0c;发现测试效果还是不错的&＃xff0c;比之前有一定幅度的提升。

如何基于开源快速搭建一个监控系统

1.zabbix

如果你的公司机器规模少于1000台&＃xff0c;没有用到K8S&＃xff0c;告警逻辑也不复杂&＃xff0c;那推荐你用zabbix&＃xff0c;基本能满足企业内部普通的IT运维。

2.Prometheus&＃43;Clickhouse

如果你的公司机器规模大于5000台&＃xff0c;并且是通过容器化编排部署&＃xff0c;告警逻辑也较为复杂&＃xff0c;推荐Prometheus&＃43;Clickhouse。可参考之前的文章。

3.Prometheus&＃43;Telegraf&＃43;influxdb

Telegraf是实现数据采集‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍的工具。Telegraf 具有内存占用小的特点&＃xff0c;通过插件系统开发人员可轻松添加支持其他服务的扩展。在平台监控系统中&＃xff0c;可以使用 Telegraf 采集多种组件的运行信息&＃xff0c;而不需要自己手写脚本定时采集&＃xff0c;大大降低数据获取的难度。

总结

最后&＃xff0c;我总结出来做好监控很重要的4个点&＃xff1a;

• 一定要建立体系化的监控告警平台&＃xff0c;确定监控scope&＃xff0c;避免成为“背锅侠”。

• 监控不只是运维的事&＃xff0c;研发设计要把组件监控纳入进来。

• 监控越往前做越有效&＃xff0c;等到组件上线运营后再补充的代价是极高的。

• 监控发展的必经之路&＃xff0c;少->全->精&＃xff0c;要避免告警风暴&＃xff0c;做到精准。

  

简介 

基哥&＃xff0c;座标厦门&＃xff0c;目前专注运维架构&＃xff0c;DevOps的落地实践。欢迎添加我的微信号(hongdiji)一起学习交流。

长按扫码关注

一个在看&＃xff0c;小编会开心一整天...