运维监控谈：Prometheus和Zabbix的对比选型

[9:4]

监控的深度

1.可用性监控

2.性能监控

3.日志监控

4.自定义监控

[13:7]

[17:15]

zabbix架构

[19:17]

prometheus架构

exporter相当于zabbix的agent

[20:20]

zabbix高级特性

低级别发现 & 自动发现

全栈级监控（所有东西都可以被监控）

可定制，有开放的API可以和devops集成

[22:27]

分组

[26:58]

告警

[29:41]

jenkins和zabbix的关联

[30:50]

zabbix对硬件的监控

[32:30]

如何选择监控平台

纯容器化的环境，建议使用prometheus

纯服务器的环境，建议使用zabbix

硬件监控，是很难通过prometheus来实现。

[33:55]

使用zabbix的收益

简单易用

专业展现

团队协作

zabbix可以覆盖80%的监控需求

[39:10]

prometheus架构

[42:15]

prometheus高可用

[45:10]

prometheus后端存储

原生prometheus默认只存储180天监控数据

[50:0]

prometheus监控redis

负责数据汇报的程序，就是exporter。

不同的exporter，负责不同的业务。

[1:8:20]

grafana整合zabbix和prometheus

条件需要，zabbix和prometheus可以同时存在。

[1:10:12]

grafana整合zabbix——安装插件

grafana如果要展示zabbix数据，需要安装zabbix插件

获取可用插件列表：

grafana-cli plugins list-remote

插件安装：

grafana-cli plugins install

alexanderzobnin-zabbix-app

加载插件

grafana整合zabbix——添加数据源

数据源的添加，最好使用zabbix api，不要使用直接连接zabbix数据库（因为升级zabbix版本后，可能会有问题，比如需要同步更新）

[1:14:45]

grafana整合prometheus

[1:18:22]

zabbix/prometheus的短板

3000～5000个节点的规模没有问题。

[1:23:40]

历史存储和对存储数据的分析

[1:28:17]

告警误报其实是配置规则、参数本身有问题。

大量使用模板降低误报的可能性，还是尽可能减少人为操作。

告警风暴，zabbix有1个特性，依赖项

机器宕机，可能会报警很多项，把这些依赖项都连起来。

告警风暴，在prometheus可以通过静默告警、加入维护组，或者做聚合，把同类告警进行合并。测试环境的告警，可以完全忽略。

[1:35:59]

智能监控、自动治愈，有方案，但由于多方面因素要考虑，很难实施。

[1:44:12]

dashboard设计

[1:51:16]

容器化选择prometheus

多种场景选择zabbix

也可以都用

[1:54:55]

prometheus更加适合容器

新版zabbix已经支持prometheus原生的exporter

我们真正需要关注的点，才需要我们的监控。

主机、网络，通过zabbix监控；服务、容器，通过prometheus监控。

基础监控可以由zabbix来做，容器监控交给prometheus

即便业务环境都是在云上，容器化率已经超过95%，也可以仍然使用zabbix

容器里的服务，service、pod，由prometheus来做；但是，node节点、ECS本身的监控、网络质量的监控还是可以交给基础监控zabbix

[2:1:15]

zabbix和prometheus可以同时存在，并不冲突。

[2:4:24]

分布式链路监控不建议使用zabbix、prometheus

没有一个技术栈可以解决所有问题

zabbix/prometheus还是偏向于服务端的监控

基于云原生，发展比较火热的微服务，各个服务之间的调用链路治理的监控需求，也不能通过zabbix/prometheus解决。

[2:8:32]

zabbix的性能瓶颈主要在数据库