zabbix-agent自定义配置监控项

1. 环境准备

本例中安装zabbix开源软件和zabbix运行所需的中间件和数据库apache、php和postgres，软件版本信息如下：

主机信息如下：

Red Hat Enterprise Linux Server 7.9 (Maipo)

2. agent的zabbix-agent.cong文件配置

要启用自定义配置，需要修改配置文件。

vi /usr/local/etc/zabbix_agentd.conf
# 修改
UnsafeUserParameters=1

如果提到了 “UnsafeUserParameters”，通常指的是允许用户定义的自定义参数或命令，这些参数可以在 Zabbix Agent 配置中通过 UserParameter 指令定义。这些自定义参数允许用户根据需要执行各种操作或收集特定的监控数据，但同时也增加了安全风险，因为不当配置可能导致安全漏洞或不可预料的系统行为。

为了避免潜在的安全问题，Zabbix Agent 在默认情况下禁用了对于 UserParameter 的使用，即使在配置文件中出现了相关的设置，也不会生效，除非明确地在配置中将其设置为允许 (UnsafeUserParameters=1)。在启用这些不安全的用户参数时，开发人员和系统管理员必须格外小心，确保仅允许受信任和经过验证的命令和参数，以减少潜在的安全风险。

3. psql环境准备

根据解决zabbix用户无法使用psql命令的问题.md文档来进行操作。

4. 创建文件夹

创建shell脚本目录，创建zabbix-agent自定义配置项目录。(如果有了不需要创建)

su - root
mkdir -p /usr/local/zabbix/etc/shell_dict
mkdir -p /usr/local/zabbix/etc/zabbix_agent.d
chown zabbix:zabbix /usr/local/zabbix/etc/shell_dict
chown zabbix:zabbix /usr/local/zabbix/etc/shell_dict

5. 创建soltStatus.conf文件

su zabbix
cd /usr/local/zabbix/etc/zabbix_agent.d
vi soltStatus.conf
cat soltStatus.conf
UserParameter=soltStatus[*],"$1"/soltStatus.sh "$2"

6. 创建soltStatus.sh文件

su zabbix
cd /usr/local/zabbix/etc/shell_dict
vi soltStatus.sh

# 创建完成之后重启zabbix_agentd服务
ps aux | grep zabbix_agentd
kill 进程pid
/etc/init.d/zabbix_agentd

shell脚本内容如下：

#!/bin/bash
PGSHELL_CONFDIR="$1"
source $PGSHELL_CONFDIR/zabbix_shell.conf 
query="SELECT active FROM pg_replication_slots where slot_name='pgbackup';"

# 执行查询，并获取结果
result=$($PSQL -t -c "${query}" | tr -d '[:space:]')
# 检查结果并输出状态
if [ "$result" == "t" ]; then
#    echo "Replication slot '$SLOT_NAME' is active."
	echo "T"
elif [ "$result" == "f" ]; then
#    echo "Replication slot '$SLOT_NAME' is inactive."
	echo "F"
else
#    echo "Unexpected result: $result"
	echo "F"
fi

7. 在server的web端创建宏

在server的web端中，点击监听的主机，再点击宏，添加宏。如下图所示

8. 创建监控项

点击主机，然后点击监控项进行监控项页面，再点击右上角的创建监控项进入创建监控项页面。如下图所示。

创建完成之后进行测试。如下图所示。

在zabbix-service端使用agent_get命令来进行测试。

[zabbix@zib-server root]$ zabbix_get -s 192.168.101.239 -k 'soltStatus['/usr/local/zabbix/etc/shell_dict','/home/zabbix/zabbix_env']'
T

附录1 pg_replication_slots

pg_replication_slots视图提供了当前存在于数据库集簇上的所有复制槽的列表，其中也包括复制槽的当前状态。

附录2 pg_stat_replication

附录3 复制槽

复制槽提供了一种自动方式，以确保主服务器在所有备用服务器收到 WAL 段之前不会删除这些段，并且主服务器不会删除可能导致恢复冲突的行，即使备用服务器已断开连接。

除了使用复制槽之外，还可以使用wal_keep_size防止删除旧的 WAL 段，或者使用archive_command或archive_library将这些段存储在存档中。但是，这些方法通常会导致保留比所需更多的 WAL 段，而复制槽仅保留已知需要的段数。另一方面，复制槽可以保留如此多的 WAL 段，以至于它们填满了为pg_wal分配的空间；max_slot_wal_keep_size限制了复制槽保留的 WAL 文件的大小。

同样，hot_standby_feedback本身在不使用复制槽的情况下，可以防止真空删除相关行，但在备用服务器未连接的任何时间段内不提供保护。复制槽克服了这些缺点。

查询和操作复制槽

每个复制槽都有一个名称，其中可以包含小写字母、数字和下划线字符。

可以在pg_replication_slots视图中查看现有的复制槽及其状态。

可以通过流复制协议或通过 SQL 函数创建和删除槽。

SELECT * FROM pg_replication_slots;

postgres=# SELECT * FROM pg_replication_slots;
 slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_
flush_lsn | wal_status | safe_wal_size | two_phase | conflicting 
-----------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+-----------
----------+------------+---------------+-----------+-------------
(0 rows)

SELECT slot_name, active, xmin, catalog_xmin, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots;

postgres=# SELECT slot_name, active, xmin, catalog_xmin, restart_lsn, confirmed_flush_lsn
postgres-# FROM pg_replication_slots;
 slot_name | active | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn 
-----------+--------+------+--------------+-------------+---------------------
(0 rows)

查询结果会包括以下字段：

• slot_name: 复制槽的名称。
• active: 指示复制槽是否处于活动状态。如果复制槽当前被使用，则为 true，否则为 false。
• xmin: 复制槽记录的最小事务 ID。
• catalog_xmin: 复制槽记录的系统目录事务 ID。
• restart_lsn: 对于物理复制槽，表示从何处重新启动复制。
• confirmed_flush_lsn: 对于逻辑复制槽，表示确认的刷新位置。

创建复制槽

1. 创建物理复制槽：

   在主服务器上执行sql：

   SELECT pg_create_physical_replication_slot('pgbackup');
   
   postgres=# SELECT pg_create_physical_replication_slot('pgbackup');
    pg_create_physical_replication_slot 
   -------------------------------------
    (pgbackup,)
   (1 row)
   
   SELECT * FROM pg_replication_slots;
   
   postgres=# SELECT * FROM pg_replication_slots;
    slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_
   flush_lsn | wal_status | safe_wal_size | two_phase | conflicting 
   -----------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+-----------
   ----------+------------+---------------+-----------+-------------
    pgbackup  |        | physical  |        |          | f         | f      |            |      |              |             |           
             |            |               | f         | 
   (1 row)
   
   

   在备份服务器上配置：

   若要配置备用服务器以使用此槽，则应在备用服务器上配置primary_slot_name。这是一个简单的示例

   primary_conninfo = 'host=192.168.101.239 port=8432 user=repuser password=123456'
   primary_slot_name = 'pgbackup'
   

2. 创建逻辑复制槽

   • 创建发布: 逻辑复制需要首先创建一个发布（publication），这决定了要复制哪些表或数据。例如，要创建名为 my_publication 的发布：

     CREATE PUBLICATION my_publication FOR TABLE my_table;
     

     这将创建一个名为 my_publication 的发布，并指定要复制的表。

   • 执行创建复制槽的命令: 使用 pg_create_logical_replication_slot 函数创建逻辑复制槽。例如，要创建名为 my_logical_slot 的复制槽：这里，'test_decoding' 是逻辑复制槽使用的解码插件。您可以根据需要选择不同的插件，如 pgoutput。

   SELECT pg_create_logical_replication_slot('my_logical_slot', 'test_decoding');
   

   • 确认复制槽的创建: 使用 pg_replication_slots 视图查看新创建的复制槽：

     SELECT * FROM pg_replication_slots;
     

   重要提示

   • 物理复制槽: 物理复制槽通常用于主备复制，必须在 PostgreSQL 主服务器和备用服务器之间配置好流复制。
   • 逻辑复制槽: 逻辑复制槽用于更灵活的数据复制和集成场景，需配置发布和订阅。

   确保在创建复制槽之前，您的 PostgreSQL 配置文件（通常是 postgresql.conf）中已经正确配置了复制相关的设置，如 wal_level、max_replication_slots 和 max_wal_senders。

   这两个操作都需要具有足够权限的用户进行操作，通常是数据库管理员。

删除复制槽

1. 删除物理复制槽

   在删除之前，您可以检查物理复制槽的状态，以确保它确实存在。

   SELECT * FROM pg_replication_slots WHERE slot_type = 'physical';
   

   使用 pg_drop_replication_slot 函数删除物理复制槽。例如，要删除名为 my_physical_slot 的物理复制槽：如果物理复制槽正在被从库使用，您可能需要先停止从库上的复制进程，然后再删除复制槽。在从库上，确保关闭或移除相关的复制配置。

   SELECT pg_drop_replication_slot('pgbackup');
   

   删除物理复制槽后，您可以再次检查复制槽的状态以确认其已被删除：

   SELECT * FROM pg_replication_slots;
   

2. 删除逻辑复制槽

   在删除之前，您可以检查逻辑复制槽的状态，以确保它确实存在。

   SELECT * FROM pg_replication_slots WHERE slot_type = 'logical';
   

   使用 pg_drop_replication_slot 函数删除逻辑复制槽。例如，要删除名为 my_logical_slot 的逻辑复制槽。

   SELECT pg_drop_replication_slot('pgbackup');
   

   请注意，如果逻辑复制槽正在被某个订阅（subscription）使用，您可能需要先删除相关的订阅。可以使用以下命令查看订阅。

   \ds+  -- 在 psql 中列出所有订阅
   

   删除逻辑复制槽后，您可以再次检查复制槽的状态以确认其已被删除：

   SELECT * FROM pg_replication_slots WHERE slot_type = 'logical';
   

特别注意：

对于创建复制槽，从库的postgresql.conf文件中的primary_conninfo配置中，关于user的配置很重要，对于复制槽的创建要使用这个用户来进行创建。负责配置的复制留的active依旧不会转变为t。

操作流程为：

1.查看当前的用户是谁。是管理员用户的话可以先查询一遍权限再切换为repuser用户。

# 查看当前用户
SELECT CURRENT_USER;
# 在主库上执行，查看repuser的用户是否有REPLICATION的权限
SELECT rolname, rolsuper, rolreplication FROM pg_roles WHERE rolname = 'repuser';
# 在主库上执行，授予权限
GRANT CREATE_REPLICATION_SLOT ON DATABASE your_database TO repuser;
# 在主库上执行，切换用户
SET ROLE repuser;

2.创建复制槽

SELECT pg_create_physical_replication_slot('pgbackup');

3.修改从库配文件

primary_conninfo = 'host=192.168.101.239 port=8432 user=repuser password=123456'
primary_slot_name = 'pgbackup'

4.验证复制槽状态

SELECT slot_name, active, xmin, catalog_xmin, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots;

postgres=# SELECT slot_name, active, xmin, catalog_xmin, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots;
 slot_name | active | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn 
-----------+--------+------+--------------+-------------+---------------------
 pgbackup  | t      |  747 |              | 0/41B0CF0   | 
(1 row)