企业级监控平台如何选择？

水深无声 2023-01-08 14:27 212阅读 0赞

*  为什么我们需要监控平台？

在公司发展的过程中，当服务器数量、项目数量、数据量、并发量等不断提升，如果没有专门的监控平台进行监控，需要运维人员24\*7的不间断关注服务器运行情况，如服务器的CPU和内存是否飙升，硬盘空间是否足够，网络环境是否畅通，更要时时刻刻关注项目是否会因为意外停机等情况，而如果由人来监控肯定是不现实的，此时我们就需要一个系统来帮助我们完成以上工作。

*  小型公司有没有必要关注监控平台呢？

监控平台的存在并不仅仅考虑到公司的整体规模，对于创业型公司可以使用Serverless的方式，只关注业务和产品，其他全部交由云服务商来监控打理，但如果公司有属于自己的服务器，并且项目，数据库等全部部署在自己的服务器上，那么合理，适当，有序的管理这些资产绝对是利大于弊的。

*  有了监控平台能给我们带来什么呢？

我觉得最切实的好处是，能让领导塌心睡个好觉，让运维人员免受提心吊胆之苦。监控平台能够实现对服务器的24\*7不间断的监控，对内存、CPU、硬盘等这些服务器常见预警信息，在达到需要告警的阈值时，及时通过钉钉、微信或者邮件的形式及时通知运维人员。此外，对于项目，能够监控项目的运行情况，包括项目中的API访问量，错误日志，JVM运行信息以及自定义监控锚点。这些都能够在项目出现情况时，让负责人立马得知具体情况然后排查解决问题，及时保障系统的稳定性。

# 一、监控平台概述 #

## 1.1 监控平台的作用 ##

正所谓「无监控，不运维」，监控系统的地位不言而喻。

不管你是监控系统的开发者还是使用者，首先肯定要清楚：监控系统的目标是什么？它能发挥什么作用？

*  **实时采集监控数据**：包括 硬件、操作系统、中间件、应用程序等各个维度的数据。
 *  **实时反馈监控状态**：通过对采集的数据进行多维度统计和可视化展示，能实时体现监控对象的状态是正常还是异常。
 *  **预知故障和告警：** 能够提前预知故障风险，并及时发出告警信息。
 *  **辅助定位故障**：提供故障发生时的各项指标数据，辅助故障分析和定位。
 *  **辅助性能调优**：为性能调优提供数据支持，比如慢SQL，接口响应时间等。
 *  **辅助容量规划**：为服务器、中间件以及应用集群的容量规划提供数据支撑。
 *  **辅助自动化运维**：为自动扩容或者根据配置的SLA进行服务降级等智能运维提供数据支撑。

## 1.2 监控的对象和指标都有哪些？ ##

监控已然成为了整个产品生命周期非常重要的一环，运维关注硬件和基础监控，研发关注各类中间件和应用层的监控，产品关注核心业务指标的监控。 可见，监控的对象已经越来越立体化。

这里，我对常用的监控对象以及监控指标做了分类整理，供大家参考。

**1 硬件监控**

包括：电源状态、CPU状态、机器温度、风扇状态、物理磁盘、raid状态、内存状态、网卡状态

**2 服务器基础监控**

*  CPU：单个CPU以及整体的使用情况
 *  内存：已用内存、可用内存
 *  磁盘：磁盘使用率、磁盘读写的吞吐量
 *  网络：出口流量、入口流量、TCP连接状态

**3 数据库监控**

包括：数据库连接数、QPS、TPS、并行处理的会话数、缓存命中率、主从延时、锁状态、慢查询

**4 中间件监控**

*  Nginx：活跃连接数、等待连接数、丢弃连接数、请求量、耗时、5XX错误率
 *  Tomcat：最大线程数、当前线程数、请求量、耗时、错误量、堆内存使用情况、GC次数和耗时
 *  缓存 ：成功连接数、阻塞连接数、已使用内存、内存碎片率、请求量、耗时、缓存命中率
 *  消息队列：连接数、队列数、生产速率、消费速率、消息堆积量

**5 应用监控**

*  HTTP接口：URL存活、请求量、耗时、异常量
 *  RPC接口：请求量、耗时、超时量、拒绝量
 *  JVM ：GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数
 *  线程池：活跃线程数、任务队列大小、任务执行耗时、拒绝任务数
 *  连接池：总连接数、活跃连接数
 *  日志监控：访问日志、错误日志
 *  业务指标：视业务来定，比如PV、订单量等

## 1.3 监控目标 ##

先来了解什么是监控，监控的重要性以及监控的目标，当然每个人所在的行业不同、公司不同、业务不同、岗位不同、对监控的理解也不同，但是我们需要注意，监控是需要站在公司的业务角度去考虑，而不是针对某个监控技术的使用。

1.  对系统不间断实时监控:实际上是对系统不间断的实时监控(这就是监控)
2.  实时反馈系统当前状态:我们监控某个硬件、或者某个系统，都是需要能实时看到当前系统的状态，是正常、异常、或者故障
3.  保证服务可靠性安全性:我们监控的目的就是要保证系统、服务、业务正常运行
4.  保证业务持续稳定运行:如果我们的监控做得很完善，即使出现故障，能第一时间接收到故障报警，在第一时间处理解决，从而保证业务持续性的稳定运行。

# 二、开源监控系统介绍 #

**老牌监控:**

*  MRTG（Multi Route Trffic Grapher）是一套可用来绘制网络流量图的软件，由瑞士奥尔滕的Tobias Oetiker与Dave Rand所开发，以GPL授权。  
    MRTG最好的版本是1995年推出的，用perl语言写成，可跨平台使用，数据采集用SNMP协议，MRTG将手机到的数据通过Web页面以GIF或者PNG格式绘制出图像。
 *  Grnglia是一个跨平台的、可扩展的、高性能的分布式监控系统，如集群和网格。它基于分层设计，使用广泛的技术，用RRDtool存储数据。具有可视化界面，适合对集群系统的自动化监控。其精心设计的数据结构和算法使得监控端到被监控端的连接开销非常低。目前已经有成千上万的集群正在使用这个监控系统，可以轻松的处理2000个节点的集群环境。
 *  Cacti（英文含义为仙人掌）是一套基于PHP、MySQL、SNMP和RRDtool开发的网络流量监测图形分析工具，它通过snmpget来获取数据使用RRDtool绘图，但使用者无须了解RRDtool复杂的参数。提供了非常强大的数据和用户管理功能，可以指定每一个用户能查看树状结构、主机设备以及任何一张图，还可以与LDAP结合进行用户认证，同时也能自定义模板。在历史数据展示监控方面，其功能相当不错。  
    Cacti通过添加模板，使不同设备的监控添加具有可复用性，并且具备可自定义绘图的功能，具有强大的运算能力（数据的叠加功能）
 *  Nagios是一个企业级监控系统，可监控服务的运行状态和网络信息等，并能监视所指定的本地或远程主机状态以及服务，同时提供异常告警通知功能等。  
    Nagios可运行在Linux和UNIX平台上。同时提供Web界面，以方便系统管理人员查看网络状态、各种系统问题、以及系统相关日志等  
    Nagios的功能侧重于监控服务的可用性，能根据监控指标状态触发告警。  
    目前Nagios也占领了一定的市场份额，不过Nagios并没有与时俱进，已经不能满足于多变的监控需求，架构的扩展性和使用的便捷性有待增强，其高级功能集成在商业版Nagios XI中。
 *  Smokeping主要用于监视网络性能，包括常规的ping、www服务器性能、DNS查询性能、SSH性能等。底层也是用RRDtool做支持，特点是绘制图非常漂亮，网络丢包和延迟用颜色和阴影来标示，支持将多张图叠放在一起，其作者还开发了MRTG和RRDtll等工具。  
    Smokeping的站点为：http://tobi.oetiker.cn/hp

开源监控系统OpenTSDB用Hbase存储所有时序（无须采样）的数据，来构建一个分布式、可伸缩的时间序列数据库。它支持秒级数据采集，支持永久存储，可以做容量规划，并很容易地接入到现有的告警系统里。  
OpenTSDB可以从大规模的集群（包括集群中的网络设备、操作系统、应用程序）中获取相应的采集指标，并进行存储、索引和服务，从而使这些数据更容易让人理解，如Web化、图形化等。

目前开源的新一代监控系统有很多，使用比较广泛的应该是Prometheus，Zabbix，所以下面会对这两个进行重点分析。

# 三、Prometheus与Zabbix的对比 #

<table> 
 <thead> 
  <tr> 
   <th>对比项</th> 
   <th>Prometheus</th> 
   <th>Zabbix</th> 
   <th>Prometheus优势</th> 
   <th>Zabbix优势</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>管理</td> 
   <td>二进制文件启动</td> 
   <td>LNMP+编译</td> 
   <td>轻量级Server，便于迁移和维护</td> 
   <td>-</td> 
  </tr> 
  <tr> 
   <td>配置</td> 
   <td>配置文件</td> 
   <td>图形化</td> 
   <td>更好的支持自动化配置</td> 
   <td>学习成本低</td> 
  </tr> 
  <tr> 
   <td>client</td> 
   <td>丰富的client库</td> 
   <td>zabbix_agent自定义脚本</td> 
   <td>为各种中间件、应用提供专业的exporter，监控项更全面</td> 
   <td>支持自定义监控项，对监控设计者的格局要求较高</td> 
  </tr> 
  <tr> 
   <td>数据存储方式</td> 
   <td>Prometheus TSDB</td> 
   <td>MySQL</td> 
   <td>监控数据以时间为维度统计情况较多，时序数据库更适用于监控数据的存储，按时间索引性能更高</td> 
   <td>MySQL较常用，学习成本低</td> 
  </tr> 
  <tr> 
   <td>数据处理</td> 
   <td>PromQL</td> 
   <td>MySQL</td> 
   <td>PromQL计算函数丰富，统计维度广</td> 
   <td>同上</td> 
  </tr> 
  <tr> 
   <td>二次开发</td> 
   <td>丰富的sdk</td> 
   <td>API</td> 
   <td>提供了GO、Java/Scala、Python、Ruby等SDK，二次开发更便捷</td> 
   <td>API适配较为常用，学习成本低</td> 
  </tr> 
  <tr> 
   <td>对云环境的支持</td> 
   <td>原生支持容器监控</td> 
   <td>更适合物理机监控</td> 
   <td>自动发现容器，更好的适配k8x</td> 
   <td>-</td> 
  </tr> 
  <tr> 
   <td>告警方式</td> 
   <td>可按照标签分组，收敛</td> 
   <td>在次数上收敛</td> 
   <td>告警收敛方式多样化</td> 
   <td>-</td> 
  </tr> 
  <tr> 
   <td>监控项值</td> 
   <td>支持数字</td> 
   <td>支持数字字符串</td> 
   <td>-</td> 
   <td>可做日志监控</td> 
  </tr> 
 </tbody> 
</table>

*  Zabbix更适合于物理机/虚拟机的监控。
 *  Prometheus更适合容器的监控，对于目前来说，大部分都是Docker或者K8s容器，如果公司所在逐渐往容器方向发展，建议采用Prometheus。

## 3.1 架构对比 ##

### 1. Prometheus ###

Prometheus的基本原理是通过HTTP周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口并且符合Prometheus定义的数据格式，就可以接入Prometheus监控。

Prometheus Server负责定时在目标上抓取metrics（指标）数据并保存到本地存储里面。Prometheus采用了一种Pull（拉）的方式获取数据，不仅降低客户端的复杂度，客户端只需要采集数据，无需了解服务端情况，而且服务端可以更加方便的水平扩展。

如果监控数据达到告警阈值Prometheus Server会通过HTTP将告警发送到告警模块alertmanger，通过告警的抑制后触发邮件或者webhook。Prometheus支持PromQL提供多维度数据模型和灵活的查询，通过监控指标关联多个tag的方式，将监控数据进行任意维度的组合以及聚合。

### 2. Zabbix ###

zabbix由2部分构成，zabbix server与可选组件zabbix agent。zabbix server可以通过SNMP，zabbix agent，ping，端口监视等方法提供对远程服务器/网络状态的监视，数据收集等功能，它可以运行在Linux，Solaris，HP-UX，AIX，Free BSD，Open BSD，OS X等平台上。

核心组件主要是Agent和Server，其中Agent主要负责采集数据并通过主动或者被动的方式采集数据发送到Server/Proxy，除此之外，为了扩展监控项，Agent还支持执行自定义脚本。Server主要负责接收Agent发送的监控信息，并进行汇总存储，触发告警等。Zabbix Server将收集的监控数据存储到Zabbix Database中。Zabbix Database支持常用的关系型数据库，如果MySQL、PostgreSQL、Oracle等，默认是MySQL，并提供Zabbix Web页面（PHP编写）数据查询。

Zabbix由于使用了关系型数据存储时序数据，所以在监控大规模集群时常常在数据存储方面捉襟见肘。所以从Zabbix 4.2版本后开始支持TimescaleDB时序数据库，不过目前成熟度还不高。

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>发行时间</th> 
   <th>开发语言</th> 
   <th>性能</th> 
   <th>社区支持</th> 
   <th>容器支持</th> 
   <th>企业使用</th> 
   <th>部署难度</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Prometheus</td> 
   <td>2016</td> 
   <td>go</td> 
   <td>支持万为单位</td> 
   <td>目前来说，应该很活跃了</td> 
   <td>不仅支持swarm原生集群，还支持K8s容器集群的监控，是目前容器监控最好解决方案</td> 
   <td>基本上使用k8s容器的企业，都选用Prometheus</td> 
   <td>只有一个核心server组件，一条命令便可以启动</td> 
  </tr> 
  <tr> 
   <td>zabbix</td> 
   <td>2012</td> 
   <td>c+php</td> 
   <td>上限约1000节点</td> 
   <td>虽然成熟，但目前活跃度应该不如prometheus高</td> 
   <td>zabbix出现较早，当时没有容器，对容器的支持较差</td> 
   <td>对于传统监控系统，尤其是服务器级别和虚拟器级别监控，占据优势</td> 
   <td>多种系统，多种监控采集方式</td> 
  </tr> 
 </tbody> 
</table>

## 3.2 二者差异解析 ##

### 1. 图形化还是配置文件 ###

Zabbix 的图形化配置毫无疑问是完爆 Prometheus 的，但这真的是个优势吗？

细想起来还真未必。图形化确实省去了手动改配置文件和命令行的繁琐，但这种努力毫无疑问是已经做出了需要人工介入的假设。但 Prometheus 是为云原生环境而生的，这种情况下，环境是动态变化的，服务器会随时增减，人工介入不太现实，那么图形化在这种情况下意义就不大了，毕竟要做自动化，那就不必要过图形界面这一道了。这么看来 Prometheus 在图形化方面的简约也是有意的取舍。

### 2. 时序数据库还是关系型数据库 ###

近几年兴起的监控系统大部分都选择了将数据存储在时序型数据库中，Prometheus 用的就是自研的 TSDB，Zabbix 则用的是 MySQL 或 PostgreSQL。对于时序型数据库我了解不多，粗浅的来看，Prometheus 的时序型数据库在高并发的情况下，读写性能是远高过传统的关系型数据库的，另外还提供了很多内置的基于时间的处理函数，简化数据聚合的难度。也许这不能简单的理解为两种数据库的特性造成的结果，但至少说明，对专门监控场景进行存储优化，是十分必要的。

### 3. 服务发现 ###

Prometheus 在收集数据时，采用的 Pull 模型（服务端主动去客户端拉取数据），而以 Zabbix 为代表的传统监控采用的 Push 模型（客户端发送数据给服务端）。Pull 模型在云原生环境中有比较大的优势，原因是分布式系统中，一定是有中心节点知道整个集群信息的，那么通过中心节点就可以完成所有要监控节点的服务发现，去拉取数据就好了；Push 模型倒是省去了服务发现的步骤，但每个被监控的服务都需要内置客户端，还需要配置监控服务端的信息，这加大了部署的难度，Push 模型在 OpenStack 和 Kubernetes 等环境中用的不多。

### 4. 开发语言 ###

Golang 和 C 语言的开发对比，这就不用多解释了，不是一个时代的语言，Golang 占绝对优势。PHP 写界面倒是很常规的选择，但无奈 Grafana 写界面都不用编程语言，**JSON** 和 **YAML** 就可以搞定。所以真的要做定制开发，Prometheus 的难度要小很多。

# 四、其他一些开源的监控平台解决方案 #

*  Nightingale
 *  官网地址：https://n9e.didiyun.com/

> 夜莺（Nightingale）是一个企业级监控解决方案。旨在满足云原生时代企业级的监控需求。Nightingale 在产品完成度、系统高可用、以及用户体验方面，达到了企业级的要求，可满足不同规模用户的场景，小到几台服务，大到数十万都可以完美支撑。兼顾云原生和裸金属，支持应用监控和系统监控，插件机制灵活，插件丰富完善，具有高度的灵活性和可扩展性。
> 
> Nightingale 在 [Open-Falcon][] 的基础上，结合滴滴内部的最佳实践，在性能、可维护性、易用性方面做了大量的改进，作为集团统一的监控解决方案，支撑了滴滴内部数十亿监控指标，覆盖了从系统、容器、到应用等各层面的监控需求，周活跃用户数千。五年磨一剑，取之开源，回馈开源。

*  Xrkmonitor
 *  官网地址：http://xrkmonitor.com/

> 集监控点监控、日志监控、数据可视化及监控告警为一体的分布式开源监控系统。  
> 通过插件方式支持常用监控需求，插件可自由选择且支持一键部署、移除、启用、禁用等操作。  
> 提供丰富的图表和多种数据类型，满足对数据可视化的需要。  
> 在线演示版地址：[http://open.xrkmonitor.com][http_open.xrkmonitor.com]

> 部分内容参考地址：https://www.cnblogs.com/luojunwu/p/13952318.html

*  个人网站：https://www.lovebetterworld.com/
 *  往后余生，只想分享一些干货，分享一些工作，学习当中的笔记、总结，并帮助需要帮助的任何人，关注我，大家一起来学习吧！

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FuMTA5MDIzOTc4Mg_size_16_color_FFFFFF_t_70_pic_center]

[Open-Falcon]: https://github.com/open-falcon
[http_open.xrkmonitor.com]: http://open.xrkmonitor.com/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0FuMTA5MDIzOTc4Mg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221119/eae0152f9d424c50a2d869f3a97a9050.png