常用运维监控工具详细对比

字数统计: 2.6k字   |   阅读时长≈ 9分

一、软件综合对比

对比项\软件 Zabbix Nagios Open-Falcon Prometheus
开发语言 C+PHP C Golang Golang
成熟度 高 高 中 中
扩展性 高 中 中 高
性能 低 中 高 高
社区活跃度 中 低 中 高
容器支持 低 低 中 高
企业使用情况 高 低 中 高
部署难度 中 中 高 低

二、应用场景说明
1.Zabbix
A.软件说明

1
2
3
Zabbix是由Alexei Vladishev开源的分布式监控系统，是一个企业级的分布式开源监控方案。能够监控各种网络参数以及服务器健康性和完整性的软件。使用灵活的通知机制，允许用户为几乎任何事件配置基于邮件的告警。这样可以快速反馈服务器的问题。基于已存储的数据，提供了出色的报告和数据可视化功能。

同时可以结合Grafana出图，Zabbix作为数仓的方式，呈现出来的监控图形更符合企业气息。

B.软件采集架构
1.png

1
2
3
4
5
6
7
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时序数据库，到现在Zabbix的版本已经更新至5.4.

C.总结

1
如果想要监控传统的软硬件资源，Zabbix首当其冲。比如监控交换机、F5、路由器、防火墙、物理服务器、Linux、Windows、Unix、Nginx、Mysql、Redis、Tomcat等等，而且考虑到稳定性和数据实时性、功能的高度集成、那就选择Zabbix吧，毕竟运维监控必不可少掌握的技能。

2.Nagios
A.软件说明

1
2
3
Nagios是一款开源软件，能有效监控 Windows 、Linux、VMware 和 Unix 主机状态，交换机、路由器等网络设置等。当监控出异常时提醒系统管理员，当异常恢复时也会通知。Nagios提供一个基于浏览器的web界面，方便管理人员查看系统的运行状态，网络状态、服务状态、日志信息，以及其他异常现象。

同时支持商用OneAlert一键集成nagios，轻松实现微信、电话、邮件、短信、APP的告警通知。

B.数据采集架构
2.png

当Nagios需要监控某个远程linux主机的服务或者资源情况时：

  • nagios运行check_nrpe插件,我们要在nagios配置文件中告诉它要检查什么.
  • check_nrpe插件会通过SSL连接到远程的NRPE daemon.check_nrpe插件会通过SSL连接到远程的NRPE daemon.
  • NRPE daemon会运行相应的nagios插件来执行检查本地资源或服务.NRPE daemon会运行相应的nagios插件来执行检查本地资源或服务.
  • NRPE daemon将检查的结果返回给check_nrpe插件,插件将其递交给nagios做处理.NRPE daemon将检查的结果返回给check_nrpe插件,插件将其递交给nagios做处理.

注意:NRPE daemon需要nagios插件和Nrpe一起安装在远程被监控linux主机上,否则,daemon不能做任何的监控. 别外因为它们间的通信是加密的SSL,所以需要安装SSL

C.总结

1
在监控主机的服务状态、服务器资源状态、网络服务状态、甚至网络设备（交换机、路由器）都是没问题的，但在配置所有监控的过程都需要通过插件来完成，但在开源社区和企业使用情况来看的话，稳定性和后续新功能扩展几率很少，终究是一款小众的监控软件，针对基础的应用进行监控。

3.Open-Falcon
A.软件说明

1
2
3
4
5
6
7
8
9
10
* 强大灵活的数据采集：自动发现，支持falcon-agent、snmp、支持用户主动push、用户自定义插件支持、opentsdb data model like（timestamp、endpoint、metric、key-value tags）
* 水平扩展能力：支持每个周期上亿次的数据采集、告警判定、历史数据存储和查询
* 高效率的告警策略管理：高效的portal、支持策略模板、模板继承和覆盖、多种告警方式、支持callback调用
* 人性化的告警设置：最大告警次数、告警级别、告警恢复通知、告警暂停、不同时段不同阈值、支持维护周期
* 高效率的graph组件：单机支撑200万metric的上报、归档、存储（周期为1分钟）
* 高效的历史数据query组件：采用rrdtool的数据归档策略，秒级返回上百个metric一年的历史数据
* dashboard：多维度的数据展示，用户自定义Screen
* 高可用：整个系统无核心单点，易运维，易部署，可水平扩展
* 开发语言： 整个系统的后端，全部golang编写，portal和dashboard使用python编写。

B.数据采集架构
3.png

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
每台服务器，都有安装falcon-agent，falcon-agent是一个golang开发的daemon程序，用于自发现的采集单机的各种数据和指标，这些指标包括不限于以下几个方面，共计200多项指标。
* CPU相关
* 磁盘相关
* IO
* Load
* 内存相关
* 网络相关
* 端口存活、进程存活
* ntp offset（插件）
* 某个进程资源消耗（插件）
* netstat、ss 等相关统计项采集
* 机器内核配置参数

只要安装了falcon-agent的机器，就会自动开始采集各项指标，主动上报，不需要用户在server做任何配置（这和zabbix有很大的不同），这样做的好处，就是用户维护方便，覆盖率高。当然这样做也会server端造成较大的压力，不过open-falcon的服务端组件单机性能足够高，同时都可以水平扩展，所以自动多采集足够多的数据，反而是一件好事情，对于SRE和DEV来讲，事后追查问题，不再是难题。

另外，falcon-agent提供了一个proxy-gateway，用户可以方便的通过http接口，push数据到本机的gateway，gateway会帮忙高效率的转发到server端。

C.总结

1
2
3
4
5
6
7
open-falcon是小米开源的监控软件，前端比较简单，但可以监控Linux主机的200多项指标数据，主要包括CPU、内存、磁盘、文件系统、内核参数、Socket连接等等，同时支持自定义监控脚本。

而采集的transfer数据源主要有三种：1.agent采集的基础监控数据。2.agent执行用户自定义的插件返回的数据。3.client library：线上的业务系统，都嵌入使用了统一的perfcounter.jar，对于业务系统中每个RPC接口的qps、latency都会主动采集并上报。

在上报数据过程，会先发送到本机的proxy-gateway,再由gateway转发给transfer。

总的来说，open-falcon相对zabbix针对数据采集、数据处理效率、高可用、都比zabbix要好，但考虑到稳定性和易用性，这两点open-falcon比zabbix要差一些。

4.Prometheus
A.软件说明

1
2
3
4
Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库。从字面上理解，Prometheus由两个部分组成，一个是监控报警系统，另一个是自带的时序数据库（TSDB）。

2016年，由Google发起的Linux基金会旗下的原生云基金会（Cloud Native Computing Foundation）将Prometheus纳入其第二大开源项目。Prometheus在开源社区也十分活跃，在GitHub上拥有两万多Star，并且系统每隔一两周就会有一个小版本的更新，而Prometheus与它的“师兄”Kubernetes都自带云原生的光环，天然能够友好协作。

B.数据采集架构
4.png

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

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

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

C.总结

1
Promethues出身自带云原生光环，注定在K8S容器监控领领域有一定的地位，同时更能与耦合在一起，统一监控入口，服务端也能横向扩展实现分布式部署，基本企业在使用K8S或者容器的时候，Prometheus作为监控是最好的一个选择。也因为开发语言是GO，近年来Go语言排行一直往上爬，更贴近云原生，另外部署成本极低，一个核心的组件+一条命令既可以实现监控。但入门成本相对Zabbix要高一些，但入门之后后面扩展可以实现更加灵活。

三、价值体现
1.实现自动检查及采集数据
2.统一资源监控管理平台入口
3.实现实时告警及自动修复。
4.安全可控，将数据安全可控性精细化。
5.开源社区，更灵活使用自定义扩展或者插件。
6.实现设备自动发现及自动注册。
7.去中心化，防止单点故障。

四、软件监控示例
1.Zabbix
4-1.png
4-2.png

2.Nagios
4-3.png
4-4.png

3.open-falcon
4-5.png
4-6.png

4.Prometheus
4-7.png
4-8.png

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

比别人优秀不重要，重要的是比昨天的自己更优秀。