概述

定义

Zabbix 官网地址 https://www.zabbix.com/

Zabbix 官网文档 https://www.zabbix.com/documentation

Zabbix GitHub源码地址 https://github.com/zabbix

Zabbix 是一个企业级的开源分布式监控、高度集成的网络监控解决方案。最新版本为6.2.4，官方文档支持很多种语言，最新中文文档支持到6.0版本。

Zabbix 诞生于1998年，核心组件采用C语言开发，Web端采用PHP开发。属于老牌监控系统中的优秀代表，监控功能很全面，使用也很广泛。是一款具备监控网络的众多参数，可以监控网络、物理服务器、虚拟机、应用程序、服务、数据库、网站、云等。

监控作用

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

使用理解

了解监控对象的工作原理：要做到对监控对象有基本的了解，清楚它的工作原理。比如想对JVM进行监控，你必须清楚JVM的堆内存结构和垃圾回收机制。
确定监控对象的指标：清楚使用哪些指标来刻画监控对象的状态？比如想对某个接口进行监控，可以采用请求量、耗时、超时量、异常量等指标来衡量。
定义合理的报警阈值和等级：达到什么阈值需要告警？对应的故障等级是多少？不需要处理的告警不是好告警，可见定义合理的阈值有多重要，否则只会降低运维效率或者让监控系统失去它的作用。
建立完善的故障处理流程：收到故障告警后，一定要有相应的处理流程和oncall机制，让故障及时被跟进处理。

监控对象和指标

运维关注硬件和基础监控，研发关注各类中间件和应用层的监控，产品关注核心业务指标的监控。

硬件监控：电源状态、CPU状态、机器温度、风扇状态、物理磁盘、raid状态、内存状态、网卡状态。
服务器基础监控
- CPU：单个CPU以及整体的使用情况
- 内存：已用内存、可用内存
- 磁盘：磁盘使用率、磁盘读写的吞吐量
- 网络：出口流量、入口流量、TCP连接状态
数据库监控：数据库连接数、QPS、TPS、并行处理的会话数、缓存命中率、主从延时、锁状态、慢查询。
中间件监控
- Nginx：活跃连接数、等待连接数、丢弃连接数、请求量、耗时、5XX错误率
- Tomcat：最大线程数、当前线程数、请求量、耗时、错误量、堆内存使用情况、GC次数和耗时
- 缓存（Redis）：成功连接数、阻塞连接数、已使用内存、内存碎片率、请求量、耗时、缓存命中率
- 消息队列(Kafka)：连接数、队列数、生产速率、消费速率、消息堆积量
应用监控
- HTTP接口：URL存活、请求量、耗时、异常量
- RPC接口：请求量、耗时、超时量、拒绝量
- JVM ：GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数
- 线程池：活跃线程数、任务队列大小、任务执行耗时、拒绝任务数
- 连接池：总连接数、活跃连接数
- 日志监控：访问日志、错误日志
- 业务指标：视业务来定，比如PV、订单量等

架构组成

Zabbix server：核心组件， Zabbix 软件的中央进程，执行监控、与 Zabbix proxy 和 agent 交互，负责接收Agent、Proxy的监控数据，也支持JMX、SNMP等多种协议直接采集数据；负责数据的汇总存储以及告警触发等。
数据库：Zabbix 收集的所有配置信息以及数据都存储在数据库中，支持MySQL、Oracle等关系型数据库，逐步支持时序数据库。
前端：Zabbix的Web的界面，提供基于 Web 可视化监控配置、展现、告警。
Zabbix proxy：可以代替 Zabbix server 收集性能监控项数据，可选，对于被监控机器较多的情况下，可使用Proxy进行分布式监控以减轻Server的压力。
Zabbix agent ：部署在被监控目标上，以主动监控本地资源和应用程序的进程（硬盘、内存、处理器统计信息等），采集本机的数据并发送给Proxy或者Server，数据收集方式同时支持主动Push和被动Pull 两种模式。从 Zabbix 4.4 开始，有两种类型的 agent 可用：Zabbix agent（轻量级，在许多平台上支持，用 C 编写）和 Zabbix agent 2（非常灵活，易于使用插件扩展，用 Go 编写）。
- 被动模式：agent 应答数据请求。Zabbix server（或 proxy）询求数据，例如 CPU load，然后 Zabbix agent 返还结果。
- 主动模式：处理过程将相对复杂，Agent 必须首先从 Zabbix sever 索取监控项列表以进行独立处理，然后会定期发送采集到的新值给 Zabbix server。
Zabbix API：使用 JSON RPC 协议来创建、更新和获取 Zabbix 对象（如主机、监控项、图表等）或执行任何其他自定义任务。
Zabbix Java gateway ：获取主机的JMX 计数器的值，Zabbix server向Zabbix Java gateway发送请求，使用 JMX 管理 API 来远程查询相关的应用。
Zabbix sender：用来推送性能数据给 Zabbix Server 处理的命令行应用程序；通常用在定期推送可用性和性能数据等在长耗时的用户脚本上。
Zabbix get ：命令行应用，它可以用于与 Zabbix agent 进行通信，并从 Zabbix agent 那里获取所需的信息；通常被用于 Zabbix agent 故障排错。

常用监控软件分析

前面我们学习过Prometheus，这里结合Zabbix、Open-falcon做下简单的优劣势分析

Zabbix
- 优势
  - 产品成熟：拥有丰富的文档资料（包括中文文档）以及各种开源的数据采集插件，能覆盖绝大部分监控场景。
  - 采集方式丰富：支持Agent、SNMP、JMX、SSH等多种采集方式，支持主动和被动的数据传输方式。
  - 较强的扩展性：支持Proxy分布式监控，有agent自动发现功能，插件式架构支持用户自定义数据采集脚本。
  - 配置管理方便：能通过Web界面进行监控和告警配置，操作方便，上手简单。
- 劣势
  - 性能瓶颈：机器量或者业务量大了后，关系型数据库的写入一定是瓶颈。
  - 应用层监控支持有限：如果想对应用程序做侵入式的埋点和采集（比如监控线程池或者接口性能），zabbix没有提供对应的sdk，需要通过插件式的脚本编写实现较为麻烦。
  - 数据模型不强大：不支持tag，没法按多维度进行聚合统计和告警配置，不灵活。
  - 方便二次开发难度大：Zabbix采用的是C语言，二次开发成本较高。
Open-falcon：是小米2015年开源的企业级监控工具，采用Go和Python语言开发，这是一款灵活、高性能且易扩展的新一代监控方案，目前小米、美团、滴滴等超过200家公司在使用。核心优势在于数据分片功能，能支撑更多的机器和监控项。
- 优势
  - 自动采集能力：无需做任何配置Falcon-agent 就能自动采集服务器的200多个基础指标（比如CPU、内存等）。
  - 强大的存储能力：底层采用RRDTool，并且通过一致性hash进行数据分片，构建了一个分布式的时序数据存储系统，可扩展性强。
  - 灵活的数据模型：借鉴OpenTSDB，数据模型中引入了tag，这样能支持多维度的聚合统计以及告警规则设置，大大提高了使用效率。
  - 插件统一管理：Open-Falcon的插件机制实现了对用户自定义脚本的统一化管理，可通过HeartBeat Server分发给agent，减轻了使用者自主维护脚本的成本。
  - 个性化监控支持：基于Proxy-gateway，很容易通过自主埋点实现应用层的监控（比如监控接口的访问量和耗时）和其他个性化监控需求，集成方便。
- 劣势
  - 整体发展一般：社区活跃度不算高，版本更新慢，支持粒度较弱。
  - 安装比较复杂：组件较多，如果对整个架构不熟悉，安装很难一蹴而就。
Prometheus：有Google和k8s加持，是容器监控方面的标配和主流方案。
- 优势
  - 轻量管理：架构简单，不依赖外部存储，单个服务器节点可直接工作，二进制文件启动即可，属于轻量级的Server，便于迁移和维护。
  - 较强的处理能力：监控数据直接存储在Prometheus Server本地的时序数据库中，单个实例可以处理数百万的metrics。
  - 灵活的数据模型：同Open-Falcon，引入了tag，属于多维数据模型，聚合统计更方便。
  - 强大的查询语句：PromQL允许在同一个查询语句中，对多个metrics进行加法、连接和取分位值等操作。
  - 很好地支持云环境：能自动发现容器，同时k8s和etcd等项目都提供了对Prometheus的原生支持，是目前容器监控最流行的方案。
- 劣势
  - 功能不够完善：Prometheus从一开始的架构设计就是要做到简单，不提供集群化方案，长期的持久化存储和用户管理，而这些是企业变大后所必须的特性，目前要做到这些只能在Prometheus之上进行扩展。
  - 网络规划变复杂：由于Prometheus采用的是Pull模型拉取数据，意味着所有被监控的endpoint必须是可达的，需要合理规划网络的安全配置。

版本选型

LTS稳定版本每一年半发布一次，对于所有稳定版本，五年的服务与支持。目前Zabbix版本支持期限列表如下，建议企业选型使用时选择LTS版本如6.0

Zabbix LTS 特点：

支持期限更长，例如：为潜在的安全问题及bug迭代更新
令人期待的高质量更新以及全新的功能点
快速更新，可适用于多变的复杂环境
在版本升级方面，更容易规划管理

俗语

host（主机）：要通过 IP/DNS 监控的联网设备。
host group（主机组）：主机的逻辑分组；可能包含主机和模板。主机组中的主机和模板没有以任何方式相互链接。在为不同用户组分配主机访问权限时使用主机组。
item（监控项）：你想要接收的主机的特定数据，一个度量/指标数据。
value preprocessing（值预处理）：在数据存入数据库之前转化/预处理接收到的指标数据。
trigger（触发器）：一个被用于定义问题阈值和 "评估" 控项接收到的数据的逻辑表达式。当接收到的数据高于阈值时，触发器从 'Ok' 变成 'Problem' 状态。当接收到的数据低于阈值时，触发器保留/返回 'Ok' 的状态。
event（事件）：一次发生的需要注意的事情，例如触发器状态改变、自动发现/agent 自动注册。
event tag（事件标签）：预设的事件标记可以被用于事件关联，权限细化设置等。
event correlation（事件关联）：一种灵活而精确地将问题与其解决方法联系起来的方法比如说，你可以定义触发器A告警的异常可以由触发器B解决，触发器B可能采用完全不同的数据采集方式。
problem（问题）：一个处在 "问题" 状态的触发器。
problem update（问题更新）：Zabbix 提供的问题管理选项，例如添加评论、确认、更改严重性或手动关闭。
action（动作）：对事件作出反应的预先定义的方法。一个动作由多个操作（例如发送通知)）和条件（什么情况下执行操作）组成。
escalation（升级）：用于在动作中执行操作的自定义场景；发送通知/执行远程命令的序列。
media（媒体）：发送告警通知的渠道；传输媒介。
notification（通知）：通过选定的媒体通道发送给用户的关于某个事件的消息。
remote command（远程命令）：在某些条件下在受监控主机上自动执行的预定义命令。
template（模板）：可以应用于一个或多个主机的一组实体集（包含监控项、触发器、图表、低级别自动发现规则、web场景等）。模版的应用使得主机上的监控任务部署快捷方便；也可以使监控任务的批量修改更加简单。模版是直接关联到每台单独的主机上。
web scenario（web 场景）：检查一个网站的可用性的一个或多个HTTP请求。

安装

部署方式

Zabbix支持多种安装方式，可单项安装也可以混合安装，包括如下：

二进制安装；
源代码安装；
容器安装；
Web界面安装。

部署

# 下载docker项目

wget https://github.com/zabbix/zabbix-docker/archive/refs/tags/6.2.4.tar.gz

# 解压

tar -xvf 6.2.4.tar.gz

# 进入目录

cd zabbix-docker-6.2.4

# 通过docker-compose一键安装启动，由于本机端口冲突，修改zabbix-web-nginx-mysql的端口为180和1443

docker-compose -f docker-compose_v3_centos_mysql_latest.yaml up -d

# 查看容器

docker-compose -f docker-compose_v3_centos_mysql_latest.yaml ps

访问Zabbix的Web页面 http://192.168.50.95:180/，输入用户名 Admin 以及密码 zabbix ，进入全局视图页面。

配置为中文，通过用户设置，选择语言为中文，点击更新后就为中文版。

zabbix-agent

# 模拟启动zabbix-agent1为Zabbix server的

docker run --name zabbix-agent1 -e ZBX_HOSTNAME="Zabbix server" --network zabbix-docker-624_zbx_net_backend -e ZBX_SERVER_HOST="zabbix-docker-624_zabbix-server_1"  -d zabbix/zabbix-agent:latest

# 进入zabbix-docker-624_zabbix-server_1的容器

docker exec -it zabbix-docker-624_zabbix-server_1 /bin/bash

# 执行测试命令，可以获取到监控项的值

zabbix_get -s zabbix-agent1 -p 10050 -k "system.cpu.load[all,avg1]"