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//values
• 能当 Prometheus 的 Backend，或 Prometheus 的替代品

VM 架构图 :

TimescaleDB

TimescaleDB : timescale.inc 开发的一款时序数据库，基于 PostgreSQL 设计

• 当数据量到百亿或千亿行时，数据库性能会下降

告警引擎

告警引擎 : 处理告警规则，生成告警事件

告警引擎的两种架构 :

• 数据触发式 : 服务端接收到监控数据后，还会发给告警引擎，告警引擎判断是否告警
• 周期轮询式 : 架构简单，指标关联计算较容易实现。产品如: Prometheus、Nightingale、Grafana

生成事件后，给告警发送的模块

• 该模块负责事件聚合、收敛，并通知不同的接收者
• 告警发送的产品: PagerDuty，能接收各类事件源的事件，只用配置 OnCall 响应

数据展示

监控数据的可视化用 Grafana

• 采用插件式架构，支持不同类型的数据源，图表非常丰富
• 很多公司的商业化产品中，甚至直接内嵌了 Grafana
• 新版本已修改了开源协议 (AGPLv3) ，基于 Grafana 二次开发，要公开代码

监控数据可视化的两类需求 :

• 即时查询 : 临时起意，要追查监控数据
• 监控大盘（Dashboard) : 日常巡检和问题排查，放重点关注的指标