Zabbix高可用监控系列文章-proxy高可用

一：proxy的配置信息

1.1：proxy安装

apt install zabbix-proxy-sqlite3
# 修改权限信息
chown zabbix:zabbix /etc/zabbix/zabbix_proxy.conf
# 配置sqlite3-db的目录及权限
mkdir /opt/zabbix-proxy
chown zabbix:zabbix /opt/zabbix-proxy

1.2：配置文件

Server=192.168.10.61;192.168.10.62
Hostname=proxy01
LogFile=/var/log/zabbix/zabbix_proxy.log
LogFileSize=0
PidFile=/run/zabbix/zabbix_proxy.pid
SocketDir=/run/zabbix
DBName=/opt/zabbix-proxy/zabbix_proxy
ConfigFrequency=60
SNMPTrapperFile=/var/log/snmptrap/snmptrap.log
Timeout=4
FpingLocation=/usr/bin/fping
Fping6Location=/usr/bin/fping6
LogSlowQueries=3000
StatsAllowedIP=127.0.0.1

1.3：添加proxy

二：添加proxy监控

2.1：安装zabbix-agent2

hostnamectl set-hostname proxy01

apt install zabbix-agent2

2.2：zabbix-agent2配置文件

PidFile=/var/run/zabbix/zabbix_agent2.pid
LogFile=/var/log/zabbix/zabbix_agent2.log
LogFileSize=0
Server=192.168.10.61,192.168.10.62
HostnameItem=system.hostname
Include=/etc/zabbix/zabbix_agent2.d/*.conf
AllowKey=system.run[*]  # 要添加这个，否则无法通过agent去执行proxy配置更新或者远程命令
ControlSocket=/tmp/agent.sock
Include=./zabbix_agent2.d/plugins.d/*.conf

2.3：在server中添加监控

注意的点：这里proxy的监控Host name值，要和proxy配置里面的name一致。

三：配置proxy健康检查监控项及触发器

这里我们直接在自带的"Zabbix proxy health"模板中添加。

3.1：proxy健康检查监控项

3.2：添加触发器

3.3：proxy健康检查监控项说明

这个监控项是zabbix-server来检查的，与该agent存活无关

虽然proxy01的agent我关闭了，但还能监测到相关的指标

3.4：创建切换脚本

脚本链接会放在文章最后。

3.5：配置对应触发器动作

这里需要先创建脚本，不然动作里面看不到相关脚本的配置选项。

先约束到对应的触发器上面

再选择脚本执行，画红线部分要注意

3.6：添加proxy配置文件更新脚本

切换主机后，上面的"switch_proxy.py"里面会调用该脚本来让proxy重新获取server的配置文件。

3.7：给proxy配置备选主机

这里我们需要给proxy的tag中，添加一个备选主机，这里面会有一些问题，当proxy是作为不同数据中心接入点时：

• 也就是说每个proxy下面的主机都是不同区域的，不能互相访问的
• 这时候不能将a数据中心的proxy下面主机，挂到b数据中心proxy主机，这是行不通的

所以想到了在proxy的tag上面添加”backup_proxy“标记，来标记当前proxy发生故障时，备选的proxy列表。

value的值填写需要切换过去的proxy主机对应名称。

注意：这里的tag不是唯一名称，可以配置多个相同名称的tag，所以也就有了备选”列表“的概念。

四：切换前的检查

上面的我们都做完后，就要进行测试了

4.1：检查监控项的值

4.2：检查主机信息

这里我配置了几个空主机，只有agent02可以用来查看监控的切换状态。

五：测试切换

5.1：停止proxy模拟故障发生

先登录proxy01的主机，使用命令停止zabbix-proxy进程。

systemctl stop zabbix-proxy

5.2：刷新"Problems"观察触发器状态

5.3：检查主机切换情况

5.4：检查切换过程中的监控项

这里我们使用agent02中的一个监控项，它的频率是1min/次

在切换时，并没有影响到监控项的获取。

（可能也是凑巧，没有在获取的点上发生切换）

5.5：查看切换脚本日志

被切换的主机id会被记录下来，后面可以使用脚本，将主机切换回修复好的proxy中，不过这是后话了，因为我们首先要保证在proxy挂了一个之后，能有一个proxy来接替故障的proxy工作。

此时已经切换成功，耗时还算客观，但这是测试环境，实际生产中的主机可能会很多，切换耗时应该会增大。

六：一些思考和计划

到这里，我们的proxy切换脚本已经完成了，最后说一下为什么要弄这个脚本，以及在写脚本时参考了哪些，思考了哪些。

• 为什么要做proxy高可用
  • 因为zabbix-server 在6.0出现了server的高可用，但是proxy还是存在单点故障隐患的
  • zabbix预计在2023年第二季度的7.0LTS版本中，才会更新proxy的高可用
• 目前有哪些proxy高可用方案及优缺点
  • 使用keepalived来做proxy的主备切换
    • 优点：切换及时（切换检查也需要时间，这里说的及时是相对的，相对手动切换proxy）
    • 缺点：备用proxy在正常时一直闲置，浪费资源
  • proxy发生故障后手动切换
    • 优点：操作难度小
    • 缺点：需要管理员接到proxy挂了，然后再登录web切换，耗时长
  • 自动切换proxy
    • 优点：全自动切换，无其他因素干预，在很短时间就能切换proxy
    • 缺点：依赖于zabbix的api，不是原生做法，需要维护脚本的可用性
• 做脚本的一些参考链接
  • 在网上搜索了一下相关的proxy高可用文章，发现了一个老外写的思路挺好的，我的这个方法也是根据他的思路改造
  • 在zabbix官网的里程碑中，看到了关于proxy高可用的建议，里面提到了对备选proxy的一个择优思路

最后放上脚本的github链接，有需要的朋友可用自行获取（记得star）。

https://github.com/cplinux/switch_zabbix_proxy

最后写一下脚本的实现思路：

1. 通过传参获取故障proxy主机名称
2. 根据故障proxy主机名称获取对应的备选proxy列表
3. 获取备选proxy的nvps值，选取最小的来新的proxy
4. 通过主机接口，筛选出关联在故障proxy上的主机
5. 通过主机批量更新接口，更新相关主机的proxy到新的proxy上
6. 通过命令更新zabbix-server的配置文件
7. 通过脚本使新的proxy主动拉取zabbix-server上的配置文件

计划是：

• 故障的proxy修复好了之后，被迁移的主机需要再转回来，后面有时间再写一个转会来的脚本
  • 手动转也可以，因为在故障发生时，我们已经保证了主机的监控可用性，后面在web中使用批量更新也可用修改
• 备选proxy增加，可以把主机分散在多个备选proxy中，这样不会导致proxy压力增加
  • 故障切换需要迅速，切换中增加的每个多余的步骤都是浪费时间。。。这也是logger在最后打印的原因，这样能减少一下io耗时

参考地址：

• https://blog.zabbix.com/how-to-setup-redundant-zabbix-proxies-without-complex-cluster-configurations/12092/

• https://www.zabbix.com/documentation/6.0/zh/manual/config/items/itemtypes/internal

• https://support.zabbix.com/browse/ZBXNEXT-5911

公众号地址：