乐趣区

关于微服务:监控系统选型一篇全搞定

大家好,我是不才陈某~

这篇文章,我将对监控体系的基础知识、原理和架构做一次系统性整顿,同时还会对几款最罕用的开源监控产品做下介绍,以便大家选型时参考。内容包含 3 局部:

  • 必知必会的监控基础知识
  • 支流监控零碎介绍
  • 监控零碎的选型倡议

关注公众号:码猿技术专栏,回复关键词:1111 获取阿里外部 Java 性能调优手册

必知必会的监控基础知识

咱们能够了解监控零碎就像咱们现代打战的哨兵一样,哨兵的角色十分重要,敌人来了,哨兵会第一工夫收回预警(吹笛、打鼓、放烟),让守城的兵士可能最快的工夫解决,应答。

那对于咱们利用零碎而言,监控零碎就像咱们第三只眼,如果有利用零碎呈现问题,咱们能够通过监控零碎看是哪里呈现问题,是 redis 挂了,还是说服务器内存满了,有监控零碎咱们能够很轻松、疾速的定位问题。

甚至咱们能够设置预警,对一些将要呈现的问题进行提前预防解决,及时防止问题的产生。

1、监控零碎的作用

  • 帮忙定位故障: 在产生故障时,咱们能够通过查看监控零碎的各项指标数据,辅助故障剖析和定位。
  • 预警缩小故障率: 对于行将可能产生的故障可能及时收回预警信息,做好提前预防解决。
  • 辅助容量布局: 为服务器、中间件以及利用集群的容量布局提供数据撑持。
  • 辅助性能调优: JVM 垃圾回收次数、接口响应工夫、慢 SQL 等等都能够监控优化。

2、常见的监控对象和指标都有哪些?

  • 服务器监控: CPU 使用率、内存使用率、磁盘使用率、磁盘读写的吞吐量、网络出入流量等等。
  • MySQL 监控: TPS、QPS、数据库连接数、慢 SQL、InnoDB 缓冲池命中率等等。
  • Redis 监控: 内存使用率、缓存命中率、key 值总数、Redis 响应申请工夫、客户端连接数、持久性指标等等。
  • MQ 监控: 连接数、队列数、生产速率、生产速率、音讯沉积量等等。
  • 利用监控:
    • HTTP 接口:URL 存活、申请量、耗时、异样量
    • JVM:GC 次数、GC 耗时、各个内存区域的大小、以后线程数、死锁线程数
    • 线程池:沉闷线程数、工作队列大小、工作执行耗时、回绝工作数

3、监控零碎的根本流程

  • 数据采集:采集的形式有很多种,包含日志埋点进行采集,JMX 标准接口输入监控指标,被监控对象提供 REST API 进行数据采集(如 Hadoop、ES),系统命令行,对立的 SDK 进行侵入式的埋点和上报等。
  • 数据传输:将采集的数据以 TCP、UDP 或者 HTTP 协定的模式上报给监控零碎,有被动 Push 模式,也有被动 Pull 模式。
  • 数据存储:有应用 MySQL、Oracle 等关系数据库存储的,也有应用时序数据库 RRDTool、OpentTSDB、InfluxDB 存储的,还有应用 HBase 存储的。
  • 数据展现:数据指标的图形化展现。
  • 监控告警:灵便的告警设置,以及反对邮件、短信、IM 等多种告诉通道。

市面上的一些常见监控零碎比拟

上面再来意识下支流的开源监控零碎,因为篇幅无限,我筛选了 3 款应用最宽泛的监控零碎:ZabbixOpen-FalconPrometheus,会对它们的架构进行介绍,同时总结下各自的优劣势。

1、Zabbix 介绍

Zabbix 1998 年诞生,外围组件采纳 C 语言开发,Web 端采纳 PHP 开发。它属于老牌监控零碎中的优良代表,监控性能很全面,应用也很宽泛,差不多有 70% 左右的互联网公司都曾应用过 Zabbix 作为监控解决方案。

先来理解下 Zabbix 的架构设计:

  • Zabbix Server:外围组件,C 语言编写,负责接管 Agent、Proxy 发送的监控数据。同时,它还负责数据的汇总存储以及告警触发等。
  • Zabbix Proxy:可选组件,对于被监控机器较多的状况下,可应用 Proxy 进行分布式监控,它能代理 Server 收集局部监控数据,以加重 Server 的压力。
  • Zabbix Agentd:部署在被监控主机上,用于采集本机的数据并发送给 Proxy 或者 Server。数据收集形式同时反对被动 Push 和被动 Pull 两种模式。
  • Database:用于存储配置信息以及采集到的数据,反对 MySQL、Oracle 等关系型数据库。同时,最新版本的 Zabbix 曾经开始反对时序数据库,不过成熟度还不高。
  • Web Server:Zabbix 的 GUI 组件,PHP 编写,提供监控数据的展示和告警配置。

Zabbix 的劣势

  • 产品成熟:因为诞生工夫长且应用宽泛,领有丰盛的文档资料以及各种开源的数据采集插件,能笼罩绝大部分监控场景。
  • 采集形式丰盛:反对 Agent、SNMP、JMX、SSH 等多种采集形式,以及被动和被动的数据传输方式。

Zabbix 的劣势

须要在被监控主机上安装 Agent,所有的数据都存在数据库里,产生的数据很大,瓶颈次要在数据库。

2、Open-Falcon(小米出品,国内风行)

Open-falcon 是小米 2015 年开源的企业级监控工具,采纳 Go 和 Python 语言开发,这是一款灵便、高性能且易扩大的新一代监控计划,目前小米、美团、滴滴等超过 200 家公司在应用它。

小米初期也应用的 Zabbix 进行监控,然而机器量和业务量上来后,Zabbix 就有些力不从心了。因而,起初自主研发了 Open-Falcon,在架构设计上汲取了 Zabbix 的教训,同时很好地解决了 Zabbix 的诸多痛点。

架构看去比 Zabbix 简单多了,其实它也是基于 Server—Agent 的模式,只不过 Server 又给他划分了好几个组件,这个耦合性和扩展性都失去了明显提高。

  • Falcon-agent:数据采集器和收集器,Go 开发,部署在被监控的机器上。就相当于 Agent,用于采集机器负载监控指标数据如:CPU、内存、磁盘、IO、网络、端口等等大略有 200 多个这些都能够自定是否收集。
  • Transfer:数据散发组件,接管客户端发送的数据,别离发送给数据存储组件 Graph 和告警断定组件 Judge,Graph 和 Judge 均采纳一致性 hash 做数据分片,以进步横向扩大能力。同时 Transfer 还反对将数据散发到 OpenTSDB,用于历史归档。
  • Graph:数据存储组件,底层应用 RRDTool(时序数据库)做单个指标的存储,并通过缓存、分批写入磁盘等形式进行了优化。据说一个 graph 实例可能解决 8W+ 每秒的写入速率。
  • Judge 和 Alarm:告警组件,Judge 对 Transfer 组件上报的数据进行实时计算,判断是否要产生告警事件,Alarm 组件对告警事件进行收敛解决后,将告警音讯推送给各个音讯通道。
  • API:面向终端用户,收到查问申请后会去 Graph 中查问指标数据,汇总后果后对立返回给用户,屏蔽了存储集群的分片细节。
Open-Falcon 劣势
  • 主动采集能力:Falcon-agent 能主动采集服务器的 200 多个根底指标(比方 CPU、内存等),无需在 server 上做任何配置,这一点能够秒杀 Zabbix.
  • 弱小的存储能力:底层采纳 RRDTool,并且通过一致性 hash 进行数据分片,构建了一个分布式的时序数据存储系统,可扩展性强。
  • 灵便的数据模型:借鉴 OpenTSDB,数据模型中引入了 tag,这样能反对多维度的聚合统计以及告警规定设置,大大提高了应用效率。
  • 插件对立治理:Open-Falcon 的插件机制实现了对用户自定义脚本的统一化治理,可通过 HeartBeat Server 分发给 agent,加重了使用者自主保护脚本的老本。
  • 个性化监控反对:基于 Proxy-gateway,很容易通过自主埋点实现应用层的监控(比方监控接口的访问量和耗时)和其余个性化监控需要,集成不便。
Open-Falcon 毛病
  • 监控类型较少: 不反对罕用应用服务器如 tomcat、apache、jetty 等的监控。
  • 整体倒退个别,社区活跃度低: 没有专门的运维反对,代码更新较少,没有一个较大的社区来保护,后续想要有什么新的能力根本只能指望本人扩大。

3、Prometheus(号称下一代监控零碎)

咱们晓得 zabbix 在监控界占有不可撼动的位置,功能强大。然而对容器监控显得力不从心。为解决监控容器的问题,引入了 Prometheus 技术。

Prometheus 是一套开源的系统监控报警框架。是由前 google 员工 2015 年正式公布的开源监控零碎,采纳 Go 语言开发。它不仅有一个很酷的名字,同时它有 Google 与 k8s 的强力反对,开源社区异样火爆。

先来理解下 Prometheus 的架构设计:

  • Exporter:次要用来采集数据,并通过 HTTP 服务的模式裸露给 Prometheus Server,Prometheus Server 通过拜访该 Exporter 提供的接口,即可获取到须要采集的监控数据。常见的 Exporter 有很多,例如 node_exporter、mysqld_exporter、redis_exporter 等
  • Prometheus Server:外围组件,负责实现对监控数据的获取,存储以及查问。Prometheus Server 也是一个时序数据库,它将监控数据保留在本地磁盘中,并对外提供自定义的 PromQL 语言实现对数据的查问和剖析。
  • Push gateway:因为 Prometheus 数据采集采纳 pull 形式进行设置的,内置必须保障 prometheus server 和对应的 exporter 必须通信,当网络状况无奈间接满足时,能够应用 pushgateway 来进行直达,能够通过 pushgateway 将外部网络数据被动 push 到 gateway 外面去,而 prometheus 采纳 pull 形式拉取 pushgateway 中数据。
  • Alert Manager:当反对基于 PromQL 创立告警规定,如果满足定义的规定,则会产生一条告警信息,进入 AlertManager 进行解决。能够集成邮件,微信或者通过 webhook 自定义报警。
  • Web UI:Prometheus 内置了一个简略的 web 控制台,能够查问配置信息和指标等,而理论利用中咱们通常会将 Prometheus 作为 Grafana 的数据源,创立仪表盘以及查看指标。
Prometheus 长处
  • 社区活跃度高: github start 超过 40k,且始终在保护。
  • 基于时序数据库,存储效率高:Prometheus 外围局部只有一个独自的二进制文件,不存在任何的第三方依赖(数据库,缓存等等)。惟一须要的就是 本地磁盘,因而不会有潜在级联故障的危险。
  • 很好地反对容器监控: 能主动发现容器,同时 k8s 和 etcd 等我的项目都提供了对 Prometheus 的原生反对,是目前容器监控最风行的计划。
  • 基于 Pull 模型的架构: Prometheus 基于 Pull 模型的架构形式,能够在任何中央(本地电脑,开发环境,测试环境)搭建咱们的监控零碎。
Prometheus 毛病
  • Prometheus 是基于 Metric 的监控,不适用于日志(Logs)、事件(Event)、调用链(Tracing)。
  • 因为 Prometheus 采纳的是 Pull 模型拉取数据,意味着所有被监控的 endpoint 必须是可达的,须要正当布局网络的平安配置。
  • 指标泛滥,需进行适当裁剪。

选型倡议

通过下面的介绍,大家对支流的监控零碎应该有了肯定的意识。面对选型问题,我的倡议是:

1、先明确分明你的监控需要:要监控的对象有哪些?机器数量和监控指标有多少?须要具备什么样的告警性能?

2、监控是一项长期建设的事件,一开始就想做一个 All In One 的监控解决方案,我感觉没有必要。从老本角度思考,在初期间接应用开源的监控计划即可,先解决有无问题。

3、从零碎成熟度上看,Zabbix 属于老牌的监控零碎,材料多,性能全面且稳固,如果机器数量在几百台以内,不必太放心性能问题,另外,采纳数据库分区、SSD 硬盘、Proxy 架构、Push 采集模式都能够进步监控性能。

4、Zabbix 在服务器监控方面占绝对优势,能够满足 90% 以上的监控场景,然而应用层的监控仿佛并不善于,比方要监控线程池的状态、某个外部接口的执行工夫等,这种通常都要做侵入式埋点。相同,新一代的监控零碎 Open-Falcon 和 Prometheus 在这一点做得很好。

5、从整体体现上来看,新一代监控零碎也有显著的劣势,比方:灵便的数据模型、更成熟的时序数据库、弱小的告警性能,如果之前对 zabbix 这种传统监控没有技术积攒,倡议应用 Open-Falcon 或者 Prometheus.

6、Open-Falcon 的外围劣势在于数据分片性能,能撑持更多的机器和监控项;Prometheus 则是容器监控方面的标配,有 Google 和 k8s 加持。

7、Zabbix、Open-Falcon 和 Prometheus 都反对和 Grafana 做疾速集成,想要好看且弱小的可视化体验,能够和 Grafana 进行组合。

8、用适合的监控零碎解决相应的问题即可,能够多套监控同时应用,这种在企业初期很常见。

9、到中后期,随着机器数据减少和个性化需要增多(比方心愿对立监控平台、买通公司的 CMDB 和组织架构关系),往往须要二次开发或者通过监控零碎提供的 API 做集成,从这点来看,Open-Falcon 或者 Prometheus 更适合。

10、如果非要自研,能够多钻研下支流监控零碎的架构计划,借鉴它们的劣势。


欢送退出陈某的常识星球,一起学习打卡,交换技术。退出形式,扫描下方二维码:

已在常识星球中更新如下几个专栏,详情戳链接理解):

  1. 《我要进大厂》:汇总了大厂面试考点系列、零碎架构设计、实战总结调优 ….
  2. 《亿级数据分库分表实战》文章 + 视频 的模式分享亿级数据的分库分表实战
  3. 《精尽 Spring Cloud Alibaba 系列》:Spring Cloud Alibaba 各个中间件的应用以及源码深究,残缺的案例源码分享,波及 Spring Cloud 的各个组件源码介绍
  4. 《精尽 Spring Boot 系列》:整顿了 Spring Boot 入门到源码级别的文章
  5. 《精尽 Spring 系列》:迭代了 47+ 篇文章,入门到源码级别的介绍,残缺的案例源码
  6. Java 后端相干技术的源码解说、全栈学习路线图

最初说一句(别白嫖,求关注)

陈某每一篇文章都是精心输入,曾经写了 3 个专栏,整顿成PDF,获取形式如下:

  1. 《Spring Cloud 进阶》PDF:关注公众号:【码猿技术专栏】回复关键词 Spring Cloud 进阶 获取!
  2. 《Spring Boot 进阶》PDF:关注公众号:【码猿技术专栏】回复关键词 Spring Boot 进阶 获取!
  3. 《Mybatis 进阶》PDF:关注公众号:【码猿技术专栏】回复关键词 Mybatis 进阶 获取!

如果这篇文章对你有所帮忙,或者有所启发的话,帮忙 点赞 在看 转发 珍藏,你的反对就是我坚持下去的最大能源!

退出移动版