一篇吃透监控系统:主流工具选型及落地场景参考

一篇吃透监控系统:主流工具选型及落地场景参考

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

  • 必知必会的监控基础知识
  • 主流监控系统介绍
  • 监控系统的选型建议

一、必知必会的监控基础知识

我们可以理解监控系统就像我们古代打战的哨兵一样,哨兵的角色非常重要,敌人来了,哨兵会第一时间发出预警(吹笛、打鼓、放烟),让守城的战士能够最快的时间处理,应对。

那对于我们应用系统而言,监控系统就像我们第三只眼,如果有应用系统出现问题,我们可以通过监控系统看是哪里出现问题,是redis挂了,还是说服务器内存满了,有监控系统我们可以很轻松、快速的定位问题。

甚至我们可以设置预警,对一些将要出现的问题进行提前预防处理,及时避免问题的发生。

1、监控系统的作用

一篇吃透监控系统:主流工具选型及落地场景参考

1)帮助定位故障

在发生故障时,我们可以通过查看监控系统的各项指标数据,辅助故障分析和定位。

2)预警减少故障率

对于即将可能产生的故障能够及时发出预警信息,做好提前预防处理。

3)辅助容量规划

为服务器、中间件以及应用集群的容量规划提供数据支撑。

4)辅助性能调优

JVM垃圾回收次数、接口响应时间、慢SQL等等都可以监控优化。

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

一篇吃透监控系统:主流工具选型及落地场景参考

1)服务器监控

CPU使用率、内存使用率、磁盘使用率、磁盘读写的吞吐量、网络出入流量等等。

2)MySQL监控

TPS、QPS、数据库连接数、慢SQL、InnoDB缓冲池命中率等等。

3)Redis监控

内存使用率、缓存命中率、key值总数、Redis响应请求时间、客户端连接数、持久性指标等等。

4)MQ监控

连接数、队列数、生产速率、消费速率、消息堆积量等等。

5)应用监控

  • HTTP接口:URL存活、请求量、耗时、异常量。
  • JVM :GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数。
  • 线程池:活跃线程数、任务队列大小、任务执行耗时、拒绝任务数。

3、监控系统的基本流程

一篇吃透监控系统:主流工具选型及落地场景参考

1)数据采集

采集的方式有很多种,包括日志埋点进行采集,JMX标准接口输出监控指标,被监控对象提供REST API进行数据采集(如Hadoop、ES),系统命令行,统一的SDK进行侵入式的埋点和上报等。

2)数据传输

将采集的数据以TCP、UDP或者HTTP协议的形式上报给监控系统,有主动Push模式,也有被动Pull模式。

3)数据存储

有使用MySQL、Oracle等关系数据库存储的,也有使用时序数据库RRDTool、OpentTSDB、InfluxDB存储的,还有使用HBase存储的。

4)数据展示

数据指标的图形化展示。

5)监控告警

灵活的告警设置,以及支持邮件、短信、IM等多种通知通道。

二、市面上的一些常见监控系统比较

下面再来认识下主流的开源监控系统,由于篇幅有限,我挑选了3款使用最广泛的监控系统:Zabbix、Open-Falcon、Prometheus,会对它们的架构进行介绍,同时总结下各自的优劣势。

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编写,提供监控数据的展现和告警配置。

1)Zabbix的优势

  • 产品成熟

由于诞生时间长且使用广泛,拥有丰富的文档资料以及各种开源的数据采集插件,能覆盖绝大部分监控场景。

  • 采集方式丰富

支持Agent、SNMP、JMX、SSH等多种采集方式,以及主动和被动的数据传输方式。

2)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中查询指标数据,汇总结果后统一返回给用户,屏蔽了存储集群的分片细节。

1)Open-Falcon优势

  • 自动采集能力

Falcon-agent 能自动采集服务器的200多个基础指标(比如CPU、内存等),无需在server上做任何配置,这一点可以秒杀Zabbix.

  • 强大的存储能力

底层采RRDTool,并且通过一致性hash进行数据分片,构建了一个分布式的时序数据存储系统,可扩展性强。

  • 灵活的数据模型

借鉴OpenTSDB,数据模型中引入了tag,这样能支持多维度的聚合统计以及告警规则设置,大大提高了使用效率。

  • 插件统一管理

Open-Falcon的插件机制实现了对用户自定义脚本的统一化管理,可通过HeartBeat Server分发给agent,减轻了使用者自主维护脚本的成本。

  • 个性化监控支持

基于Proxy-gateway,很容易通过自主埋点实现应用层的监控(比如监控接口的访问量和耗时)和其他个性化监控需求,集成方便。

2)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的数据源,创建仪表盘以及查看指标。

1)Prometheus优点

  • 社区活跃度高

github start超过40k,且一直在维护。

  • 基于时序数据库,存储效率高

Prometheus核心部分只有一个单独的二进制文件,不存在任何的第三方依赖(数据库,缓存等等)。唯一需要的就是 本地磁盘,因此不会有潜在级联故障的风险。

  • 很好地支持容器监控

能自动发现容器,同时k8s和etcd等项目都提供了对Prometheus的原生支持,是目前容器监控最流行的方案。

  • 基于Pull模型的架构

Prometheus基于Pull模型的架构方式,可以在任何地方(本地电脑,开发环境,测试环境)搭建我们的监控系统。

2)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 原创文章作者:7033,如若转载,请注明出处: https://www.52hwl.com/103606.html

 2 温馨提示:软件侵权请联系469472785#qq.com(三天内删除相关链接)资源失效请留言反馈

 3 下载提示:如遇蓝奏云无法访问,请修改lanzous(把s修改成x)

 免责声明:本站为个人博客,所有软件信息均来自网络 修改版软件,加群广告提示为修改者自留,非本站信息,注意鉴别

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2024年1月17日 下午6:44
下一篇 2024年1月17日 下午6:45