企业级Zabbix监控平台
1、监控的意义
**保障业务稳定运行**:监控系统通过实时关注与业务相关的各项指标,确保服务器、网络设备等硬件资源的正常运行,从而保障公司线上业务的稳定性。**及时发现和解决问题**:监控系统能够及时发现系统的异常和故障,通过告警管理迅速通知运维人员,以便尽快采取措施解决问题,减少潜在的损失。数据收集与分析:监控系统可以收集系统运行的各种数据,如性能数据、日志信息等,通过数据分析帮助管理者更好地理解系统运行状况,优化系统性能。
**预防故障**:除了发现和解决已经发生的故障,监控系统还能够通过历史数据分析预测潜在的问题,提前采取预防措施,避免故障发生。
2、监控的对象
通常情况下,我们可以将监控对象这么来分:
服务器监控:主要监控服务器如:CPU 负载、内存使用率、磁盘使用率、登陆用户数、进程状态、网卡状态等。
应用程序监控:主要监控该应用程序的服务状态,吞吐率和响应时间,因为不同应用需要监控的对象不同,这里不一一列举。
数据库监控:只所以把数据库监控单独列出来,足以说明它的重要性,一般监控数据库状态,数据库表或者表空间的使用情况,是否有死锁,错误日志,性能信息等等。
网络监控:主要监控当前的网络状况,网络流量,端口,连接等。
举例:
Nginx监控:Zabbix可以收集包括活跃连接数(active connections)、已接受的连接数(accepts)、已处理的请求总数(handled requests)等在内的关键性能指标。这些数据可以通过自定义脚本使用awk等工具从Nginx状态页中提取出来。
3、常见监控软件: 夜莺监控 睿象云
Nagios:Nagios是一款开源的监控工具,主要用于监控系统和网络的运行状态,它可以通过多种插件来监控不同的服务和应用。Nagios的特点是轻量级,配置复杂,但是功能强大。
Zabbix:Zabbix是一款更加强大的监控工具,它不仅可以监控系统和应用的运行状态,还可以进行分布式监控、容器监控、网络监控等。Zabbix的特点是功能强大,界面友好,同时支持多种插件和自定义脚本。 MySQL zabbix-proxy
Prometheus:Prometheus是一款开源的监控和报警系统,它将所有监控数据保存为时间序列数据,并对这些数据进行高效的查询和聚合。Prometheus的特点是数据模型简单,强大的查询语言,以及可通过Pull模式获取监控数据。 grfana

4、Zabbix应用手册
4.1 Zabbix介绍
zabbix官方网站:https://www.zabbix.com/
Zabbix是一款开源的监控软件,用于监控各种网络参数、服务器的健康状况以及应用程序的状态。它能够提供灵活的通知机制,允许用户在问题发生时立即得到通知
**分布式监控**:Zabbix支持分布式监控,可以轻松地从一台主机监控远程主机和服务。**实时数据收集**:Zabbix提供了实时数据收集和图形展示功能,使管理员能够快速了解系统状态并及时响应问题。灵活的告警机制:Zabbix具有灵活的告警机制,可以根据预设的条件触发告警,并通过多种方式(如邮件、短信)通知管理员。
**自动发现**:Zabbix支持自动发现功能,可以自动检测网络中的设备和服务,简化了配置过程。模板化管理:Zabbix使用模板来简化监控项的配置,只需将模板应用于特定的主机或服务,就可以实现对多个对象的统一监控。
**Web界面**:Zabbix提供了一个直观的Web界面,使管理员能够轻松查看监控数据、配置告警和管理系统设置。Agent和Agentless监控:Zabbix支持基于Agent的监控和无Agent的监控。基于Agent的监控需要在被监控的主机上安装Zabbix Agent,而无Agent的监控则通过SNMP、IPMI等协议收集数据。
历史数据存储:Zabbix可以将历史数据存储在数据库中,以便进行长期趋势分析和报告生成。
**权限管理**:Zabbix具有强大的权限管理功能,可以定义不同角色的用户,并赋予他们对特定资源的访问权限。
4.1.1 zabbix企业版选型
Zabbix LTS (长期支持版本)的生命周期

Zabbix标准版本的生命周期
4.2 zabbix架构图详解

zabbix是一个典型的C/S(客户端/服务端)架构。
监控大致流程:zabbix-agent(客户端)获取监控数据,zabbix_server端(服务端)索要数据,然后数据会被存放至数据库,zabbix web展示所收集的监控数据。

4.2.1 zabbix 组件介绍
Zabbix Server:Zabbix Server 是 Zabbix 的核心组件,是所有配置信息、统计信息和操作数据的核心存储器。 它主要负责接收客户端发送的报告和信息,同时,所有配置、统计数据及配置操作数据均由其组织进行。
Zabbix Database Storage:主要用于存储数据,所有配置信息和 Zabbix 收集到的数据都被存储在数据库中。常用的存储设备有 MySQL、Oracle 等。
Zabbix Web 界面:这是 Zabbix 提供的 GUI 接口,通常(但不一定)与 Zabbix Server 运行在同一台物理机器上。
Zabbix Proxy 代理服务器:这是一个可选组件,常用于分布监控环境中,代理 Server 可以替 Zabbix Server 收集性能和可用性数据,汇总后统一发往 Zabbix Server 端。
Zabbix Agent 监控代理: Zabbix Agent 部署在被监控主机上,能够主动监控本地资源和应用程序,并负责收集数据发往 Zabbix Server 端或 Zabbix Proxy 端。从 zabbix 5 版本开始,zabbix_agent 分为 zabbix_agent 和 zabbix_agent2,zabbix_agent2 是第二个 agent 版本,功能更加强大,采用 go 语言编写,支持 zabbix_agent 所有功能。使用 zabbix_agent2 可监控 docker 容器、ceph、mysql、oracle、 redis等。
4.2.2 zabbix 进程介绍
根据功能和用途,默认情况下 zabbix 包含 5 个进程,分别是 zabbix_agentd/zabbix_agent2、zabbix_get、zabbix_proxy、zabbix_sender、zabbix_server,另外还有一个 zabbix_java_gateway 是可选的功能,需要另外安装。下面分别介绍下它们各自的作用。
**zabbix_agentd/zabbix_agent2**: zabbix_agentd/agent2 是 Zabbix Agent 监控代理端守护进程,此进程收集客户端数据,例如cpu 负载、内存、硬盘、网络使用情况等,推荐使用 zabbix_agent2。**zabbix_get**: zabbix 提供的一个工具,通常在 Zabbix server 或者 Zabbix proxy 端执行用来获取远程客户端信息,这其实是 Zabbix server 去 Zabbix Agent 端拉取数据的过程,此工具主要用来进行用户排错。例如在 Zabbix server 端获取不到客户端的监控数据时,可以使用 zabbix_get 命令测试获取客户端数据来做故障排查。zabbix_sender:zabbix 提供的一个工具,用于发送数据给 Zabbix server 或者 Zabbix proxy,这其实是 Zabbix Agent 端主动推送监控数据到 Zabbix Server 端的过程,通常用于耗时比较长的检查或者有大量主机(千台以上)需要监控的场景。此时通过主动推送数据到 Zabbix server,可以在很大程度上减轻 Zabbix server 的压力和负载。
zabbix_proxy:Zabbix Proxy 的代理守护进程。功能类似 Zabbix server,唯一不同的是它只是一个中转站,它需要把收集到的数据提交或者被提交到 Zabbix server上。
zabbix_java_gateway:Zabbix 2.0 之后引入的一个功能。顾名思义:Java 网关,主要用来监控 JAVA 应用环境,类似 zabbix_agentd 进程。需要特别注意的是,它只能主动去推送数据,而不能等待 zabbix server或者 zabbix proxy 来拉取数据。它的数据最终会给到 zabbix server 或者 zabbix proxy 上。
**zabbix_server**:Zabbix server 是整个 Zabbix 系统的核心进程。其它进程 zabbix_agentd、zabbix_get、zabbix_sender、zabbix_proxy、zabbix_java_gateway 的数据最终都是提交到 Zabbix server 来统一进行处理。zabbix web service:Zabbix web service 是一个用来连接外部网站服务的进程。
4.3 Zabbix 优点和不足
优点:
开源性:Zabbix作为一个开源工具,意味着用户可以免费使用,并且拥有对软件进行二次开发的灵活性。
数据采集能力:它支持多种数据收集方式,包括agent、SNMP、JMX和telnet等,还支持主动和被动模式的数据传输。用户还可以自定义插件来收集数据,这提供了高度的灵活性和适应性。
高可用性:Zabbix server对设备性能要求低,支持proxy分布式监控,这使得它能够适应不同规模和需求的监控环境。
监控能力:Zabbix能够监控各种网络参数,并提供灵活的通知机制,帮助运维人员快速定位并解决存在的问题。
模板丰富:Zabbix自带多种监控模板,这简化了新设备的监控配置过程,加快了部署速度。
自动发现与全面监控:Zabbix支持自动发现网络中的设备和服务,这减少了手动配置的工作量,并确保了监控覆盖的全面性。
报警处理:它可以针对报警默认进行固定操作,减少人为操作失误的风险,同时降低人员成本。
1 | **缺点:** |
性能瓶颈:当机器数量增加时,数据量的增大会导致数据库写入成为瓶颈。Zabbix官方指出单机上限为5000台设备,超过这个数量就需要增加proxy来分担负载
数据延迟问题:在采用主动模式即server pull方式采集数据时,如果目标机器数量庞大,则可能出现任务积压和数据延迟的问题。
数据库压力:所有数据都存在数据库里, 产生的数据据很大,瓶颈主要在数据库。
4.4 Zabbix功能
可用性和性能采集;
支持 SNMP(包括主动轮询和被动捕获)、IPMI、JMX、VMware 监控;
自定义检查;
按照自定义的时间间隔采集需要的数据;
通过 Server/Proxy 和 Agents 来执行数据采集。
- 您可以定义非常灵活的告警阈值,称之为触发器,触发器从后端数据库获得参考值。
可以根据递增计划、接收者、媒介类型自定义发送告警通知;
使用宏变量可以使告警通知变得更加高效有益;
自动动作包含远程命令。
- 使用内置图形功能可实以将监控项绘制成图形。
- Zabbix 可以追踪模拟鼠标在 Web 网站上的点击操作,来检查 Web 网站的功能和响应时间。
- 能够创建可以将多个监控项组合到单个视图中的自定义图形;
存储在数据库中的数据;
可配置的历史数据;
内置数据管理机制(housekeeping)。
将被监控设备添加为主机;
主机一旦添加到数据库中,就会采集主机数据用于监控;
将模板用于监控设备。
在模板中分组检查;
模板可以关联其他模板,获得继承。
自动发现网络设备;
Zabbix Agent 发现设备后自动注册;
基于 PHP 的 Web 前端;
可以从任何地方访问;
您可以定制自己的操作方式;
审计日志。
- Zabbix API 为 Zabbix 提供可编程接口,用于批量操作、第三方软件集成和其他用途。
- 使用 Zabbix Proxy 代理,可以轻松实现分布式远程监控。
4.5 zabbix 监控数据流程
首先,为了创建一个采集数据的监控项,您就必须先创建主机。其次,必须有一个监控项,然后创建触发器。最后,您必须有一个触发器来触发一个动作,这几个点构成了一个完整的数据流。因此,如果您想要收到 CPU load it too high on Server X 的告警,您必须首先为 Server X 创建一个主机条目,其次创建一个用于监视其 CPU 的监控项,最后创建一个触发器,用来触发 CPU is too high 这个动作,并将其发送到您的邮箱里。虽然这些步骤看起来很繁琐,但是使用模板的话,其实并不复杂。也正是由于这种设计,使得 Zabbix 的配置变得更加灵活易用。
4.5.1 Zabbix 核心概念

主机(host)
你想要监控的联网设备,有IP/DNS。
主机的逻辑组;可能包含主机和模板。一个主机组里的主机和模板之间并没有任何直接的关联。通常在给不同用户组的主机分配权限时候使用主机组。
你想要接收的主机的特定数据,一个度量/指标数据。
转化/预处理接收到的指标数据* 存入数据库之前
一个被用于定义问题阈值和“评估”监控项接收到的数据的逻辑表达式
当接收到的数据高于阈值时,触发器从“OK”变成“Problem”状态。当接收到的数据低于阈值时,触发器保留/返回“OK”的状态。
一次发生的需要注意的事情,例如触发器状态改变、发现/监控代理自动注册
提前设置的事件标记*可以被用于事件关联,权限细化设置等。
自动灵活的、精确的关联问题和解决方案
比如说,你可以定义触发器A告警的异常可以由触发器B解决,触发器B可能采用完全不同的数据采集方式。
一个处在“异常”状态的触发器
Zabbix提供的问题管理选项,例如添加评论、确认异常、改变问题级别或者手动关闭等。
预先定义的应对事件的操作
一个动作由操作(例如发出通知)和条件(什么时间进行操作)组成
一个在动作内执行操作的自定义方式; 发送通知/执行远程命令的顺序安排。
发送告警通知的方式;传送途径
关于事件的信心,将通过选设定的媒介途径发送给用户。
一个预定义好的,满足特定条件的情况下,可以在被监控主机上自动执行的命令。
一组可以被应用到一个或多个主机上的实体(监控项,触发器,图形,聚合图形,应用,LLD,Web场景)的集合
模版的应用使得主机上的监控任务部署快捷方便;也可以使监控任务的批量修改更加简单。模版是直接关联到每台单独的主机上。
一组监控项组成的逻辑分组
检查网站可浏览性的一个或多个HTTP请求
Zabbix提供的web界面
- Zabbix API允许用户使用JSON RPC协议来创建、更新和获取Zabbix对象(如主机、监控项、图形和其他)信息或者执行任何其他的自定义的任务
Zabbix监控的核心程序,主要功能是与Zabbix proxies和Agents进行交互、触发器计算、发送告警通知;并将数据集中保存等
部署在监控对象上的,能够主动监控本地资源和应用的程序
一个帮助Zabbix Server收集数据,分担Zabbix Server的负载的程序
支持Zabbix组建之间的加密通讯(server, proxy, agent, zabbix_sender 和 zabbix_get 程序)使用TLS(Transport Layer Security )协议。
5、Zabbix 常用监控架构
- 分布式监控 (企业常用) server-proxy-agent

- server-anget(点对点监控)

监控报警流程图:

6、Zabbix 监控系统监控对象
数据库: MySQL,MariaDB,Oracle,SQL Server agent
应用软件:Nginx,Apache,PHP,Tomcat agent
集群: LVS,Keepalived,HAproxy,RHCS,F5 agent
虚拟化: VMware,KVM,XEN ,docker,k8s agent
操作系统:Linux,Unix,Windows性能参数 agent
硬件: 服务器,存储,网络设备 IPMI
网络: 网络环境(内网环境,外网环境) SNMP
6.1 Zabbix监控方式
被动模式
- 被动检测: server向agent请求获取配置的各监控项相关的数据,agent接收请求、获取数据并响应给server; 适合对时效性要求较高的监控项,因为服务器可以随时请求数据。
主动模式
- 主动检测:agent向server请求与自己相关监控项配置,主动地将server配置的监控项相关的数据发送给server; 减少Zabbix服务器的负载,特别是在大量监控项时,避免了服务器对每个监控项进行轮询。主动监控能极大节约监控server的资源。
7、安装和配置 Zabbix 服务
服务器配置要求:2 安装要求 (zabbix.com)
7.1 实验准备
Centos7.9 系统服务器3台、 一台作为监控服务器, 两台台作为被监控节点, 配置好yum源、 防火墙关闭、 各节点时钟服务同步、 各节点之间可以通过主机名互相通信。
1. 所有机器关闭防火墙和selinux
1 | $ setenforing 0 |
2. 根据架构图,实验基本设置如下:
| 机器名称 | IP配置 | 服务角色 | 备注 |
|---|---|---|---|
| zabbix-server | 192.168.153.147 | zabbix-server | 开启 |
| zabbix-node1 | 192.168.153.178 | zabbix-agent-node1 | 开启 |
| zabbix-node2 | 192.168.153.179 | zabbix-agent-node2 | 开启 |
7.2 安装 Zabbix-server端
安装NGINX
1 | # 安装nginx |
安装PHP
1 | # 安装epel源 |
修改nginx配置文件
1 | [root@zabbix-server ~]# vim /etc/nginx/conf.d/zabbix.conf |
修改PHP的服务的启动用户和用户组
1 | # 进行替换 |
数据库部署
1 | # 添加数据库源 |
zabbix server 配置
1 | # 解压安装包 |
1 | # 安装编译需要的基础环境 |
部署前端代码
1 | # 切换前端代码目录 |
7.3 测试访问

游览器输入: http://zabbix.tanke.love

修改php配置文件,解决报错:
1 | # 修改配置文件参数 |
修改时区


文件位置:/app/code/zbx/conf/zabbix.conf.php

用户名:Admin
**密码:zabbix**

此故障表示没有安装zabbix-agnet或者客户端宕机
zabbix server 自我测试
1 | # 安装zabbix-agent安装源 |
再次访问web界面

7.4 zabbix 主机图形乱码解决
原因:zabbix显示中文的字体有问题,导致显示中文异常。
解决:把zabbix中文字体替换即可。


1 | # 切换值zabbix 字体目录 |

注意:修改成新的字体后,但是仍然有些许字段没有改变,生产环境建议使用英文版的。
8、配置文件详解
zabbix_server主配置文件详解
1 | [root@zabbix-server ~]# grep "^[a-Z]" /etc/zabbix/zabbix_server.conf |
9、zabbix agent版本差异解释(了解)
zabbix-agent:
- C语言开发,基于传统的单线程设计,使用单个进程来处理所有的数据收集。
zabbix-agent2:
- GO语言和C语言混合开发,基于多线程设计,采用了更先进的异步架构,能够更高效地处理并发请求和大量数据。
10、监控任意主机
监控步骤:
被监控端安装客户端工具,并修改配置文件中,server端的主机IP地址。
启动客户端工具,并且查看服务是否正常启动。
(ps netstat)服务端 web界面进行配置。





10.1 快速添加新的主机
被监控端安装客户端工具zabbix-agent
通过web界面配置过的被监控主机进行克隆。
流程图如下:




11、主机群组使用
将多个相同服务的主机,归纳一个主机群组,该主机群组可针对服务设定相同的监控项或者自定义监控项,比如多个nginx,他们所监控的指标一致,可以为它们专门创建一个主机群组,例如web-servers。实现统一,方便后期管理。



12、自定义监控模版
12.1 boot分区剩余容量监控





vfs.fs.size[fs,fs)的大小。<mode> 参数指定了如何计算和显示文件系统的大小。
fs是文件系统的具体实例。一个具体的挂载点,如/home或者/boot等等;<mode>参数决定了如何计算文件系统的大小。通常,以下是一些常见的模式:- total: 返回文件系统的总大小,包括所有已使用的和未使用的空间。
- used: 返回文件系统中已经使用的空间大小。
- free: 返回文件系统中剩余的可用空间大小。
- available: 返回文件系统中可以分配给普通用户的空间。
历史数据和趋势数据是Zabbix中存储收集到的数据两种方式:
历史数据是指Zabbix系统针对每个监控项目在每次采集时所收集到的数据,这个数据保存在Zabbix系统数据库的历史表中。因为每次采集到的数据都保存在历史表中,所以如果监控项目的更新间隔越小,则在固定时间内保存到历史表中的数据就越多。例如,如果每个监控项目的更新间隔是30秒,那么两个小时该监控项目在Zabbix数据库的历史表中就会产生240条记录,一天就会产生2880条记录。虽然对于只监控一个项目或少量项目的系统来说,这些记录可能并不显著,但对于监控大量项目或需要长时间保存数据的系统来说,历史数据可能会占用大量的存储空间,并对数据库造成较大的负载压力。常见的历史数据表如下:
**history**表:用于存放整数类型的数据,例如 CPU 使用率(以百分比表示)。**history_uint**表:用于存放无符号整数类型的数据,适合存储不会出现负值的监控数据。**history_str**表:用于存放字符串类型的数据,例如日志信息或其他文本类型的监控项。**history_text**表:用于存放长文本数据,适合存储大量文本数据(例如完整的日志行)。**history_log**表:专门用于存储日志文件的监控数据。- 每个表的字段通常包括
itemid、clock、value、ns等:
itemid:监控项的唯一标识符。clock:时间戳,记录数据采集的具体时间(以秒为单位)。value:具体的监控项值。ns:纳秒级的时间戳,确保数据在同一秒内的精确排序。
趋势数据则是按小时统计计算后的平均数据,它是一种Zabbix内建的历史数据压缩机制。趋势数据可以用来存储数字类型监控项的每小时的最小值、最大值、平均值和记录数量。由于趋势数据是计算后的汇总数据,因此其数量相对于历史数据要少得多,同时其保存的时间通常也比历史数据要长。趋势数据通常用于生成图表或报告,以便用户能够更直观地了解监控项目的长期趋势和变化。常见的表如下:
**trends**表:用于存储整数类型的数据的趋势。**trends_uint**表:用于存储无符号整数类型的数据的趋势。- 趋势数据表存储格式:每个趋势表的字段通常包括
itemid、clock、num、value_min、value_avg、value_max:
itemid:监控项的唯一标识符。clock:时间戳,表示数据对应的时间段(通常是小时级别)。num:在该时间段内的数据样本数量。value_min:该时间段内的最小值。value_avg:该时间段内的平均值。value_max:该时间段内的最大值。
强烈建议将历史数据保留时长设置得尽可能的小。这么做可以让数据库不会因存储了大量的历史数据,导致超负荷运行。可以选择长时间的保留趋势数据,来替代长期需要的历史数据。例如:设置成保留14天历史数据和5年的趋势数据。
创建图形




添加主机



查看监控指标



或者:

测试监控数据变化
1 | # 被监控端boot分区压测 |
被监控端压测完成以后,回到监控面板查看图形

12.2 网卡出入流量监控
12.2.1 ens33网卡进入流量监控







net.if.in[if,ens33 是网络接口的名称。net.if.in[ens33] 键值会返回网络接口 ens33 上接收到的字节总数。
if是网络接口的具体实例,表示我们希望监控的网络接口。<mode>参数决定了如何计算或显示输入的数据流量。常见的模式如下:- bytes: 返回通过该网络接口接收到的数据量(以字节为单位)。
- packets: 返回通过该网络接口接收到的数据包数量。
- errors: 返回接收到的数据包中发生的错误数量。
- dropped: 返回接收到的数据包中被丢弃的数量。
12.2.2 ens33网卡出去流量监控
选择配置–>模版–>监控项







12.3 监控服务端口



创建图形



net.tcp.service[service,<ip>,<port>] 是一个用于检查TCP服务是否在某个端口上运行的键值(key)。这个键值会尝试与指定的端口建立TCP连接,并检查连接是否成功。如果连接成功,则意味着该服务在该端口上正在运行。
service指的是具体的 TCP 服务(如 Web 服务、FTP 服务、数据库服务等),此参数用于标识所监控的服务类型。<ip>参数代表 TCP 服务所绑定的 IP 地址。它标识了该服务所在的主机或服务器的 IP 地址。<port>参数代表该 TCP 服务所监听的端口号。每个服务都通过特定的端口号来区分其他服务。例如,HTTP 服务通常运行在端口80 。net.tcp.service[http,192.168.174.11,80]: 监控或查询运行在 IP 地址192.168.174.11上端口80的 HTTP 服务的状态。net.tcp.service[ftp,10.96.74.22,21]: 监控或查询运行在 IP 地址10.96.74.22上端口21的 FTP 服务的状态。
12.2.3监控网卡的上下流量总和







12.4 监控系统进程数量
- 系统总进程数量



创建监控项图形


proc.num 是一个用于监控进程数量的键值(key)。它允许你根据进程名称、用户、状态、命令行参数和区域(在容器化环境中)来过滤和计数进程。
键值 proc.num[<name>,<user>,<state>,<cmdline>,<zone>] 的参数是可选的,你可以根据需要包含或省略它们。以下是这些参数的说明:
<name>:进程的名称或名称模式。可以使用通配符(如*)来匹配多个进程。<user>:运行进程的用户名。<state>:进程的状态。可以是Z(僵尸)、R(运行)、S(睡眠)、T(停止)或D(不可中断的睡眠)。<cmdline>:进程的命令行参数。这是一个正则表达式,用于匹配进程的完整命令行。<zone>:在容器化环境中,这个参数可以用来指定容器或区域。
如果不提供某个参数,那么Zabbix将不会根据该参数进行过滤。例如,如果你只提供进程名称,那么Zabbix将计算具有该名称的所有进程的数量,不考虑其他参数。
proc.num[mysql]计算名为 mysql 的进程数量。
proc.num[,nginx]计算用户 nginx 运行的进程数量。
- 运行中的进程数量

- 监控系统中沉睡的进程数量

12.5 监控cpu的状态
- cpu 五分钟负载情况

system.cpu.load[<cpu>,<mode>] 是一个用于监控CPU负载的键值(key)。这个键值提供了关于CPU使用情况的信息,通常用于评估系统的性能和瓶颈。
下面是关于这个键值的参数的详细说明:
:这个参数指定了要监控的CPU或CPU核心。它可以是以下几种值之一: all:表示监控所有CPU核心的平均负载。
0到N(其中N是CPU核心的数量减去1):表示监控特定的CPU核心。例如,0表示第一个CPU核心,1表示第二个CPU核心,依此类推。
avg1,avg5,avg15:这些不是CPU核心编号,而是表示过去1分钟、5分钟和15分钟的平均负载。这些值通常用于评估系统负载随时间的变化情况。
- cpu 1分钟负载情况

- cpu 15分钟负载情况
13、自定义监控设置(Items)
客户端(安装有zabbix-agent端):
通过命令、脚本取出需要监控的值;
安装zabbix-agent2,编写配置文件、创建键值;格式为:key=values,key为监控项名称。values为监控项的值。通过shell命令取出。
重启客户端服务,并测试是否取出数据。
zabbix-agent2 -t Key名
服务端:
服务端命令行测试是否
get到客户端自定义监控的值;web界面:获取到的键值与监控项关联;
web界面:测试。
13.1 自定义监控项编写
小试牛刀:监控web服务80端口
1 | # 命令行取值 |

1 | # 查看自定监控配置文件存放路径 |
Include=/etc/zabbix/zabbix_agent2.d/*.conf 自定义监控项配置文件默认位置。
UserParameter=key,cmd
UserParameter=固定格式,表示要自定义监控项。
key表示键值名称,也就是自定义监控项的名称,命名最好为 单词+”_”
cmd表示取值的命令或者脚本。
1 | # 客户端本地测试 |

解释:**web_port_status** 表示自定义监控的Key,非配置文件名称。
1 | # 服务端测试,安装测试工具 |
解释:
-s 客户端IP地址;
-p 客户端zabbix-agent 端口,默认:10050;
-k 客户端自定义监控项Key名。

web界面添加自定义监控项

配置–>主机–>选择主机监控项


参数解释:
历史数据保留时长:根据服务器的配置决定,建议保留时长不宜过久;
趋势存储时间:通常趋势数据设置的的留存时间应当比历史数据留存时间设置的长。
详细信息参考官方文档:4 历史数据与趋势数据 (zabbix.com)




web 查看自定义监控项数据


13.2 获取不到内容报错解决
报错内容

1 | **Unknown metric web_port_statuss** |
客户端测试时,自定义监控名称写错;
自定义监控项配置文件内部语法错误,例如:固定格式、命令;
自定义监控项创建完成没有重启客户端。
13.3 使用脚本定义自定义监控项
1 | **详细请见附件基于脚本实现自定义监控项** |
14、 自定义图形
14.1 自定义单个监控项图形





查看自定义图形


14.2 仪表盘创建(聚合图形)
仪表盘用于,将我们自定以图像进行集中值一个界面进行展示,使得我们更方便的找到服务器的瓶颈。






查看自定义仪表盘



15、触发器器设置( Triggers) P0级服务
15.1 触发器介绍
触发器是条件的定义,一个触发器是根据一个监控项的返回值,将之对比预先设置的阈值,当监控项返回了不符合预定义的值范围后,就进行触发下一步操作的警戒线,一般要对创建的监控项设置触发器以及触发方式和值的大小
可以在指定主机上创建触发器,只是针对指定主机有效;
也可以在指定
模板上创建触发器,则使用此模板的所有主机都有效,一个模板中可以有多触发器;
触发器中使用的表达式是非常灵活的。你可以使用它们去创建关于监控统计的复杂逻辑测试。
15.2 触发器严重性
触发器严重性表示触发器的重要程度,Zabbix支持下列6种触发器的严重程度:

严重性功能:
通过不同的颜色区分不同的严重程度;
用户媒介,不同的用户媒介(通知渠道)代表不同的严重程度。例如,短信 - 高严重性,email - 其他;
不同的严重性通过触发器执行对应的条件动作。
15.3 配置触发器
15.3.1 触发器示例一:web服务端口




解释:
监控项:自定义监控项默认没有触发器,需要自己去添加,选择自定义监控项的名称;
功能:
last函数:表示最新的值和最近一次的值作比较。结果:如果自定义监控项取出的值为0时,触发报警。

解释:表达式 zabbix5和zabbix6之间的区别
zabbix 6
- last(/nginx01/web_port_status)=0 # 函数(/主机/自定义监控项)=0
zabbix 5
- {nginx01:web_port_status.last()}=0 # {主机:自定义监控项名称.功能函数}=0
测试触发器是否生效
1 | # 客户端关闭nginx |
web界面查看

15.3.2 触发器示例二:cpu 1分钟负载
1 | $ dd if=/dev/zero of=/1.txt bs=1M count=4000 |



查看触发器


表达式:last(/nginx_status_monitor/system.cpu.load[all,avg1])>=0.4
解释:表达式函数(/监控模版/自定义监控项)>=0.4
图形查看触发器

15.4 触发器常用表达式功能函数介绍

触发器示例场景
1 | # 触发器示例场景1:www.zabbix.com的处理器负载过高 |
16、zabbix监控模版
16.1 zabbix server自带模版
1 | Linux by Zabbix agent |
| 名称 | 解释 |
|---|---|
| Linux: Host name of Zabbix agent running | Linux:Zabbix代理运行的主机名 |
| Linux: Zabbix agent ping | Linux:Zabbix代理ping |
| Linux: Version of Zabbix agent running | Linux:运行Zabbix代理的版本 |
| Linux: Maximum number of open file descriptors | 打开文件描述符的最大数量 |
| Linux: Maximum number of processes | Linux:进程的最大数量 |
| Linux: Number of processes | Linux:进程数 |
| Linux: Number of running processes | Linux:正在运行的进程数 |
| Linux: System boot time | Linux:系统启动时间 |
| Linux: Interrupts per second | Linux:每秒中断次数 |
| Linux: Load average (1m avg) | Linux:平均负载(平均1分钟) |
| Linux: Load average (5m avg) | Linux:平均负载(平均5分钟) |
| Linux: Load average (15m avg) | Linux:平均负载(平均15分钟) |
| Linux: Number of CPUs | Linux:CPU数量 |
| Linux: Context switches per second | Linux:每秒上下文切换次数 |
| Linux: CPU idle time: Linux: CPU utilization | Linux:CPU空闲时间:Linux:CPU利用率 |
| Linux: CPU guest time | Linux 中的 CPU guest time 是指虚拟机在宿主机上运行期间,CPU 资源被占用的时间。这个指标可以帮助管理员了解虚拟机对宿主机 CPU 资源的使用情况,以便进行性能优化和资源分配。 |
| Linux: CPU guest nice time | Linux 中的 CPU guest nice time 是指虚拟机在宿主机上运行期间,CPU 资源被占用的 nice 时间。nice 值是 Linux 系统中用于控制进程优先级的一个参数,范围从 -20(最高优先级)到 19(最低优先级)。 |
| Linux: CPU idle time | 在 Linux 系统中,CPU idle time 指的是 CPU 处于空闲状态的时间。这是系统性能监控中的一个重要指标,因为它可以帮助你理解系统资源是否得到了充分利用或者是否存在过剩的计算能力。 |
| Linux: CPU interrupt time | Linux 中的 CPU interrupt time 是指 CPU 在处理中断请求时所花费的时间。中断是计算机系统中的一种机制,用于响应硬件设备或软件程序的请求,以便进行相应的操作。 |
| Linux: CPU iowait time | 在 Linux 中,CPU iowait time(I/O等待时间)是指 CPU 等待 I/O 操作完成的时间。当 CPU 需要从磁盘、网络或其他慢速设备读取数据时,如果该数据尚未准备好,CPU 就会进入等待状态。iowait 是衡量系统 I/O 性能的关键指标之一,它可以帮助识别是否存在 I/O 瓶颈问题。 |
1 | Apache by HTTP |
| 名称 | 解释 |
|---|---|
| Apache: Service ping | httpd服务是否存活 |
| Apache: Service response time | Apache 服务器的响应时间。是指从客户端发送请求到接收到服务器响应所需的时间。这个指标对于评估服务器性能和用户体验非常重要。 |
| Apache: Get status: Apache: Total workers idle | Apache: Total workers idle 是指当前空闲的工作进程数量。这个指标可以帮助你了解服务器的负载情况,以及是否需要增加或减少工作进程的数量来优化性能。 |
| Apache: Get status: Apache: Total workers busy | Apache: Total workers busy 是指当前正在处理请求的工作进程数量。这个指标可以帮助你了解服务器的负载情况,以及是否需要增加或减少工作进程的数量来优化性能。 |
| Apache: Get status: Apache: Workers waiting for connection | Apache: Workers waiting for connection 是指当前正在等待连接的工作进程数量。这个指标可以帮助你了解服务器的负载情况,以及是否需要增加或减少工作进程的数量来优化性能。 |
| Apache: Get status: Apache: Workers starting up | Apache: Workers starting up 是指当前正在启动的工作进程数量。这个指标可以帮助你了解服务器的负载情况,以及是否需要增加或减少工作进程的数量来优化性能。 |
| Apache: Get status: Apache: Workers slot with no current process | 指当前没有正在处理请求的工作进程的插槽数量。 |
| Apache: Get status: Apache: Workers sending reply | 指当前正在发送响应的工作进程数量。 |
| Apache: Get status: Apache: Workers reading request | 指当前正在读取请求的工作进程数量。 |
| Apache: Get status: Apache: Workers logging | 指当前正在记录日志的工作进程数量。 |
| Apache: Get status: Apache: Workers keepalive (read) | 指当前正在处理 Keep-Alive 连接的工作进程数量。 |
| Apache: Get status: Apache: Workers finishing | 指当前正在结束请求的工作进程数量。 |
| Apache: Get status: Apache: Workers DNS lookup | 指当前正在执行 DNS 查询的工作进程数量。 |
| Apache: Get status: Apache: Workers closing connection | 指当前正在关闭连接的工作进程数量。 |
| Apache: Get status: Apache: Workers idle cleanup | 指当前正在执行空闲清理的工作进程数量。 |
| Apache: Get status: Apache: Version | 指 Apache HTTP Server 的版本号。 |
| Apache: Get status: Apache: Uptime | 指 Apache HTTP Server 自上次启动以来的运行时间。 |
| Apache: Get status: Apache: Requests per second | 指 Apache HTTP Server 每秒处理的请求数量。 |
| Apache: Get status: Apache: Total requests | 指 Apache HTTP Server 自上次启动以来处理的总请求数量。 |
| Apache: Get status | 指获取 Apache HTTP Server 的状态信息。 |
| Apache: Get status: Apache: Bytes per second | 指 Apache HTTP Server 每秒传输的字节数。 |
| Apache: Get status: Apache: Total bytes | 指 Apache HTTP Server 自上次启动以来传输的总字节数。 |
1 | Nginx by Zabbix agent |
17、触发器 Action
17.1 Action 动作介绍
Zabbix中的Action是根据不同的事件状态执行相应操作的功能。
在Zabbix监控系统中,Action是一个核心功能,它允许你基于事件的不同状态来执行预定义的操作。这些操作可以极大地自动化日常的运维工作,减少手动干预的需要。以下是Zabbix Action的一些主要特点和用途:
自动响应:当监控系统检测到问题(如触发器状态变化)时,可以自动执行一系列操作,而不是需要人工介入。
可配置性::自定义Action,例如发送报警通知、执行远程命令等。
权限管理:为了执行某些操作,如重启服务,可能需要相应的权限。因此,配置sudo权限或修改zabbix配置文件以允许接收远程命令是常见的设置步骤。
报警通知:最常见的用法是在检测到问题时,通过邮件、短信或其他方式将报警信息发送给指定的用户。
远程命令执行:可以配置Action来在特定条件下执行远程命令,如系统重启、服务重启等,这通常需要确保Zabbix用户具有执行这些命令的权限。
日志记录:所有执行的Action都会被记录在Zabbix的日志中,便于后续的问题排查和分析。
17.2 告警分类
| 报警方式 | 企业使用场景 |
|---|---|
| 邮件告警 | 企业邮箱,免费试用 |
| 企业微信/飞书-告警机器人 | 企业微信,免费使用 |
| OA系统(钉钉) | 钉钉,免费使用 |
| 短信 | 0.04元/条左右,云厂商,收费 |
| 电话 | 收费 |
17.2 邮箱告警
详细请见附件:zabbix 6.0 结合邮箱触发告警
17.3 飞书告警
详细请见附件:zabbix 6.0结合飞书触发告警
17.4 zabbix 基于ssh远程执行故障恢复操作




zabbix中远程命令 ssh报错Cannot obtain authentication methods: Error waiting on socket
去agent2节点中的/etc/ssh/sshd_config中,将UseDNS打开注释并将yes改为no然后重启sshd服务。
UseDNS 选项打开状态下,当客户端试图登录SSH服务器时,服务器端先根据客户端的IP地址进行DNS,PTR反向查询出客户端的主机名,然后根据查询出的客户端主机名进行DNS正向A记录查询,验证与其原始IP地址是否一致,这是防止客户端欺骗的一种措施,但一般我们的是动态IP不会有PTR记录,打开这个选项不过是在白白浪费时间而已,不如将其关闭。Linux优化时常这样做。
18、宏
18.1 介绍
Zabbix中的宏是一种用于简化配置和提高可重用性的功能强大的工具。在Zabbix中,宏可以被视为一种变量,用于保存预设的文本模式,并在调用时将其替换为相应的值。例如,内置宏{HOST.NAME}会在使用中自动替换为对应主机的名称。
18.2 设置优先级
全局宏:作用于所有模板和主机,但优先级最低。
模板宏:仅适用于关联的模板。
主机宏:特定于单个主机。
18.3 作用及场景
简化配置:通过使用宏,可以在多个地方重复使用相同的值,而不必手动更改每个实例。
统一管理:方便后期统一修改和维护,例如,如果需要更改服务器名称,只需更改全局宏一次即可。
实际应用场景
- 监控项和触发器:在创建监控项或触发器时,可以使用宏来定义动态的名称或参数值。
18.4 宏设置
触发动作的名字:{ACTION.NAME}
日期格式为yyyy.mm.dd:{DATE}
触发动作的事件的时长:{EVENT.AGE}
触发动作的事件的日期:{EVENT.DATE}
事件持续时间:{EVENT.DURATION}
触发动作的事件的数字ID:{EVENT.ID}
触发动作的问题事件名称:{EVENT.NAME}
描述事件严重性的数值:{EVENT.NSEVERITY}
描述事件对象的数值:{EVENT.OBJECT}
问题对应触发器的当前值:{EVENT.OPDATA}
事件恢复日期:{EVENT.RECOVERY.DATE}
恢复时间名称:{EVENT.RECOVERY.NAME}
恢复事件的文字描述:{EVENT.RECOVERY.STATUS}
出发动作的事件的文字描述:{EVENT.STATUS}
触发动作的事件时间*:{EVENT.TIME}
依赖于主机设置的主机IP地址或DNS名称:{HOST.CONN}
主机描述.:{HOST.DESCRIPTION}
主机名称:{HOST.HOST}
主机 ID.:{HOST.ID}
主机IP地址:{HOST.IP}
可见的主机名:{HOST.NAME}
主机(代理)端口:{HOST.PORT}
目标主机IP地址或DNS名称,取决于主机设置:{HOST.TARGET.CONN}
目标主机的DNS名称:{HOST.TARGET.DNS}
目标主机的技术名称:{HOST.TARGET.HOST}
目标主机的IP地址。:{HOST.TARGET.IP}
目标主机的技术名称:{HOST.TARGET.NAME}
引发通知的触发器表达式中的第N个监控项的描述。:{ITEM.DESCRIPTION}
引发通知的触发器表达式中的第 N 个监控项的序列ID。:{ITEM.ID}
触发器表达式中导致通知的第 N 监控项的键:{ITEM.KEY}
触发器表达式中导致通知的第N个监控项的名称:{ITEM.NAME}
触发器表达式中导致通知的第 N 监控项的最新状态:{ITEM.STATE}
如果在触发器状态更改的上下文中使用:{ITEM.VALUE}
触发器表达式中导致通知的第N个监控项的值类型:{ITEM.VALUETYPE}
触发器描述。:{TRIGGER.DESCRIPTION}
触发器表达式。:{TRIGGER.EXPRESSION}
触发器的名称 (已解析宏).:{TRIGGER.NAME}
触发器的原始名称 (即未解析宏).:{TRIGGER.NAME.ORIG}
触发器的最新状态 可能的值: 未知 和 正常:{TRIGGER.STATE}
当前触发器的值 可以是 PROBLEM 或者 OK:{TRIGGER.STATUS}
当前触发数值: 0 - 触发器处于正常状态, 1 - 触发器处于问题状态。:{TRIGGER.VALUE}
19、zabbix 自动发现
为了满足监控企业成千上万台服务器,因此我们需要使用Zabbix批量监控来实现。自动发现功能是一个强大的网络监控工具,它允许系统管理员无需手动添加即可自动检测网络中的设备和服务。自动发现功能发现被监控对象。同时自动发现功能能够提高监控系统的效率,因为它能够自动发现并添加新的主机或服务,使得管理员无需手动添加监控对象。
自动发现(被动模式):由服务端主动发起,Zabbix Server开启发现进程,定时扫描局域网中IP服务器、设备。实现自动将发现主机、自动将主机添加到主机组、自动加载模板、自动创建项目(item)、自动创建图像等功能。缺点:当 Agent服务器过多的时候采用自动发现,zabbix-server压力会比较大,自动添加主机进度就会非常慢。






查看自动发现主机


https://www.cnblogs.com/zdoubly/p/9222902.html
20、zabbix自动注册
自动注册(主动模式):Zabbix Server 等待 Zabbix Agent2主动上报。由客户端主动发起,客户端必须安装并启动Agent,否则无法被自动注册添加至主机列表。
20.1 zabbix自动注册介绍
Zabbix 自动注册是一种方便的功能,它允许 Zabbix Agent2 主动向 Zabbix Server 注册自己,而无需手动在 Zabbix 中为每个主机创建条目。以下是实现 Zabbix 自动注册的关键步骤:
配置元数据:在 Zabbix Agent2 的配置文件中,需要设置一些参数,如
Hostname、HostMetadata等客户端的元数据信息,以便 Zabbix Server 根据这些信息来匹配服务器的主机或模板。启用 Agent2 的主动模式:确保 Zabbix Agent2 是以主动模式运行的,即 Agentd必须安装并启动。在被动模式下,Zabbix Server 会主动扫描局域网中的设备,这在 Agent 数量较多时可能会给 Zabbix Server 带来较大压力。
修改 zabbix_agent2.conf 文件:在客户端的 zabbix_agent2.conf 文件中,需要定义要执行的监控命令和自定义的 key。这些 key 将与服务器端的监控项相对应。
20.2 zabbix自动注册操作
客户端配置
1 | #>>> 被监控端修改zabbix-agent2配置文件,开启主动模式 |
服务端配置




21、Zabbix 系列之分布式监控 Proxy 代理

21.1 介绍
Zabbix Proxy 可以代表 Zabbix Server 收集性能和可用性数据。
通过这种方式,Proxy 可以自己承担一些收集数据的负载,并减轻 Zabbix Server 的负担。
此外,当所有 Agents 和 Proxy 都向一个 Zabbix Server 报告并且所有数据都集中收集时,使用 Proxy 代理是实现集中式和分布式监控的最简单方法。Zabbix Proxy 代理是一个数据收集器,它不运行触发器、处理事件或发送警报。
21.2 应用场景
- 监控远程位置:Zabbix Proxy 可以部署在远程位置,比如分支机构或数据中心,以收集该位置下所有被监控设备的数据。
这样可以减少网络带宽的使用,因为 Proxy 可以先将数据进行聚合,然后再传输到中央的 Zabbix Server。 - 监控通信不可靠的场景:当网络环境不稳定或通信可靠性不高时,Zabbix Proxy 可以作为一个缓存或中转站。即使网络暂时中断,Proxy 也可以继续收集数据,并在网络恢复后将数据发送给 Zabbix Server。这有助于确保数据的完整性和可靠性。
- 监视数千个设备:当需要监控的设备数量非常大时,单一的 Zabbix Server 可能无法处理所有的数据。在这种情况下,可以使用多个 Zabbix Proxy 来分散负载。每个 Proxy 负责一部分设备的监控,然后将数据发送给 Zabbix Server 进行集中处理。
- 多机房采集:通过使用 Zabbix Proxy,可以简化分布式监控的维护。管理员只需要配置和维护 Zabbix Server 和各个 Proxy,而不需要直接管理所有的被监控设备。此外,由于 Proxy 可以处理一些基本的监控任务(如数据聚合、存储和转发),因此可以减少对 Zabbix Server 的依赖,降低单点故障的风险。
21.3 Zabbix Proxy 必须使用单独的数据库的原因
- 数据一致性和完整性: Zabbix Proxy 代理负责收集来自被监控设备的数据,并将这些数据暂时存储在本地数据库中。如果 Proxy 代理和 Server 共享同一个数据库,可能会导致数据写入的冲突和混乱,尤其是在高并发或网络不稳定的情况下。使用单独的数据库可以确保 Proxy 代理收集的数据在传输到 Server 之前得到妥善保存,并且不会因为 Server 的临时通信问题而丢失。
- 减轻server压力: Zabbix Proxy 代理可以在一定程度上分担 Zabbix Server 的压力,特别是在监控大量设备或远程区域设备时。通过使用单独的数据库,Proxy 代理可以在本地处理大部分的数据收集和存储工作,然后再将汇总后的数据发送给 Server,从而减轻 Server 的负担。
21.4 安装
安装数据库
1 | #>>> 安装mariadb |
注意:zabbix-proxy主机名需要和配置文件中的Hostname保持一致
zabbix-agent2配置
1 | [root@web03 ~]# hostname -I |
zabbix 服务端 web界面配置




配置主机


注意:如果主机可用性长时间没有变绿,则先重启被监控端zabbix-agnet2,和proxy端的zabbix-proxy。
22、zabbix优化方案
zabbix-proxy:当监控集群规模庞大时,使用zabbix-proxy,减少Zabbix Server的负载。
数据库优化:HA,读写分离,创建和维护适当的索引,减少查询时间。
主机和模版优化:简化配置管理,确保一致性;合理分组监控项,避免单个主机过多监控项;减少每个主机的监控负担,提高性能,使用低频率的监控项收集非关键数据,高频率的监控项收集关键数据。
触发器优化:减少触发器数量,避免不必要的复杂逻辑。
历史数据和趋势数据优化:设置合理的数据保留周期,减少数据库负担。定期清理旧数据,防止数据库膨胀。
调整 Zabbix 服务器参数:
- StartPollers:控制 Zabbix 服务器同时运行的轮询器进程数量,建议设置为系统 CPU 核数的 2-4 倍。 轮询器负责主动从客户端(Zabbix Agent)或其他监控对象(如 HTTP、SNMP 等)获取数据。
- StartTrappers:控制 Zabbix 服务器同时运行的 trapper 进程数量,建议设置为 10-20。 该进程用于接收 Zabbix 客户端和其他设备主动发送的数据(例如主动模式下的监控数据)。
- CacheSize:用于存储历史数据和趋势数据的缓存大小,建议设置为系统内存的 10%-20%。以减少数据库负载。 缓存越大,Zabbix 可以更高效地处理和存储数据,从而减少对数据库的频繁读写操作。
- HistoryCacheSize:历史缓存大小,用于缓存历史数据,减少数据库的 I/O 负载。建议:64M 到 256M,根据监控数据趋势计算的需求设置。
- Timeout:设置 Zabbix 服务器与代理或受监控对象的通信超时时间,可以根据网络状况适当增加,但不宜过大,以免延迟过多。
- StartDiscoverers:控制 Zabbix 服务器同时运行的发现进程数量,决定自动发现的并发能力。默认为1。
- StartDBSyncers:数据库同步进程数量,用于将数据从 Zabbix 缓存写入数据库。默认为4。
23、zabbix结合Grafana实现图形展示
详细请见后续文章。







