一篇吃透监控系统：主流工具选型及落地场景参考( 三 ) _监控系统

不支持常用应用服务器如Tomcat、Apache、jetty等的监控。

整体发展一般，社区活跃度低

没有专门的运维支持，代码更新较少，没有一个较大的社区来维护，后续想要有什么新的能力基本只能指望自己扩展。

3、Prometheus（号称下一代监控系统）

我们知道 zabbix 在监控界占有不可撼动的地位，功能强大。但是对容器监控显得力不从心。为解决监控容器的问题，引入了 Prometheus 技术。

文章插图

Prometheus 是一套开源的系统监控报警框架。是由前google员工2015年正式发布的开源监控系统，采用Go语言开发。它不仅有一个很酷的名字，同时它有Google与k8s的强力支持，开源社区异常火爆。

先来了解下Prometheus的架构设计：

文章插图

Exporter

主要用来采集数据，并通过 HTTP 服务的形式暴露给 Prometheus Server，Prometheus Server 通过访问该 Exporter 提供的接口，即可获取到需要采集的监控数据。常见的Exporter有很多，例如node_exporter、mysqld_exporter、redis_exporter 等

Prometheus Server

核心组件，负责实现对监控数据的获取，存储以及查询。Prometheus Server 也是一个时序数据库，它将监控数据保存在本地磁盘中，并对外提供自定义的 PromQL 语言实现对数据的查询和分析。

Push gateway

由于 Prometheus 数据采集采用 pull 方式进行设置的，内置必须保证 prometheus server 和对应的 exporter 必须通信，当网络情况无法直接满足时，可以使用 pushgateway 来进行中转，可以通过 pushgateway 将内部网络数据主动 push 到 gateway 里面去，而 prometheus 采用 pull方式拉取 pushgateway 中数据。

Alert Manager

当支持基于 PromQL 创建告警规则，如果满足定义的规则，则会产生一条告警信息，进入 AlertManager 进行处理。可以集成邮件，微信或者通过 webhook 自定义报警。

Web UI

Prometheus内置了一个简单的web控制台，可以查询配置信息和指标等，而实际应用中我们通常会将Prometheus作为Grafana的数据源，创建仪表盘以及查看指标。

1）Prometheus优点

社区活跃度高

github start超过40k，且一直在维护。

基于时序数据库，存储效率高
Prometheus核心部分只有一个单独的二进制文件，不存在任何的第三方依赖(数据库，缓存等等) 。唯一需要的就是本地磁盘，因此不会有潜在级联故障的风险。

很好地支持容器监控
能自动发现容器，同时k8s和etcd等项目都提供了对Prometheus的原生支持，是目前容器监控最流行的方案。

基于Pull模型的架构
Prometheus基于Pull模型的架构方式，可以在任何地方（本地电脑，开发环境，测试环境）搭建我们的监控系统。

2）Prometheus缺点

Prometheus 是基于 Metric 的监控，不适用于日志（Logs）、事件(Event)、调用链(Tracing) 。
由于Prometheus采用的是Pull模型拉取数据，意味着所有被监控的endpoint必须是可达的，需要合理规划网络的安全配置。
指标众多，需进行适当裁剪。

三、选型建议

通过上面的介绍，大家对主流的监控系统应该有了一定的认识。面对选型问题，我的建议是：
1）先明确清楚你的监控需求：要监控的对象有哪些？机器数量和监控指标有多少？需要具备什么样的告警功能？
2）监控是一项长期建设的事情，一开始就想做一个 All In One 的监控解决方案，我觉得没有必要。从成本角度考虑，在初期直接使用开源的监控方案即可，先解决有无问题。
3）从系统成熟度上看，Zabbix属于老牌的监控系统，资料多，功能全面且稳定，如果机器数量在几百台以内，不用太担心性能问题，另外，采用数据库分区、SSD硬盘、Proxy架构、Push采集模式都可以提高监控性能。
4）Zabbix在服务器监控方面占绝对优势，可以满足90%以上的监控场景，但是应用层的监控似乎并不擅长，比如要监控线程池的状态、某个内部接口的执行时间等，这种通常都要做侵入式埋点。相反，新一代的监控系统Open-Falcon和Prometheus在这一点做得很好。