workerman进程数监控应通过ps aux配合精准grep过滤实现，避免status命令不稳及pgrep漏匹配问题；zabbix需用userparameter封装脚本，并配置合理触发器（如min(30)
Workerman进程数监控：用ps + grep提取真实存活数
Workerman的status命令输出不稳定，且依赖Web控制台或本地CLI，远程监控不可靠。直接查进程更准——但要注意过滤掉grep自身和父shell进程。
实操建议：
- 在Zabbix Agent端（被监控机器）写脚本，例如
/usr/local/bin/check-worker-process.sh，内容为：ps aux | grep 'php.*start\.php' | grep -v grep | grep -v 'check-worker' | wc -l
（注意替换start.php为你实际的启动入口文件名） - 确保
zabbix_agentd用户有权限执行ps aux；若受限，可加sudo并配置免密visudo：zabbix ALL=(ALL) NOPASSWD: /bin/ps - 避免用
pgrep -f，某些系统下它会漏匹配带空格的命令行参数
Zabbix自定义key配置：让Agent识别Workerman指标
Zabbix不能直接执行带管道的命令，必须封装成UserParameter，否则返回空或报错Value of type "string" is not suitable for value type "Numeric (unsigned)"。
实操建议：
- 编辑
/etc/zabbix/zabbix_agentd.d/userparameter_workerman.conf，添加：UserParameter=workerman.process.count[*],/usr/local/bin/check-worker-process.sh
- 若需区分多个Worker实例（如API和WebSocket），可加参数：
UserParameter=workerman.process.count[api],/usr/local/bin/check-worker-process.sh api
，脚本内用$1判断并调整grep关键词 - 改完后必须执行
systemctl restart zabbix-agent，且用zabbix_get -s 127.0.0.1 -k "workerman.process.count[]"本地验证是否返回纯数字
端口占用监控：别只看LISTEN，要确认是Workerman在用
netstat -tlnp | grep :2345能查端口，但Zabbix里直接调用会因权限失败或输出含PID/程序名混杂信息，解析易出错。
实操建议：
- 用
ss -tlnp替代netstat（更快、更少依赖），配合awk精准提取：ss -tlnp 2>/dev/null | awk '$4 ~ /:2345$/ && $7 ~ /php/ {print $7; exit}' | cut -d',' -f2 | cut -d':' -f1 | tr -d ' ' - 把该命令也封装进UserParameter，比如
workerman.port.owner[2345]，返回进程名（如php）或空字符串，Zabbix触发器设为「等于空」即告警 - 注意SELinux或firewalld可能拦截
ss -p，测试时先临时setenforce 0确认是否为此类问题
触发器设计要点：进程数突降比为0更危险
Workerman进程偶尔重启会导致瞬时为0，但持续低于阈值（如3秒内连续2次≤2）才真正异常；单纯设「等于0」会产生大量误报。
实操建议：
- 在Zabbix Web界面创建触发器，表达式用：
{HOSTNAME:workerman.process.count[].min(30)}（表示最近30秒最小值小于3） - 对端口监控，建议组合两个条件：
{HOSTNAME:workerman.port.owner[2345].str("php")}=0 and {HOSTNAME:net.tcp.port[,2345]}=1，即端口通但无PHP进程持有，说明Worker已崩而端口未释放 - 避免在模板里硬编码端口号，用Zabbix的
{$WORKERMAN_PORT}宏替代，方便多环境复用
cd工作目录差异，都会导致ps匹配失败。上线前务必在目标机器上以zabbix用户身份手动跑一遍采集命令，看输出是否符合预期。
