zabbix_sender发不出数据主因是网络连通性或配置错误：需确认udp 10051端口可达、主机启用且代理方式正确、key与监控项完全一致；建议用-i批量发送、-vv调试、检查返回值并设timeout。
zabbix_sender 命令发不出数据？先确认配置和权限
绝大多数发送失败不是语法问题，而是 zabbix_sender 根本没连上 Zabbix Server 或 Proxy。它默认走 UDP 10051 端口，且不校验服务端是否存在——发完就退出，不报错也不反馈成功。常见现象是：命令执行无输出、Zabbix 前端看不到新指标、zabbix_get 却能查到其他项。
必须检查三项：
-
zabbix_sender所在主机能否telnet zabbix-server-ip 10051（或用nc -u zabbix-server-ip 10051测试 UDP 连通性） - Server/Proxy 的
StartAgents和ListenPort不影响 sender，但AllowRoot=1（若用 root 运行）和SourceIP（若需指定出口 IP）可能被忽略 - 被监控主机在 Zabbix 前端的「主机」配置里，必须启用「已启用」且「代理方式」选对（直接连 Server 就别配 Proxy）
用 -k 指定 key 时，key 名必须和监控项完全一致
Zabbix 不做 key 模糊匹配或自动补全。zabbix_sender -k system.cpu.util 和后台定义的监控项 key 是 system.cpu.util[,idle]，就会静默丢弃——不会报错，也不会入库。
实操建议：
- 在 Zabbix 前端点开对应主机 →「监控项」→ 找到目标项 → 复制「键值」列的完整内容（含括号和参数），例如
custom.network.latency[eth0] - 避免手写 key；如果 key 含空格或特殊字符，必须用单引号包裹：
-k 'app.log.error.count[nginx]' - 测试阶段加
-vv参数看详细日志：zabbix_sender -z zabbix-server -s "host-name" -k 'my.custom.metric' -o 42 -vv，输出里会显示“sent: 1 packet(s)”才算真正发出
批量发数据别硬拼 -k/-o，改用 -i 读取文件更可靠
一次发多个指标时，用多次 zabbix_sender 调用效率低，且容易因时间差导致数据时间戳不一致。-i 参数支持从文件按行提交，每行格式为：hostname key value [timestamp]。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
注意细节：
- 文件里 hostname 必须和 Zabbix 前端配置的「主机名称」（Host name）完全一致，不是 DNS 名或 IP
- timestamp 是可选的 Unix 时间戳秒级整数；不填则用 sender 本地当前时间，但多指标间误差可能达几十毫秒
- 文件编码必须是 UTF-8 无 BOM，Windows 换行符（CRLF）会导致解析失败，用
dos2unix清理 - 示例文件
/tmp/metrics.txt：
web01 custom.http.response.time 247 1717023456 web01 custom.http.status.5xx 3 1717023456
然后执行：zabbix_sender -z zabbix-server -i /tmp/metrics.txt
脚本中调用 zabbix_sender 容易忽略返回值和超时
zabbix_sender 成功时返回 0，失败返回 1，但网络超时、权限拒绝、server 拒收等都统一返回 1——无法区分原因。而且默认无超时机制，遇到防火墙拦截可能卡住几秒。
安全做法：
- 始终检查返回值：
if ! zabbix_sender -z ... -o ... >/dev/null 2>&1; then echo "send failed"; exit 1; fi - 用
timeout控制最大耗时：timeout 3s zabbix_sender -z ...，避免脚本 hang 住 - 不要把
zabbix_sender放进高频循环（如每秒采集），Zabbix Server 对单 host 单 key 的写入频率有限制，默认 1 条/秒，超出会被丢弃（日志里出现 “item is not supported” 或 “rate limit exceeded”）
自定义指标的难点不在发送动作本身，而在 key 的生命周期管理——一旦前端删掉对应监控项，sender 继续发的数据就永远沉底了，连错误日志都不会有。
