Prometheus + Grafana 应用级监控方案(1)-概述
主流监控方案比较
比较项 | Prometheus+Grafana | Zabbix | BKCE |
---|---|---|---|
整体方案 | Prometheus更像一个“监控引擎”,文本配置,UI极简,适用于应用级监控,配合Grafana配置界面,UI够漂亮 | 传统监控,以IP为监控主目标,更适合于主机、网络监控,对SNMP支持很好,带PHP界面,可自行扩展但整体界面不够“靓” | 腾讯蓝鲸社区版,运维及CMDB功能非常强大,PaaS,DevOps,社区版的监控是PaaS之上的APP,专业性、扩展性均一般(据说企业版很强大),开源生态较一般 |
监控目标 | exporter-Pull模型,更安全,性能影响小 | Agent-Push方式,部署复杂 | Agent-重点在于下发指令及文件传输(BT),监控只是顺带功能,支持自动远程部署 |
支持 | 数据库/中间件/应用/硬件,开源生态圈丰富 | 对SNMP支持特别好,偏硬件、网络、服务器,对应用级监控支持一般 | 支持常用的监控项,要扩展不是一般的麻烦 |
存贮 | 自带TDB及外部数据库,建议使用外部InfluxDB | Mysql/PostgreSQL,对时序类的支持不好 | InfluxDB+Mysql |
UI | 建议使用Grafana配置方式 | PHP,自定义扩展,界面一般 | 有限几种展示,扩展就别想了(社区版) |
性能 | 10万数据/秒,GO语言的程序,性能值得信赖 | 一般,个人认为Mysql不适合用于存监控数据 | BKCE自身较占资源,必竟它的使用场景是“上万台服务器下的自动运维、监控”,小场景下无优势 |
告警 | 类SQL方式脚本化配置,建议将告警放到Grafana,告警时能带图片+链接,很友好 | 事件+条件+操作,较完整的告警体系 | 告警规则较死板,通过BKCE的消息通道推送,支持微信、短信等(自家产品) |
其它方案
Elastic stack
- 以ElasticSearch为核心件,Beats为其监控扩展插件,Kibana为UI展示端的“全家桶”方案
- Filebeat + ES + Kibana 组成的日志分析型监控,无出其右者!
- 支持常用的OS、数据库、中间件等多种Beat,UI界面友好
- 扩展性一般、第三方扩展资源较少
- 企业级应用需要用到权限、远程同步等安全及高级功能,则需要购买xpack许可,可不便宜
Prometheus + Grafana 方案小结
- 引擎 + UI ,较好地体现了“Unix哲学”之一: 让程序只做一件事并把它做好,Unix最伟大的功能之一”管道“就是这个体现," ls |grep | sort |wc " 这种操作,相信作为运维人员是很熟悉的
- yml配置文件而非界面配置:开发人员写文档更喜欢 markdown而非Word/Notepad,编辑配置同理
- export设计简洁:Don't call me,I will call you!
- TDB及RDB-InfluxDB: 非时序型数据库的监控方案不应该被采用,除非数据量很小
- Prometheus 这个名字太美,就像Eclipse的名字一样美妙--自行体会吧
方案不足之处
- Prometheus自身的扩展不方便,Go语言写的代码,到处是协程、管道,要读懂处理过程还是比较麻烦的
- 吐槽一下:Golang由于众所周知的原因,编译时下载依赖包及编译环境初始化有些障碍,这不是事,我从没见过一个程序编译需要8CPU全跑满,几分钟后告诉你”XX变量申明但没有使用,编译失败!“这种体验!
- 关于告警:Prometheus的告警方案体验一般,Grafana的告警方案不够灵活,两者都不太理想,能结合一下就完美
- 自动部署:BKCE的监控模块有一大优点是能通过它自己的NodeMan远程自动部署,”能让机器完成的事,不浪费程序员一秒钟“,在本方案中均需要手工配置完成监控系统、exports、view、Alert等工作
智慧运维之监控系统
- 增加自动部署子系统,完成大部分监控对象的批量自动化部署,极大提升监控开发、部署的效率
- 修改自动化部署配置文件 --> 一键部署,完成监控数据采集、监控展示界面、监控告警输出等过程
- 扩展Prometheus 的 UI部分,集成自动部署工具及Grafana的扩展界面(如:交换机状态图、运维窗口设置等)
- 扩展Grafana,增加几个有用的显示插件
- 通过Grafana的 webhook增加告警输出处理(如优化钉钉推送,告警信息反向推送至Granfna界面等)
自动化部署方案
自动化部署示例
监控及告警示例
如对我们的产品有兴趣,请联系: tianhc@tythin.com