监控选型
监控目标确定后,需要选择合适平台来实现数据收集、展示、以及告警。
经过调研发现小米运维部开源出来的Openfalcon设计巧妙,组件足够松散,扩容方便,经过大规模数据考验,周边生态比较完善。数据展示部分做得比较粗糙,不够美观,控制起来不是很方便,果断选择展示效果更胜一筹的Grafana,Grafana有比较绚的展示效果,而且有可以自动化的api使用,很容易实现定制以及程序化生成Dashboard,这里很感谢快网同学为Grafana与Openfalcon系统桥接插件做出的努力。
遇到的坑
- Openfalcon的dashboard等个别组件依赖python,安装比较困难,跟作者沟通过,后续可能会用go重写。
- Openfalcon组件太过于分散,管理成本较高,1.0版本也可能会做出调整。
- Openfalcon权限部分太弱,扩展起来比较麻烦,快网、小米、美团等基本都是自己定制版。
- Openfalcon的Judge组件以及mysql建议使用ssd盘,避免IO过高的问题
- Grafana当时使用的是 v3.0.0-beta2,遇到了删除Dashboard API不太好用的问题,被迫使用页面上URL删除,这有很大隐患,目前V3.1.1问题已经fixed。
数据采集
- Worker JVM信息通过Jmx的方式获取:GC、线程、老年代内存等
- Worker 进程使用资源通过脚本获取:cpu、fd、日志等
- 任务相关信息通过NimbusClient来获取,并做二次加工
- 定时脚本抓取Jstack
- 触发开关触发Jmap,生成堆文件
- Openfalcon Agent默认会采集300项系统指标
数据汇报
- agent插件汇报
- jsonrpc4go RPC汇报
数据展示
Openfalcon提供API可以查看到endpoint下所有的监控项,Grafana也可以通过API的方式创建Dashboard,根据展示规则,采用程序【定时+手动】化生Dashboard【DashboardIndex】。
这里没有选择通过在Grafana中配置Template的方式来展示数据,这种方式效果不太理想,比如:过滤过期数据,展示版面控制个性化描述信息,用户视图展示等。
Oepfalcon API
- POST /graph/last
- POST /api/counters
Grafana API
- GET /api/search?query=$queryTitle&starred=false
- POST /api/dashboards/db/$dashboardName
- DELETE /api/dashboards/db/$dashboardName
- POST /api/user/stars/dashboard/$dashboardName
监控规模
- 监控主机2800+
- 监控指标70W+
- 对接另外一个监控系统数据会整体翻倍
告警力度
- 管理员收主机以及集群相关告警
- 用户只收与自己相关任务告警
老年代内存监控