Monitor 监控架构
Monitor 监控架构
采集器: 负责采集监控数据的，采集到数据之后传输给服务端，通常是直接写入时序库
对时序库的数据 :
- 分析部分: 告警规则判断, 并进行通知
- 可视化: 通过各种图表来合理地渲染各类监控数据
采集器
采集器：负责采集监控数据
采集器的部署方式 :
- 跟随监控对象部署，如: 所有的机器上都部署一个采集器，采集机器的 CPU、内存、硬盘、IO、网络相关的指标
- 远程探针式，如: 选取一个中心机器做探针，同时探测很多机器的 PING 连通性
采集器的数据，推给服务端的两种方法 :
- 直接推给时序库
- 先推给 Kafka，再由 Kafka 写到时序库。更复杂情况，可能会用 Kafka + Flink + 时序库
| 采集器 | 优点 | 缺点 | 推荐场景 |
|---|---|---|---|
| Telegraf | 指标的全家桶 | 不适合 Prometheus 生态 | 配合 InfluxDB 使用 |
| Exporters | 生态庞大 | Exporter 水平参差不齐 | Kubermetes |
| Grafana-Agent | 指标, 日志, 链路统一 | 采集器集成不全 | Kubermetes |
| Categraf | 指标, 日志, 链路统一 | 采集器集成不全 | 物理机, 虚拟机, 容器都适用 |
Telegraf
Telegraf 是 InfluxData 公司的产品
- All-In-One 采集器，支持各种采集插件
- 与 Prometheus、Graphite、Datadog、OpenTSDB、InfluxDB 配合存储
Telegraf 采集数据多为字符串类型，这类数据推给 Prometheus，VictoriaMetrics、M3DB、Thanos (数值型时序数据) 要转为数值型存储
对于标签变化的指标 (标签非稳态结构) ，与 Prometheus 生态的时序库对接时 ，要把这类标签丢弃掉
- 设置 Telegraf :
metric_version = 2 - drop_tag : 删除不要的标签
Exporters
Exporter : 专门对接 Prometheus 生态的组件
- Exporter 组件众多，如: mysqld_exporter，redis_exporter，snmp_exporter，jmx_exporter
由于 Prometheus 影响较大，很多中间件都内置暴露 /metrics 监控数据的接口
- 如: kube-apiserver、kube-proxy、kube-scheduler ，etcd，ZooKeeper、 RabbitMQ、HAProxy
Grafana-Agent
Grafana-Agent 是 Grafana 公司推出的 All-In-One 采集器
- 能采集指标数据，也能采集日志数据 , 链路数据
Grafana-Agent 有个框架，方便导入各类 Exporter，如: Node-Exporter、Kafka-Exporter、Elasticsearch-Exporter、Mysqld-Exporter
- 用 PUSH 方式推送监控数据，完全兼容 Node-Exporter 指标
- 支持用 PULL 方式去抓取其他 Exporter 的数据，再通过 Remote Write 将采集到的数据转发给服务端
- 对日志采集，集成了 Loki 生态的日志采集器 Promtail
- 对链路数据，集成了 OpenTelemetry Collector
Categraf
Categraf 是快猫团队开源的一款监控采集器
- 支持 metrics、logs、traces 的采集
- 只采集数值型时序数据 (标签是稳态结构) ，通过 Remote Write 方式推送数据给后端存储(Prometheus、VictoriaMetrics、M3DB、Thanos)
- 支持读取
prometheus.yml的 scrape 配置，对接各类服务发现机制
时序库
| 时序库 | 优点 | 缺点 |
|---|---|---|
| OpenTSDB | 指标设计较灵活 | 基于 Hbase, Cassandra 架构较复杂 |
| influxDB | 与 Grafana , Telegraf 整合良好 | 只开源单机版本 |
| TDEngine | 集群爸爸开源 , 针对设备场景优化设计 | 不支持 Prometheus Querier 接口 |
| M3DB | 抗住大容量 , 扩展方便 | 对 CPU,内存要求较高 , 架构复杂 |
| VictoriaMetrics | 集群版 , 架构简单 , 支持 Prometheus Querier 接口 | |
| TimescaleDB | 基于 PostgreSQL 开发 | 国内应用较少 |
OpenTSDB
OpenTSDB 出现较早，2010 年左右就有了
- OpenTSDB 是基于 HBase 封装或 基于 Cassandra 封装
架构图 :
InfluxDB
InfluxDB 来自 InfluxData
- 针对时序存储场景专门设计了存储引擎、数据结构、存取接口，国内使用范围较广泛
- InfluxDB 配合 Grafana、Telegraf 使用，生态非常完备
- InfluxDB 开源版本是单机
TDEngine
TDEngine 是国产版 InfluxDB，针对物联网设备的场景做了优化，性能很好，能配合 Grafana、Telegraf 使用
- 集群版是开源
- 内置支持了流式计算
- 支持 Prometheus 的 remote_read 和 remote_write 接口
M3DB
M3DB 是 Uber 的时序数据库
- 声称能抗住 66 亿监控指标，
- M3DB 是全开源，但架构原理较复杂
VictoriaMetrics
VM (VictoriaMetrics) : 架构非常简单清晰，采用 merge read 方式，避免数据迁移
- 用一批云上虚拟机，挂上云硬盘，部署 VM 集群，用单副本，是非常轻量可靠的集群方式
- 实现了 Prometheus 的 Query 类接口，如:
/api/v1/query、/api/v1/query_range、/api/v1/label/<label-key>/values - 能当 Prometheus 的 Backend，或 Prometheus 的替代品
VM 架构图 :
TimescaleDB
TimescaleDB : timescale.inc 开发的一款时序数据库，基于 PostgreSQL 设计
- 当数据量到百亿或千亿行时，数据库性能会下降
告警引擎
告警引擎 : 处理告警规则，生成告警事件
告警引擎的两种架构 :
- 数据触发式 : 服务端接收到监控数据后，还会发给告警引擎，告警引擎判断是否告警
- 周期轮询式 : 架构简单，指标关联计算较容易实现。产品如: Prometheus、Nightingale、Grafana
生成事件后，给告警发送的模块
- 该模块负责事件聚合、收敛，并通知不同的接收者
- 告警发送的产品: PagerDuty，能接收各类事件源的事件，只用配置 OnCall 响应
数据展示
监控数据的可视化用 Grafana
- 采用插件式架构，支持不同类型的数据源，图表非常丰富
- 很多公司的商业化产品中，甚至直接内嵌了 Grafana
- 新版本已修改了开源协议 (AGPLv3) ，基于 Grafana 二次开发，要公开代码
监控数据可视化的两类需求 :
- 即时查询 : 临时起意，要追查监控数据
- 监控大盘（Dashboard) : 日常巡检和问题排查，放重点关注的指标