想吃透监控系统,就这一篇够不够?

2021-02-13    分类: 网站建设

经济高速发展的今天,我们处于信息大爆炸的时代。随着经济发展,信息借助互联网的力量在全球自由地流动,于是就催生了各种各样的服务平台和软件系统。

图片来自 Pexels

由于业务的多样性,这些平台和系统也变得异常的复杂。如何对其进行监控和维护是我们 IT 人需要面对的重要问题。就在这样一个纷繁复杂地环境下,监控系统粉墨登场了。

今天,我们会对 IT 监控系统进行介绍,包括其功能,分类,分层;同时也会介绍几款流行的监控平台。

监控系统的功能

在 IT 运维过程中,常遇到这样的情况:

  • 某个业务模块出现问题,运维人员并不知道,发现的时候问题已经很严重了。
  • 系统出现瓶颈了,CPU 占用持续升高,内存不足,磁盘被写满;网络请求突增,超出网关承受的压力。

以上这些问题一旦发生,会对我们的业务产生巨大的影响。因此,每个公司或者 IT 团队都会针对此类情况建立自己的 IT 监控系统。

Java 代码运行原理图

在介绍这种方式之前,我们先来复习一下 Java 代码运行的原理。通常我们会把 Java 源代码,通过“Java 编译器”编译成 Class 文件。再把这个 Class 的字节码文件装载到“类装载器”中进行字节码的验证。

最后,把验证过后的字节码发送到“Java 解释器”和“及时编译器”交给“Java 运行系统”运行。

Java 探针,字节码增强的方式就是利用 Java 代理,这个代理是运行方法之前的拦截器。

在 JVM 加载 Class 二进制文件的时候,利用 ASM 动态的修改加载的 Class 文件,在监控的方法前后添加需要监控的内容。

例如:添加计时语句,用于记录方法耗时。将方法耗时存入处理器,利用栈先特性(先进后出)处理方法调用顺序。

每当请求处理结束后,将耗时方法和入参 map 输出到文件中,然后根据 map 中相应参数,区分出耗时业务。

最后将相应耗时文件取下来,转化为 xml 格式并进行解析,通过浏览器将代码分层结构展示出来。

时序数据库数据模型图例

时序数据库的存储原理,关系型数据库存储采用的是 B tree,虽然降低了数据查询的磁盘寻道时间,但是无法解决大量数据写入时的磁盘效率。

由于监控系统的应用场景,经常会遇到大批量的数据写入,所以我们会选择 LSMtree(Log Structured Merge Tree)存储时序数据库。

LSMtree(Log Structured Merge Tree),从字面意义上理解,记录的数据按照日志结构(Log Structured)追加到系统中,然后通过合并树(Merge Tree)的方式将其合并。

来看一个 LevelDB 的例子,方便我们理解,LSM-tree 被分成三种文件:

  • 接收写入请求的 memtable 文件(内存中)
  • 不可修改的 immutable memtable 文件(内存中)
  • 磁盘上的 SStable文件(Sorted String Table),有序字符串表,这个有序的字符串就是数据的key。SStable 一共有七层(L0 到 L6)。下一层的总大小限制是上一层的 10 倍。

LSMtree LevelDB 存储示意图

LSMtree 写入流程:

  • 将数据追加到日志 WAL(Write Ahead Log)中,写入日志的目的是为了防止内存数据丢失,可以及时恢复。
  • 把数据写到 memtable 中。
  • 当 memtable 满了(超过一定阀值),就将这个 memtable 转入 immutable memtable 中,用新的 memtable 接收新的数据请求。
  • immutablememtable 一旦写满了, 就写入磁盘。并且先存储 L0 层的 SSTable 磁盘文件,此时还不需要做文件的合并。

每层的所有文件总大小是有限制的(8MB,10MB,100MB… 1TB)。从 L1 层往后,每下一层容量增大十倍。

  • 某一层的数据文件总量超过阈值,就在这一层中选择一个文件和下一层的文件进行合并。

如此这般上层的数据都是较新的数据,查询可以从上层开始查找,依次往下,并且这些数据都是按照时间序列存放的。

监控系统的分层

谈完了监控系统的分类,再来聊聊监控系统的分层。用户请求到数据返回,经历系统中的层层关卡。

监控系统分层示意图

一般我们将监控系统分为五层来考虑,当然也有人分成三层,大致的意思都差不多,仅供参考:

  • 客户端监控,用户行为信息,业务返回码,客户端性能,运营商,版本,操作系统等。
  • 业务层监控,核心业务的监控,例如:登录,注册,下单,支付等等。
  • 应用层监控,相关的技术参数,例如:URL 请求次数,Service 请求数量,SQL 执行的结果,Cache 的利用率,QPS 等等。
  • 系统层监控,物理
  • Zabbix 的部署模式

    Zabbix 的数据采集,主要有两种模式:Server 主动拉取数据和 Agent 主动上报数据。

    以 Server 拉取数据为例,用户在 Web-portal 中,设置需要监控的机器,配置监控项,告警策略。Zabbix-Server 会根据策略主动获取 Agent 的数据,然后存储到 MySQL 中。

    同时根据用户配置的策略,判定是否需要告警。用户可以在 Web 端,以图表的形式,查看各种指标的历史趋势。

    在 Zabbix 中,将 Server 主动拉取数据的方式称之为 Active Check。这种方式配置起来较为方便,但是会对 Zabbix-Server 的性能存在影响。

    所以在生产环境中,一般会选择主动推送数据到 Zabbix-Server 的方式,称之为 Trapper。

    即用户可以定时生成数据,再按照 Zabbix 定义的数据格式,批量发送给 Zabbix-Server,这样可以大大提高 Server 的处理能力。

    Proxy,作为可选项,起到收集 Agent 数据并且转发到 Server 的作用。

    当 Server 和 Agent 不在一个网络内,就需要使用 Proxy 做远程监控,特别是远程网络有防火墙的时候。同时它也可以分担 Server 的压力,降低 Server 处理连接数的开销。

    Prometheus(普罗米修斯)

    随着这几年云环境的发展,Prometheus 被广泛地认可。它的本质是时间序列数据库,而 Zabbix 采用 MySQL 进行数据存储。

    从上面我们对时间序列数据库的分析来看,Prometheus 能够很好地支持大量数据的写入。

    它采用拉的模式(Pull)从应用中拉取数据,并通过 Alert 模块实现监控预警。据说单机可以消费百万级时间序列。

    一起来看看 Prometheus 的几大组件:

    • Prometheus Server,用于收集和存储时间序列数据,负责监控数据的获取,存储以及查询。
    • 监控目标配置,Prometheus Server 可以通过静态配置管理监控目标,也可以配合 Service Discovery(K8s,DNS,Consul)实现动态管理监控目标。
    • 监控目标存储,Prometheus Server 本身就是一个时序数据库,将采集到的监控数据按照时间序列存储在本地磁盘中。
    • 监控数据查询,Prometheus Server 对外提供了自定义的 PromQL 语言,实现对数据的查询以及分析。
    • Client Library,客户端库。为需要监控的服务生成相应的 Metrics 并暴露给 Prometheus Server。
    • 当 Prometheus Server 来 Pull 时,直接返回实时状态的 Metrics。通常会和 Job 一起合作。
    • Push Gateway,主要用于短期的 Jobs。由于这类 Jobs 存在时间较短,可能在 Prometheus 来 Pull 之前就消失了。为此,这些 Jobs 可以直接向 Prometheus Server 端推送它们的 Metrics。
    • Exporters,第三方服务接口。将 Metrics(数据集合)发送给 Prometheus。
    • Exporter 将监控数据采集的端点,通过 HTTP 的形式暴露给 Prometheus Server,使其通过 Endpoint 端点获取监控数据。
    • Alertmanager,从 Prometheus Server 端接收到 Alerts 后,会对数据进行处理。例如:去重,分组,然后根据规则,发出报警。
    • Web UI,Prometheus Server 内置的 Express Browser UI,通过 PromQL 实现数据的查询以及可视化。

    Prometheus 架构图

    说完了 Prometheus 的组件,再来看看 Prometheus 的架构:

    • Prometheus Server 定期从 Jobs/Exporters 中拉 Metrics。同时也可以接收来自 Pushgateway 发过来的 Metrics。
    • Prometheus Server 将接受到的数据存储在本地时序数据库,并运行已定义好的 alert.rules(告警规则),一旦满足告警规则就会向 Alertmanager 推送警报。
    • Alertmanager 根据配置文件,对接收到的警报进行处理,例如:发出邮件告警,或者借助第三方组件进行告警。
    • WebUI/Grafana/APIclients,可以借助 PromQL 对监控数据进行查询。

    最后将两个工具进行比较如下:

    Zabbix 和 Prometheus 比较图

    从上面的比较可以看出:

    • Zabbix 的成熟度更高,上手更快。高集成度导致灵活性较差,在监控复杂度增加后,定制难度会升高。而且使用的关系型数据库,对于大规模的监控数据插入和查询是个问题。
    • Prometheus 上手难度大,定制灵活度高,有较多数据聚合的可能,而且有时序数据库的加持。
    • 对于监控物理机或者监控环境相对稳定的情况,Zabbix 有明显优势。如果监控场景多是云环境的话,推荐使用 Prometheus。

    总结

    监控系统思维导图

    监控系统对 IT 系统运维意义重大,从状态监控到收集/分析数据,到故障报警,以及问题解决,最后归档报表,协助运维复盘。

    监控系统分为三大类,日志类,调用链类,度量类,他们有各自的特点,且应用场景各不相同。

    因为要对整个 IT 系统进行监控,所以将其分为五层,分别是,客户端,业务层,应用层,系统层,网络层。

    Zabbix 和 Prometheus 是当下流行的监控系统,可以根据他们的特点选择使用。

    网站名称:想吃透监控系统,就这一篇够不够?
    链接地址:/news46/100696.html

    成都网站建设公司_创新互联,为您提供响应式网站App设计面包屑导航服务器托管移动网站建设小程序开发

    广告

    声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联

    网站优化排名