一、zabbix完整的监控配置流程大体上由如下步骤组成：
Host group --> Hosts --> Applications --> Items --> Triggers --> Events --> Actions (conditon+operation) --> User groups --> Users --> Medias (graph, screen)
依赖关系： Host --> Item --> Trigger --> Action --> Notice, Command
1. Application：把功能相近的一组item归类在一起统一进行管理组件；
2. Template：模板；包括item, application, trigger, graph, action
3. 主机组： 机器用途、系统版本、应用程序、地理位置、业务单元
4. Item： 定义item：key+parameters
- zabbix内建：预定义；内建key有n种分类；
type：- agent：被动
- agent：主动
- snmp v1，...
网卡流量相关：
net.if.in[if,]
if: 接口，如eht0
mode: bytes, packets, errors, dropped
例如：[root@zabbix ~]# zabbix_get -s 192.168.43.14 -k "net.if.in[ens33,packets]"
net.if.out[if,]
例如：[root@zabbix ~]# zabbix_get -s 192.168.43.14 -k "net.if.out[ens33,bytes]"
net.if.total[if.]
端口相关：
net.tcp.listen[port]
net.tcp.port[,port]
net.tcp.service[service,,]
net.udp.listen[port]
进程相关：
kernel.maxfiles
kernel.maxproc
CPU相关：
system.cpu.intr
system.cpu.load[,]
system.cpu.num[]
system.cpu.switches
system.cpu.util[,,]
磁盘IO或文件系统相关：
vfs.dev.read[,,]
vfs.dev.write[,,]
vfs.fs.inode[fs,]
用户可自定义item：
关键：选取一个惟一的key；
命令：收集数据的命令或脚本；采集到的信息的种类：
numeric：数值，无符号，浮点数；
charactor：字符串数据；
log 日志数据；
text 文本数据；数据的类型：
boolean：布尔型；
octal：八进制数据；
decimal：十进制数据；
hexadecimal：十六进制数据；store value：
AS is：数据不做任何处理；采样的是什么就记录什么；
Delta（Simple change）：本次采样数据减去前一次采样数据；
Delta（speed per second）：本次采样数据减去前一次采样数据，而后除以采样间隔时长；
5. Trigger:触发器；逻辑表达式，定义了数据指标的阈值；通常定义不合理区间；条件满足时，TRUE,表示PROBLEM状态；反之，则OK状态
-
状态：
- OK：正常状态 --> 老版本为false;
- PROBLEM：有事件发生；非正常状态 --> 老版本为true;
-
基本的触发器表达式格式如下：
{: . { }} server：主机名称
key：主机上关系的相应监控项的key
function：评估采集到的数据是否在合理范围内时所使用的函数，其评估过程可以根据采取的数据、当前时间及其他因素进行
目前，触发器所支持的函数有：avg, count, change, date, dayofweek, dayofmonth, delta, diff, iregexp, regexp, last, max, min, nodata, now, prev, str, strlen, sum
parameter：函数参数：大多数数值函数可以接受秒数为其参数，而如果在数值参数之前使用“#”作为前缀，则表示为最近几次的取值，如sum(300)表示300秒内所有取值之和，而sum(#10)则表示最近10此取值之和；
此外，avg、count、last、min和max还支持使用第二个参数，用于完成时间限定：如，max(1h,7d)将返回一周之前的最大值
operator: 表达式所支持的运算符机器功能
>, <, =, #(不等于)，/, *, -, + ，&, |示例：{www.magedu.com:system.cpu.load[all,avg1].last(0)}>3
表示主机www.magedu.com上所以CPU的过去1分钟内的平均负载的最后一次取值大于3时将出发状态变换
对last函数来说，last(0)相当于last(#1) zabbix server每次接收到items的新数据时，就会对Item的当前采样值进行判断，即与trigger的表达式进行比较；
-
一个trigger只能属于一个Item, 但一个Item可以有多个trigger；
- regexp：检查最后一次采样的数据是否能够被指定的模式所匹配；1表示匹配，0表示不匹配；
- now：返回自Unix元年至此刻经历的秒数；
- prev: 倒数第二个采样值；
- str: 从最后一次的采样中查找此处指定的子串；
- strlen：
-
Severity：
- Not classified: 未知级别，灰色；
- Information: 一般信息，亮绿；
- Warning：警告信息，黄色；
- Average: 一般故障，橙色；
- High：高级别故障，红色；
- Disater：致命故障，亮红；
触发器间有依赖关系；
6. Action：动作
-
conditions：触发此动作的条件，一般通过事件触发
- Trigger events: OK --> PROBLEM
- Discovery events: zabbix的network discovery工作时发现主机；
- Auto registration events：主动模式的agent注册时产生的事件；
- Internal events：Item变成不再被支持，或Trigger变成未知状态；
-
Operations：触发条件满足时要采取的动作
- send message：发送报警信息给关联的用户
Meida Type：传递消息的通道；
script：用来定义信息通道，完成信息传递的脚本；
（1）脚本放置路径：在服务器端/etc/zabbix/zabbix_server.conf
AlertScriptsPath=/usr/lib/zabbix/alerscripts
（2）zabbix会向脚本传递三个参数：
$1：经由此信道发送的信息的接收目标；可以是邮箱地址，电话号码；
$2：信息的主题，subject；
$3：传递信息的内容； - Remote command
功能：在agent所在的主机上运行用户指定的命令或脚本来尝试着恢复故障
例如：- 重启服务：
- 使用IPMI接口重启服务器；
- 任何自定义脚本可完成的功能：清理磁盘空间，完成虚拟机实例迁移等等；
- remote command中的脚本是远程执行的脚本，而sent message中media type里的脚本是用来发信息的脚本；
- send message：发送报警信息给关联的用户
配置send message：
(1) 定义好Media；
(2) 定义好用户；
(3) 配置要发送的信息；
7. Media types：媒介：
定义告警方式的传输信息的通道；
- Meida Type类型：
默认3种：- Email：邮件；需要定义发件人邮箱地址和SMTP服务器
- jabber：即时通信通用框架；基于msn、sq、Yahoo Messenger、google的GTalk的等通信软件；
- SMS：短信（仅北美使用）；
- script：自定义脚本；必须放置在指定路径下，可调用短信网关、微信网关；
- Ez Texting（USA，Canada）：商业；
- 安全连接：发邮件时是否使用安全的连接；
- starttls：使用smtp协议时，自动触发ssl；
- ssl/tls：需要额外配置ssl，明确指明使用smtp协议时才会调用ssl；
如果使用的是互联网上的邮件服务器，基于认证的方式，填入注册的邮箱、密码即可；
- 在被管理主机上zabbix_agentd进程是以zabbix用户身份运行的，所以要执行远程命令时，会用到管理权限，所以zabbix基于sudo的方式执行命令；
在被管理端：
第一步：开启zabbix用户的sudo管理权限：
]# visudo
添加：
zabbix ALL=(ALL) NOPASSWD: ALL
表示zabbix用户拥有所有权限，无需密码就可执行命令；
其中显示：
/#includedir /etc/sudoers.d
表示也可自己创建一个配置文件，在/etc/sudoers.d/目录下：第二步：开启zabbix server执行远程命令
]# cd /etc/zabbix/
]# vim /etc/zabbix/zabbix_agentd.conf
EnableRemoteCommands=1 允许远程命令在本机执行
LogRemoteCommands=1 启用远程命名执行的记录日志
/#Defaults requiretty 把此项注释掉，否则远程执行命令失败；
- 宏：macro，预设的文本替换模式；
- zabbix中有两种：
内置宏：{MACRO}
自定义宏：{$MACRO} - 命名方式：大写字母、数字、下划线；
注意：定义宏，调用或定义时都必须有$； - 级别：
全局宏：
模板宏：
主机宏： - 宏的应用优先级：
主机 --> 模板 --> 全局
宏是一种抽象（Abstraction），它根据一系列预定义的规则替换一定的文本模式，而解释器或编译器在遇到宏时会自动进行这一模式替换；
类似地，zabbix基于宏保存预设文本模式，并且在调用时将其替换为其中的文本；
zabbix有许多内置的宏，如{HOST.NAME}、{HOST.IP}、{TRIGGER.DESCRIPTION}、{TRIGGER.NAME}、{TRIGGER.EVENTS.ACK}等；
详细信息查看官方文档： https://www.zabbix.com/documentation/3.0/manual/appendix/macros/supported_by_location
为了更强的灵活性，zabbix还支持在全局、模板或主机级别使用用户自定义宏(user macro);
用户自定义的宏要使用{$MACRO}，这种特殊的语法格式；
宏可以应用在item keys和descriptions、trigger名称和表达式、主机接口IP/NDS及端口、discovery机制的SNMP协议的相关信息中等等；
宏的名称只能使用大写字母、数字、下划线；
进一步信息请参考：
https://www.zabbix.com/documentation/3.0/manual/appendix/macros/supported_by_location - 宏替换次序
首先是主机级别的宏；
其次是当前主机上一级模板张（直接链接至主机的模板）的宏，多个一级模板按其ID号排序；
再接着是二级模板中的宏；而后以此类推；
最后检查的是全局宏；
zabbix如果无法查找到某主机定义使用的宏，则不会对其进行替换操作；要使用用户自定义宏，有以下两种途径：
全局宏：Administration --> General --> Macros
主机或模板级别的宏：编辑相应的主机或模板的属性即可；
- 用户自定义key：
使用UserParameter 指令定义key，在有些场景中的监控，使用内建key不足以实现，所以才要自定义key；
例如监控nginx的stat页面，输出信息中有已接受的链接数、正在处理的链接数、等等，要展示这些数据时，zabbix内建key是没有此功能的，就需要自定义key了；
配置item时必然用到key；
用户自定义key在每一个zabbix的agent端进行定义；
只有agent支持UserParameter，才能够使用key；
这个key返回的数据最大为512KB；
如果被监控主机是UNIX主机或类UNIX主机（linux）操作系统，则使用/bin/sh命令行解释器启动一个子进程完成命令，而不是命令在当前进程中运行的，因为zabbix agent没有附加在shell解释器上，只是守护进程，所以需要单独启用一个子进程执行命令；
UserParameter位置：在zabbix agent端实现；
zabbix agent端配置文件：zabbix_agentd.conf
UserParameter 指令定义key
注意：改变配置文件需要重启agent端服务；
语法格式：
UserParameter=,
接受参数的命令:
UserParameter=key[*],command
*：表示可传递任意参数，取决于后面的命令能够接受这么多参数；
command：对于命令自身就有$1,$2,...$9用法时，例如awk命令，要使用$$0,$$1,$$2,...来表示；例如awk '{print $$2}'
除非UnsafeUserParameters已经启用，否则不要使用\'"`*?[]{}~$&;()<>|#@这些符号；
任何一个key主要就是用来采集数据，command就是产生数据的命令；这个数据通过zabbix协议发送给zabbix server端，所以，这个命令agent端要支持才可以；
还可以向key传参数，这个参数其实是传递给command命令接收的参数，就是在key中给定的参数，分别用2,9；如果后面脚本就是向脚本传参数，是命令就是在命令后面补上key中的参数；
示例：
监控TCP 连接数
<1>. 写获取数据的脚本：
[root@zabbix ~]# cd /etc/zabbix/zabbix_agentd.d/ #将脚本和自定义的配置文件放置在此目录下
[root@zabbix zabbix_agentd.d]# vim tcp_conn_plugin.sh
#!/bin/bash
#
#监控tcp连接数
tcp_conn_status(){
TCP_STAT=$1
ss -ant | awk 'NR>1 {++s[$1]} END {for(k in s) print k,s[k]}'> /tmp/tcp_conn.txt
TCP_NUM=$(grep "$TCP_STAT" /tmp/tcp_conn.txt | cut -d ' ' -f2)
if [ -z $TCP_NUM ];then
TCP_NUM=0
fi
echo $TCP_NUM
}
main(){
case $1 in
tcp_status)
tcp_conn_status $2;
;;
esac
}
main $1 $2
<2>. 创建.conf的配置文件引用脚本
[root@zabbix zabbix_agentd.d]# vim all.conf
UserParameter=linux_status[*],/etc/zabbix/zabbix_agentd.d/tcp_conn_plugin.sh "$1""$2""$3"
<3>. 编辑agent的配置文件导入自定义的配置文件all.conf
[root@zabbix zabbix_agentd.d]# grep "^[a-Z]" ../zabbix_agentd.conf
PidFile=/var/run/zabbix/zabbix_agentd.pid
LogFile=/var/log/zabbix/zabbix_agentd.log
LogFileSize=0
DebugLevel=4
EnableRemoteCommands=1
LogRemoteCommands=1
Server=192.168.43.11
ListenPort=10050
Hostname=192.168.43.14
Timeout=30
Include=/etc/zabbix/zabbix_agentd.d/*.conf #启用这项引用自定义配置all.conf
UnsafeUserParameters=1
[root@zabbix zabbix_agentd.d]# systemctl restart zabbix-agent.service #修改配置文件后需要重启才能生效
<4>. 在被监控的主机上为zabbix用户授权
[root@zabbix ~]# vim /etc/sudoers
zabbix ALL=(ALL) NOPASSWD: ALL
#Defaults requiretty # 用#号注释此行
<5>. 创建模板并关联到主机
验证数据：
示例：实现邮件报警
<1>. 定义 Trigger （触发器）
<2>. 定义媒介，用户及动作
<3>. 在server端定义发送邮件脚本
[root@zabbix ~]# cd /usr/lib/zabbix/alertscripts
[root@zabbix alertscripts]# vim sendmail.sh
#!/bin/bash
#
#zabbix发送邮件脚本
#date：2018-9-18
contact=$1
subject=$2
body=$3
echo "$body" | mail -s "$subject" "$contact"
<4>. 安装mialx，并修改配置文件
[root@zabbix ~]# yum -y install mailx
[root@zabbix ~]# vim /etc/mail.rc
添加如下内容：
set sendcharsets=iso-8859-1,utf-8
set [email protected]
set smtp=smtp.163.com:25
set [email protected]
set smtp-auth-password=xxxxxx
<5>.重启zabbix-server
[root@zabbix ~]# systemctl restart zabbix-server.service
<6>. 停止监听agent端的80端口后测试发送邮件成功
<7>.查看邮件发现发送的是附件格式，安装dos2unix转换工具并修改脚本
[root@zabbix ~]# yum -y install dos2unix
[root@zabbix ~]# vim /usr/lib/zabbix/alertscripts/sendmail.sh
#!/bin/bash
#
#zabbix发送邮件脚本
#date：2018-9-18
mailTmp=/tmp/mailTmp
echo $3 > $mailTmp
contact=$1
subject=$2
dos2unix -k $mailTmp
mail -s "$subject" "$contact" < $mailTmp
[root@zabbix ~]# systemctl restart zabbix-server.service
实现短信报警
实现过程和邮件报警类似，只是脚本不同，具体创建媒介、用户和动作的过程就不在赘述，下面是短信报警的脚本，需要用到第三方的短信平台需要自行注册
#!/bin/bash
# 脚本的日志文件
LOGFILE="/tmp/SMS.log"
:>"$LOGFILE"
exec 1>"$LOGFILE"
exec 2>&1
MOBILE_NUMBER=$1 # 手机号码
MESSAGE_UTF8=$3 # 短信内容 $2没有用到
XXD="/usr/bin/xxd"
CURL="/usr/bin/curl"
TIMEOUT=5
# 短信内容要经过URL编码处理
MESSAGE_ENCODE=$(echo "$MESSAGE_UTF8" | ${XXD} -ps | sed 's/\(..\)/%\1/g' | tr -d '\n')
# Uid和Key的值需要自行修改
# Uid 网站用户ID
# Key 接口秘钥
Uid="XXXXXXX"
Key="XXXXXXX" #接口秘钥可以在网站中查询到
# SMS API
URL="http://sms.253.com/msg/send?un=${Uid}&pw=${Key}&rd=1&phone=${MOBILE_NUMBER}&msg=${MESSAGE_ENCODE}"
# Send it
set -x
${CURL} -s --connect-timeout ${TIMEOUT} "${URL}"
验证脚本是否正确：
cd /usr/lib/zabbix/alertscripts/
./sendSms.sh 手机号xxxxx "hello"
@本脚本来自 无风的雨 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/guyan0319/article/details/78739451?utm_source=copy
- zabbix自动发现：
功能：将多台主机自动添加至被监控主机列表中；
前提是被监控主机上都安装了agent或启用了snmp；
server端通过自动扫描到指定的ip或网段中所有主机（agent或snmp端是活动的），添加之，自动将模板链接至主机；扫描过程是可判定服务器类型，如扫描到的是windows主机、mysql服务器；取决于扫描的哪些端口；
还可实现将扫描不到的主机自动移除，判定添加和移除取决于定义的行为；
zabbix网络发现可通过以下方式进行：
1.扫描ip地址范围；可使用snmp的ping或zabbix的ping命令；
2.扫描可用的服务(ftp,ssh,http,...)端口；
3.向zabbix_agent发请求，有zabbix_agent的响应；
4.向snmp_agent发请求，有snmp_agent的响应；zabbix网络发现分两个阶段：
discovery：发现
zabbix周期性的扫描在网络发现规则中定义的IP范围；
频繁的检查对每个独立的规则是可配置的；
对IP范围内的主机执行定义好的检查每个规则有一系列的服务检查；
每一种检查主机IP和服务的方式执行发现操作，一旦发现被网络发现模块生成一个发现事件；
actions：添加发现事件：两种目标
service：服务
host：主机IP每种的有四类事件：discoverd，lost，up，down；
- service up 每次zabbix检测到服务处于活动；
- service down 每次zabbix不能扫描到服务；
- host up 检测的主机ip至少有一个服务是up的；
- host down 检测的ip所有服务没有响应；service discoverd 服务被发现，包括第一次发现的服务或此前发现过后来扫描不到了；
service lost 启动后服务扫描不到服务；
host discovered 主机被发现，包括第一次发现主机或其次发现过后来扫描不到了；
host lost 启动后服务扫描不到ip；
可采取的actions：
网络发现中的事件可以触发action，从而自动执行指定的操作，如：
remote command，send message
(发现)添加/(丢失)删除主机；
(上线)启用/(下线)禁用主机；
将主机添加至组中，从组中删除主机；
将模板链接至主机，(把模板拆除)反链接；
还可执行远程脚本；
这些事件的配置还可基于设备的类型、IP、状态、上线/离线等进行配置；发现状态和采取的动作：
discovered --> add host
lost --> delete host
up --> enable
down --> disable网络发现：接口添加
网络发现中添加主机时会自动创建interface（agent，IPMI，JMX，SNMP）；
the services detected
例如，如果基于SNMP检测成功，则会创建SNMP接口；
如果某服务同时需要给了agent和SNMP，则两种接口都会创建；
如果同一种发现机制（如agent）返回了非唯一数据，则第一个接口被识别为默认，其它的为额外接口；
即便是某主机开始时只有agent接口，后来又通过snmp发现了它，同样会为其添加额外的snmp接口；
不同的主机如果返回了相同的数据，则第一个主机将被添加，余下的主机会被当作第一个主机的额外接口；配置网络发现
配置发现规则：
IP range：指明扫描地址范围；
Check：基于指定方式检测；支持SSH,LDAP,SMTP,FTP,HTTP,POP,NNTP,IMAP,TCP,Zabbix,agent,SNMPv1 agent SNMPv2 agent SNMPv3 agent,ICMP ping；使用的探测越高级结果越精确；一般对agent探测时通常对key检测（agent.ping）；
status：其中Active表示启用，Disabled表示禁用；
Delay：定义多长时间扫描一次网段；默认1h（小时），建议不要过于频繁；
zabbix分布式监控概述：
-
zabbix能高效地监控分布式IT架构；
在大型环境中zabbix提供两种解决方案；使用代理（proxy）：用于本区域数据收集，并将数据发送给zabbix server端；
-
使用节点（node）：提供完整的zabbix server用以建立分布式监控中的层级
proxy node Lightweight yes no GUI no yes works independently yes yes easy maintenance yes no automatic DB creation yes no local administraton no yes ready for embedded hardware yes no one way TCP connectons yes yes centralised configuration yes no generates notifications no yes
node本身是一台zabbix server，它有完整的web页面，完整的数据库，它将数据源源不断传送给Master；
proxy只有一个proxy的daemon进程，proxy也有自己的数据库，但它的数据库只会保存一定时间的数据，它与Master通信是将一批信息打包后发送到Master，Master将这些数据merge入Master数据库；
-
Master-Proxy相比Master-Node的优点有以下：
- proxy压力小，数据库只存储一定时间数据；
- Master压力变小，数据不是源源不断获取，减小IO压力；
架构更清晰，易维护；
-
server-node-client特性：
解决host过多时单台server面临性能瓶颈的问题；- 使用多个instance；
- 每个instance是独立的一套zabbix，有database和frontend（optional）；
- 支持热插拔，node和server的连接可随时断开，但不影响node的正常运行；
- node定时给server发送configuration，history，event；
- server定时给node发送configuration；
- 所有配置变更只能在node节点操作，不能在server端操作；
-
server-proxy-client工作特性：
- proxy不会向server端同步configuration，只会接收；
- proxy的数据库定时会将数据传送给server端，proxy本地数据库只保存最近没有发送的数据；
-
zabbix proxy功能：
功能：- 监控远程主机；
- 监控端可以是不可靠的链接；
- 当监控成千上万台设备时，可卸载zabbix server；
- 如果是分布式监控简化了维护；
- 代理仅需要TCP链接到zabbix server端；
- 这种方式很容易避开防火墙，因为仅需配置一条防火墙规则；
- 注意：
- zabbix proxy必须用一个单独的数据库；
- 指向zabbix server端数据库将改变配置；pointing it to the zabbix server database will break the configuration；
Items：
Zabbix agent checks 支持
Zabbix agent checks(active) 支持
Simple checks 支持
Trapper items 支持
SNMP checks 支持
SNMP traps 支持
IPMI checks 支持
JMX checks
Log file monitoring 支持
Internal checks 不支持，数据都在server端，无法做内部检查；
SSH checks 支持
Telnet checks 支持
External checks 支持
Built-in web monitoring 支持
Network discover 支持
Low-level discovery 支持
Calculating triggers 不支持，存储数据短，没办法获取长期数据计算再触发；
Processing events 不支持，无法触发事件，对应的事件触发都在server端进行；
Sending alerts 不支持，不能发送警告，在server端进行；
Remote commands 不支持，不能执行远程命令，在server端进行；
监控zabbix：
需要记住确保zabbix自身的健康状态；
利用nagios来监控zabbix；可以给nagios做高可用，也可给zabbix server做高可用；
zabbix performance tuning：zabbix性能调优
nvps：new values per second
zabbix server每秒接收到的新数据量；1000w/m，15000/s；调优：
（1）Database：历史数据不要保存太长时间；尽量让数据集可缓存到数据库服务器内存中；趋势数据时间可长些；
（2）触发器表达式：减少使用min(),max(),avg(),尽量使用last(),nodate()；
（3）数据收集：基于polling方式较慢，减少使用SNMP/agent-less/agent，尽量使用trapping（agent类型为active）；
（4）数据类型：文本型数据处理较慢，尽量少收集类型为text或string的数据，多使用类型为Numeric的数据；非关键指标，数据采集频率不要太高；
-
zabbix服务的配置调优：
（1）zabbix internal类型的监控来获知zabbix自己的状态；
（2）服务器组件的数量调优：
alerter，discoverer，escalator（报警升级），http poller，housekeeper，icmp pinger，ipmi poller，poller，trapper；
configuration syscer，db watchdog；
以上zabbix server端的进程数量一般需要调整，提高；例如： StartPollers=100 StartPingers=10 StartPollersUnreachable=50 StartIPMIPollers=10 StartTrappers=20 StartDBSyncers=8 数据库优化：
分库分表；
所有以history_,trends,events*开头的表，做分表；
使用pci-e固态硬盘做硬件存储；