一 形形色色的监控系统
-
监控对象:通用型(通用的监控方式,适应于大部分的监控对象),专一型(为某一功能定制,例如Java的JMX系统、CPU的高温保护、硬盘的断电保护、UPS切换系统、交换机监控系统、专线监控等);
-
数据获取方式:Push(CollectD、Zabbix、InfluxDB);Pull(Prometheus、SNMP、JMX);
-
部署方式:耦合式(和被监控系统在一起部署);单机(单机单实例部署);分布式(可以横向扩展);SaaS化(很多商业的公司提供SaaS的方式,无需部署);
-
数据获取方式:接口型(只能通过某些API拿去);DSL(可以有一些计算,例如PromQL、GraphQL);SQL(标准SQL、类SQL);
-
商业属性:开源免费(例如Prometheus、InfluxDB单机版);开源商业型(例如InfluxDB集群版、Elastic Search X-Pack);闭源商业型(例如DataDog、Splunk、AWS Cloud Watch);
二 Pull or Push
三 Pull vs Push概览
一级分类 |
二级分类 |
Pull |
Push |
原理与部署 |
配置 | 原生中心化配置 |
端上配置,通过配置中心支持中心化 |
监控对象发现 |
依赖服务发现机制,例如Zookeeper、Etcd、Consul等注册中心 |
由应用、Agent自主上报,无需服务发现模块 |
|
部署方式 | 1. 应用暴露端口,接入服务发现,原生支持Pull协议; 2. 其他系统例如主机、MySQL、NGINX等中间件依赖适配器(也成为Exporter)去抓取指标再提供Pull端口 |
1. Agent统一代理,抓取主机、MySQL等中间件数据推送到监控系统;Agent也可以作为转发器接收应用推送 2. 应用主动推送到监控系统 |
|
扩展性 |
可扩展性 |
依赖Pull端扩展;需要Pull Agent和存储解耦(原生Prometheus不支持);Push Agent按照分片划分 |
简单,本身Agent可横向扩展 |
能力对比 |
监控对象存活性 |
简单 |
无法区分对象未存活的原因 |
数据齐全度计算 |
1. Pull端和存储耦合部署时较简单 2. Pull Agent分布式部署下较困难 较困难 |
较困难 |
|
短生命周期(Job、Serverless)/数据获取实时性 |
难以适用 |
适用 |
|
指标获取灵活性 |
On Demand按需获取 |
被动接受,需要一些过滤器额外支持 |
|
应用耦合性 |
应用与监控系统解耦,应用无需关心Push的对端地址、Push错误处理等 |
耦合性相比Pull较高 |
|
机器、人力代价 |
资源消耗 |
1. 应用暴露端口方式资源消耗低 2. Exporter方式资源消耗较高 |
1. 应用推送方式资源消耗低 2. Agent方式资源消耗较低(可同时采集多套系统) |
安全性保证 |
工作量大,需要保证应用暴露端口的安全性以及Exporter端口的安全性,容易被DDos攻击或者出现数据泄露 |
低,Agent与服务端一般都进行带有加密、鉴权的数据传输 |
|
核心运维消耗 |
1. Pull Agent稳定性与扩容 2. 服务端稳定性与扩容 3. 服务发现系统稳定性 4. Exporter稳定性与扩容 5. 网络连通性保障(反向连通性,跨集群、网络ACL) |
1. Push Agent稳定性 2. 服务端稳定性与扩容 3. 配置中心稳定性与扩容(可选) 4. 网络连通性保障(正向连通性,较简单) |