运维监控系统实战笔记
秦晓辉
快猫星云联合创始人,Open-Falcon、Nightingale、Categraf 核心研发
9147 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 25 讲
运维监控系统实战笔记
15
15
1.0x
00:00/00:00
登录|注册

03|架构概述:一个监控系统的典型架构是什么样的?

你好,我是秦晓辉。
这一讲,我们来聊聊监控系统的典型架构,看看监控系统由哪些模块组成,各个模块是如何相互协同的。业界监控系统数量较多,如果我们一上来就陷入某个具体的系统中,容易一叶障目,不见泰山。这里我把众多监控系统的架构做了一个统一的抽象和概括,后面你再看到任何一个监控系统,都能快速理解了。

典型架构

我们先来看监控系统的典型架构图,从左往右看,采集器是负责采集监控数据的,采集到数据之后传输给服务端,通常是直接写入时序库。然后就是对时序库的数据进行分析和可视化,分析部分最典型的就是告警规则判断(复杂一些的会引入统计算法和机器学习的能力做预判),即图上的告警引擎,告警引擎产生告警事件之后交给告警发送模块做不同媒介的通知。可视化比较简单,就是图上的数据展示,通过各种图表来合理地渲染各类监控数据,便于用户查看比较、日常巡检。
下面我们就来逐一分析一下每个模块的职能和设计。

采集器

采集器负责采集监控数据,有两种典型的部署方式,一种是跟随监控对象部署,比如所有的机器上都部署一个采集器,采集机器的 CPU、内存、硬盘、IO、网络相关的指标;另一种是远程探针式,比如选取一个中心机器做探针,同时探测很多个机器的 PING 连通性,或者连到很多 MySQL 实例上去,执行命令采集数据。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

监控系统的典型架构包括采集器、时序库、告警引擎和数据展示模块。在选择采集器时需考虑具体业务需求和监控对象特点,常用工具包括Telegraf、Exporters、Grafana-Agent等。时序库是架构核心,常用的包括OpenTSDB、InfluxDB、TDEngine、M3DB、VictoriaMetrics、TimescaleDB等。告警引擎负责处理告警规则和生成告警事件,数据展示方面,Grafana是业界成功的可视化工具,支持即时查询和监控大盘。文章还介绍了各个功能模块的职能和推荐的工具,为读者提供了全面的技术概览,有助于快速了解监控系统的架构特点和选择适用的工具。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《运维监控系统实战笔记》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(26)

  • 最新
  • 精选
  • 怀朔
    置顶
    作者已经罗列非常全的,就不怎么想说之前的开源监控产品,目前主流还是向promethues 或者说向云原生靠近。近期质量比较高的课程了👍查看大家的留言,想回答小公司运维人员不多情况 又想达到好的效果,考虑到投入产出比,建议报警收敛和告警升级 聚合管理推荐商业化产品好了。 优点:大而全可以直接用,很多功能都已经完善开箱即用。 缺点:数据隐私问题 、还要钱。

    作者回复: 嗯,整个技术保障体系可以做的事情很多,一些脏活累活可以采购商业产品,自己多学习一些方法论、最佳实践,思路远比写两行业务代码有价值的多

    2023-01-13归属地:浙江
    10
  • 李慢慢
    极度想听告警引擎跟告警收敛这块,告警引擎这块有没有开源的,自己开发头大,没思路

    作者回复: 告警引擎分两类,数据触发式,周期查询式。数据触发式可以参考open-falcon的judge模块,周期查询式可以参考prometheus和nightingale的告警逻辑。 题外话,尽量不要自研,轮子已经挺多了,很多开源产品也有很多用户,自研的话后面持续维护比较麻烦

    2023-01-13归属地:江西
    4
  • 郭刚
    请问老师,Elasticsearch可以当时序库吗?

    作者回复: 可以,Elastic公司自己对外的产品就有可观测产品,存储就是用的es

    2023-01-30归属地:广东
    3
    3
  • aaaaa
    介绍的还是比较全面的,各个工具都能简要了解

    作者回复: 后面就开始围绕Prometheus详细展开了, 坐稳扶好 :)

    2023-01-13归属地:江苏
    2
  • Mori
    老师请教下,其实现在很多产品都是基于云上的,想机器类的我们可以通过安装agent采集指标,但是如果像中间件、数据库等云产品,通过接口获取指标又存在1:拉取时延 2:无法跟应用关联 的这种情况,这种有什么其他的思路想法呢?

    作者回复: 1,延迟不用担心的,不是个问题,没啥延迟。其实更大的问题是有些数据我们通过agent采集不到,比如lb的数据 2,跟应用关联的话,最简单的办法就是为数据打标签,比如某个rds实例是服务a使用,采集这个rds数据的时候就可以打上service=a这样的标签

    2023-01-13归属地:广东
    1
  • 玫友人
    课程非常受用,容易理解,深度也够,希望课程可以更新多些。

    作者回复: 每周一三五零点更新哈,加油,每一堂课都跟下来 :)

    2023-01-13归属地:广东
    1
  • 良才
    我想问下,文中提到的由于时序数据库的原因,大多数采集器是收集的数值型数据么。那对于这些产品我需要采集字符型数据时又是如何处理呢

    作者回复: 拿Prometheus来举例,一些字符串类型的数据,如果是metadata类型的,比如xx的version的信息,一般是放在label里的。 如果不是metadata类型,比如是一行日志,Prometheus就完全搞不定了,需要使用日志监控方案。

    2023-01-13归属地:辽宁
    1
  • 周文杰
    你好,关于日志的处理有两个疑问 1.日志从非结构化转化到结构化一般是用什么工具 2.日志的告警又是怎么实现的

    作者回复: 1.很多工具都可以做日志清洗,开源的工具比如 vector、logstash 2.日志告警有几种办法:a)用mtail、grok_exporter在端上读取日志生成指标,对指标告警;b)日志写入es、clickhouse 等,周期性查询判断阈值

    2023-10-29归属地:江苏
  • mover
    你好,我有一个关于vm作为大规模时序数据库的疑惑,辛苦解答一下。vm集群是没有副本概念的,也没有wal机制,如果vm节点故障了,是不是故障期间路由到故障vm节点的数据,以及节点故障前缓存在系统中,还没有刷到磁盘上的数据都丢失了?如果一个节点的磁盘损坏了,是不是这个节点上的所有数据都可能丢失了?生产环境中,我们该如何考虑时序数据的高可用呢?

    作者回复: vm是有副本的,不过机器故障的时候没有补副本的逻辑,比如刚开始写入的时候设置了2个副本,vminsert会写两份内容到vmstorage,其中一个故障了没关系,merge read还可以读取到另一份

    2023-04-06归属地:广东
  • frekoala
    请问老师,这4种采集器对信创机器支持怎么样呢?

    作者回复: x86和arm的理论上都没问题

    2023-02-23归属地:广东
收起评论
显示
设置
留言
26
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部