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