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.实战演示自动注册功能，实现批量自动监控服务器

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

简易脚本，初始化数据库可以改，centos7.9 亲测完美执行

#!/bin/bash

# 关闭SELinux、暂停防火墙
setenforce 0
systemctl stop firewalld
# 中文乱码修正
yum install -y wqy-microhei-fonts
\cp -f /usr/share/fonts/wqy-microhei/wqy-microhei.ttc /usr/share/zabbix/assets/fonts/graphfont.ttf

# 安装Zabbix
rpm -ivh https://mirrors.tuna.tsinghua.edu.cn/zabbix/zabbix/4.0/rhel/7/x86_64/zabbix-release-4.0-1.el7.noarch.rpm
sed -i 's#repo.zabbix.com#mirrors.tuna.tsinghua.edu.cn/zabbix#g' /etc/yum.repos.d/zabbix.repo
yum install -y zabbix-server-mysql zabbix-web-mysql zabbix-agent mariadb-server
systemctl start mariadb.service && systemctl enable mariadb.service
echo "rpm和yum安装Zabbixc完成"

# 初始化数据库
# mysql_secure_installation
mysqladmin password 123456
mysql -uroot -p123456 <<EOF
CREATE DATABASE zabbix character set utf8 collate utf8_bin;
GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost' IDENTIFIED BY 'zabbix';
FLUSH PRIVILEGES;
EOF
echo "初始化数据库完成"
# 备份并修改Zabbix服务器配置
cp /etc/zabbix/zabbix_server.conf /etc/zabbix/zabbix_server_$(date +%Y%m%d).conf
cat > /etc/zabbix/zabbix_server.conf << EOF
# This is a configuration file for Zabbix server daemon
# To get more information about Zabbix, visit http://www.zabbix.com

############ GENERAL PARAMETERS #################

### Option: ListenPort
#	Listen port for trapper.
#
# Mandatory: no
# Range: 1024-32767
# Default:
# ListenPort=10051

### Option: SourceIP
#	Source IP address for outgoing connections.
#
# Mandatory: no
# Default:
# SourceIP=

### Option: LogType
#	Specifies where log messages are written to:
#		system  - syslog
#		file    - file specified with LogFile parameter
#		console - standard output
#
# Mandatory: no
# Default:
# LogType=file

### Option: LogFile
#	Log file name for LogType 'file' parameter.
#
# Mandatory: yes, if LogType is set to file, otherwise no
# Default:
# LogFile=

LogFile=/var/log/zabbix/zabbix_server.log

### Option: LogFileSize
#	Maximum size of log file in MB.
#	0 - disable automatic log rotation.
#
# Mandatory: no
# Range: 0-1024
# Default:
# LogFileSize=1

LogFileSize=0

### Option: DebugLevel
#	Specifies debug level:
#	0 - basic information about starting and stopping of Zabbix processes
#	1 - critical information
#	2 - error information
#	3 - warnings
#	4 - for debugging (produces lots of information)
#	5 - extended debugging (produces even more information)
#
# Mandatory: no
# Range: 0-5
# Default:
# DebugLevel=3

### Option: PidFile
#	Name of PID file.
#
# Mandatory: no
# Default:
# PidFile=/tmp/zabbix_server.pid

PidFile=/var/run/zabbix/zabbix_server.pid

### Option: SocketDir
#	IPC socket directory.
#       Directory to store IPC sockets used by internal Zabbix services.
#
# Mandatory: no
# Default:
# SocketDir=/tmp

SocketDir=/var/run/zabbix

### Option: DBHost
#	Database host name.
#	If set to localhost, socket is used for MySQL.
#	If set to empty string, socket is used for PostgreSQL.
#
# Mandatory: no
# Default:
DBHost=localhost

### Option: DBName
#	Database name.
#
# Mandatory: yes
# Default:
# DBName=

DBName=zabbix

### Option: DBSchema
#	Schema name. Used for IBM DB2 and PostgreSQL.
#
# Mandatory: no
# Default:
# DBSchema=

### Option: DBUser
#	Database user.
#
# Mandatory: no
# Default:
# DBUser=

DBUser=zabbix

### Option: DBPassword
#	Database password.
#	Comment this line if no password is used.
#
# Mandatory: no
# Default:
DBPassword=zabbix

### Option: DBSocket
#	Path to MySQL socket.
#
# Mandatory: no
# Default:
# DBSocket=

### Option: DBPort
#	Database port when not using local socket.
#
# Mandatory: no
# Range: 1024-65535
# Default:
# DBPort=

### Option: HistoryStorageURL
#	History storage HTTP[S] URL.
#
# Mandatory: no
# Default:
# HistoryStorageURL=

### Option: HistoryStorageTypes
#	Comma separated list of value types to be sent to the history storage.
#
# Mandatory: no
# Default:
# HistoryStorageTypes=uint,dbl,str,log,text

### Option: HistoryStorageDateIndex
#	Enable preprocessing of history values in history storage to store values in different indices based on date.
#	0 - disable
#	1 - enable
#
# Mandatory: no
# Default:
# HistoryStorageDateIndex=0

### Option: ExportDir
#	Directory for real time export of events, history and trends in newline delimited JSON format.
#	If set, enables real time export.
#
# Mandatory: no
# Default:
# ExportDir=

### Option: ExportFileSize
#	Maximum size per export file in bytes.
#	Only used for rotation if ExportDir is set.
#
# Mandatory: no
# Range: 1M-1G
# Default:
# ExportFileSize=1G

############ ADVANCED PARAMETERS ################

### Option: StartPollers
#	Number of pre-forked instances of pollers.
#
# Mandatory: no
# Range: 0-1000
# Default:
# StartPollers=5

### Option: StartIPMIPollers
#	Number of pre-forked instances of IPMI pollers.
#       The IPMI manager process is automatically started when at least one IPMI poller is started.
#
# Mandatory: no
# Range: 0-1000
# Default:
# StartIPMIPollers=0

### Option: StartPreprocessors
#	Number of pre-forked instances of preprocessing workers.
#       The preprocessing manager process is automatically started when preprocessor worker is started.
#
# Mandatory: no
# Range: 1-1000
# Default:
# StartPreprocessors=3

### Option: StartPollersUnreachable
#	Number of pre-forked instances of pollers for unreachable hosts (including IPMI and Java).
#	At least one poller for unreachable hosts must be running if regular, IPMI or Java pollers
#	are started.
#
# Mandatory: no
# Range: 0-1000
# Default:
# StartPollersUnreachable=1

### Option: StartTrappers
#	Number of pre-forked instances of trappers.
#	Trappers accept incoming connections from Zabbix sender, active agents and active proxies.
#	At least one trapper process must be running to display server availability and view queue
#	in the frontend.
#
# Mandatory: no
# Range: 0-1000
# Default:
# StartTrappers=5

### Option: StartPingers
#	Number of pre-forked instances of ICMP pingers.
#
# Mandatory: no
# Range: 0-1000
# Default:
# StartPingers=1

### Option: StartDiscoverers
#	Number of pre-forked instances of discoverers.
#
# Mandatory: no
# Range: 0-250
# Default:
# StartDiscoverers=1

### Option: StartHTTPPollers
#	Number of pre-forked instances of HTTP pollers.
#
# Mandatory: no
# Range: 0-1000
# Default:
# StartHTTPPollers=1

### Option: StartTimers
#	Number of pre-forked instances of timers.
#	Timers process maintenance periods.
#	Only the first timer process handles host maintenance updates. Problem suppression updates are shared
#	between all timers.
#
# Mandatory: no
# Range: 1-1000
# Default:
# StartTimers=1

### Option: StartEscalators
#	Number of pre-forked instances of escalators.
#
# Mandatory: no
# Range: 0-100
# Default:
# StartEscalators=1

### Option: StartAlerters
#	Number of pre-forked instances of alerters.
#	Alerters send the notifications created by action operations.
#
# Mandatory: no
# Range: 0-100
# Default:
# StartAlerters=3

### Option: JavaGateway
#	IP address (or hostname) of Zabbix Java gateway.
#	Only required if Java pollers are started.
#
# Mandatory: no
# Default:
# JavaGateway=

### Option: JavaGatewayPort
#	Port that Zabbix Java gateway listens on.
#
# Mandatory: no
# Range: 1024-32767
# Default:
# JavaGatewayPort=10052

### Option: StartJavaPollers
#	Number of pre-forked instances of Java pollers.
#
# Mandatory: no
# Range: 0-1000
# Default:
# StartJavaPollers=0

### Option: StartVMwareCollectors
#	Number of pre-forked vmware collector instances.
#
# Mandatory: no
# Range: 0-250
# Default:
# StartVMwareCollectors=0

### Option: VMwareFrequency
#	How often Zabbix will connect to VMware service to obtain a new data.
#
# Mandatory: no
# Range: 10-86400
# Default:
# VMwareFrequency=60

### Option: VMwarePerfFrequency
#	How often Zabbix will connect to VMware service to obtain performance data.
#
# Mandatory: no
# Range: 10-86400
# Default:
# VMwarePerfFrequency=60

### Option: VMwareCacheSize
#	Size of VMware cache, in bytes.
#	Shared memory size for storing VMware data.
#	Only used if VMware collectors are started.
#
# Mandatory: no
# Range: 256K-2G
# Default:
# VMwareCacheSize=8M

### Option: VMwareTimeout
#	Specifies how many seconds vmware collector waits for response from VMware service.
#
# Mandatory: no
# Range: 1-300
# Default:
# VMwareTimeout=10

### Option: SNMPTrapperFile
#	Temporary file used for passing data from SNMP trap daemon to the server.
#	Must be the same as in zabbix_trap_receiver.pl or SNMPTT configuration file.
#
# Mandatory: no
# Default:
# SNMPTrapperFile=/tmp/zabbix_traps.tmp

SNMPTrapperFile=/var/log/snmptrap/snmptrap.log

### Option: StartSNMPTrapper
#	If 1, SNMP trapper process is started.
#
# Mandatory: no
# Range: 0-1
# Default:
# StartSNMPTrapper=0

### Option: ListenIP
#	List of comma delimited IP addresses that the trapper should listen on.
#	Trapper will listen on all network interfaces if this parameter is missing.
#
# Mandatory: no
# Default:
# ListenIP=0.0.0.0

### Option: HousekeepingFrequency
#	How often Zabbix will perform housekeeping procedure (in hours).
#	Housekeeping is removing outdated information from the database.
#	To prevent Housekeeper from being overloaded, no more than 4 times HousekeepingFrequency
#	hours of outdated information are deleted in one housekeeping cycle, for each item.
#	To lower load on server startup housekeeping is postponed for 30 minutes after server start.
#	With HousekeepingFrequency=0 the housekeeper can be only executed using the runtime control option.
#	In this case the period of outdated information deleted in one housekeeping cycle is 4 times the
#	period since the last housekeeping cycle, but not less than 4 hours and not greater than 4 days.
#
# Mandatory: no
# Range: 0-24
# Default:
# HousekeepingFrequency=1

### Option: MaxHousekeeperDelete
#	The table "housekeeper" contains "tasks" for housekeeping procedure in the format:
#	[housekeeperid], [tablename], [field], [value].
#	No more than 'MaxHousekeeperDelete' rows (corresponding to [tablename], [field], [value])
#	will be deleted per one task in one housekeeping cycle.
#	If set to 0 then no limit is used at all. In this case you must know what you are doing!
#
# Mandatory: no
# Range: 0-1000000
# Default:
# MaxHousekeeperDelete=5000

### Option: CacheSize
#	Size of configuration cache, in bytes.
#	Shared memory size for storing host, item and trigger data.
#
# Mandatory: no
# Range: 128K-64G
# Default:
# CacheSize=8M

### Option: CacheUpdateFrequency
#	How often Zabbix will perform update of configuration cache, in seconds.
#
# Mandatory: no
# Range: 1-3600
# Default:
# CacheUpdateFrequency=60

### Option: StartDBSyncers
#	Number of pre-forked instances of DB Syncers.
#
# Mandatory: no
# Range: 1-100
# Default:
# StartDBSyncers=4

### Option: HistoryCacheSize
#	Size of history cache, in bytes.
#	Shared memory size for storing history data.
#
# Mandatory: no
# Range: 128K-2G
# Default:
# HistoryCacheSize=16M

### Option: HistoryIndexCacheSize
#	Size of history index cache, in bytes.
#	Shared memory size for indexing history cache.
#
# Mandatory: no
# Range: 128K-2G
# Default:
# HistoryIndexCacheSize=4M

### Option: TrendCacheSize
#	Size of trend cache, in bytes.
#	Shared memory size for storing trends data.
#
# Mandatory: no
# Range: 128K-2G
# Default:
# TrendCacheSize=4M

### Option: ValueCacheSize
#	Size of history value cache, in bytes.
#	Shared memory size for caching item history data requests.
#	Setting to 0 disables value cache.
#
# Mandatory: no
# Range: 0,128K-64G
# Default:
# ValueCacheSize=8M

### Option: Timeout
#	Specifies how long we wait for agent, SNMP device or external check (in seconds).
#
# Mandatory: no
# Range: 1-30
# Default:
# Timeout=3

Timeout=4

### Option: TrapperTimeout
#	Specifies how many seconds trapper may spend processing new data.
#
# Mandatory: no
# Range: 1-300
# Default:
# TrapperTimeout=300

### Option: UnreachablePeriod
#	After how many seconds of unreachability treat a host as unavailable.
#
# Mandatory: no
# Range: 1-3600
# Default:
# UnreachablePeriod=45

### Option: UnavailableDelay
#	How often host is checked for availability during the unavailability period, in seconds.
#
# Mandatory: no
# Range: 1-3600
# Default:
# UnavailableDelay=60

### Option: UnreachableDelay
#	How often host is checked for availability during the unreachability period, in seconds.
#
# Mandatory: no
# Range: 1-3600
# Default:
# UnreachableDelay=15

### Option: AlertScriptsPath
#	Full path to location of custom alert scripts.
#	Default depends on compilation options.
#	To see the default path run command "zabbix_server --help".
#
# Mandatory: no
# Default:
# AlertScriptsPath=${datadir}/zabbix/alertscripts

AlertScriptsPath=/usr/lib/zabbix/alertscripts

### Option: ExternalScripts
#	Full path to location of external scripts.
#	Default depends on compilation options.
#	To see the default path run command "zabbix_server --help".
#
# Mandatory: no
# Default:
# ExternalScripts=${datadir}/zabbix/externalscripts

ExternalScripts=/usr/lib/zabbix/externalscripts

### Option: FpingLocation
#	Location of fping.
#	Make sure that fping binary has root ownership and SUID flag set.
#
# Mandatory: no
# Default:
# FpingLocation=/usr/sbin/fping

### Option: Fping6Location
#	Location of fping6.
#	Make sure that fping6 binary has root ownership and SUID flag set.
#	Make empty if your fping utility is capable to process IPv6 addresses.
#
# Mandatory: no
# Default:
# Fping6Location=/usr/sbin/fping6

### Option: SSHKeyLocation
#	Location of public and private keys for SSH checks and actions.
#
# Mandatory: no
# Default:
# SSHKeyLocation=

### Option: LogSlowQueries
#	How long a database query may take before being logged (in milliseconds).
#	Only works if DebugLevel set to 3, 4 or 5.
#	0 - don't log slow queries.
#
# Mandatory: no
# Range: 1-3600000
# Default:
# LogSlowQueries=0

LogSlowQueries=3000

### Option: TmpDir
#	Temporary directory.
#
# Mandatory: no
# Default:
# TmpDir=/tmp

### Option: StartProxyPollers
#	Number of pre-forked instances of pollers for passive proxies.
#
# Mandatory: no
# Range: 0-250
# Default:
# StartProxyPollers=1

### Option: ProxyConfigFrequency
#	How often Zabbix Server sends configuration data to a Zabbix Proxy in seconds.
#	This parameter is used only for proxies in the passive mode.
#
# Mandatory: no
# Range: 1-3600*24*7
# Default:
# ProxyConfigFrequency=3600

### Option: ProxyDataFrequency
#	How often Zabbix Server requests history data from a Zabbix Proxy in seconds.
#	This parameter is used only for proxies in the passive mode.
#
# Mandatory: no
# Range: 1-3600
# Default:
# ProxyDataFrequency=1

### Option: AllowRoot
#	Allow the server to run as 'root'. If disabled and the server is started by 'root', the server
#	will try to switch to the user specified by the User configuration option instead.
#	Has no effect if started under a regular user.
#	0 - do not allow
#	1 - allow
#
# Mandatory: no
# Default:
# AllowRoot=0

### Option: User
#	Drop privileges to a specific, existing user on the system.
#	Only has effect if run as 'root' and AllowRoot is disabled.
#
# Mandatory: no
# Default:
# User=zabbix

### Option: Include
#	You may include individual files or all files in a directory in the configuration file.
#	Installing Zabbix will create include directory in /usr/local/etc, unless modified during the compile time.
#
# Mandatory: no
# Default:
# Include=

# Include=/usr/local/etc/zabbix_server.general.conf
# Include=/usr/local/etc/zabbix_server.conf.d/
# Include=/usr/local/etc/zabbix_server.conf.d/*.conf

### Option: SSLCertLocation
#	Location of SSL client certificates.
#	This parameter is used only in web monitoring.
#	Default depends on compilation options.
#	To see the default path run command "zabbix_server --help".
#
# Mandatory: no
# Default:
# SSLCertLocation=${datadir}/zabbix/ssl/certs

### Option: SSLKeyLocation
#	Location of private keys for SSL client certificates.
#	This parameter is used only in web monitoring.
#	Default depends on compilation options.
#	To see the default path run command "zabbix_server --help".
#
# Mandatory: no
# Default:
# SSLKeyLocation=${datadir}/zabbix/ssl/keys

### Option: SSLCALocation
#	Override the location of certificate authority (CA) files for SSL server certificate verification.
#	If not set, system-wide directory will be used.
#	This parameter is used only in web monitoring and SMTP authentication.
#
# Mandatory: no
# Default:
# SSLCALocation=

### Option: StatsAllowedIP
#	List of comma delimited IP addresses, optionally in CIDR notation, or DNS names of external Zabbix instances.
#	Stats request will be accepted only from the addresses listed here. If this parameter is not set no stats requests
#	will be accepted.
#	If IPv6 support is enabled then '127.0.0.1', '::127.0.0.1', '::ffff:127.0.0.1' are treated equally
#	and '::/0' will allow any IPv4 or IPv6 address.
#	'0.0.0.0/0' can be used to allow any IPv4 address.
#	Example: StatsAllowedIP=127.0.0.1,192.168.1.0/24,::1,2001:db8::/32,zabbix.example.com
#
# Mandatory: no
# Default:
# StatsAllowedIP=

####### LOADABLE MODULES #######

### Option: LoadModulePath
#	Full path to location of server modules.
#	Default depends on compilation options.
#	To see the default path run command "zabbix_server --help".
#
# Mandatory: no
# Default:
# LoadModulePath=${libdir}/modules

### Option: LoadModule
#	Module to load at server startup. Modules are used to extend functionality of the server.
#	Formats:
#		LoadModule=<module.so>
#		LoadModule=<path/module.so>
#		LoadModule=</abs_path/module.so>
#	Either the module must be located in directory specified by LoadModulePath or the path must precede the module name.
#	If the preceding path is absolute (starts with '/') then LoadModulePath is ignored.
#	It is allowed to include multiple LoadModule parameters.
#
# Mandatory: no
# Default:
# LoadModule=

####### TLS-RELATED PARAMETERS #######

### Option: TLSCAFile
#	Full pathname of a file containing the top-level CA(s) certificates for
#	peer certificate verification.
#
# Mandatory: no
# Default:
# TLSCAFile=

### Option: TLSCRLFile
#	Full pathname of a file containing revoked certificates.
#
# Mandatory: no
# Default:
# TLSCRLFile=

### Option: TLSCertFile
#	Full pathname of a file containing the server certificate or certificate chain.
#
# Mandatory: no
# Default:
# TLSCertFile=

### Option: TLSKeyFile
#	Full pathname of a file containing the server private key.
#
# Mandatory: no
# Default:
# TLSKeyFile=

####### For advanced users - TLS ciphersuite selection criteria #######

### Option: TLSCipherCert13
#	Cipher string for OpenSSL 1.1.1 or newer in TLS 1.3.
#	Override the default ciphersuite selection criteria for certificate-based encryption.
#
# Mandatory: no
# Default:
# TLSCipherCert13=

### Option: TLSCipherCert
#	GnuTLS priority string or OpenSSL (TLS 1.2) cipher string.
#	Override the default ciphersuite selection criteria for certificate-based encryption.
#	Example for GnuTLS:
#		NONE:+VERS-TLS1.2:+ECDHE-RSA:+RSA:+AES-128-GCM:+AES-128-CBC:+AEAD:+SHA256:+SHA1:+CURVE-ALL:+COMP-NULL:+SIGN-ALL:+CTYPE-X.509
#	Example for OpenSSL:
#		EECDH+aRSA+AES128:RSA+aRSA+AES128
#
# Mandatory: no
# Default:
# TLSCipherCert=

### Option: TLSCipherPSK13
#	Cipher string for OpenSSL 1.1.1 or newer in TLS 1.3.
#	Override the default ciphersuite selection criteria for PSK-based encryption.
#	Example:
#		TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
#
# Mandatory: no
# Default:
# TLSCipherPSK13=

### Option: TLSCipherPSK
#	GnuTLS priority string or OpenSSL (TLS 1.2) cipher string.
#	Override the default ciphersuite selection criteria for PSK-based encryption.
#	Example for GnuTLS:
#		NONE:+VERS-TLS1.2:+ECDHE-PSK:+PSK:+AES-128-GCM:+AES-128-CBC:+AEAD:+SHA256:+SHA1:+CURVE-ALL:+COMP-NULL:+SIGN-ALL
#	Example for OpenSSL:
#		kECDHEPSK+AES128:kPSK+AES128
#
# Mandatory: no
# Default:
# TLSCipherPSK=

### Option: TLSCipherAll13
#	Cipher string for OpenSSL 1.1.1 or newer in TLS 1.3.
#	Override the default ciphersuite selection criteria for certificate- and PSK-based encryption.
#	Example:
#		TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
#
# Mandatory: no
# Default:
# TLSCipherAll13=

### Option: TLSCipherAll
#	GnuTLS priority string or OpenSSL (TLS 1.2) cipher string.
#	Override the default ciphersuite selection criteria for certificate- and PSK-based encryption.
#	Example for GnuTLS:
#		NONE:+VERS-TLS1.2:+ECDHE-RSA:+RSA:+ECDHE-PSK:+PSK:+AES-128-GCM:+AES-128-CBC:+AEAD:+SHA256:+SHA1:+CURVE-ALL:+COMP-NULL:+SIGN-ALL:+CTYPE-X.509
#	Example for OpenSSL:
#		EECDH+aRSA+AES128:RSA+aRSA+AES128:kECDHEPSK+AES128:kPSK+AES128
#
# Mandatory: no
# Default:
# TLSCipherAll=

EOF

echo "备份并修改Zabbix服务器配置完成"

# 获取最新的create.sql文件并导入到数据库
latest_sql_file=$(ls /usr/share/doc/ | grep 'zabbix-server-mysql' | sort -V | tail -1)
zcat "/usr/share/doc/${latest_sql_file}/create.sql.gz" | mysql -uzabbix -pzabbix zabbix
echo "获取最新的create.sql文件并导入到数据库完成"

# 启动Zabbix服务进程，并加入开机自启
systemctl start zabbix-server.service
systemctl enable zabbix-server.service
echo "启动Zabbix服务进程，并加入开机自启完成"

# 配置Apache的配置文件，修改时区
sed -i 's/# php_value date.timezone Europe\/Riga/php_value date.timezone Asia\/Shanghai/g' /etc/httpd/conf.d/zabbix.conf
echo "配置Apache的配置文件，修改时区完成"
# 重启Apache Web服务器
systemctl start httpd
systemctl start zabbix-agent.service
echo "Zabbix安装脚本执行完毕。"

↩

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

‍ ↩

zabbix 客户端一键安装脚本

本环境：centos7.9

简易安装脚本，Server=192.168.2.111此处需要修改为 server 的 ip 地址

#!/bin/bash
# 关闭SELinux、暂停防火墙
setenforce 0
systemctl stop firewalld

# 安装Zabbix仓库和zabbix-agent zabbix-get
rpm -ivh https://mirrors.tuna.tsinghua.edu.cn/zabbix/zabbix/4.0/rhel/7/x86_64/zabbix-release-4.0-1.el7.noarch.rpm
sed -i 's#repo.zabbix.com#mirrors.tuna.tsinghua.edu.cn/zabbix#g' /etc/yum.repos.d/zabbix.repo
yum install -y zabbix-agent zabbix-get.x86_64 net-tools

# 配置zabbix-agent，Server和ServerActive保持一致，Hostname根据情况修改
cat << 'EOF' > /etc/zabbix/zabbix_agentd.conf
PidFile=/var/run/zabbix/zabbix_agentd.pid
LogFile=/var/log/zabbix/zabbix_agentd.log
LogFileSize=0
Server=192.168.2.111
ServerActive=192.168.2.111
Hostname=Zabbix agent
Include=/etc/zabbix/zabbix_agentd.d/*.conf
EOF

# 启动zabbix-agent并检查
systemctl start zabbix-agent.service 
systemctl enable zabbix-agent.service
netstat -lntup | grep 10050

↩

Zabbix-Get 详解

‍ ↩
配置 zabbix_agentd.conf 详解

zabbix_agentd.conf 示例
```
[root@web02 ~]# cat /etc/zabbix/zabbix_agentd.conf        
PidFile=/var/run/zabbix/zabbix_agentd.pid
LogFile=/var/log/zabbix/zabbix_agentd.log
LogFileSize=0
Server=10.0.1.61
ServerActive=10.0.1.61
Hostname=Zabbix agent
Include=/etc/zabbix/zabbix_agentd.d/*.conf
```
zabbix_agentd.conf 是 Zabbix 代理守护进程的配置文件，它定义了代理如何与 Zabbix 服务器通信以及如何记录日志等。以下是文件中每个配置项的解释：
1. PidFile：
```
PidFile=/var/run/zabbix/zabbix_agentd.pid
```
  这个配置项指定了存储 Zabbix 代理进程 ID（PID）的文件的路径。当代理启动时，它的 PID 会被写入到这个文件中。这通常用于监控代理进程是否正在运行，或者在需要时终止代理进程。
2. LogFile：
```
LogFile=/var/log/zabbix/zabbix_agentd.log
```
  这个配置项指定了 Zabbix 代理日志文件的路径。所有代理的日志信息，包括错误、警告和信息消息，都会被写入到这个文件中。这对于调试和监控代理的行为非常有用。
3. LogFileSize：
```
LogFileSize=0
```
  这个配置项设置了日志文件的最大大小（以 MB 为单位）。如果设置为 0（如上所示），则日志文件的大小将不受限制，直到代理被重启。如果设置了具体的数值，当日志文件达到这个大小时，旧的日志会被滚动（即创建一个新的日志文件，旧的日志文件会被重命名或删除）。
4. Server：
```
Server=10.0.1.61
```
  这个配置项指定了 Zabbix 代理应该连接的 Zabbix 服务器的 IP 地址。在这个例子中，代理将尝试连接到 IP 地址为 192.168.2.111 的服务器。
5. ServerActive：
```
ServerActive=10.0.1.61
```
  这个配置项指定了 Zabbix 代理用于接收来自 Zabbix 服务器的主动检查（active checks）的 IP 地址。在这个例子中，代理期望从地址（10.0.1.61）接收数据。应该与 Server 地址一致
6. Hostname：
```
Hostname=Zabbix agent
```
  这个配置项设置了代理在与 Zabbix 服务器通信时使用的主机名。这个名称会在 Zabbix 的 Web 界面中显示，以便于识别代理。实际定义应有所区别，如 Zabbix agent001 等
7. Include：
```
Include=/etc/zabbix/zabbix_agentd.d/*.conf
```
  这个配置项指定了一个目录，Zabbix 代理会在这个目录下查找并包含（include）额外的配置文件。这些文件通常以 .conf为扩展名，可以用来定义额外的用户参数（UserParameters），这些参数可以被 Zabbix 服务器用来获取更多的监控数据。
这些配置项是 Zabbix 代理正常运行的基础，确保代理能够正确地与 Zabbix 服务器通信，并记录必要的日志信息。在修改配置文件后，通常需要重启 Zabbix 代理服务以使更改生效。 ↩
用 docker 快速部署 zabbix

【全网最简单的 Zabbix 部署方式】 https://www.bilibili.com/video/BV16a411n7Mt/?share_source=copy_web&vd_source=060a67fd53d735ce5086832f669200d5

https://github.com/Jack-Ywn/zabbix-docker/blob/4.0/docker-compose_v3_alpine.yaml

https://www.zabbix.com/documentation/4.0/zh/manual/installation/containers

https://github.com/zabbix/zabbix-docker

https://www.imooc.com/article/324911 ↩

Zabbix 学习路线和要点摘抄

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

为什么要使用监控

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

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

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

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

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

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

zabbix 客户端一键安装脚本

Zabbix-Get 详解

配置 zabbix_agentd.conf 详解

用 docker 快速部署 zabbix

相关帖子

zabbix 客户端一键安装脚本

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

IB 网卡流量带宽监控

Zabbix

修改 Hostname 值

zabbix 通过 jmx 监控 java/tomcat

zabbix 发送报警信息带图片

欢迎来到这里！

近期热议

推荐标签标签

最新标签

Zabbix 学习路线和要点摘抄

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

为什么要使用监控

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

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

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

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

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

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

zabbix 客户端一键安装脚本

Zabbix-Get 详解

配置 zabbix_agentd.conf 详解

用 docker 快速部署 zabbix

相关帖子

zabbix 客户端一键安装脚本

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

IB 网卡流量带宽监控

Zabbix

修改 Hostname 值

zabbix 通过 jmx 监控 java/tomcat

zabbix 发送报警信息带图片

欢迎来到这里！

近期热议

推荐标签 标签

最新标签

推荐标签标签