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来进行中转
