智慧团建网站登录平台官网,拐角型网页布局,网站设计怎么划分块,网站广告案例监控系统的典型架构图#xff0c;从左往右看#xff0c;采集器是负责采集监控数据的#xff0c;采集到数据之后传输给服务端#xff0c;通常是直接写入时序库。然后就是对时序库的数据进行分析和可视化#xff0c;分析部分最典型的就是告警规则判断#xff0c;即图上的告…监控系统的典型架构图从左往右看采集器是负责采集监控数据的采集到数据之后传输给服务端通常是直接写入时序库。然后就是对时序库的数据进行分析和可视化分析部分最典型的就是告警规则判断即图上的告警引擎告警引擎产生告警事件之后交给告警发送模块做不同媒介的通知。可视化比较简单就是图上的数据展示通过各种图表来合理地渲染各类监控数据便于用户查看比较、日常巡检。 1、采集器
采集器负责采集监控数据有两种典型的部署方式一种是跟随监控对象部署比如所有的机器上都部署一个采集器采集机器的 CPU、内存、硬盘、IO、网络相关的指标另一种是远程探针式比如选取一个中心机器做探针同时探测很多个机器的 PING 连通性或者连到很多 MySQL 实例上去执行命令采集数据。
Telegraf 是 InfluxData 公司的产品开源协议是 MIT非常开放有很多外部贡献者主要配合 InfluxDB 使用。当然Telegraf 也可以把监控数据推给 Prometheus、Graphite、Datadog、OpenTSDB 等很多其他存储但和 InfluxDB 的对接是最丝滑的。Exporter 是专门用于 Prometheus 生态的组件Prometheus 生态的采集器比较零散每个采集目标都有对应的 Exporter 组件比如 MySQL 有 mysqld_exporterRedis 有 redis_exporter交换机有 snmp_exporterJVM 有 jmx_exporter。Grafana-Agent 是 Grafana 公司推出的一款 All-In-One 采集器不但可以采集指标数据也可以采集日志数据和链路数据。开源协议是 Apache 2.0比较开放。Grafana-Agent 集成了 Loki 生态的日志采集器 Promtail。对于链路数据Grafana-Agent 集成了 OpenTelemetry Collector。Categraf 的定位类似 Grafana-Agent支持 metrics、logs、traces 的采集。Categraf 偏重 Prometheus 生态标签是稳态结构只采集数值型时序数据通过 Remote Write 方式推送数据给后端存储所有支持 Remote Write 协议的时序库都可以对接比如 Prometheus、VictoriaMetrics、M3DB、Thanos 等等。 采集器采集到数据之后要推给服务端。通常有两种做法一个是直接推给时序库一个是先推给 Kafka再经由 Kafka 写到时序库。
2、时序库
监控系统的架构中最核心的就是时序库。老一些的监控系统直接复用关系型数据库比如 Zabbix 直接使用 MySQL 存储时序数据MySQL 擅长处理事务场景没有针对时序场景做优化容量上有明显的瓶颈。
OpenTSDB 是基于 HBase 封装的后来持续发展也有了基于 Cassandra 封装的版本。由于底层存储是基于 HBase 的一般小公司都玩不转在国内的受众相对较少当下再选型时序数据库时就已经很少有人会选择 OpenTSDB 了。
InfluxDB 针对时序存储场景专门设计了存储引擎、数据结构、存取接口国内使用范围比较广泛而且 InfluxDB 可以和 Grafana、Telegraf 等良好整合生态是非常完备的。不过 InfluxDB 开源版本是单机的没有开源集群版本。毕竟是商业公司需要赚钱实现良性发展这个点是需要我们斟酌的。
TDEngine 可以看做是国产版 InfluxDB。针对物联网设备的场景做了优化性能很好也可以和 Grafana、Telegraf 整合对于偏设备监控的场景TDEngine 是个不错的选择。TDEngine 的集群版是开源的相比 InfluxDBTDEngine 这点很有吸引力。TDEngine 不止是做时序数据存储还内置支持了流式计算可以让用户少部署一些组件。
M3DB 是来自 Uber 的时序数据库M3 声称在 Uber 抗住了 66 亿监控指标这个量非常庞大。而且 M3DB 是全开源的包括集群版不过架构原理比较复杂CPU 和内存占用较高在国内没有大规模推广起来。M3DB 的架构代码中包含很多分布式系统设计的知识是个可以拿来学习的好项目。
VictoriaMetrics简称 VM架构非常简单清晰采用 merge read 方式避免了数据迁移问题搞一批云上虚拟机挂上云硬盘部署 VM 集群使用单副本是非常轻量可靠的集群方式。
TimescaleDB 是 timescale.inc 开发的一款时序数据库作为一个 PostgreSQL 的扩展提供服务。
3、告警引擎
告警引擎的核心职责就是处理告警规则生成告警事件。通常来讲用户会配置数百甚至数千条告警规则一些超大型的公司可能要配置数万条告警规则。每个规则里含有数据过滤条件、阈值、执行频率等有一些配置丰富的监控系统还支持配置规则生效时段、持续时长、留观时长等。
告警引擎通常有两种架构一种是数据触发式一种是周期轮询式。
数据触发式是指服务端接收到监控数据之后除了存储到时序库还会转发一份数据给告警引擎告警引擎每收到一条监控数据就要判断是否关联了告警规则做告警判断。因为监控数据量比较大告警规则的量也可能比较大所以告警引擎是会做分片部署的即部署多个实例。
周期轮询式架构简单通常是一个规则一个协程按照用户配置的执行频率周期性查询判断即可因为是主动查询的做指标关联计算就会很容易。像 Prometheus、Nightingale、Grafana 等都是这样的架构。生成事件之后通常是交给一个单独的模块来做告警发送这个模块负责事件聚合、收敛根据不同的条件发送给不同的接收者和不同的通知媒介。
4、数据展示
监控数据的可视化也是一个非常通用且重要的需求业界做得最成功的当数 Grafana。Grafana 采用插件式架构可以支持不同类型的数据源图表非常丰富基本可以看做是开源领域的事实标准。很多公司的商业化产品中甚至直接内嵌了 Grafana可见它是多么流行。
监控数据可视化通常有两类需求一个是即时查询一个是监控大盘Dashboard。即时查询是临时起意比如线上有个问题需要追查监控数据还原现场排查问题这就需要有个方便我们查看的指标浏览功能快速找到想要的指标。监控大盘通常用于日常巡检和问题排查由资深工程师创建放置了一些特别值得重点关注的指标一定程度上可以引发我们思考具有很强的知识沉淀效果。如果想要了解某个组件的原理这个组件的监控大盘通常可以带给你一些启发。 此文章为7月Day29学习笔记内容来源于极客时间《运维监控系统实战笔记》推荐该课程。
