曩昔20年开源的或许商业的监控体系许多，详细能够参阅维基百科的条目。一个完好的监控体系，往简略了讲，首要包含三个首要部分：数据搜集、告警、数据图表展现。咱们环绕这三个方面，对其中12款典型的开源东西做一些介绍和剖析。

1. Cacti

引荐指数： ⭐ ⭐

Cacti，最悠久的监控体系之一，2001年9月，一个名叫Lan Berry的高中生，当时他还在为一家小的ISP厂商作业，为了更好地监控网络质量，开发了Cacti的榜首个版别，依据RRDtool，供给更友爱的运用体验。

Cacti的数据搜集，选用的是Server端poll的方法，在默许装置状况下，会有一个PHP的Poller，来守时履行相关的数据搜集脚本，或许直接搜集SNMP的接口输出，搜集到的数据会以RRDtool的格局存储到磁盘上，供后续绘图、展现。在要搜集的数据较多的状况下，PHP版别的Poller功率较低。为了处理这个问题，Cacti官方供给了一个组件Spine（早期叫Cactid），这是一个用C言语编写的多线程程序，用来替代PHP版别的Poller，有用地提高了数据搜集功率。用户能够在Cacti供给的设备办理页，对设备列表进行增、删、改操作，来操控Poller要拉取的使命。

Cacti的数据图表展现，底层是依据RRDtool的，Cacti供给了一个用PHP开发的页面，能够让用户很便利地查看每个数据搜集项的前史趋势图。Cacti供给了一个树状的graph列表，便运用户高效地安排、办理多个graph。别的，Cacti的graph预览功用很强壮，答应在一个页面中放置许多的graph预览图，便于用户了解其所重视的目标全貌。

Cacti之所以很强壮，原因在于其强壮的插件。比方aggregate插件能够对多个搜集项进行聚合展现，discovery插件用来主动发现设备，thold插件用来装备告警战略，slowlog插件能够便利地用来剖析MySQL的慢查询等。完好的插件列表能够在docs.Cacti.net/plugins 查看，包含官方支撑的和社区支撑的。

2. RRDtool

引荐指数： ⭐ ⭐

RRDtool，在时刻序列数据（time-series data）的存储、展现方面，其独创的round-robin database数据存储格局，曾经是事实上的工业规范。包含Cacti、MRTG、Collectd、Ganglia、Zenoss等体系，都是选用RRDtool的格局来存储数据，以及运用RRDtool的Graph东西来绘图的。

RRDtool运用的数据存储格局，大家也常常称之为环状数据库，其作业方法有三个明显的特色：榜首，RRD文件在创立的时分，其文件巨细就确认下来了，跟着数据的不断写入，RRD文件的巨细一向坚持不变；第二，数据每次更新到RRD文件的时分，都会触发RRD文件中的归档战略，也便是数据采样战略；第三，查询前史数据的时分，会主动挑选最优化的采样数据，而不是全量获取数据，查询功率很高。

RRDtool包含了一组东西集，用于创立RRD文件，更新RRD文件，获取RRD文件中的数据，依据RRD文件直接生成相应的图片等，详细能够参阅oss.oetiker.ch/rrdtool。

运用RRDtool的进程中遇到过一些问题，RRDtool的数据是以文件的方法存储在磁盘上，以单机的方法来供给服务的，这样就存在容量上限。该上限的决定要素较多，比方磁盘容量、磁盘IO、CPU等，可是最中心的约束要素便是磁盘IO，用户每push一次数据，都会转化为对相应的RRD文件的一些全量的读/写，磁盘IO会最早遇到瓶颈。在一台普通的Linux服务器上，在1分钟push数据的频率下，一般20万条的Counter上报就会跑满磁盘IO。这显然无法满意较大规划数据下的监控需求。

为了在必定程度上缓解磁盘IO压力的问题，RRDtool官方供给了一个组件rrdcached，这是一个常驻内存的后台程序，用户能够把读/写恳求经过网络发送给rrdcached，而不是直接操作磁盘。rrdcached内部做了一些优化措施来减轻对磁盘的读/写压力，包含：缓存RRD文件的header部分，每次数据push上来的时分能够削减一次读取操作；对RRD文件的写入，供给了用户态的缓存，即把用户的多次写入操作合并成一次flush到磁盘上，这样有用地提高了写入功率。经过该项优化，使得单机的容量提高不少。 不过上述优化，也只能处理必定程度上的问题，整体容量依然局限于单机的容量上限。

3. Collectd

引荐指数： ⭐ ⭐ ⭐

Collectd比较Cacti、RRDtool来说，较为年青一些，项目最早是在2005年由Florian Forster开发的，之后便蓬勃发展成为一个开源的项目，许多开发者对其做了许多的改善和扩展。Collectd的定位是搜集和传输数据。在告警方面不是Collectd的规划初衷，不过它也支撑一些简略的阈值断定，并发送告警信息。要支撑更高档的一些告警需求，Collectd能够和Nagios合作运用，有一个名为collectd-nagios 的插件能够很便利地完结这个功用。

Collectd是一个用C言语开发的常驻内存的程序，由一堆功用强壮的插件组成，其架构示意图如图1所示。

二十年里12个开源监控工具大对比

插件化是Collectd最重要的一个规划思维，Collectd的一切功用都是经过插件来支撑的，Collectd自身没有任何额定的依靠，这使得它简直能够跑在大多数的操作体系上，包含一些嵌入式体系如OpenWrt。从图1来看，用户能够经过各种插件push数据到Collectd，然后经过RRDtool插件存储为RRD的格局，或许经过CSV插件存储为CSV的格局。Collectd支撑的上百个插件，能够在该列表中查阅。

4. Nagios

引荐指数： ⭐ ⭐

前面讲到的几个体系，都专心于数据的搜集、传输、聚合、存储和展现。说到告警，Nagios可谓是事实上的工业规范，能够用来监控主机和网络基础设施，以及各种运用服务。在监控目标呈现问题时，及时发送邮件或许短信告诉相关人员；当问题处理后，发送恢复信息。

Nagios 从结构上来说，能够分为中心和插件两个部分。Nagios 的中心部分只供给了很少的监控功用，因而要建立一个完善的监控办理体系，用户还需求在Nagios服务器上装置相应的插件，插件能够从Nagios官方网站www.nagios.org 下载，也能够依据实践要求自己编写所需的插件。

Nagios能够监控各种网络服务，比方SMTP、POP3、HTTP、NTP、ICMP、FTP、SSH等，也能够监控主机资源，比方CPU、Load、磁盘运用、Syslog等。根本作业形式如图2所示。

二十年里12个开源监控工具大对比

这儿介绍两个比较重要的概念：NRPE和SNMP。

NRPE的全称是Nagios Remote Plugin Executor，是Nagios的Agent，这能够让Nagios具有监控长途主机和设备的才能。Nagios服务端，经过check_nrpe插件会守时地调用运转在长途主机上的NRPE，履行详细的脚原本获取数据，比方check_load、check_disk、check_ftp等。

SNMP（Simple Network Management Protocol，简略的网络办理协议）是一种运用层协议，被路由器、交换机、服务器、作业站、打印机等网络设备广泛支撑，首要用于办理和监控网络设备。SNMP的作业方法首要有三种：办理员需求向设备获取数据，SNMP供给了“读”操作；办理员需求向设备履行设置操作，SNMP供给了“写”操作；设备需求在重要状况改变的时分，向办理员通报事情的发生，SNMP供给了“Trap”操作。

SNMP的根本思维是：为不同种类的设备、不同厂家出产的设备、不同型号的设备，界说一个一致的接口和协议，使得办理员能够运用一致的方法对这些需求办理的网络设备进行办理。经过网络，办理员能够办理坐落不同物理空间的设备，然后大大提高了网络办理的功率，简化了网络办理员的作业。Nagios很好有利地势用了SNMP的读和Trap功用，很容易地获取各种网络设备的运转数据，到达监控的目的。

进阶：关于SNMP监控更多内容，能够查看快猫星云系列文章《SNMP(简略网络办理协议)简介》、《SNMP命令相关参数介绍》、《经过 Categraf SNMP 插件搜集监控数据》

5. Zabbix

引荐指数： ⭐ ⭐ ⭐ ⭐

Zabbix作为一款企业级分布式监控体系，功用齐全，用户体验杰出，文档完善，API强壮，合适于中小规划的公司或许团队运用。

进阶：关于Zabbix和夜莺监控的详细介绍，请阅览快猫系列文章《Zabbix 和夜莺监控选型对比》

Zabbix的首要特色有：

  • 文档齐全，装置、保护、学习本钱低。
  • 多言语支撑。
  • 完全免费开源。当然，假如需求技术支撑的话，Zabbix官方是收费的。
  • 主动发现服务器和网络设备，便于用户装备。
  • 支撑告警战略模板的概念，便运用户对一批服务器的监控战略进行办理。
  • 用户体验杰出的Web端，用户能够进行会集装备、保护和办理。
  • Zabbix Agent功用强壮，默许的搜集项足够丰富，且支撑用户自界说插件扩展。
  • 不必Agent合作，也能够完结监控使命，支撑SNMP、JMX等规范的协议，用户也能够自行推送数据- 控体系中。
  • Web端也供给了杰出的Dashboard功用、绘图查看功用。
  • 能够装备前史数据的存储周期，前史数据支撑采样存储。
  • 支撑分布式监控，比方多个IDC之间，或许有防火墙隔绝。
  • 强壮、完善的API支撑。

在以上特色中，尤其是API功用，完善程度很高，根本上Zabbix的大部分操作都供给了相应的API接口，便运用户编程，和现有的一些体系进行整合。比方以下一些场景。

  1. 运用前史数据查询API，守时从Zabbix中获取线上服务器的各项资源运用状况，生成每日查看报表；一起，对某些资源运用率不达标的服务器和事务进行挑选，每周进行通报，有用地促进资源运用率的提高。
  2. 运用Zabbix graph的API，能够对重视的目标获取对应的趋势图，嵌入到各个运维体系中，便利运维人员快速地了解服务状况。
  3. 运用Zabbix的告警添加API，能够让监控体系和布置体系联动起来。比方某个模块添加了一个实例，那么能够主动添加所需求的监控战略；反之，下线一个实例，能够主动删去关联的监控战略。

Zabbix首要由Server、Agent、Proxy和Web-portal几个部分组成。典型的Zabbix的布置形式如下图所示。

Zabbix的数据搜集，首要有两种形式：Server主动拉取数据和Agent主动上报数据。以前者为例，用户在Web-portal中，装备好机器，并给机器运用相应的模板后，Zabbix-server就会守时地去获取Agent的数据，存储到MySQL中，一起依据用户装备的战略，断定是否需求告警。用户能够在Web端，以图表的方法，查看各种目标的前史趋势。

在Zabbix中，将Server主动拉取数据的方法称之为active check。这种方法装备起来较为便利，可是会对Zabbix-server的功用存在影响，所以在出产环境中，一般会挑选主动推送数据到Zabbix-server的方法，称之为trapper。即用户能够守时生成数据，再按照Zabbix界说的数据格局，批量发送给Zabbix-server，这样能够大大提高Server的处理才能。

二十年里12个开源监控工具大对比

Proxy是Zabbix具有分布式监控才能的一个必备条件，试想咱们有一批服务器和网络设备坐落防火墙之后，Zabbix-server无法直接拜访这些Agent，这时分咱们能够挑选在防火墙的后边放置一个Zabbix-proxy，那么Proxy就会充任Server的人物，守时搜集它所担任的这些Agent的数据，然后守时推送回Zabbix-server。别的，Proxy还能够分管Server的压力，替代Server守时拉取数据，再一致push给Server，这样能够有用地下降Server的开销。

在Zabbix的规划中，以下几个概念是最重要的。

  • Host：主机，是Zabbix里边的监控主体，能够是服务器，也能够是网络设备，经过DNS或许IP地- 衔接。
  • Item：Host的某个数据搜集项，比方hostA的cpu_idle便是一个Item。
  • Template：这是Zabbix的一个很先进的概念，是对具有相同属性和资源的Host的一种抽象。即与- Template关联的Host，会主动具有该Template所具有的Item、Trigger、Graph等属性。一起- late具有承继的才能。
  • Trigger：触发器，具有三种状况，即unknown、problem和ok。只有当状况从problem变为ok- 候，或许ok变为problem的时分，才会触发相关的Action。当Zabbix-server每次取到Item的值- 与这个Item相关的Trigger都会被查看一次，并生成相应的Event。
  • Action：顾名思义，便是履行动作，Zabbix的Action支撑多种动作的履行，用户能够装备满意什- 的条件，做什么样的动作，动作包含发短信、发邮件、履行脚本等。
  • Event：当Trigger的状况每发生一次变化时，就会发生一个Event。

Zabbix在事务处于较小规划的时分，作用仍是相当不错的。可是当监控的目标超越上千台设备，而且还包含一些服务自身的事务目标也推送到Zabbix的时分，咱们遇到了两个严重的问题——Zabbix的功用问题和用户的“运用功率”低下问题。

Zabbix的功用问题首要存在两个方面，一是Zabbix-server处理才能有限，尤其当active check形式的搜集项较多的时分，会明显消耗Server的Puller线程，使得数据搜集推迟，发生堆积，形成报警推迟。咱们能够调大Puller的线程数，缓解这个问题，但Zabbix-server自身无法水平扩展，所以不能处理根本问题；二是Zabbix的数据存储引擎存在功用瓶颈，咱们线上选用的是MySQL，当数据搜集项过多的时分，比方在每分钟大概有20万搜集项的规划下，MySQL的写入会到达瓶颈。

综上所述，在事务规划较小的前提下，Zabbix是一个很可靠的开源处理计划。在事务规划不断增长的状况下，需求投入较多的精力在其功用优化上。

6. OpenTSDB

引荐指数： ⭐ ⭐

OpenTSDB是最具代表性的时刻序列数据（time-series data）存储和展现的分布式处理计划之一，恪守LGPL开源协议。OpenTSDB具有以下特色。

  • 数据存储：依据HBase，而且存储的都是用户上报的原始数据，不会对数据进行采样和钝化处理，前史数据能够一向保存。支撑毫秒级别的数据上报频率。
  • 可扩展性：因为后端的数据存储引擎是HBase，因而能够容易地支撑每秒上百万次的数据更新操作，而且处理才能跟着HBase节点数量的添加而添加。
  • 数据查询：OpenTSDB供给了友爱的用户拜访界面，便运用户查看相关的数据趋势。别的，也供给了HTTP方法的数据获取接口，便运用户经过编程，主动化地获取HBase中的前史数据，用作其他用处。不只能够查询单个目标的前史数据，OpenTSDB还供给了强壮的聚合功用，比方能够查看多个目标求和后的数据。

OpenTSDB的布置结构和作业流程如下图所示。

HBase为数据存储引擎，TSD是OpenTSDB最中心的组件，和HBase的一切数据交互都经过TSD来完结。TSD是一个常驻内存的进程，是无状况的，能够水平扩展。

咱们能够经过tcollector来搜集每台服务器的各个目标，然后推送给TSD；也能够经过SNMP来获取网络设备的各项目标，推送给TSD。TSD收到数据后，会更新到后端的HBase中。

二十年里12个开源监控工具大对比

OpenTSDB供给了Web界面，经过HTTP的接口向TSD查询数据；咱们也能够编写一些插件，比方告警插件，从TSD中获取某个目标的数据来断定是否满意阈值，以及是否需求告警。

OpenTSDB的呈现，让时刻序列数据的存储和展现多了一个很好的挑选。关于许多写入的场景十分有用。不过也存在一些缺乏的当地，比方前史数据的查询速度较慢：因为OpenTSDB存储的是原始数据，没有做任何采样，因而在需求查询某几个目标在曩昔一个月甚至一年的前史数据的时分，TSD真的就会去HBase中扫描相应时段的一切数据。首要，数据量很大；其次，读操作并不是HBase最拿手的；最终，费了好大力气获取到许多的数据，也无法很好地展现给用户，依然需求运用程序对数据做采样，形成无谓的一些消耗和浪费。

7. TDengine

引荐指数： ⭐ ⭐ ⭐

TDengine 是一款开源、云原生的时序数据库，专为物联网、工业互联网、金融、IT 运维监控等场景规划并优化。它能让许多设备、数据搜集器每天发生的高达 TB 甚至 PB 级的数据得到高效实时的处理，对事务的运转状况进行实时的监测、预警，从大数据中挖掘出商业价值。

TDengine 能够与开源数据可视化体系 Grafana 快速集成建立数据监测报警体系，整个进程无需任何代码开发，TDengine 中数据表的内容能够在仪表盘(DashBoard)上进行可视化展现。关于 TDengine 插件的运用您能够在GitHub中了解更多。

此外，TDengine也能够作为Prometheus的分布式时序数据库，来处理存储的扩展性问题。Prometheus 是一款流行的开源监控告警体系。Prometheus 于2016年参加了 Cloud Native Computing Foundation （云原生云核算基金会，简称 CNCF），成为继 Kubernetes 之后的第二个保管项目，该项目具有十分活泼的开发人员和用户社区。

Prometheus 供给了 remote_write 和 remote_read 接口来运用其它数据库产品作为它的存储引擎。为了让 Prometheus 生态圈的用户能够运用 TDengine 的高效写入和查询，TDengine 也供给了对这两个接口的支撑。

经过恰当的装备， Prometheus 的数据能够经过 remote_write 接口存储到 TDengine 中，也能够经过 remote_read 接口来查询存储在 TDengine 中的数据，充分运用 TDengine 对时序数据的高效存储查询功用和集群处理才能。

注意：Prometheus数据在写入到TDengine的时分，需求经过taosadapter的转发。

二十年里12个开源监控工具大对比

8. Influxdb

引荐指数： ⭐ ⭐ ⭐

influxdb是一个现代化的开源时序数据库（比较rrdtool、opentsdb等），他有以下特色：

  • 创新性的界说了表达才能更强的时序数据模型，引入了Label标签；
  • 配套的数据搜集器telegraf，是监控数据搜集领域内领先的开源东西；
  • 界说和完成了强壮灵敏的数据查询和处理言语FluxQL，用户能够像运用SQL查询关系型数据库那样，选用FluxQL来查询Influxdb；

运用开源版别的Influxdb，你需求重视两点：

  1. 开源版别的Influxdb是单机版别，不支撑水平扩展，因而假如您的数据量过大，要么选用布置多个Influxdb来分管承载数据，要么购买其企业版别或许运用Influxdb Cloud；
  2. Influxdb 是支撑字符串数据类型的，所以相应的 telegraf 搜集的许多 field 是字符串类型，别的 influxdb 的规划，答应 labels 是非稳态结构，比方 result_code 标签，有时其 value 是 0，有时其 value 是 1，在 influxdb 中都能够承受。可是上面两点，在相似 prometheus 的时序库中，处理起来就很费事。

9. VictoriaMetrics

引荐指数： ⭐ ⭐ ⭐ ⭐

VictoriaMetrics是一款开源的、可扩展的、与Prometheus无缝兼容的时序数据库。其架构简略，可靠性高，在功用，本钱，可扩展性方面体现出色，社区活泼，且和 Prometheus 生态绑定严密。假如单机版别的 Prometheus 无法在容量上满意贵司的需求，能够运用 VictoriaMetrics 作为时序数据库。

VictoriaMetrics 供给单机版和集群版。假如您的每秒写入数据点数小于100万（这个数量是个什么概念呢，假如仅仅做机器设备的监控，每个机器差不多搜集200个目标，搜集频率是10秒的话每台机器每秒搜集20个目标左右，100万/20=5万台机器），VictoriaMetrics 官方默许引荐您运用单机版，单机版能够经过添加服务器的CPU中心数，添加内存，添加IOPS来取得线性的功用提高。且单机版易于装备和运维。

二十年里12个开源监控工具大对比

vmstorage、vminsert、vmselect 三者组合构成 VictoriaMetrics 的集群功用，三者都能够经过发动多个实例来分管承载流量，经过要在 vminsert 和 vmselect 前面架起负载均衡。

vmstorage 是数据存储模块:

  • 其数据保存在-storageDataPath指定的目录中，默许为./vmstorage-data/，vmstorage 是有状况模块，删去 storage node 会丢失约1/N的前史数据（N 为集群中 vmstorage node 的节点数量）。添加 storage node，则需求同步修正 vminsert 和 vmselect 的发动参数，将新参加的storage node节点地址经过命令行参数-storageNode传入给vminsert和vmselect
  • vmstorage 发动后，会监听三个端口，分别是-httpListenAddr :8482、-vminsertAddr :8400、-vmselectAddr :8401。端口8400担任接纳来自 vminsert 的写入恳求，端口8401担任接纳来自 vmselect 的数据查询恳求，端口8482则是 vmstorage 自身供给的 http api 接口

vminsert 接纳来自客户端的数据写入恳求，并担任转发到选定的vmstorage:

  • vminsert 接纳到数据写入恳求后，按照jump consistent hash算法，将数据转发到选定的某个vmstorage node 上。vminsert 自身是无状况模块，能够添加或许删去一个或多个实例，而不会形成数据的损失。vminsert 模块经过发动时的参数-storageNode xxx,yyy,zzz来感知到整个 vmstorage 集群的完好 node 地址列表
  • vminsert 发动后，会监听一个端口-httpListenAddr :8480。该端口完成了prometheus remote_write协议，因而能够接纳和解析经过remote_write协议写入的数据。不过要注意，VictoriaMetrics 集群版别具有多租户功用，因而租户ID会以如下方法呈现在 API URL 中:http://vminsert:8480/insert/<account_id>/prometheus/api/v1/write
  • 更多 URL Format 能够参阅VictoriaMetrics官网

vmselect 接纳来自客户端的数据查询恳求，并担任转发到一切的 vmstorage 查询成果，最终将成果 merge 后回来:

  • vmselect 发动后，会监听一个端口-httpListenAddr :8481。该端口完成了prometheus query相关的接口。不过要注意，VictoriaMetrics 集群版别具有多租户功用，因而租户ID会以如下方法呈现在 API URL 中:http://vminsert:8481/select/<account_id>/prometheus/api/v1/query。
  • 更多 URL Format 能够参阅VictoriaMetrics官网

10. Prometheus

引荐指数： ⭐ ⭐ ⭐ ⭐

Prometheus 是由前 Google 工程师从 2012 年开端在 Soundcloud 以开源软件的方法进行研制的体系监控和告警东西包，自此以后，许多公司和安排都选用了 Prometheus 作为监控告警东西。Prometheus 的开发者和用户社区十分活泼，它现在是一个独立的开源项目，能够独立于任何公司进行保护。为了证明这一点，Prometheus 于 2016 年 5 月参加 CNCF 基金会，成为继 Kubernetes 之后的第二个 CNCF 保管项目。

Prometheus是一个开源的完好监控处理计划，其对传统监控体系的测验和告警模型进行了完全的推翻，形成了依据中央化的规矩核算、一致剖析和告警的新模型。 比较于传统监控体系Prometheus具有以下优点：

1. 易于办理

Prometheus中心部分只有一个单独的二进制文件，不存在任何的第三方依靠(数据库，缓存等等)。唯一需求的便是本地磁盘，因而不会有潜在级联毛病的风险。

Prometheus依据Pull模型的架构方法，能够在任何当地（本地电脑，开发环境，测验环境）建立咱们的监控体系。关于一些杂乱的状况，还能够运用Prometheus服务发现(Service Discovery)的才能动态办理监控目标。

2. 监控服务的内部运转状况

Pometheus鼓舞用户监控服务的内部状况，依据Prometheus丰富的Client库，用户能够轻松的在运用程序中添加对Prometheus的支撑，然后让用户能够获取服务和运用内部真正的运转状况。

3. 强壮的数据模型

一切搜集的监控数据均以目标(metric)的方法保存在内置的时刻序列数据库傍边(TSDB)。一切的样本除了根本的目标称号以外，还包含一组用于描述该样本特征的标签。 如下所示：

http_request_status{code='200',content_path='/api/path', environment='produment'} => [value1@timestamp1,value2@timestamp2...]
http_request_status{code='200',content_path='/api/path2', environment='produment'} => [value1@timestamp1,value2@timestamp2...]

每一条时刻序列由目标称号(Metrics Name)以及一组标签(Labels)唯一标识。每条时刻序列按照时刻的先后顺序存储一系列的样本值。

表明维度的标签或许来源于你的监控目标的状况，比方code=404或许content_path=/api/path。也或许来源于的你的环境界说，比方environment=produment。依据这些Labels咱们能够便利地对监控数据进行聚合，过滤，裁剪。

4. 强壮的查询言语PromQL

Prometheus内置了一个强壮的数据查询言语PromQL。 经过PromQL能够完成对监控数据的查询、聚合。一起PromQL也被运用于数据可视化(如Grafana)以及告警傍边。

经过PromQL能够轻松答复相似于以下问题：

  • 在曩昔一段时刻中95%运用推迟时刻的分布规划？
  • 预测在4小时后，磁盘空间占用大致会是什么状况？
  • CPU占用率前5位的服务有哪些？(过滤)

5. 高效

关于监控体系而言，许多的监控使命必然导致有许多的数据发生。而Prometheus能够高效地处理这些数据，关于单一Prometheus Server实例而言它能够处理：

  • 数以百万的监控目标
  • 每秒处理数十万的数据点。

6. 可扩展

Prometheus是如此简略，因而你能够在每个数据中心、每个团队运转独立的Prometheus Sevrer。Prometheus关于联邦集群的支撑，能够让多个Prometheus实例发生一个逻辑集群，当单实例Prometheus Server处理的使命量过大时，经过运用功用分区(sharding)+联邦集群(federation)能够对其进行扩展。

7. 易于集成

运用Prometheus能够快速建立监控服务，而且能够十分便利地在运用程序中进行集成。现在支撑： Java， JMX， Python， Go，Ruby， .Net， Node.js等等言语的客户端SDK，依据这些SDK能够快速让运用程序归入到Prometheus的监控傍边，或许开发自己的监控数据搜集程序。一起这些客户端搜集的监控数据，不只仅支撑Prometheus，还能支撑Graphite这些其他的监控东西。

一起Prometheus还支撑与其他的监控体系进行集成：Graphite， Statsd， Collected， Scollector， muini， Nagios等。

Prometheus社区还供给了许多第三方完成的监控数据搜集支撑：JMX， CloudWatch， EC2， MySQL， PostgresSQL， Haskell， Bash， SNMP， Consul， Haproxy， Mesos， Bind， CouchDB， Django， Memcached， RabbitMQ， Redis， RethinkDB， Rsyslog等等。

8. 可视化

Prometheus Server中自带了一个Prometheus UI，经过这个UI能够便利地直接对数据进行查询，而且支撑直接以图形化的方法展现数据。一起Prometheus还供给了一个独立的依据Ruby On Rails的Dashboard处理计划Promdash。最新的Grafana可视化东西也已经供给了完好的Prometheus支撑，依据Grafana能够创立更加精巧的监控图标。依据Prometheus供给的API还能够完成自己的监控可视化UI。

9. 开放性

一般来说当咱们需求监控一个运用程序时，一般需求该运用程序供给对相应监控体系协议的支撑。因而运用程序会与所挑选的监控体系进行绑定。为了削减这种绑定所带来的约束。关于决策者而言要么你就直接在运用中集成该监控体系的支撑，要么就在外部创立单独的服务来适配不同的监控体系。

而关于Prometheus来说，运用Prometheus的client library的输出格局不止支撑Prometheus的格局化数据，也能够输出支撑其它监控体系的格局化数据，比方Graphite。

因而你甚至能够在不运用Prometheus的状况下，选用Prometheus的client library来让你的运用程序支撑监控数据搜集。

上述 prometheus 介绍文字，引用自：prometheus book by yunlzheng

不过prometheus在落地出产环境的进程中，现在存在以下痛点：

  • 现有开源组合计划 Prometheus + Alertmanager + Grafana 多个体系较为割裂，无法开箱即用;
  • 经过修正装备文件来办理 Prometheus、Alertmanager ，学习曲线大，用户量多时，协同有难度;
  • 数据量过大而无法有用扩展 Prometheus 集群；
  • 出产环境运转多套 Prometheus 集群，面临分区办理和运用本钱高的问题；
  • Metric、Log、Trace 等数据要素贯穿，关于毛病定位、功用剖析至关重要；

11. Open-Falcon

引荐指数： ⭐ ⭐ ⭐

监控体系是整个运维环节，甚至整个产品生命周期中最重要的一环，事前及时预警发现毛病，过后供给翔实的数据用于追查定位问题。监控体系作为一个老练的运维产品，业界有许多开源的完成可供挑选。当公司刚刚起步，事务规划较小，运维团队也刚刚建立的初期，挑选一款开源的监控体系，是一个省时省力，功率最高的计划。之后，跟着事务规划的持续快速增长，监控的目标也越来越多，越来越杂乱，监控体系的运用目标也从最初少量的几个SRE，扩大为更多的DEVS，SRE。这时分，监控体系的容量和用户的“运用功率”成了最为杰出的问题。

open-falcon是小米技术团队开发开源的一款互联网企业级监控体系，重在处理日益增长的监控数据量和监控体系的容量约束之间的矛盾。open-falcon在架构规划上，一个最关键的考量点便是“怎样做到水平扩展”。

二十年里12个开源监控工具大对比

open-falcon的优势

  1. 强壮灵敏的数据搜集：主动发现，支撑falcon-agent、snmp、支撑用户主动push、用户自界说插件支1. 持、opentsdb data model like（timestamp、endpoint、metric、key-value tags）
  2. 水平扩展才能：支撑每个周期上亿次的数据搜集、告警断定、前史数据存储和查询
  3. 高功率的告警战略办理：高效的portal、支撑战略模板、模板承继和掩盖、多种告警方法、支撑1. callback调用
  4. 人性化的告警设置：最大告警次数、告警级别、告警恢复告诉、告警暂停、不一起段不同阈值、支撑保护1. 周期
  5. 高功率的graph组件：单机支撑200万metric的上报、归档、存储（周期为1分钟）
  6. 高效的前史数据query组件：选用rrdtool的数据归档战略，秒级回来上百个metric一年的前史数据
  7. dashboard：多维度的数据展现，用户自界说Screen
  8. 高可用：整个体系无中心单点，易运维，易布置，可水平扩展
  9. 开发言语： 整个体系的后端，悉数golang编写，portal和dashboard运用python编写。

open-falcon在架构规划上的特色

  1. 界说了可扩展的数据模型（label），引入了标签的概念，能够大大增强监控目标的表达才能；
  2. 从一开端就规划了专属的数据搜集器falcon-agent，数据采什么、怎样采、采了怎样用，都考虑到了，做到了开箱即用，常识沉淀。
  3. 数据选用“推”的方法；falcon-agent搜集到的数据，直接推送到transfer组件，当然用户也能够经过transfer的api来推送自界说数据；（保障了时效性、便利研制团队接入数据）
  4. transfer 组件，是数据传输网关，能够水平扩展，一起transfer会依据必定的数据分片规矩，将数据推送给存储模块graph、以及告警断定模块judge。
  5. 在整个open-falcon的架构中，中心思维是选用数据分片架构处理扩展性问题。比方 transfer 模块自身是无状况的，能够水平扩展；graph组件是按照一致性hash算法对数据进行分片存储，judge模块也是按照一致性hash算法来处理特定分片的数据和使命；
  6. 最终，open-falcon 不只仅是一个东西，更多的是一个产品，将互联网公司的运维经历沉淀到产品中，一起具有较高的产品完结度，在数据搜集、办理portal、可视化、告警断定、告警告诉、等方面，都有不错的体现；

open-falcon的缺乏

  1. 在数据模型上，尽管很早（2013年）就引入标签的维度，可是未能和Prometheus的数据模型看齐，导致后续在生态的融合上呈现额定的妨碍
  2. 选用推的数据模型，在“操控”方面会比较弱（要做好流控、脏数据操控等才能），关于数据中止的监控无法感知（添加了“nodata”的额定逻辑，Prometheus是在scrape数据的时分，供给了target_up目标）
  3. 流式的judge模型，天然无法很好的处理多条件组合报警等杂乱断定（aggregator处理了一部分问题）
  4. proxy架构，没有很好的处理数据再平衡的问题（尽管供给了扩缩容时migrate数据的计划，可是运维操作比较杂乱。vm选用的proxy的架构）
  5. 依据RRD的数据格局，环状数据库，尽管磁盘的运用功率很高，可是磁盘 IO 负载很高（尽管做了优化，将小文件的随机写入，加了写的缓存，修正为批量写入等）此外关于adhoc查询，支撑比较弱。

12. Nightingale(夜莺监控)

引荐指数： ⭐ ⭐ ⭐ ⭐

夜莺监控是一款开源云原生监控剖析体系，选用 All-In-One 的规划理念，集数据搜集、可视化、监控告警、数据剖析于一体，与云原生生态严密集成，供给开箱即用的企业级监控剖析和告警才能，已有众多企业挑选将 Prometheus + AlertManager + Grafana 的组合计划升级为运用夜莺监控。夜莺监控，由滴滴开发和开源，并于 2022 年 5 月 11 日，捐献予我国核算机学会开源发展委员会（CCF ODC），为 CCF ODC 建立后承受捐献的榜首个开源项目。

夜莺监控的优势

  • 夜莺监控用户界面好看，功用全面，是一个all-in-one监控产品；
  • 配套开箱即用的监控数据搜集器categraf，一起支撑目标、日志、链路追寻数据的搜集；
  • 一起合适传统架构 & 云原生架构 & 混合云架构；
  • 多数据源架构规划，习惯灵敏多变的布置环境和生态；
  • 可扩展架构规划，水平灵敏扩展；
  • 统筹中心化布置和边际设备集群办理；
  • Go言语开发，安全，易保护，架构简洁；

夜莺监控由数据搜集器、告警引擎、可视化引擎、告警自愈引擎构成。夜莺的规划十分简略，中心是 server 、webapi、frontend 三个模块。

二十年里12个开源监控工具大对比

webapi 无状况，中心端布置，承接前端frontend的恳求，将用户装备写入数据库，一起对外供给API 供frontend 运用；

server 是告警引擎，也承担数据处理、转发功用，一般伴跟着时序数据库布置，一个时序库就对应一套 server，每套 server 能够只发动一个实例，也能够发动多个实例组成集群。

server 能够接纳 Categraf、Telegraf、Grafana-Agent、Datadog-Agent、Falcon-Plugins 等多种数据搜集器上报的数据，写入后端时序数据库，并周期性从数据库同步用户装备的告警规矩，查询时序数据库进行告警判别。

此外，快猫星云自研的数据搜集器Categraf，是夜莺默许的数据搜集器，有以下特色：

  1. All-in-one：一切的搜集作业运用一个 agent 来处理，包含 metrics、logs、 traces ，并从数据搜集的源头建立起数据间的关联关系，保障好数据的质量。
  2. 开箱即用：掩盖支撑上百种搜集目标，包含K8s、中间件、服务器、交换机等，针对常用的搜集目标，在供给搜集才能的一起，配套有默许的监控仪表盘模板和告警规矩模板，用户能够直接导入并运用。
  3. 布置方法灵敏：支撑在 K8s 集群中以 Daemonset 或许 Sidecar 运转，支撑公有云产品的数据搜集，也支撑独立运转在宿主机上。
  4. Go言语开发：安全、易分发、易装置保护，插件化。

二十年里12个开源监控工具大对比

专业的告警功用

  1. 支撑多数据源告警，Prometheus、Victoriametrics、M3DB、Thanos，ElasticSearch、SLS；
  2. 多种告警断定战略，多条件战略，收效周期，产品化装备和办理；
  3. 多告诉途径和自界说告诉模版；
  4. 支撑毛病自愈和告警 Webhook；
  5. 支撑告警聚合、收敛、排班、协同（需求对接Flashcat SaaS运用）；

二十年里12个开源监控工具大对比

自研可视化引擎，对标Grafana

俗语讲，一图胜千言，可视化是透传数据价值最直接的手法。夜莺监控的 Dashboard 不只从功用、规划上能够对标 Grafana，一起也兼容 Grafana，要是你觉得 Grafana 某个 Dashboard 十分有用，甚至能够直接导入到夜莺监控中运用。

二十年里12个开源监控工具大对比

此外，夜莺监控的 Dashboard 支撑多种数据源，比方时序数据库 Prometheus、Victoriametrics、M3DB、Thanos，又比方日志数据源 ElasticSearch、SLS 等。

进阶：快猫星云是一家云原生智能运维科技公司，由开源监控东西“夜莺监控”的中心开发团队组成。快猫星云打造的云原生监控剖析渠道——Flashcat渠道，旨在处理云原生架构、混合云架构下一致监控难、毛病定位慢的问题。Flashcat渠道支撑云原生架构、公有云、物理机/虚拟机、混合云等多种环境的监控数据一致搜集，集告警剖析、可视化、数据剖析于一体，从事务到运用到基础设施，打通metrics、logging、tracing、event，供给立体的、一致的监控处理计划。

原文链接：flashcat.cloud/blog/open-s…