一,监控系统的作用和目前主流监控系统
1,作用:监控系统一般有以下这几个作用
- 实时采集监控数据:包括硬件、操作系统、中间件、应用程序等各个维度的数据。
- 实时反馈监控状态:通过对采集的数据进行多维度统计和可视化展示,能实时体现监控对象的状态是正常还是异常。
- 预知故障和告警:能够提前预知故障风险,并及时发出告警信息。
- 辅助定位故障:提供故障发生时的各项指标数据,辅助故障分析和定位。
- 辅助容量规划:为服务器、中间件以及应用集群的容量规划提供数据支撑。
- 辅助自动化运维:为自动扩容或者根据配置的SLA进行服务降级等智能运维提供数据支撑。
对于监控的数据,一般也会有如下:
-
硬件监控
- 包括:电源状态、CPU状态、机器温度、风扇状态、物理磁盘、raid状态、内存状态、网卡状态
-
服务器基础监控
-
CPU:单个CPU以及整体的使用情况
-
内存:已用内存、可用内存
-
磁盘:磁盘使用率、磁盘读写的吞吐量
-
网络:出口流量、入口流量、TCP连接状态
-
-
数据库监控
- 包括:数据库连接数、QPS、TPS、并行处理的会话数、缓存命中率、主从延时、锁状态、慢查询
-
中间件监控
-
Nginx:活跃连接数、等待连接数、丢弃连接数、请求量、耗时、5XX错误率
-
Tomcat:最大线程数、当前线程数、请求量、耗时、错误量、堆内存使用情况、GC次数和耗时
-
缓存 :成功连接数、阻塞连接数、已使用内存、内存碎片率、请求量、耗时、缓存命中率
-
消息队列:连接数、队列数、生产速率、消费速率、消息堆积量
-
-
应用监控
-
HTTP接口:URL存活、请求量、耗时、异常量
-
RPC接口:请求量、耗时、超时量、拒绝量
-
线程池:活跃线程数、任务队列大小、任务执行耗时、拒绝任务数
-
连接池:总连接数、活跃连接数
-
日志监控:访问日志、错误日志
-
业务指标:视业务来定,比如PV、订单量等
-
2,目前主流的监控系统:
当前主流的监控系统有zabbix,open-falcon,prometheus,bosun等等
-
从最终数据的存储源头(最终如何收集到一个聚拢的数据中心)上来说,监控系统可分为拉模式,和推模式,zabbix,open-falcon都是采用推模式的,和promethues则是采用拉模式来进行数据采集。
- 顾名思义,推模式是将所有数据往数据中心推,拉模式则是将数据中心将所有数据拉到自己身上。
-
Pull模式的特点
- 被监控方提供一个server,并负责维护,pull 不到数据本身就说明了节点存在故障;又比如监控指标自然而言由用户自己维护,使得标准化很简单。
- 监控方控制采集频率,缺点也很明显,用户不知道你什么时候来pull一下,数据维护多久更新也不好控制,容易造成一些信息的丢失和不准确。
-
push模式的特点:
-
在正常情况下数据的延迟可以做到更低,也就是能更快的获取metrics并发现问题。
-
增加了服务的实现复杂度(比如推送错误处理等);不利于平行扩展;不支持自定义metrics采集策略,比如高峰期减少采集频率。
-
二,zabbix监控系统
(1)介绍:老牌监控系统,一体化,核心组件用C语言,web端采用php。目前已经很少有人使用
(2)架构:
(3)组件:
- Zabbix Server:核心组件,C语言编写,负责接收Agent、Proxy发送的监控数据,也支持JMX、SNMP等多种协议直接采集数据。同时,它还负责数据的汇总存储以及告警触发等。
- Zabbix Proxy:故名思义,server的代理,若监控机器较多,可传到proxy上,再传到server的形式来实现数据的采集。
- Zabbix Agentd:部署在被监控主机上,用于采集本机的数据并发送给Proxy或者Server,它的插件机制支持用户自定义数据采集脚本。Agent可在Server端手动配置,也可以通过自动发现机制被识别。数据收集方式同时支持主动Push和被动Pull两种模式(注意,这里的agent从普遍上来说肯定都是支持推拉模式的,因为是分布到各个服务器上的;总体的推拉模式指的数据中心的采集)
- Database:用于存储配置信息以及采集到的数据,之前只支持MySQL、Oracle等关系型数据库。但最新版本的Zabbix已经开始支持时序数据库,不过成熟度还不高。
- Web Server:Zabbix的GUI组件,PHP编写,提供监控数据的展现和告警配置
(4)从架构上来看,zabbix的设计还是很简单的,作为老一代的监控系统有它的意义,但实际上也有它自身的很多缺点,如:
- 性能瓶颈:机器量或者业务量大了后,关系型数据库的写入一定是瓶颈,官方给出的单机上限是5000台,个人感觉达不到,尤其现在应用层的指标越来越多。虽然最新版已经开始支持时序数据库,不过成熟度还不高。
- 应用层监控支持有限:如果想对应用程序做侵入式的埋点和采集(比如监控线程池或者接口性能),zabbix没有提供对应的sdk,通过插件式的脚本也能曲线实现此功能,个人感觉zabbix就不是做这个事的。
- 数据模型不强大:不支持tag,因此没法按多维度进行聚合统计和告警配置,使用起来不灵活。
- 方便二次开发难度大:Zabbix采用的是C语言,二次开发往往需要熟悉它的数据表结构,基于它提供的API更多只能做展示层的定制。
三,open-falcon监控系统
(1)介绍:Open-falcon 是小米2015年开源的企业级监控工具,采用Go和Python语言开发,这是一款灵活、高性能且易扩展的新一代监控方案,目前小米、美团、滴滴等超过200家公司在使用它。
(2)架构:
(3)
- Falcon-agent:数据采集器和收集器,Go开发,部署在被监控的机器上,支持3种数据采集方式。能自动采集单机200多个基础监控指标,无需做任何配置;同时支持用户自定义的plugin获取监控数据;此外,用户可通过http接口,自主push数据到本机的proxy-gateway,由gateway转发到server.
- Transfer:数据分发组件,接收客户端发送的数据,分别发送给数据存储组件Graph和告警判定组件Judge,Graph和Judge均采用一致性hash做数据分片,以提高横向扩展能力。同时Transfer还支持将数据分发到OpenTSDB,用于历史归档。
- Graph:数据存储组件,底层使用RRDTool(时序数据库)做单个指标的存储,并通过缓存、分批写入磁盘等方式进行了优化。据说一个graph实例能够处理8W+每秒的写入速率。
- Judge和Alarm:告警组件,Judge对Transfer组件上报的数据进行实时计算,判断是否要产生告警事件,Alarm组件对告警事件进行收敛处理后,将告警消息推送给各个消息通道。
- API:面向终端用户,收到查询请求后会去Graph中查询指标数据,汇总结果后统一返回给用户,屏蔽了存储集群的分片细节。
- Heartbeat Server:
agent
发送心跳信息给HBS
的时候,会把hostname、ip、agent version、plugin version等信息告诉HBS
,HBS
负责更新host表。将IP白名单分发到所有的agent。告诉各个agent应该执行哪些插件。类似于服务发现中心 - Nodata:用于检测监控数据的上报异常。nodata和实时报警judge模块协同工作,过程为: 配置了nodata的采集项超时未上报数据,nodata生成一条默认的模拟数据;用户配置相应的报警策略,收到mock数据就产生报警。采集项上报异常检测,作为judge模块的一个必要补充,能够使judge的实时报警功能更加可靠、完善。
- Aggreagator:集群聚合模块。聚合某集群下的所有机器的某个指标的值,提供一种集群视角的监控体验。
- Dashboard:前端界面,用python编写
四,Prometheus监控系统
(1)prometheus作为一个是由前 Google 工程师从 2012 年开始在 Soundcloud 以开源软件的形式进行研发的系统监控和告警工具包,自此以后,许多公司和组织都采用了 Prometheus 作为监控告警工具。Prometheus 的开发者和用户社区非常活跃,它现在是一个独立的开源项目,可以独立于任何公司进行维护。为了证明这一点,Prometheus 于 2016 年 5 月加入 CNCF 基金会,成为继成为继 Kubernetes 之后的第二个 CNCF 托管项目。
从应用上上来说,prometheus可谓是十分契合目前的容器化后的微服务的监控,可谓是容器监控方面的标配
(2)架构:
-
Prometheus Server:核心组件,用于收集、存储监控数据。它同时支持静态配置和通过Service Discovery动态发现来管理监控目标,并从监控目标中获取数据。此外,Prometheus Server 也是一个时序数据库,它将监控数据保存在本地磁盘中,并对外提供自定义的 PromQL 语言实现对数据的查询和分析。
-
Exporter:用来采集数据,作用类似于agent,区别在于Prometheus是基于Pull方式拉取采集数据的,因此,Exporter通过HTTP服务的形式将监控数据按照标准格式暴露给Prometheus Server,社区中已经有大量现成的Exporter可以直接使用,用户也可以使用各种语言的client library自定义实现。
-
Push gateway:主要用于瞬时任务的场景,防止Prometheus Server来pull数据之前此类Short-lived jobs就已经执行完毕了,因此job可以采用push的方式将监控数据主动汇报给Push gateway缓存起来进行中转。
-
Alert Manager:当告警产生时,Prometheus Server将告警信息推送给Alert Manager,由它发送告警信息给接收方。
-
Web UI:Prometheus内置了一个简单的web控制台,可以查询配置信息和指标等,而实际应用中我们通常会将Prometheus作为Grafana的数据源,创建仪表盘以及查看指标。
(3)特点介绍:
- 由指标名称和和键/值对标签标识的时间序列数据组成的多维数据模型
- 强大的查询语言 PromQL
- 不依赖分布式存储;单个服务节点具有自治能力。
- 时间序列数据是服务端通过 HTTP 协议主动拉取获得的。
- 也可以通过中间网关来推送时间序列数据
- 可以通过静态配置文件或服务发现来获取监控目标。
- 支持多种类型的图表和仪表盘。
五,总结
从原理来说,监控告警系统都是大同小异的,真正实际应用到公司中,需要结合公司实际,进行具体情况分析,一通百通