Zabbix7.4.8（一）：通过Zabbix agent 2监控postgresql相关指标
一、概述
Zabbix agent 2 是新一代的 Zabbix agent，使用 Go 编写（并复用了一些来自 Zabbix agent 的 C 代码）。 其设计目标包括：
减少 TCP 连接的数量。
提供更高效的检查并发性。
通过 plugins 实现轻松扩展，支持使用最少代码实现简单检查，并支持由长时间运行的脚本组成的复杂检查，以及具有周期性报告功能的独立数据收集。
作为 Zabbix agent 的替代品，支持其所有先前功能。
二、安装部署
2.1zabbix-server和zabbix-agent2在同一台机器
docker run --name zabbix-agent2 -e TZ=Asia/Shanghai -e ZBX_HOSTNAME="pg204" -e ZBX_SERVER_HOST="172.22.0.1,zabbix-server-pgsql" -e ZBX_SERVER_PORT="10051" --network=sinops_network -p 10053:10050 --restart unless-stopped -d zabbix/zabbix-agent2:ubuntu-7.0-latest
2.2zabbix-server和zabbix-agent2在不在同一台机器
docker run --name zabbix-agent2 -e TZ=Asia/Shanghai -e ZBX_HOSTNAME="pg201" --network=host -e ZBX_SERVER_HOST="192.168.1.204" -e ZBX_ALLOWED_HOSTS="127.0.0.1,::1,192.168.1.0/24" -e ZBX_SERVER_PORT="10051" -p 10050:10050 --restart unless-stopped -d zabbix/zabbix-agent2:ubuntu-7.0-latest
2.3host 模式
| 问题 | 如何解决 |
| 跨主机通信 | 使用宿主机 IP（192.168.1.x），走物理网络 ✅ |
| IP 冲突 | 不使用 Docker bridge IP（172.22.x.x）✅ |
| DNS 解析失败 | 直接用 IP 通信，不依赖容器名 ✅ |
| 网络隔离 | host 模式直接使用物理网卡 ✅ |
2.4.配置后的效果
监测——主机——创建主机
模版选择Templates/Databases————PostgreSQL by Zabbix agent 2
主机群组：Databases
接口:192.168.1.201(对agent2的宿主机ip） 端口：10050(对agent2的端口）
三、部分指标说明
1. Blocks hit per second (每秒缓存命中块数)
含义：表示每秒钟从共享缓冲区中读取的数据块数量。
重要性：高缓存命中率（即高 Blocks hit per second 和低 Disk blocks read per second）表明数据库能够有效地利用内存缓存，减少磁盘 I/O 操作，从而提高查询性能。
图表显示：绿色线，平均值为 2.93K。
2. Disk blocks read per second (每秒磁盘读取块数)
含义：表示每秒钟直接从磁盘读取的数据块数量。
重要性：如果这个值较高，说明数据库需要频繁地从磁盘读取数据，可能是因为缓存不足或查询效率低下。这会增加 I/O 负载，影响性能。
图表显示：红色线，平均值为 0，说明当前情况下几乎不需要从磁盘读取数据。
3. Detected conflicts per second (每秒检测到的冲突数)
含义：表示每秒钟检测到的并发事务冲突数量。
重要性：较高的冲突数可能表明存在锁竞争问题，导致事务等待或失败。这通常与并发控制机制有关。
图表显示：深绿色线，平均值为 0，说明没有检测到明显的事务冲突。
4. Detected deadlocks per second (每秒检测到的死锁数)
含义：表示每秒钟检测到的死锁数量。
重要性：死锁会导致事务被回滚，严重影响数据库的稳定性和性能。必须及时发现并解决死锁问题。
图表显示：橙色线，平均值为 0，说明没有检测到死锁。
5. Temp_bytes written per second (每秒写入临时文件的字节数)
含义：表示每秒钟写入临时文件的字节数。当查询结果集过大，无法完全放入内存时，PostgreSQL 会使用临时文件存储中间结果。
重要性：如果这个值较高，说明查询可能需要大量临时存储空间，可能是由于复杂的查询或不合理的索引设计导致的。
图表显示：粉色线，平均值为 0 B，说明当前情况下几乎没有使用临时文件。
6. Temp_files created per second (每秒创建的临时文件数)
含义：表示每秒钟创建的临时文件数量。
重要性：与 Temp_bytes written per second 类似，较高的值可能表明查询需要大量临时存储空间。
图表显示：紫色线，平均值为 0，说明没有创建临时文件。
7. Tuples deleted per second (每秒删除的元组数)
含义：表示每秒钟从表中删除的行数。
重要性：可以用来评估数据删除操作的频率和影响。频繁的大规模删除操作可能会影响性能和磁盘空间管理。
图表显示：黄色线，平均值为 0.02619。
8. Tuples fetched per second (每秒获取的元组数)
含义：表示每秒钟从表中检索的行数。
重要性：反映了数据库的读取负载。较高的值可能表明应用程序对数据的读取需求较大。
图表显示：深紫色线，平均值为 1.81K。
9. Tuples inserted per second (每秒插入的元组数)
含义：表示每秒钟向表中插入的行数。
重要性：反映了数据库的写入负载。较高的值可能表明应用程序对数据的写入需求较大。
图表显示：粉红色线，平均值为 3.6。
10. Tuples returned per second (每秒返回的元组数)
含义：表示每秒钟通过查询返回的行数。
重要性：反映了查询的执行情况和数据访问模式。较高的值可能表明查询返回了大量数据。
图表显示：浅绿色线，平均值为 6.24K。
11. Tuples updated per second (每秒更新的元组数)
含义：表示每秒钟更新的行数。
重要性：反映了数据库的更新负载。频繁的大规模更新操作可能会影响性能和一致性。
图表显示：红色线，平均值为 0.5976。
12. Commits per second (每秒提交的事务数)
含义：表示每秒钟成功提交的事务数量。
重要性：反映了数据库的事务处理能力。较高的值表明数据库能够高效地处理大量事务。
图表显示：紫色线，平均值为 25.6596。
13. Rollbacks per second (每秒回滚的事务数)
含义：表示每秒钟回滚的事务数量。
重要性：较高的回滚数可能表明存在事务失败或异常终止的情况，需要进一步调查原因。
图表显示：蓝色线，平均值为 0.6976。