prometheus 概述
- 语言:go,高性能和并发
- 监控方式:pull方式,客户端只负责采集数据,简化复杂度
- 接口:HTTP,简单方便
- 数据库:时序数据库
- 报警:支持
Pull方式的优势是能够自动进行上游监控和水平监控,配置更少,更容易扩展,更灵活,更容易实现高可用,与Push(推)方式的监控不同
时序数据库和关系型数据库
时序数据库
- 写操作:
- 时间是一个主坐标轴,数据通常按照时间顺序抵达
- 大多数测量是在观察后的几秒或几分钟内写入的,抵达的数据几乎总是作为新条目被记录
- 基本95%到99%的操作是写入
- 读操作:
- 随机位置的单个测量读取、删除操作几乎没有
- 读取和删除是批量的,从某时间点开始的一段时间内时间段内
- 读取的数据有可能非常巨大
- 存操作:
- 数据结构简单,价值随时间推移迅速降低
- 通过压缩、移动、删除等手段降低存储成本
大多数都是写操作,对于数据本身没有那么重要,一般都是保留近时间段的,支持存储压缩,节约存储资源
关系型数据库
- 写操作:大多数操作都是DML操作,插入、更新、删除等
- 读操作:读取逻辑一般都比较复杂
- 存操作:很少压缩,一般也不设置数据生命周期管理
基本操作都有,查询逻辑复杂,对于数据要求高
对于监控系统来说可以分2种类型
- 传统行业:针对的都是服务器本身,通过IP载体
- 云计算:载体变成了服务,一个对象
传统行业监控无法做到的场景
- 对云计算除主机外服务数据收集和监控
- 对容器编排这种跨宿主机的对象持续的数据收集和监控
- 对Paas或Saas类的服务进行数据收集和监控
- 对业务系统,IOT进行数据收集和监控
prometheus是面向服务监控,zabbix等传统工具是面向ip监控
prometheus 组件
- Prometheus server(服务器端):普罗米修斯的主服务器,用来收集和存储时间序列数据
- AlertManage(服务器端)r:告警处理,支持基于PromQL创建告警规则,如果满足PromQL定义的规则,则会产生一条告警,而告警的后续处理流程则由AlertManager进行管理
- Exporters(客户端):暴露服务指标(对比服务就区分支持与否了)
- 服务支持:这一类Exporter直接内置了对Prometheus监控的支持,比如cAdvisor,Kubernetes,Etcd,Gokit等,都直接内置了用于向Prometheus暴露监控数据的端点
- 服务不支持:原有监控目标并不直接支持Prometheus,因此我们需要通过Prometheus提供的Client Library编写该监控目标的监控采集程序。例如: Mysql Exporter,JMX Exporter,Consul Exporter等
- PushGateway:当服务端与客户端无法直接通讯时,可以借助PushGateway来进行中转