Monitor 监控架构

Monitor 监控架构

  • 采集器
    • Telegraf
    • Exporters
    • Grafana-Agent
    • Categraf
  • 时序库
    • OpenTSDB
    • InfluxDB
    • TDEngine
    • M3DB
    • VictoriaMetrics
    • TimescaleDB
  • 告警引擎
  • 数据展示

采集器: 负责采集监控数据的,采集到数据之后传输给服务端,通常是直接写入时序库

对时序库的数据 :

  • 分析部分: 告警规则判断, 并进行通知
  • 可视化: 通过各种图表来合理地渲染各类监控数据

Monitor 监控架构_第1张图片

采集器

采集器:负责采集监控数据

采集器的部署方式 :

  • 跟随监控对象部署,如: 所有的机器上都部署一个采集器,采集机器的 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 封装

架构图 :
Monitor 监控架构_第2张图片

InfluxDB

InfluxDB 来自 InfluxData

  • 针对时序存储场景专门设计了存储引擎、数据结构、存取接口,国内使用范围较广泛
  • InfluxDB 配合 Grafana、Telegraf 使用,生态非常完备
  • InfluxDB 开源版本是单机

TDEngine

TDEngine 是国产版 InfluxDB,针对物联网设备的场景做了优化,性能很好,能配合 Grafana、Telegraf 使用

  • 集群版是开源
  • 内置支持了流式计算
  • 支持 Prometheus 的 remote_read 和 remote_write 接口

Monitor 监控架构_第3张图片

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 架构图 :
Monitor 监控架构_第4张图片

TimescaleDB

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

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

告警引擎

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

告警引擎的两种架构 :

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

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

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

数据展示

监控数据的可视化用 Grafana

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

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

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

你可能感兴趣的:(Monitor,架构,kafka,大数据,分布式,java)