一、概述
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.3 host 模式
|------------|-----------------------------------|
| 问题 | 如何解决 |
| 跨主机通信 | 使用宿主机 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的端口）
三、部分指标说明
- Blocks hit per second (每秒缓存命中块数)
含义：表示每秒钟从共享缓冲区中读取的数据块数量。
重要性：高缓存命中率（即高 Blocks hit per second 和低 Disk blocks read per second）表明数据库能够有效地利用内存缓存，减少磁盘 I/O 操作，从而提高查询性能。
图表显示：绿色线，平均值为 2.93K。
- Disk blocks read per second (每秒磁盘读取块数)
含义：表示每秒钟直接从磁盘读取的数据块数量。
重要性：如果这个值较高，说明数据库需要频繁地从磁盘读取数据，可能是因为缓存不足或查询效率低下。这会增加 I/O 负载，影响性能。
图表显示：红色线，平均值为 0，说明当前情况下几乎不需要从磁盘读取数据。
- Detected conflicts per second (每秒检测到的冲突数)
含义：表示每秒钟检测到的并发事务冲突数量。
重要性：较高的冲突数可能表明存在锁竞争问题，导致事务等待或失败。这通常与并发控制机制有关。
图表显示：深绿色线，平均值为 0，说明没有检测到明显的事务冲突。
- Detected deadlocks per second (每秒检测到的死锁数)
含义：表示每秒钟检测到的死锁数量。
重要性：死锁会导致事务被回滚，严重影响数据库的稳定性和性能。必须及时发现并解决死锁问题。
图表显示：橙色线，平均值为 0，说明没有检测到死锁。
- Temp_bytes written per second (每秒写入临时文件的字节数)
含义：表示每秒钟写入临时文件的字节数。当查询结果集过大，无法完全放入内存时，PostgreSQL 会使用临时文件存储中间结果。
重要性：如果这个值较高，说明查询可能需要大量临时存储空间，可能是由于复杂的查询或不合理的索引设计导致的。
图表显示：粉色线，平均值为 0 B，说明当前情况下几乎没有使用临时文件。
- Temp_files created per second (每秒创建的临时文件数)
含义：表示每秒钟创建的临时文件数量。
重要性：与 Temp_bytes written per second 类似，较高的值可能表明查询需要大量临时存储空间。
图表显示：紫色线，平均值为 0，说明没有创建临时文件。
- Tuples deleted per second (每秒删除的元组数)
含义：表示每秒钟从表中删除的行数。
重要性：可以用来评估数据删除操作的频率和影响。频繁的大规模删除操作可能会影响性能和磁盘空间管理。
图表显示：黄色线，平均值为 0.02619。
- Tuples fetched per second (每秒获取的元组数)
含义：表示每秒钟从表中检索的行数。
重要性：反映了数据库的读取负载。较高的值可能表明应用程序对数据的读取需求较大。
图表显示：深紫色线，平均值为 1.81K。
- Tuples inserted per second (每秒插入的元组数)
含义：表示每秒钟向表中插入的行数。
重要性：反映了数据库的写入负载。较高的值可能表明应用程序对数据的写入需求较大。
图表显示：粉红色线，平均值为 3.6。
- Tuples returned per second (每秒返回的元组数)
含义：表示每秒钟通过查询返回的行数。
重要性：反映了查询的执行情况和数据访问模式。较高的值可能表明查询返回了大量数据。
图表显示：浅绿色线，平均值为 6.24K。
- Tuples updated per second (每秒更新的元组数)
含义：表示每秒钟更新的行数。
重要性：反映了数据库的更新负载。频繁的大规模更新操作可能会影响性能和一致性。
图表显示：红色线，平均值为 0.5976。
- Commits per second (每秒提交的事务数)
含义：表示每秒钟成功提交的事务数量。
重要性：反映了数据库的事务处理能力。较高的值表明数据库能够高效地处理大量事务。
图表显示：紫色线，平均值为 25.6596。
- Rollbacks per second (每秒回滚的事务数)
含义：表示每秒钟回滚的事务数量。
重要性：较高的回滚数可能表明存在事务失败或异常终止的情况，需要进一步调查原因。
图表显示：蓝色线，平均值为 0.6976。