prometheus_operator

谈谈监控的选型相关问题

传统的主机监控类


zabbix

很早有许多使用 zabbix 做相关监控的

核心组件的话 是agent server 模式的
agent负责采集数据 主动或者被动的方式发送到 server/proxy
为了扩展 还可以进行自定义脚本的监控等等

数据存储默认是选择的mysql 提供一个php web的页面来做查询

因为是使用关系型数据库 因此在大规模集群的时候 有点捉襟见肘

4.2版本之后开始采用时序的数据库 但是成熟度不算很高


open-falcon

是小米成熟的开源项目 目前在市面上也有很多公司选用

小米 滴滴(在此基础上做了夜莺系统拥抱开源) 美团等

采用golang 开发的daemon 程序 运行在每台linux机器上 采集主机的各种指标

heartbeat server 心跳服务 周期性的通过RPC 的方式上报信息 主机名 ip agent版本 插件版本等

transfer 负责接收发送的监控数据 并对数据进行数据整理 过滤之后通过一致性哈希发送到judge/graph

graph 是基于RRD的数据上报 归档 存储组件

judge 模块 触发用户的告警规则 满足的情况下 会触发邮件 微信或者是回调接口 为了避免重复告警引入redis暂存告警 从而完成告警的合并和抑制

dashboard 面向用户的监控数据查询和告警配置页面


腾讯蓝鲸

腾讯开源的一整套系统 相对来说 是比较重的资产 要全套使用 系统配置相当之繁琐


prometheus

2016 年 CNCF 的第二大开源项目

通过http 周期性抓取被监控组件的状态 任意组件只要提供对应的http接口并且符合定义的数据格式 就可以接入到监控之中

prometheus server pull 多个 exporter 的数据 pull这种方式降低了客户端的复杂性 不需了解服务端情况

监控数据如果达到告警阀值 会将告警发送到 altermanger 邮件或者webhook的方式来通知消息

页面展示的话 一般选择还是grafana

一般情况下拉取的数据还是会存储在本地的 tsdb

开发语言上来看 java占据业务开发 c占据底层开发 golang 在中间件的开发需求 在开源中间件重应用广泛

再就是容器角度 在云原生蓬勃发展的时代 成为主导容器监控的标配