浅析主流监控告警系统基本架构和原理

一，监控系统的作用和目前主流监控系统

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模式的特点
  1. 被监控方提供一个server，并负责维护,pull 不到数据本身就说明了节点存在故障；又比如监控指标自然而言由用户自己维护，使得标准化很简单。
  2. 监控方控制采集频率,缺点也很明显，用户不知道你什么时候来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 协议主动拉取获得的。
• 也可以通过中间网关来推送时间序列数据
• 可以通过静态配置文件或服务发现来获取监控目标。
• 支持多种类型的图表和仪表盘。

五，总结

从原理来说，监控告警系统都是大同小异的，真正实际应用到公司中，需要结合公司实际，进行具体情况分析，一通百通