Zabbix 学习路线和要点摘抄

zabbix 相关书籍

• Zabbix 企业级分布式监控系统 (吴兆松) (Z-Library)
• 深入理解 Zabbix 监控系统 (鲍光亚) (Z-Library)

roadmap

• 本文根据参考书籍目录得出 roadmap 并摘录要点为新手作指引，未完善的内容可自行百度学习

• 参考书籍：Zabbix 企业级分布式监控系统

• 第 1 章 开篇——监控系统简介

  • 1.1 监控系统的功能概述（什么是监控系统？）

    监控系统，一是监测，二是控制，监测以达到控制的效果，在计算机领域，可以将其分为 5 种监控类型。

    • 应用性能监控（Application Performance Monitoring）。
    • 业务交易监控（Business Transaction Monitoring）。
    • 网络性能监控（Network Monitoring）。
    • 操作系统监控（System Monitoring）。
    • 网络站点监控（Website Monitoring）。

    大规模的监控环境，被监控节点多且监控类型多产生的数据和网络连接开销非常大，数据采集方式除了使用主动采集模式，还需要使用代理架构分摊服务器端的性能开销。

    ​​

    通常监控系统会选用以下 几种数据存储方式。

    （1）本地存储。使用本地磁盘，基于文件的方式存储。

    （2）使用时序数据库进行数据存储，如古老的环状数据库 （Round Robin Database, RRD）等。近年来，随着时序数据技术的不断发展，出现了比较成熟的时序数据库，如 OpenTSDB（底层存储基于 HBase）、Graphite、InfluxDB、Prometheus 等，与直接使用文件的存储方式相比，这些时序数据库更加高效。
    （ 3 ） 使 用 数 据 库 管 理 系 统 （ Database Management System, DBMS）进行数据存储，如常见的 MySQL、Oracle、SQL Server 等。使用 这种数据库来存储监控数据，当数据量达到一定规模时，其读/写效率 均会显著下降，数据库的压力比较大，通常优化方案思路有 3 种，一是 减少数据的存储量；二是优化数据库本身，调整配置参数，优化运行 环境；三是使用分布式数据库和数据库集群技术方案。
    （4）使用 NoSQL 数据库进行数据存储。NoSQL 相对于 DBMS 这种传统 的数据库有着一些天然的优势，单机的 QPS 通常较高。但 NoSQL 本身并 不是为监控系统设计的，在数据结构存储方面存在一些缺陷
    （5）使用列存储数据库进行数据存储。列存储数据库由于其设计 之初专为大数据而有所考虑，故无须担心其存储容量，底层均有良好 的解决方案。但由于其部署、运维均较为复杂，故一般监控系统也不 会常采用这种技术作为数据库存储。这方面的数据库代表为 HBase。
    （6）使用全文搜索引擎数据库进行监控数据存储。这方面的代表 是 Elasticsearch，其作为监控数据库存储监控数据具有天然的优势， 支持集群、分布式部署、容灾，并且集群能够提供较高的性能。目前 采用全文搜索引擎数据库进行监控数据存储，典型的代表是 ELK 套件，在 Zabbix 4.0 中可以选用 Elasticsearch 作为数据库存储。

    监控系统的重要功能是根据设定的阈值进行告警，将不同级别的告警分成不同的梯度发送给不同的告警接收人。告警模块需要支持故障的有效汇报和集中汇报，尽量避免出现“告警风暴”，防止同一时间大量发送重复、类 似的告警，即告警功能支持对告警内容进行分析和自动处理，防止误报、漏报及抖动。

    事后还需要对告警信息进行统计分析，以方便衡量系统的稳定性、可用性。通常使用 SLA 服务质量指标来衡量。

  • 为什么要使用监控

    1.对系统不间断实时监控
    2.实时反馈系统当前状态
    3.保证服务可靠性安全性
    4.保证业务持续稳定运行

  • 如果去到一家新公司，如何入手监控（怎么实现监控系统？新入职）

    1.硬件监控 路由器、交换机、防火墙
    2.系统监控 CPU、内存、磁盘、网络、进程、 TCP
    3.服务监控 nginx、 php、 tomcat、 redis、 memcache、 mysql
    4.WEB 监控 请求时间、响应时间、加载时间、
    5.日志监控 ELk（收集、存储、分析、展示） 日志易
    6.安全监控 Firewalld、 WAF(Nginx+lua)、安全宝、牛盾云、安全狗
    7.网络监控 smokeping 多机房
    8.业务监控 活动引入多少流量、产生多少注册量、带来多大价值

  • 单机时代如何监控，比如我们需要监控磁盘的使用率

    CPU 监控命令: w、 top、 htop、 glances

    %Cpu(s): 0.3 us, 0.3 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
    us 用户态: 跟用户的操作有关 35%
    sy 系统态: 跟内核的处理有关 60%
    id CPU 空闲:
    

    内存监控命令: free

    [root@m01 ~]# free -h
                  total        used        free      shared  buff/cache   available
    Mem:           977M        105M        724M        6.6M        148M        729M
    Swap:          1.0G          0B        1.0G
    

    磁盘监控命令: df、 iotop

    Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
    sda 0.80 25.32 33.36 221034 291193
    设备名 每秒传输次数 每秒读大小 每秒写大小 读的总大小 写的总大小
    

    1.如何查看磁盘使用率 df -h
    2.监控磁盘的那些指标 block、 inode
    3.如何获取具体的信息 df -h | awk '{if(NR>1) print $6,$5}'
    4.获取的数值到达多少报警 80%

    网络监控命令: ifconfig、 route、 glances、 iftop、 nethogs、 netstat

    单位换算
    Mbps 100Mbps/8
    MB 12MB
    iftop 中间的<= =>这两个左右箭头，表示的是流量的方向。
    TX：发送流量、 RX：接收流量、 TOTAL：总流量
    #查看 TCP11 中状态
    netstat -an|grep ESTABLISHED
    netstat -rn # 查看路由信息
    netstat -lntup
    

    需求: 每隔 1 分钟监控一次内存,当你的可用内存低于 100m,发邮件报警,要求显示剩余内存 1.怎么获取内存可用的值 free -m|awk '/^Mem/' 2.获取到内存可用的值如何和设定的阈值进行比较 3.比较如果大于 100m 则不处理，如果小于 100 则报警 4.如何每隔 1 分钟执行一次

    [root@ZabbixServer ~]# cat free.sh
    #!/usr/bin/bash
    HostName=$(hostname)_$(hostname -i)
    Date=$(date +%F)
    while true;do
    Free=$(free -m|awk '/^Mem/{print $NF}')
    if [ $Free -le 100 ];then
    echo "$Date: $HostName Mem Is < ${Free}MB"
    fi
    sleep 5
    done
    

  • 1.2 监控系统的实现原理（怎么实现监控系统？原理）

    • 一个监控系统的组成大体可以分为两部分：数据采集部分（客户 端，Agent）和数据存储分析告警展示部分（服务器端，Server）
    • 监控系统数据采集可以分为两种：专用客 户端采集和公用协议采集（SNMP、IPMI、SSH、Telnet 等）
    • 监控系统数据采集的工作模式可以分为被动模式（从服务器端到 客户端采集数据，对应的英文单词是 pull）和主动模式（客户端主动 上报数据到服务器端，对应的英文单词是 push）两种。一般来说，被动模式对监控控制端服务器的开销较大，适合小规 模的监控环境；主动模式对监控控制端服务器的开销较小，适合大规 模的监控环境。

  • 1.3 监控系统的开源产品（怎么实现监控系统？现有产品）

    在监控软件中，开源的解决方案有流量监控（MRTG、Cacti、 SmokePing 等 ） 、 性能告警 （ Nagios 、 Zabbix 、 Zenoss Core 、 Ganglia 、 Netdata 等 ） 、 基于时 序据库存储数据的监控 （Graphite、OpenTSDB、InfluxDB、Prometheus、OpenFalcon 等）、 基于全文搜索引擎数据库存储数据的监控（如 ELK 套件）可供选择。上述各监控产品具有一些共同特征，例如 采集数据、分析展示、告警以及简单的故障自动处理等，最终都能达 到对 IT 系统服务可用性的完全展示。需要说明的是，当前的时序数据库侧重于监控数据的存储，其采集需要借助其他工具来实现。时序监控产品的设计理念较为先进，具有很多创新功能

    流行的监控工具

    1.Zabbix
    2.Lepus(天兔)数据库监控系统
    3.Open-Falcon 小米
    4.Prometheus(普罗米修斯， Docker、 K8s)

• 第 2 章 Zabbix 简介/

  • 2.3 Zabbix 是一个什么样的产品（Zabbix 是什么？简介）

    • Zabbix 是一个企业级的高度集成的开源监控软件，提供了分布式 监控解决方案，可以用来监控设备、服务等的可用性和性能。其产品不分企业版和社区版，是一个真正的源码开放产品，用户可以自由下载并使用该软件。

  • 2.4 为何选择 Zabbix 作为监控系统（为什么用 Zabbix？）

    可自由修改发布(GPL2.0)，搭建环境、安装和配置简单，完全支持 Linux、UNIX、Windows、AIX、BSD 和 Solaris，C 语言编写占用非常少性能速度非常好，开源社区支持良好，超强扩展能力只有想不 到的事情，没有办不到的事情

  • 2.1 Zabbix 的用户群体都有谁（Zabbix 谁来用？）

    • Zabbix 自身的定位是中型企业和大型企业
    • 单个服务器节点可以支持 10 万台 设备的监控，其每秒可以处理 5 万次请求（NVPS 在有历史数据和触发器 的情况下为 5 万次，而在无历史数据和触发器的情况下则可以达到单机 30 万次）。

  • 2.2 使用 Zabbix 需要具备什么基础（Zabbix 怎么用？所需基础）

    • 入门阶段：以前从未接触过任何监控系统，也不熟悉 Linux 操 作系统。在这个阶段，能够熟练地掌握 Zabbix 的安装和基本配 置即可。
    • 中级阶段：具备 Linux 基础，熟悉 LAMP 和 LNMP 环境搭建、MySQL 数据库、Shell 脚本，以及具有简单的英文阅读能力，主要难点 在于触发器、数据库调优和 API 的使用。在这个阶段，读者可以 将 Zabbix 与其他系统进行集成对接。
    • 高级阶段：熟悉 PHP 语言或 C 语言，具备二次开发能力，能够修改源码，可以对 Zabbix 从代码级别进行优化和扩展。在这个阶段，读者一般都能熟练地掌握 Zabbix 的各个功能，已经从使用阶段到了源码级别的研究阶段，因此主要是对编程能力的要求。

  • 2.5 该选用 Zabbix 的哪个版本（Zabbix 怎么用？版本选择）

    到目前 2024 年，4.0 在中国应用广泛，向 5.0 过渡，6.0 很少用

  • 2.6 Zabbix 的架构是什么样的（Zabbix 怎么用？架构）

    ​​

    ​​

  • 2.7 Zabbix 的功能特性都有哪些（Zabbix 是什么？功能特性）

    • 1.数据收集 · 可用性、性能检测。 · 支持 Agent、SNMP（包括 Trapping 和 Polling）、IPMI、JMX、 SSH、Telnet 等。 · 自定义检测。 · 自定义收集数据的频率。 · 客户端/代理端/服务器端模式。
    • 2.灵活的触发器 可以定义非常灵活的告警阈值和与多种告警相关联的条件。
    • 3.高度可定制的告警 · 发送通知，可定制包括告警级别、动作升级、收件人和媒体类 型。 · 通知可以使用全局宏变量和自定义变量。 · 自动处理功能包括远程命令的自动调用和执行。
    • 4.实时的绘图功能 监控项将数据实时绘制在图形上。
    • 5.Web 监控能力 Zabbix 可以模拟浏览器请求访问一个网站，并检查返回值和响应时间。
    • 6.多种可视化展示 · 可以自定义监控的展示图，将多种监控数据集中展示到一张图 上。 · 网络拓扑图。 · 自定义的 Screens 和 Slide shows 可以将多种图形集中展示。 · 报表功能。 · 资源使用情况的监控展示。
    • 7.历史数据的存储 · 将数据存储在数据库中。 · 历史数据的存放周期可配置。 · 定期删除过期的历史数据。
    • 8.配置非常容易 配置比较简单，只需要以下两步即可。 （1）添加设备。 （2）应用模板即可完成监控。
    • 9.使用模板 · 模板可以分组。 · 模板具有可继承性。
    • 10.网络发现 · 支持自动发现网络设备和服务器（可以通过配置自动发现服务 规则实现）。 · Agent 自动注册。 · 支持用自动发现（Low Level Discovery）实现动态监控项的 批量监控（支持自定义），内置的自动发现包括文件系统、网 络接口、SNMP OID，可定制自动发现。
    • 11.快速的访问接口 · Web 页面基于 PHP。 · 远程访问。 · 日志审计。
    • 12.API 功能 应用 API 功能可以方便地与其他系统结合，包括手机客户端的使 用。
    • 13.系统权限 · 不同的用户展示监控的资源不同。 · 用户身份认证。
    • 14.程序特性 服务器端 Zabbix-Server 和采集端 Zabbix-Agent 使用 C 语言编写， 其性能非常高，内存开销非常小。 15.大型环境的支持 利用 Zabbix-Proxy 方式可轻松构建远程监

• 第 3 章 安装与部署

  • 3.1 安装环境概述

    最小化的安装环境，磁盘 I/O 性能、数据库性能是系统良好运行的关键因素

    ​​

    所需磁盘空间：数据库写入的一个关键 指标是 NVPS（New Values Per Second），NVPS 值是指每秒处理的平均数据量，通过这个值可以计算出数据 存储所需的空间大小。原理为，每条数据都占用大约 50B 的存储空间， 因此 NVPS× 每条数据的平均大小=历史数据所需的空间大小。计算公式：历史数据所需的空间大小=天数 x 每秒处理的数据量 x1 天 24 小时 x1 小时 3600sx50B

    ​​

    操作系统要求：

    ​​

    软件环境：

    ​​

    ​​

    ​​

  • 3.2 Zabbix-Server 服务器端的安装

    • zabbix 服务端一键安装初始配置脚本¹

    • Zabbix-Server 安装配置步骤详解

      • Zabbix-Server 服务器端安装配置步骤详解²

  • 3.3 Zabbix-Agent 客户端的安装

    • zabbix 客户端一键安装脚本³

  • 3.4 SNMP 监控配置

  • 3.5 在 Windows 中安装 Zabbix-Agent

  • 3.6 在其他平台安装 Zabbix-Agent

  • 3.7 Zabbix-Get 的使用、3.8 Zabbix 相关术语（命令）

    • Zabbix-Get 详解⁴

  • 3.9 Zabbix-Server 对数据的存储

    • 3.9.1 监控数据的存储
    • 3.9.2 MySQL 表分区实例

  • 3.10 高可用和安全

  • 3.11 Zabbix 数据库备份

    • Zabbix 数据库备份脚本

  • 3.12 升级 Zabbix

    • 3.12.1 同版本升级的方法
    • 3.12.2 跨版本升级的方法
    • 3.12.3 数据库自动升级的原理
    • 3.12.4 升级失败的处理案例

  • 配置 zabbix_agentd.conf 详解⁵

  • 用 docker 快速部署 zabbix

    • 用 docker 快速部署 zabbix⁶

• 第 4 章 快速配置和使用

  • 4.1 配置流程

    其完整的配置流程可以 简单描述为： Host groups（主机组）→Hosts（主机）、图形（模板链接）→Applications（监控 项组）→Items（监控项、模板链接）→Triggers（触发器、模板链接）→Problems（故 障）→Actions（处理动作）→User groups（用户组）→Users（用 户）→Medias（告警方式）→Action log（日志审计）。

    ​​

  • 4.2 添加主机组

    • 4.2.1 如何划分主机组

      在 Zabbix 的软 件设计规则中，已规定主机、模板必须属于一个分组。 对同一属性的主机或者模板应归类到相同组，相关原则如下：

      • 以地理位置纬度进行划分。
      • 以业务为单位划分组。
      • 以机器用途进行划分。
      • 以系统版本进行划分。
      • 以应用程序来划分组。
      • 其他方式等。

    • 支持对主机组进行层级分组

  • 4.3 添加模板

  • 4.4 添加主机

  • 4.5 配置图形

  • 4.6 配置大屏

  • 4.7 配置幻灯片

  • 4.8 配置地图（拓扑图）

  • 4.9 使用（IT）服务

  • 4.10 使用报表

  • 4.11 资产管理

  • 4.12 图形共享

  • 4.13 全局搜索

  • 4.14 最新数据

  • 4.15 故障

  • 4.16 数据的导入/导出

    • Zabbix 支持将所有的配置导出为标准格式的 XML 文件，同样，也支 持导入标准格式的 XML 配置文件。

  • 4.17 用户权限

    • 用户类型主要有 3 类，分别为超级管 理员、管理员和普通用户。还有一类特殊用户，即匿名用户 guest。

  • 4.18 调试模式

    • Zabbix 的调试模式（Debug mode）主要用于前后端的调试，如果 想知道对某个页面的查询使用了哪些 SQL 语句，则可以打开调试模式

  • 4.19 与 LDAP 对接

    • Zabbix 本身具有认证体系，还支持与 LDAP 集成来实现身份的统一 认证。

  • 4.20 维护模式

    • 在某些场合中，我们不需要告警，例如业务的正常维护，所以此 时维护时间功能特别有用。

  • 4.21 故障确认

    • 故障确认（Problem acknowledgement）功能用于人为干预故障， 当某个故障发生时，我们无法立即解决，但是已经知晓了该故障，即 先响应后彻底消除。为方便故障处理流程的转动，我们就可以使用这 一功能。

  • 4.22 批量更新

• 第 5 章 处理监控指标数据

  • 5.1 添加新的监控项（Items）

  • 5.2 监控指标的自定义

  • 5.3 Zabbix 内置的监控方式

    Zabbix 4.0 支持的监控方式如下：

    • Zabbix agent check

      • Agent 用于从 Zabbix-Agent 采集数据，其工作方式分为被动模式和主动模式两种

        ​​

    • SNMP agent check

    • SNMP trap

    • IPMI check

    • Simple check

      • Simple check 监控方式是 Zabbix-Server 主动发起的对外请求，所 以请求的源地址是 Zabbix-Server 服务器的 IP 地址，目标地址为远程 IP 地址，这样我们就可以不用安装任何 Agent，即可对一些常见的服务协 议进行监控了

        ​​

    • VMware monitoring

    • Log file monitoring

    • Calculated item

    • Zabbix internal check

    • SSH check

    • Telnet check

    • External check

    • Aggregate check

    • Trapper item

    • JMX monitoring

    • ODBC check

    • Dependent items

    • HTTP check

  • 5.3.3 日志监控方式

    Zabbix-Agent 支持对日志文件的监控，可以对日志的关键字进行 监控，然后告警。日志监控支持普通的日志文件，也支持日志轮询、 切割的文件。当日志中出现特殊的字符串（例如，警告、报错等字符 串）时，可以发送通知给用户。为了使日志监控能够正常使用，必须 满足以下条件： ·

    • Zabbix-Agent 必须运行，且工作方式为主动模式。 ·
    • 日志的 Item 必须设置，必须指定文件名。 ·
    • Zabbix-Agent 有读取日志的权限，如日志位于/home/用户名/ 文件中，则会因为权限的问题而导致无法读取到文件。

    注意：Zabbix 日志监控必须工作于主动模式下，在 Web 前端配置的主机名 （ 宏 为 {HOST.HOST} ） 必须和 Zabbix-Agent 端 zabbix_agentd.conf 中的 Hostname 值是一致的，并且这个 Hostname 值具有唯一性；否则，在主动模式下是无法正常采集到数据的。

  • 5.3.4 计算型监控方式

    计算型（Calculated）监控方式是在 Zabbix-Server 端对历史数据 进行统计分析的一个功能，例如，可以求主机总的磁盘容量、网络流 量等。经过计算后的指标值，如配置了该 Item 的 Trigger，则同样可以 触发告警阈值进行告警。

  • 5.3.5 聚合型监控方式

    聚合型（Aggregate）监控方式是指将已经存储在数据库中的监控 指标数值进行二次统计运算，从而形成新的监控指标。利用这个功 能，我们很容易做到对一组已有的监控指标进行再次统计求值，如计 算一组或多组服务器的 CPU 平均 iowait、计算一组或多组服务器 的/data 分区总的容量。

  • 5.3.6 内部检测监控方式

    内部检测用于监控 Zabbix 自身的性能数据，可以监控 ZabbixServer 和 Zabbix-Proxy，选择监控方式为“Zabbix internal”，添加 相应的 Item key，即可完成监控。

  • 5.3.7 SSH 监控方式

    在默认情况下，Zabbix-Server 并不知道我们使用哪个 SSH 密钥来 连接服务器，因此需要指定 SSH 密钥的位置。由于使用 RPM 包安装的 Zabbix-Server，其用户家目录在/var/lib/zabbix 目录下面，因此我 们将 SSH 密钥目录设置为/var/lib/zabbix/.ssh

  • 5.3.8 Telnet 监控方式

    Telnet 监控方式，Zabbix-Server 使用 Telnet 协议来获取数据。为 什么要支持这么古老的方式呢？ 因为在某些场景下，有些设备只提供 了 Telnet 方式来获取数据，所以这个时候 Telnet 监控方式就有用武之地了。

  • 5.4 监控项指标数据的预处理

    • 5.4.1 预处理概述

      预处理（Preprocessing），指在 Zabbix-Server 接收到监控项数 据之后，在入库之前再次处理的过程，这意味着可以从客户端采集任 意格式的数据，大大提高了数据处理的灵活性。例如，我们可以从客 户端采集 JSON 格式的数据，然后通过预处理功能进行值的分割，将符 合规则的数据入库。采用预处理功能可以批量获取数据，如图 5-43 所 示，左侧是通过预处理功能，一次可以获取多个指标数据；右侧是以 一问一答方式轮询获取数据的

    • 5.4.2 预处理的运行流程

      ​​

    • 5.4.3 预处理的数据类型

  • 5.5 配置宏（变量）

    • 5.5.1 全局宏
    • 5.5.2 模板宏
    • 5.5.3 主机宏
    • 5.5.4 监控项宏

  • 5.6 配置值映射

    值映射（Value mapping）功能是指将监控指标取到的数据替换为 文本进行展示，如将数值 1 替换为 available，则表示在监控指标取到 数值 1 时，在界面中将显示为 available。

• 第 6 章 精通告警配置

  • 6.1 告警流程

    Host groups（设备组）→Hosts（设备）→Applications（监控 项组）→Items（监控项）→Triggers（触发器）→Actions（告警动 作）→Medias（告警方式）→User groups（用户组）→Users（用 户）。

    Zabbix 告警的配置步骤如下： （1）配置 Trigger。 （2）配置用户。 （3）配置告警介质。 （4）配置 Action。

  • 6.2 告警触发器（Trigger）的配置

  • 6.3 告警处理的配置

    • 6.3.1 如何发送告警

      客户端定期采集需要监控的指 标，然后发送给 Zabbix-Server 服务器，Zabbix-Server 对数据进行存 储和分析，如果指标的数据值满足告警表达式规则，则会触发一个告 警，但告警并不会主动通知给用户，在 Zabbix-Web 界面中我们可以看 到故障告警的显示。如果此故障不仅要在 Zabbix-Web 界面中展示，同 时也要发送给用户，这时就需要在 Zabbix-Web 界面的 Action 页面中对 告警信息进行规则匹配，并将其发送给不同的用户。

      ​​

    • 6.3.2 Action 功能概述

      Action 中文翻译为“动作”，如果从中文字义来理解它，则确实 很难理解。其实可以这么理解，Action 就是指发生了什么事件，根据 一定的条件采取什么措施，可以为发送消息，也可以为执行命令。通 过这样的解释，相信读者对 Action 的理解就不会很难了。 Action 的 事 件 来 源 有 4 种 ， 包 括 ： Triggers （ 触 发 器 ） 、 Discovery（网络自动发现）、Auto registration（Agent 主动注册） 和 Internal（内部事件）

  • 6.4 邮件告警配置

  • 6.5 自定义脚本告警

    6.5.1 自定义脚本告警的原理 自定义脚本在/etc/zabbix/zabbix_server.conf 中，配置语句如 下：

    AlertScriptsPath=/etc/zabbix/alertscripts
    

    Zabbix-Server 在调用脚本时会传递参数给脚本，在 Zabbix 3.0 以 下版本中，默认传递 3 个参数，即收件人、主题和内容；在 Zabbix 3.0 以上版本中，则可以自定义多个参数传递给脚本

  • 6.6 邮件告警脚本的配置

  • 6.7 告警升级机制

    ​​

    ​​

  • 6.8 触发器标签配置

  • 6.9 手动关闭告警

  • 6.10 如何取消告警发送

  • 6.11 如何删除故障信息

  • 6.12 告警聚合

    告警聚合则基于告警对告警数据 进行分析。这种功能属于监控系统的高级功能，在大规模环境中，这 种功能是不可缺少的，其重要性比监控系统本身更重要。比如一天人 均收到几百个告警，但如果都是同一类型，那么接收告警的人员会对 告警产生免疫效果，时间一长，对告警消息处理的灵敏度就会下降。 因此在设置告警时，可以通过触发器函数本身来调整触发器依赖的配 置，最终的解决办法还是告警聚合系统在发挥作用。 在 Zabbix 4.0 中，告警聚合的原理是通过对每个事件打标签，然 后匹配标签来关闭告警。

  • 6.13 告警配置故障排查

• 第 7 章 探究告警触发器

  • 7.1 Trigger 函数的意义
  • 7.2 Trigger 函数的分类
  • 7.3 Trigger 函数——比较与查找
  • 7.4 Trigger 函数——计算
  • 7.5 Trigger 函数——时间
  • 7.6 Trigger 函数——日志
  • 7.7 Trigger 函数——字符串匹配
  • 7.8 Trigger 函数——趋势预测
  • 7.9 参考资料

• 第 8 章 剖析监控方式

  • 8.1 Zabbix 支持的监控方式

    ​​

  • 8.2 Zabbix 监控方式的逻辑

    Zabbix 支持多种监控方式，其获取数据的方式可以分为三类：一 是 Zabbix-Server 主动对外请求数据；二是外部主动发送数据给 Zabbix-Server；三是 Zabbix-Server 内部进行数据计算，对已有数据 进行重新计算分析，如图 8-4 所示。

    ​​

  • 8.3 Zabbix-Agent 的工作模式

    • Zabbix-Agent 的工作模式可以分为主动模式（Active）和被动模 式（Passive），下文会详细剖析各自的工作原理。 主动模式是指 Zabbix-Agent 将采集到的数据主动推送给 ZabbixServer，其行为是 Zabbix-Agent 向 Zabbix-Server 主动发起的数据连接 过 程 ， Zabbix-Server 不 必 等 待 Zabbix-Agent 的 数 据 采 集 行 为 ， Zabbix-Agent 能够一次批量发送多条数据给 Zabbix-Server，属于一对 多的响应模式，对 Zabbix-Server 的性能开销较少，适合大规模环境使 用。 被动模式是指 Zabbix-Server 向 Zabbix-Agent 请求数据，ZabbixAgent 被动接受数据请求后进行回应，属于一对一的响应模式。比如有 100 个监控项，Zabbix-Server 需要向 Zabbix-Agent 请求 100 次，同时， Zabbix-Agent 在响应 Zabbix-Server 时，对监控项数据采集也需要消耗 时间，此时，Zabbix-Server 只能耗着时间安静地等待 Zabbix-Agent。 相对于主动模式的高效，被动模式从时间开销和发送数据量上都处于 劣势，对 Zabbix-Server 的性能开销较大，适合小规模环境使用。 主动模式和被动模式在同一个 Zabbix-Agent 上，是可以共存的， 比如让一部分监控项处于被动模式，另一部分处于主动模式。处于主 动模式的监控项，由 Zabbix-Agent 周期性地采集数据传输给 ZabbixServer；处于被动模式的监控项，则由 Zabbix-Server 周期性地从 Zabbix-Agent 获取数据。
    • 被动模式的工作流程 被动模式的工作流程总结如下： （1）Zabbix-Server 打开一个 TCP 连接。 （2）Zabbix-Server 发送一个 key 为 agent.ping\n 的请求。 （3）Zabbix-Agent 接受这个请求，然后响应数据 ＜HEADER＞＜ DATALEN＞。 （4）Zabbix-Server 对接收到的数据进行处理。 （5）关闭 TCP 连接。
    • Zabbix-Agent 主动向 Zabbix-Server 发送请求的工作流程 在主动模式中，Zabbix-Agent 在启动时就会向 Zabbix-Server 发送 请求，以获取需要主动监控的监控项。这部分的运行流程总结如下： （1）Zabbix-Agent 向 Zabbix-Server 建立一个 TCP 连接。 （2）Zabbix-Agent 请求需要检测的数据列表。 （ 3 ） Zabbix-Server 响 应 Zabbix-Agent ， 发 送 一 个 Item 列 表 （Item key、Delay）。 （4）Zabbix-Agent 响应请求。 （5）完成本次会话后关闭 TCP 连接。 （6）Zabbix-Agent 开始周期性地采集数据
    • Zabbix-Agent 发送数据给 Zabbix-Server 的工作流程 当 Zabbix-Agent 将监控项数据采集完成之后，会将数据发送给 Zabbix-Server。这部分的运行流程总结如下： （1）Zabbix-Agent 向 Zabbix-Server 建立一个 TCP 连接。 （2）Zabbix-Agent 将数据发送给 Zabbix-Server，其发送周期等 于 Item 的更新周期。 （3）Zabbix-Server 处理 Zabbix-Agent 发送的数据。 （4）关闭 TCP 连接。

  • 8.4 Zabbix-Trapper（zabbix sender）监控方式

    Zabbix-Trapper 监 控 方 式 可 以 一 次 批 量 发 送 数 据 给 ZabbixServer，与主动模式不同，Zabbix-Trapper 可以让用户控制数据的发 送，而不用 Zabbix-Agent 进程控制，这意味着可以使用 Linux 定时任 务 ， 或 者 借 助 其 他 程 序 调 用 Zabbix-Trapper 发 送 数 据 给 ZabbixServer。由于可以一次批量发送更多的数据（为防止数据过大导致内 存溢出，在 Zabbix 4.0 中 Zabbix 协议明确限制单次传输数据的大小最 多为 128MB），因此这种方式的性能比 Zabbix-Agent 主动模式会更好。 在 Zabbix-Trapper 工 作 模 式 中 ， Zabbix 发 送 数 据 的 程 序 是 zabbix_sender。

  • 8.5 SNMP 监控方式

    使用 SNMP 可以监控路由器、交换机、打印机、UPS 或者其他开启 SNMP 的设备，如果要支持 SNMP 监控方式，需要 Zabbix-Server 在编译源 码时带上--with-net-snmp 参数。

    • 8.5.1 SNMP 协议概述
    • 8.5.2 SNMP 协议的工作方式
    • 8.5.3 SNMP 协议的工作原理

  • 8.6 SNMPTraps 监控方式

    • 8.6.1 SNMPTraps 的概念

      SNMPTraps 是 SNMP 的被管理端向 SNMP 管理端主动发送数据的过程， 管理端使用 UDP 162 端口接收被管理端发送的数据，这个功能通常用于 故障推送、信息发送等场景中，以便管理端能够在被管理端发生事件 时及时接收到相关信息。

    • 8.6.2 SNMPTraps 的工作原理

      在 Zabbix-Server 服务器中，SNMPTraps 使用 snmptrapd 进程接收 SNMP 被管理端发送过来的数据，然后使用 snmptt 对接收到的数据进行 处理，写入日志文件中，Zabbix-Server 中的 snmptrap 处理进程对日志 进行处理，符合 Zabbix 的数据格式要求，后续对数据进行阈值判断、 告警等处理。

      ​​

  • 8.7 IPMI 监控方式

    • 8.7.1 IPMI 的概念

      IPMI（Intelligent Platform Management Interface）即智能平 台管理接口，原本是 Intel 架构中企业系统的周边设备所采用的一种工 业标准，后来成为业界通用的标准。 用户可以利用 IPMI 监视服务器的物理特征，如温度、电压、电扇 工作状态、电源供应以及机箱入侵等。

    • 8.7.2 IPMI 的特性

      IPMI 独立于 CPU BIOS 和 OS 自行运行，允许管理者在缺少操作系 统、系统管理软件或受监控的系统关机但接通电源的情况下仍能远端 管理服务器硬件。IPMI 也能在操作系统启动后活动，与系统管理功能 一并使用时还能提供加强功能，IPMI 只定义架构和接口格式成为标 准，具体操作时可能会有所不同。

  • 8.8 JMX 监控方式

    JMX（Java Management Extensions，Java 管理扩展）是 Java 平台 上为应用程序、设备、系统等植入管理功能的框架。JMX 可以跨越一系 列异构操作系统平台、系统体系结构和网络传输协议，灵活地开发无 缝集成的系统、网络和服务管理应用。 JMX 可以获取 Java 应用程序的性能数据，因此，我们可以直接通过 JMX 协议对 Java 应用程序内部进行深入的监控

    • 8.8.1 JMX 在 Zabbix 中的运行流程

      在 Zabbix 中，对 JMX 监控数据的获取由专门的代理程序来完成，即 由 Zabbix-Java-Gateway 负责数据的采集。Zabbix-Java-Gateway 采集 Java 应用程序（已开启 JMX 协议）的性能数据，然后把采集到的数据发 送给 Zabbix-Server

      ​​

  • 8.9 HTTP agent 监控方式

    HTTP 是互联网中应用最广泛的一种网络协议，主要有 HTTP 和 HTTPS 两种，在 HTTP agent 监控方式中，是由 Zabbix-Server 主动对外发起请 求的，然后目标 URL 响应请求。除支持 Zabbix-Server 主动发起请求 外，HTTP agent 还支持 Zabbix-Porxy 主动对目标 URL 发起请求（即 Item 位于 Proxy 模式的主机中），不需要 Agent 即可采集到数据。

  • 8.10 Web 监控方式

    Web 监控方式是用来监控 Web 程序的，可以监控 Web 程序的下载速 度、返回码及响应时间，还支持将一组连续的 Web 动作作为一个整体进 行监控。

    • 8.10.1 Web 监控的原理

      Web 监控即对 HTTP 服务的监控，模拟用户访问网站，对状态码、返 回字符串等特定的数据进行比较和监控，从而判断网站 Web 服务的可用 性。很多时候，我们可以用脚本、程序来进行自定义监控，如 Linux 下 的命令程序 curl、wget，其他语言提供的 http 库等都可以帮助我们完 成这一需求。

  • 8.11 Dependent item 监控方式

  • 8.12 ODBC 监控方式

  • 8.13 其他监控方式

  • 8.14 命令执行的监控方式

    • 8.14.1 system.run

      system.run 是 Zabbix-Agent 的一个 key，在默认情况下这个 key 是 不 能 使 用 的 。 若 要 使 用 这 个 key ， 需 要 在 /etc/zabbix/zabbix_agentd.conf 中 将 EnableRemoteCommands=0 修 改为 EnableRemoteCommands=1（如图 8-73 所示）。注意，如果没有远 程执行命令需要这个 key，那么为了安全考虑，可以将其关闭，在关闭 后，Action 中的远程命令也将无法使用；如果将其开启，则务必保证 Zabbix-Server 和 Zabbix-Agent 之间的通信安全，防止被黑客劫持而造 成损失。

• 第 9 章 分布式监控与自动化

  • 9.1 Zabbix-Proxy 分布式监控

    Zabbix 是一个分布式的监控系统，即采用一个中心点、多个分节 点的部署模式，适合于跨机房、跨地域的网络环境。 Zabbix-Proxy 的典型工作环境如下： · 监控远程区域，如异地区域。 · 监控网络非直连的区域，如处于 NAT 模式下的设备。 · 分担 Zabbix-Server 服务器的负载，在 Zabbix-Proxy 中预先处 理数据。

    ​​

    Zabbix-Proxy 支持的监控功能和 Zabbix-Server 差不多，不同的 是，对于需要在数据库层面计算的监控方式，Zabbix-Proxy 不支持， 其他方式均支持，详细支持情况如表 9-1 所示。

    ​​

    Zabbix-Proxy 和 Zabbix-Server 之间的数据通信，需要一个 TCP 端 口连接，为保证数据传输的安全，可以在网络防火墙层面设置允许 Zabbix-Proxy 和 Zabbix-Server（默认 10051 端口）进行通信。 Zabbix-Proxy 将采集到的数据传送给 Zabbix-Server 之前保存在本 地数据库中。这样的功能设计保证了不会因为 Zabbix-Proxy 临时与 Zabbix-Server 中断而造成监控数据丢失。Zabbix-Proxy 配置文件中的 ProxyLocalBuffer 和 ProxyOfflineBuffer 参数控制数据在本地保存的 时间。

  • 9.2 监控的自动化功能

    首先，Zabbix 提供了网络自动发现功能，该功能可以基于 FTP、 SSH 、 Web 、 LDAP 、 POP3 、 IMAP 、 SMTP 、 TCP 、 SNMP 、 Telnet 、 zabbix_agent 等，主动扫描网络中的协议和服务，当它们存在时，即 认为主机和设备存在，表示该 IP 地址存活，而是否添加到监控，则由 Action 来决定。在 Zabbix 中，网络自动发现和自动注册都具有以上提 到的功能。 其次，Zabbix 提供了对多变的监控项自动发现监控的功能。比 如，服务器有两块网卡，再增加两块网卡，那么新增加的两块网卡如 何做到自动监控？再比如磁盘分区、硬盘设备等，它们存在不确定的 因素，一台服务器可能只有一块硬盘，也可能有多块，那么如何做到 自动监控？如上问题，都可以用 Zabbix 的 LLD 功能轻松解决。即对于监 控项中具有相同的属性，但存在部分变量配置不同的情况，完成自动 添加监控项。 基于 Zabbix 的这两个功能，我们可以实现： · 自动添加主机、模板，自动分组，自动添加监控项、触发器 等。 · 自动添加监控项中有规律的“变量”。 Zabbix 监控的自动化功能如图 9-4 所示。

    ​​

  • 9.3 网络自动发现

    Zabbix 的网络自动发现是一个非常强大的功能，利用该功能可以 完成以下工作。 · 快速发现并添加主机。 · 进行简单的管理。 · 随着环境的改变而快速搭建监控系统。 网络自动发现基于以下信息： · IP 地址段。 · 基于服务的 FTP、SSH、Web、POP3、IMAP、TCP 等。 · 从 Zabbix-Agent 接收到的信息。 · 从 SNMP agent 接收到的信息。 网络自动发现功能不能做到的事情是发现网络拓扑图。 网络自动发现的两个工作流程是：Discovery 和 Action。

  • 9.4 主动方式的自动注册功能

    主动方式的自动注册（Active agent auto-registration）功能 主要用于 Agent 主动且自动向 Server 注册,即 Agent 处于主动模式，主动 向 Zabbix-Server 发送数据进行注册，如图 9-8 所示。与网络自动发现 具有同样的功能，都能够实现将设备自动添加到监控系统中。但是主 动方式的功能更适合于在特定的环境中使用，当一个条件未知（这里 的未知条件包括 Agent 端的 IP 地址段、Agent 端的操作系统版本等信 息）时，仍然可以实现自动添加监控。它特别适合于当前云环境下的 监控，在云环境中 IP 地址分配、操作系统版本等都可能随机，该功能 可以很好地解决类似的问题。

  • 9.5 监控项自动发现功能

    在 Zabbix 中，由于监控指标都是基于模板进行的，因此会存在模 板的通用性问题。比如 OS 层面的监控，一台服务器具有多块网卡、多 个分区、多块磁盘、多个进程端口等需要监控，因为 Zabbix 提供了 LLD（Low Level Discovery）功能，可以实现一个监控项原型生成多 个监控项的场景

  • 9.6 使用自动化工具 SaltStack 批量部署 Zabbix

    在实际的生产环境中，会对 Zabbix 进行大规模的部署、运维和管 理，此时一套集中的配置管理工具是必需的。自动化部署软件包、管 理配置文件等开源的工具有 Chef、Puppet、SaltStack、Ansible 等， 本节介绍 SaltStack 的安装与配置，其他工具的安装与配置与之类似。

    • 9.6.1 使用 SaltStack 配置管理 Zabbix

      SaltStack 是一个管理配置工具，其作用是为系统管理人员提供标 准 化 的 配 置 管 理 和 命 令 执 行 ， 架 构 为 通 用 的 Client/Server （ Master/Minion ， 服 务 器 / 客 户 端 ） 或 Client/Proxy/Server（Master/Sync-dic/Minion，服务器/代理/客户 端），通信采用证书认证方式，开发语言为 Python，提供 API，二次开 发 较 容 易 ， 可 以 运 行 在 多 种 平 台 上 ， 其 官 方 网 址 为 http://www.saltstack.com。 注意：一般采用自动化运维工具进行的配置管理，其软件都应该 采用标准化安装，如 RPM 包安装，需要有软件仓库。因此， 前提是将 Zabbix 放在指定的软件仓库中，定制 RPM 包，相关 内容可参考第 15 章。

• 第 10 章 监控功能案例

  • 10.1 监控 TCP 连接状态
  • 10.2 监控 Nginx
  • 10.3 监控 PHP-FPM
  • 10.4 监控 MySQL
  • 10.5 监控物理服务器
  • 10.6 监控物理机磁盘
  • 10.7 监控 Cisco 路由器
  • 10.8 监控 VMware
  • 10.9 监控 RabbitMQ
  • 10.10 监控 Elasticsearch
  • 10.11 监控 Kafka
  • 10.12 监控 Redis
  • 10.13 监控 Oracle 数据库
  • 10.14 监控 W ebLogic
  • 10.15 监控 SQL Server
  • 10.16 监控 HTTPS 证书过期

• 第 11 章 监控数据可视化

  • 11.1 Grafana
  • 11.2 Graphtrees
  • 11.3 谷歌浏览器告警插件
  • 11.4 Mac App 的使用
  • 11.5 手机 App 的使用
  • 11.6 导出实时监控数据
  • 11.7 网络拓扑自动发现
  • 11.8 监控数据可视化的意义
  • 11.9 总结

• 第 12 章 监控性能优化

  • 12.1 Zabbix 性能优化概述

    ​​

    ​​

    Zabbix 性能低下的一些表现如下： · Zabbix 队 列 中 有 太 多 被 延 迟 的 Item ， 可 以 通 过 Administration→Queue 查看。 · Zabbix 绘图中经常出现断图，一些 Item 没有数据。 · 带有 nodata()函数的触发器出现告警。 · 前端页面无响应，或者响应很慢。 解决方案如下： · 不使用默认模板，定制自己的模板。 · 调优数据库，使用分布式数据解决方案，使用最新稳定版本， 如 MySQL 5.6/5.7/8.0，一般来说，版本越新，其性能越好。 · 优化架构，如使用分布式架构，各服务器功能独立。 · 调优 Item、Trigger。 · 更换更好的硬件，如硬盘采用 PCI-E SSD。

  • 12.2 Zabbix 性能优化依据

    Zabbix-Server 的缓存监控情况如图 12-3 所示

    ​​

    监 控 指 标 是 剩 余 量 ， 如 果 剩 余 量 非 常 小 ， 则 可 以 调 大 zabbix_server.conf 中的缓存参数，直到这里的相关指标数据的剩余 量大于 0 为止。 Zabbix-Server 性能的监控指标有以下两个： · 每秒处理数据的数量。 · 等待的队列数量。 监控 Zabbix-Server 内部的进程运行情况，如图 12-4 所示。

    ​​

    查看等待的队列，如图 12-5 所示。

    ​​

    等待的队列越多，说明 Zabbix-Server 性能越差。

    衡量 Zabbix-Server 服务处理性能的一个指标是每秒新处理的数据 个数，英文缩写是 NVPS。在 Zabbix 4.0 中，从 zabbix_server 进程端口 中获取 NVPS，查看前端代码

  • 12.3 Zabbix 配置文件参数的优化

    在 Zabbix-Server 中，调整配置文件中的参数，可以设置的内容如 下： · 进程的数量。 · 缓存的大小。 · 超时时间。

  • 12.4 Zabbix 架构的优化

    Zabbix 架构有以下两种模式： · Server/Agent 模式。 · Serve/Proxy/Agent 模式。 通过采用分布式模式，可以大大降低服务器的负担，从而大大提 升单台服务器的性能。

  • 12.5 Item 的工作模式及 Trigger 的优化

    Zabbix 中的 Item 默认工作于被动模式下，但可以通过设置主动模 式来提升服务器的性能。 Item 除可以采用主动模式外，还可以采用 Trapper 工作模式，通过 zabbix_sender 程序发送数据，此种模式也具有很高的性能（请参考本 书 8.4 节）。 Trigger 中正则表达式函数 last()、nodata()的处理速度是最快 的，min()、max()、avg()的处理速度是最慢的，尽量使用处理速度快 的函数，并根据实际情况来权衡使用哪个函数。 在 Trigger 的配置中，需要注意一些表达式，如果配置失误，则很 可能会由于一个函数的逻辑错误而导致数据库查询较慢。

  • 12.6 Zabbix 数据库的优化

    Zabbix 数据库的优化分为以下几个部分。 · 对数据库本身的优化。采用更高性能的数据库版本，如选择 Percona（在最新版本的性能对比中，和 MySQL 官方版本相比， 性能相差不是特别的大），选用最新版本的 MySQL。 · 对数据库本身的参数进行调优配置。 · 对 Zabbix 数据库结构进行优化，采用诸如表分区的方案，表分 区在删除一个区间的数据时速度非常快，如删除 200GB 的数据， 也只需要 1 分钟。因此 Zabbix 数据库结构优化一般就采用表分区 的方式，方法是对 history. 、trends. 等表进行分表操作，从 而降低 Zabbix 数据库的压力。具体实施方法，请读者参考第 3 章 的内容。 · 采用数据库中间件的方式。 在进行分表操作时，我们是直接关闭 Housekeeper 的，因为 MySQL 执行 DELETE（删除）操作非常低效，而采用表分区删除却非常高效。 zabbix_server.conf 中的 LogSlowQueries 参数设置是关于慢查询 的，比如将超过 1000ms 的查询记录到日志中，就将其值设置为 1000。 开启这个参数可以对慢查询继续记录，方便调优配置。 更 多 MySQL 参 数 的 配 置 ， 读 者 可 以 参 考 https://github.com/zabbix-book/MySQL_conf，此处省略相关配置， 因为本书的主体不是 MySQL 配置的优化。

  • 12.7 Zabbix 运行硬件的优化

    通常，在优化软件无效的情况下，更换成更好的物理硬件会有非 常明显的效果，如选用 RAID10、SSD 固态硬盘、多核 CPU、大容量内存 等硬件配置，如果使用云主机，则更换为高配即可。

  • 12.8 Zabbix 压力测试

    12.8.1 压力测试原理

    Zabbix-Server 对 Zabbix-Agent 的监控项取值时间间隔，最小值限 制为 1s（但是对于 zabbix_sender，则可以取小于 1s 的值存储时间间 隔）。因此，我们通过创建大量的监控项，让监控项 1s 更新一个数 据，对同一个 Zabbix-Agent 频繁地大量获取数据，即可模拟出真实的 压力情况。

  • 12.9 Zabbix-Server 内部实现原理

    • Zabbix-Server 的整体流程

      在 Zabbix 内部的进程中，进程和缓存之间是相互关联的。或许读 者会有这样的疑问：为什么 Zabbix 使用关系型数据库存储配置数据， 但速度却不慢，而自己写程序直接读取关系型数据库速度却不够理 想？为什么 Zabbix 没有使用 RabbitMQ 这样专业的消息队列？为什么 Zabbix 没有使用第三方的 NoSQL 缓存？这是因为 Zabbix 具有良好的软件 架构设计，在内部通过高性能的算法实现了队列、缓存等技术。当 然，只有一层缓存是不够的，还需要通过分层的缓存设计，让不同层 级的缓存解决不同的问题，最终让程序尽量少地访问关系型数据库。 在 Zabbix 中，缓存有以下几类。 （1）配置缓存：将主机组、主机、模板、全局宏、主机宏、监控 项、触发器表达式、Action 的条件和动作、告警聚合条件和动作等的 数据同步到内存中。 （2）历史数据缓存：将采集到的监控数据，经过预处理进程处理 后进行缓存。 （3）趋势数据缓存：将趋势数据存储到内存中。 （4）指标数据缓存：数据归档，将历史数据归档为趋势数据时， 从指标数据缓存中读取；触发告警事件，对需要告警的监控指标进行 判断，如涉及历史数据的告警指标判断，会从指标数据缓存中读取数 据，而不是从数据库中直接读取的。 以上缓存和其他进程中的流程与数据走向，以及如何通信，我们 可以通过图 12-14 来了解。看懂这个图后，我们对配置参数的优化思路 会更加明晰。

      ​​

    • Zabbix-Server 采集器的工作流程

      我们学习了 Zabbix 监控数据的采集方式，但读者 是否意识到一个问题，这样的采集功能是如何高效工作的？配置数据 又这么复杂，会不会很低效？答案就在本节中。 采集进程在读取采集任务时，首先从配置缓存中获取数据，只有 在需要更新主机可用性状态，或者处理 LLD 数据时，才会与数据库交互 写入数据，而绝大多数时候是直接读写缓存的，从而提高了处理性 能。如图 12-15 所示为 Zabbix-Server 数据采集的流程，展示了 Zabbix 内部的采集器是如何在缓存和数据库之间进行交互的。 我们看到，对于每种数据采集器所采集到的数据，当需要预处理 时都会通过预处理进程进行处理，流程如图 12-16 所示。

      ​​

      ​​

    • 12.9.3 Zabbix-Proxy 工作流程

      ​​

    • 12.9.4 Zabbix-Server 告警的工作流程

      Zabbix-Server 告警支持多进程，并且可以自定义脚本，其高效的 告警离不开内部缓存的支持，工作流程如图 12-18 所示

      ​​

  • 12.10 Zabbix-Server 配置参数

    ​​

  • 12.11 Zabbix-Server 性能优化总结

    其思路无非就是本身配置的优化、 数据库的优化，在做了这一系列优化后，其效果会比较明显，对于中 小规模的环境，Zabbix 能够运行良好；但对于超大规模的环境，可能 就会出现另一种局面了。由于 Zabbix 本身的一些限制，其无法横向扩 展，无法使用第三方消息队列，也不支持集群。因此，在超大规模的 环境中其存在天然的缺陷，尤其是在飞速发展的互联网环境中，加之 本身的监控方式具有限制（虽然足够良好，但仍无非满足某些场合的 需求，如把 Zabbix 当日志采集、APM 数据采集等功能使用时），因此要 取得非常理想的优化效果是非常困难的。只能从代码级别进行二次开 发优化，改造成适合超大规模环境的架构，但其改造成本不低。

• 第 13 章 Zabbix API 的使用

  • 13.1 Zabbix API 简介
  • 13.2 JSON-RPC
  • 13.3 Zabbix API 的使用流程
  • 13.4 第三方 Zabbix API 模块
  • 13.5 编写命令行管理工具 zbx-tool

• 第 14 章 安装与部署的扩展

  • 14.1 源码安装 Zabbix-Server
  • 14.2 源码安装 Zabbix-Agent
  • 14.3 定制安装包
  • 14.4 使用 RPMbuild 定制 RPM 包
  • 14.5 使用 Elasticsearch 作为数据库

• 第 15 章 分布式监控项目实践

  • 15.1 监控系统项目概述

    在大规模的监控系统中，需要考虑以下因素。 第一，分布式架构是首要考虑因素。要求系统架构具备分布式的 设计，原则是将中心节点压力分散在各边缘节点上，使其尽可能监控 更多的设备。 第二，数据存储扩展的问题。节点数量增加到一定规模后，给监 控数据的存储带来了十分严峻的挑战，数据存储扩展的问题是整个监 控系统能否正常工作的前提条件。 第三，高可用性和健壮性、稳定可靠的系统架构、冗余的灾备， 是大型监控系统必备条件。 第四，提供 API 的能力，易于与第三方集成。在大型环境中，一个 孤立的监控系统会给其他业务系统造成很大的麻烦，通常需要花费更 多的精力进行改造，使其为其他系统提供所需的数据。 第五，具备自动化功能。自动化是解放繁重的体力劳动最有效的 方式，未来的运维一定更智能、更偏向于业务，以业务为核心，而不 是仅仅解决系统的底层问题。 以上观点适用于任何监控系统，而不仅仅是 Zabbix。

  • 15.2 监控系统项目的背景

    在 IT 运维管理中，日常的工作可以分为三类：一是基础环境搭 建；二是维护与更新；三是监控告警与调整优化。在维护与更新的工 作中，可以采用手动或自动化工具来实现，均可以满足不同企业的需 求。对于配置统一、基础环境一致的环境，通常会采用统一的配置管 理工具，如 Puppet、SaltStack、Ansible、Chef 等。而有些环境，配 置变更不频繁，其没法统一管理，如一年半载可能才发生一次变更， 而相同规模的设备不多，在这种情况下，配置管理工具就无法发挥它 的优势了。但是对于监控告警系统，无论是互联网公司还是传统公 司，都是必不可少的，因为 IT 设备并不是 100% 可靠的，就算是 100% 可 靠的设备，也会有人为因素造成服务不可用。因此，集中的监控告警 平台建设，是每个公司 IT 部门都十分关心的问题，即使是不懂 IT 技术 的公司成员，也知道监控告警系统是必需的。 在了解了 IT 监控系统的重要性后，我们来看看具体的监控需求。 一般来说，监控系统的构建可以分为如下几个层面。 （1）基础架构设施的监控，包括硬件服务器、存储、网络、虚拟 化等。 （2）应用存活与基本性能的监控，包括数据库、Web 应用、中间 件、消息队列、缓存等。 （3）代码内部的工作状态监控，这属于监控的细分领域，需要采 用其他技术来实现，如采用开源的 APM 监控工具 PinPoint、Zipkin、 CAT、OpenTraceing 等，这种层面的监控，需要软件工程师在编写业务 代码时，采用业务监控指标的埋点，进行整个业务调用链的监控，一 般需要软件架构师来规划设计，项目的整体推动实现过程通常较难。 （4）日志流监控，监控应用设备和应用软件的日志，并从日志中 提取相关的指标进行分析，其实现方式有开源的套件 ELK 等。 在 Zabbix 能够支持的监控范围中，上面提到的（1）（2）（4）部 分的功能被支持。所以，在构建监控系统之前，必须明白监控的具体 需求范围，以免范围扩大，从而造成需求蔓延和监控系统使用效果满 意度的下降。 在通常意义的监控建设项目中，一般的需求有：建立基于网络、 存储、虚拟化、应用、数据库系统、缓存、消息队列等的监控预警体 系，设备和服务的宕机、恢复均需要实时反馈给运维团队。监控目标 触发预警后可以设置重复的轮询作业确认问题是否存在。设置合理的 预警级别，根据预警的重要程度、紧急程度、问题处理程度，预警反 馈给不同级别的人员。 在监控系统的构建过程中，监控系统并不是孤立存在的，它往往 需要与其他系统打通，形成闭环，让工作的各个环节进行流通。因 此，企业在建立监控系统的过程中，往往是按照标准产品，加上个性 化定制来实现的。 在 IT 运维管理框架中，往往从逻辑结构上划分为五个平台和一个 中心配置库（简称“五台一库”），分别是集中监控平台、流程管理 平台、数据展现平台、自动化操作平台、历史数据分析平台和配置管 理数据库（CMDB）。它们的功能如下。 （1）监控平台：构建整个 IT 监控架构，实现集中事件管理，并为 面向业务的监控管理打下基础。 （2）流程管理平台：整合并标准化运维的日常工作，将日常的工 作规范化，并透明化。 （3）数据展现平台：建设统一报表平台和统一门户平台，将有效 增强数据利用和展示效果。 （4）自动化操作平台：完成对整个 IT 操作的集中管控和自动化。 （5）历史数据分析平台：集中存放历史数据，提供后期统一分析 及规划。 （6）配置管理数据库：记录完整的、准确的 IT 环境中各组件的信 息和彼此间的关联关系，作为唯一、可信的数据源，为周边系统提供 支撑数据。 因此，在这种背景环境下，我们需要重新审视企业中的 IT 监控系 统项目。无论是高速发展的互联网企业，还是平稳发展的传统企业， 抑或是金融保险企业，其构建监控系统的目的都一样，都是通过监控 系统发现故障与问题，并及时通知相关负责人，一线工程师能够根据 故障报告快速处理，并对处理的过程和结果进行整理分析，形成知识 积累，对于可以预见的常规故障，制定出应急方案。

  • 15.3 监控系统项目的步骤

  • 15.4 监控系统项目的规划——工作计划

  • 15.5 监控系统项目的启动——需求调研

  • 15.6 监控系统架构的设计——架构设计图

  • 15.7 监控系统项目的推进——软硬件环境配置

  • 15.8 监控系统项目的实施——安装与部署

  • 15.9 监控功能的实现——配置与定制开发

  • 15.10 监控系统与其他系统的集成

  • 15.11 监控系统项目的总结

• 第 16 章 后记——探究监控系统

  • 16.1 监控系统的使用场景
  • 16.2 如何设置监控指标
  • 16.3 如何度量设置告警指标
  • 16.4 如何发送告警与处理告警风暴
  • 16.5 告警轮班机制
  • 16.6 DevOps 与监控
  • 16.7 ITIL 与监控

实战：

• zabbix 作业训练

  • 1 实现对系统层的监控 监控 cpu 内存 硬盘 磁盘 （可以用模板）
  • 2 .实现 zabbix 比如 80 端口进程宕机 邮件报警 实战演示
  • 3 监控一个 ip 状态 是否正常
  • 4.主动模式和被动模式的区别
    被动模式：服务端发送一条指令，客户端就执行一次，100 条指令就需要来回 100 次
    主动模式：agent 主动采集，采集完一起发给 server ，server 端不干预，大大减轻 server 压力
  • 5.监控 mysql 性能的监控
  • 6.实战演示 自动注册功能，实现批量自动监控服务器