Mr.括号做运维的应该都有这个感觉：Zabbix 监控 Linux 服务器是常规操作，但一到 AIX 小型机就容易卡壳。我这几年接过不少 Power 小机接入 Zabbix 的活儿，客户基本都在金融、制造业，跑的是核心数据库和中间件，停机窗口少、权限卡得严，还要把 CPU、内存、磁盘、errpt 硬件日志这些指标完整采上来。这篇文章就把我实际验证过的方案从头到尾讲清楚，给正在接手 AIX 机组的同学一个可以直接抄作业的参考。
1. 为什么 Zabbix 要盯 AIX 小型机：核心需求与现实挑战
1.1 AIX 机组的运维场景
AIX 是 IBM Power 小型机的操作系统，这类机器在银行核心账务、制造 ERP、交通收费等场景里非常常见。它跟普通 x86 服务器不一样，通常承载的是 Oracle、DB2、WebSphere 这类关键负载，稳定性要求极高，很多系统跑了好几年都不敢动。因为不能随便重启、不能轻易升级补丁，日常巡检和监控就显得更重要。一旦磁盘写满、内存不足或者硬件报错，往往不是立即宕机，而是业务响应变慢、交易失败，等到用户投诉才发现就晚了。
我见过不少企业的 AIX 机组还是靠人工每天登录服务器敲命令看 topas、df、errpt，效率低不说，晚上和节假日很容易漏检。把它们纳入 Zabbix 统一监控平台之后，至少能做到 7x24 小时数据采集、阈值告警和历史趋势回溯，跟 Linux、网络设备、存储放在同一个视图下面，运维同学不用再频繁登录跳板机。这里最核心的诉求不是“能不能采到数据”，而是“能不能稳定、安全、可维护地采到数据”。
1.2 Zabbix 的适配性
Zabbix 对 AIX 的支持其实比很多运维想象中完整。官方源码包里提供了 AIX 下的 agent 编译支持，也可以通过 SNMP 做基础采集。关键优势是模板和告警体系统一，不需要为了几十台小机再单独上一套商业监控软件。相比 IBM 原厂的 Tivoli Monitoring，Zabbix 部署成本几乎可以忽略，批量管理、自定义采集项、告警通知都更灵活。
不过要注意，AIX 上没有现成的二进制安装包，agent 需要自己编译。这是很多人第一次尝试时被卡住的地方。但只要依赖对齐、编译参数正确，编译一次后就可以打包分发到同版本 AIX 机器上复用，后续维护成本并不高。如果只是临时看几台机器，也可以先用 SNMP 顶上。整体来说，Zabbix 和 AIX 的适配性足够支撑生产环境，关键是前期要把方案想清楚。
1.3 明确监控维度
接入前一定要先规划好采集内容，否则后期反复改配置很痛苦。基础项包括 CPU 使用率、内存使用率、文件系统空间、交换分区使用率、磁盘 IO、网络流量。AIX 特有的监控项也要加上，比如 errpt 硬件错误日志、逻辑卷状态、rootvg 镜像同步情况。如果机器上跑的是数据库和中间件，进程存活、端口连通性、关键日志文件同样需要纳入监控。
建议把这些维度列成一张清单，逐项确认哪些用 Zabbix agent 采，哪些用 SNMP，哪些需要自定义脚本。比如 errpt 用 agent 的 UserParameter 非常方便，而硬件电源状态可能要看 HMC 带外接口。先有清单再动手，能避免“装完 agent 才发现少采了文件系统”这种尴尬。我在项目里通常会把清单同步给系统管理员，确认每台机器的业务角色和维护窗口，后面建触发器时才不会误伤。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 监控方案选型：Agent、SNMP 还是 HMC 带外
2.1 三种采集方式对比
从实际使用来看，AIX 接入 Zabbix 主要有三条路：装 agent、走 SNMP、通过 HMC 带外采集。三者的区别可以用下面这张表概括。
| 采集方式 | 部署成本 | 数据丰富度 | 适用场景 |
|---|---|---|---|
| Zabbix agent | 需编译安装，较高 | 高，可采集 errpt、自定义命令、日志 | 生产小机，长期重点监控 |
| SNMP | 修改系统配置，低 | 中，基础性能指标和部分硬件信息 | 临时接入、只采基础指标 |
| HMC 带外 | 需配置管理口，中 | 低，主要看电源、风扇、温度等硬件状态 | 硬件健康兜底，OS 层不适用 |
大部分长期项目都会选择 agent 为主、HMC 为辅。SNMP 虽然部署简单，但采集 errpt、执行自定义命令非常麻烦，而且 AIX 上 net-snmp 的 OID 兼容性时好时坏，花在调试上的时间不一定比编译 agent 少。HMC 则更适合做硬件健康巡检，不能替代操作系统层面的性能监控。
2.2 Zabbix agent on AIX 的获取与安装
Zabbix agent 的源码可以从 Zabbix 官方源码包获取，下载与 Zabbix server 版本一致的源码包在 AIX 上编译。AIX 默认没有 gcc，需要先安装 IBM 提供的 gcc 包，或者通过系统自带的包管理工具安装。编译前确认 zlib、pthread 等依赖存在，否则会出现 agent 启动后立即退出的问题。个人习惯把安装路径指定为 /opt/zabbix，目录清晰，后续打包分发也方便。
编译过程不复杂，关键参数要在 configure 阶段指定，例如：
bash复制./configure --prefix=/opt/zabbix --enable-agent --enable-static
make
sudo make install
这里的 --enable-static 很重要。AIX 的动态库依赖比 Linux 更敏感，静态编译可以避免 agent 在运行环境里找不到共享库。编译完成后，agent 的二进制和配置文件会放在 /opt/zabbix 下，检查一下 zabbix_agentd 是否存在，然后就可以写配置了。
2.3 SNMP 方式与常用 OID
如果是临时接入，走 SNMP 确实省事。AIX 上一般自带 net-snmp，修改 /etc/snmpd.conf，设置 community 和允许访问的管理端 IP，启动 snmpd 即可。Zabbix 自带了不少 SNMP 模板，但直接用模板不一定完全匹配 AIX。常用 OID 比如 UCD-SNMP-MIB 的 CPU 和内存（.1.3.6.1.4.1.2021）、HOST-RESOURCES-MIB 的文件系统（.1.3.6.1.2.1.25），这些在 AIX 上基本能返回数据，但返回值格式跟 Linux 有差异，需要实际验证。
SNMP 的最大问题是扩展性差。想通过 SNMP 拿 errpt 错误记录、检查逻辑卷状态，基本不可行。如果只是采 CPU、内存、磁盘使用率，SNMP 可以接受。但遇到需要做硬件日志告警的场景，还是得回到 agent 方案。所以我的建议是：SNMP 只做探路，正式生产监控尽量用 agent。
2.4 HMC 带外监控
对于 Power 小型机，HMC 管理口能采集电源、风扇、温度等硬件状态。如果只是监控操作系统层面，HMC 不是必须；但它可以作为很好的兜底手段。有些硬件故障在 OS 里已经出现异常但还能运行，通过 HMC 能提前看到电源模块或者风扇的告警。Zabbix 可以通过 IPMI 或 SNMP 读取 HMC 的数据，不过 HMC 的 MIB 需要确认。
如果环境里有多台小机，HMC 的告警往往是第一道防线。我遇到过一次内存故障，errpt 里已经有记录，但真正定位问题还是通过 HMC 的硬件面板确认是哪根内存条。建议在 Zabbix 里单独建一个 HMC 主机组，把每台 HMC 管的所有分区作为附属主机，用自定义脚本定期抓取硬件状态，报警走独立的告警路线。
3. 从零实操：AIX 接入 Zabbix 的完整步骤
3.1 环境准备与版本确认
开始操作之前，先确认 Zabbix server 的版本，agent 小版本尽量跟 server 保持一致。AIX 的版本（6.1、7.1、7.2）会影响编译器的选项，但 agent 源码基本通用。需要确认 AIX 上是否有 gcc，没有的话从 IBM 维护站点下载配套 gcc 包。建议先在一台测试小机上操作，确认无误后再推广到生产，避免在权限审批严格的环境里反复试错。
另外要确认 Zabbix server 所在网段能访问 AIX 的 10050 端口。AIX 自带的防火墙并不像 Linux 那么常用，但有时会启用网络访问控制，需要在系统层面放通。最好提前让网络管理员做好巡检，别到添加主机的时候才发现端口不通。这个步骤虽然简单，但能省掉后面大量排查时间。
3.2 编译安装 Zabbix agent
在 AIX 上编译 Zabbix agent 的流程并不复杂，但有几个细节要注意。源码包下载后解压，进入目录执行 configure。configure 参数我建议固定为静态编译，避免动态库问题。make 过程可能比较慢，小机上耐心等待即可。编译完成后，把 zabbix_agentd 和 zabbix_agentd.conf 放到 /opt/zabbix 对应目录，然后修改配置文件。
这里有两点心得。第一，AIX 上编译时不要加奇怪的 CFLAGS 优化参数，默认参数最稳。第二，编译产物可以打包，在相同版本的 AIX 机器上直接解压使用，节省大量重复编译时间。但要注意，不同 AIX 小版本之间不一定完全兼容，最好按系统版本分类打包。
3.3 配置 agentd.conf
agent 的配置文件是 zabbix_agentd.conf，核心参数包括 Server、ServerActive、Hostname、ListenIP、LogFile、Timeout。默认情况下需要把 Server 和 ServerActive 都填成 Zabbix server 的地址，Hostname 用这台小机的主机名，不要留默认值。LogFile 指定为 /var/log/zabbix/zabbix_agentd.log，启动前先创建目录。Timeout 建议设成 5 或更大，因为有的自定义脚本执行时间较长。
启动 agent 的方式可以用 nohup 或做成系统服务。如果权限允许，把启动命令加到 /etc/inittab，这样开机自动启动。启动后先看日志有没有报错，再用命令手动测试一下：
bash复制/opt/zabbix/sbin/zabbix_agentd -t system.cpu.util[,,avg1]
如果返回正常值，说明 agent 工作正常。如果报错，多半是配置里的 Server 地址不对，或者依赖库缺失。在 server 端也可以用 zabbix_get 命令测试连通性，例如：
bash复制zabbix_get -s 10.0.0.1 -p 10050 -k system.cpu.util[,,avg1]
3.4 在 Zabbix 前端添加主机
登录 Zabbix 管理界面，配置 → 主机 → 创建主机。主机名称必须与 agent 的 Hostname 保持一致，否则 agent 会认为数据来源不匹配。分组可以选“AIX Servers”这种自定义组，方便后续按业务线管理。IP 地址填小机管理 IP，端口默认 10050。模板先选择 Linux by Zabbix agent 作为基础模板，再附加自定义 AIX 模板。
添加完成后，等一两分钟看前端状态是否变绿。如果显示红色或不可达，先看 agent 日志，再检查网络连通性。一个很常见的坑是主机名不一致：前端填的是 IP，agent 配置里是主机名，Zabbix 默认用主机名匹配，HTTP agent 会直接拒绝。保持命名规范一致，能减少很多无谓的告警。
3.5 验证数据与配置触发器
主机添加成功后，在“最新数据”页面能看到 agent 返回的指标。确认 CPU、内存、磁盘、网络等基础数据都有值，再配置触发器。AIX 场景下我建议优先设置这几个触发器：磁盘使用率超过 85%、errpt 新增硬件错误、agent 不可达、交换分区使用率超过 80%。触发器要结合业务实际情况调整阈值，不要照搬模板。
触发器挂好后，还要配置告警媒介。Zabbix 可以接入邮件、钉钉、企业微信等渠道。AIX 侧只要保证数据正常，server 端在触发器触发后就会调用通知脚本。首次配置完建议故意触发一个测试告警，确认链路完整，再正式上线。别等到真出故障才发现告警没收到。
4. 关键监控项与模板解析
4.1 CPU、内存、磁盘、网络指标采集
AIX 的 CPU 使用率可以通过 Zabbix 自带的 system.cpu.util 系列 key 获取，但实测下来 AIX 的计算方式跟 Linux 略有差异，返回的 idle 值可能偏高或偏低。建议在模板里同时采集 system.cpu.util[,,avg1] 和一个自定义的 CPU 占用率 key，用 topas 的输出做对照。内存方面要重点监控 real memory 和 paging space，AIX 的交换分区满比内存满更容易引发故障，因为 paging space 一旦耗尽，系统会强制杀掉进程。
磁盘监控要按文件系统挂载点分别采集。AIX 上 df -k 的输出格式跟 Linux 不完全一样，Zabbix 自带的 vfs.fs.size 基本能识别，但某些虚拟文件系统可能采不到。网络流量通过 net.if 采集时，注意 AIX 的接口名多为 en0、ent0，Zabbix 模板里的网络接口名称可能不匹配，需要手动改成实际接口名。这些细节不处理，前端会显示一堆找不到的 key。
4.2 errpt 硬件日志监控
errpt 是 AIX 特有且最有价值的硬件日志接口。errpt -d S 可以列出软件错误，errpt -d H 列出硬件错误。要把 errpt 纳入 Zabbix，推荐使用 UserParameter 自定义 key。例如采集新增硬件错误条数：
bash复制UserParameter=aix.errpt.hwcount,/usr/bin/errpt -d H -s `date +%m%d%H%M%y` 2>/dev/null | wc -l
这个 key 会统计从当前时间往前推一分钟内的硬件错误数量。触发器设为值大于 0 即告警。还可以增加一个采集最近一条错误摘要的 key，方便告警时直接看到错误标识。errpt 能识别磁盘、内存、电源等硬件故障，比单纯看 CPU、内存更能提前发现潜在风险。
4.3 日志文件监控与进程监控
数据库或中间件日志是排查故障的重要线索。Zabbix 的 log 监控 key 可以按正则匹配异常关键字，AIX 上要注意日志文件编码，中文日志经常出现乱码。如果应用日志是 GBK 或者非 UTF-8，建议先通过 iconv 转码后再匹配，或者在 UserParameter 里用 grep 过滤关键字后返回计数。
进程监控方面，用 proc.num[进程名] 检查关键进程存活。AIX 上的进程名可能比 Linux 短，而且同名进程可能分布在多用户环境下，需要先通过 ps -ef 确认。比如监控 Oracle 监听进程：
bash复制UserParameter=aix.proc.lsnr,/usr/bin/pgrep -l tnslsnr | /usr/bin/wc -l
进程监控要设置合理的触发器，比如进程数小于 1 就告警。需要注意的是，Zabbix 自带 proc.num 在某些 AIX 版本上可能无法识别进程名，这时用 pgrep + wc 自定义 key 更可靠。
4.4 自定义 UserParameter 实战
AIX 专用采集项建议集中在 UserParameter 里维护。除了 errpt，还可以采集 rootvg 逻辑卷状态、交换分区使用率、系统负载等。比如：
bash复制UserParameter=aix.lsvg.pending,/usr/sbin/lsvg rootvg 2>/dev/null | /usr/bin/grep -c "PENDING"
UserParameter=aix.paging.used,/usr/bin/lsps -s | /usr/bin/awk 'NR==2 {print $1}'
写 UserParameter 时要特别注意使用绝对路径，因为 agent 启动环境不会加载用户 PATH。每条命令先用 AIX 命令行手工执行确认有输出，再写进配置文件。每次修改 UserParameter 后必须重启 zabbix_agentd 进程，否则新 key 不生效。这个操作在 Linux 上很顺手，在 AIX 上经常被忽略，导致数据一直不出来。
5. 常见问题与排查技巧实录
5.1 agent 无法启动或启动后立刻退出
最常见的原因是缺少共享库。用 ldd 查看 agent 依赖：
bash复制ldd /opt/zabbix/sbin/zabbix_agentd
如果输出里有 not found，说明动态库缺失。解决办法是编译时加 --enable-static，或者安装对应依赖包。AIX 6.1 和 7.2 的线程模型有差异，但 configure 默认参数通常都能适配。如果手动 CFLAGS 加了优化选项，反而可能导致运行时崩溃。
启动 agent 后，立刻看日志文件。常见的报错 “cannot open shared library” 基本都是依赖问题。另外，如果 AIX 上安装了安全加固软件，可能限制 agent 访问文件系统，需要把 /opt/zabbix 目录和 agent 运行账户加入白名单。这个坑比较冷门，我在一个金融客户现场遇到过，排查了很久。
5.2 最新数据不更新
前端能看到主机但数据不更新，先确认 agent 是否还在运行。直接在 AIX 上手动执行：
bash复制/opt/zabbix/sbin/zabbix_agentd -t system.cpu.util[,,avg1]
能返回值说明 agent 正常，问题出在 server 到 agent 的网络或防火墙。用 zabbix_get 测试：
bash复制zabbix_get -s 10.0.0.1 -p 10050 -k system.cpu.util[,,avg1]
如果 zabbix_get 无响应，检查 AIX 端口是否监听：
bash复制netstat -an | grep 10050
还有种情况是 agent 配置里的 Hostname 和前端主机名不匹配。Zabbix 在主动模式下会校验 Hostname，不一致就无法上报数据。把两端命名统一，重启 agent，基本能解决。
5.3 errpt 中文乱码
AIX 的 errpt 输出经常是本地编码，Zabbix 前端默认 UTF-8 显示会乱码。简单办法是在 UserParameter 命令里用 iconv 转码，或者把系统 locale 改成 C，强制英文输出。我不建议追求完整中文，告警里只要能看到错误标识符和时间就行。英文错误标识在 IBM 文档里很好查，反而是乱码会让人无从下手。
如果一定要保留中文，可以在 agent 脚本里调用：
bash复制/usr/bin/errpt -d H | /usr/bin/iconv -f GBK -t UTF-8
但前提是 AIX 上安装了 iconv 组件。实际生产里，直接把 LC_ALL=C export 到脚本里最省事。前端显示英文摘要，告警内容也容易归档和检索。
5.4 history syncer processes over 75% 怎么处理
这个问题出现时，Zabbix server 前端会报警，意思是历史数据写入不够快。很多同学第一反应是加 agent 采集频率，其实问题通常出在 server 端。当接入的 AIX 主机数量增多，每秒生成的历史数据量大幅提升，而数据库写入能力跟不上，就会出现 history syncer 过载。
可以先调大 Zabbix server 配置文件里的 HistoryCacheSize、TrendCacheSize、ValueCacheSize，然后重启服务。如果还在报警，要检查数据库磁盘 IO 和慢查询，必要时对 history 表做分区或归档。AIX 侧监控项如果太多，也可以适当调大收集间隔，比如把 errpt 检查从 30 秒改成 60 秒，减少无效数据量。
5.5 钉钉告警配置
AIX 监控告警接入钉钉时，脚本要放在 Zabbix server 端，不是 agent 端。AIX 侧只要保证数据上报正常，server 端在触发器触发后调用 webhook 脚本。常见坑是钉钉机器人加签和关键词设置不匹配，导致消息发送失败。建议先在 server 上手工执行一次 curl 测试钉钉地址，确认返回 ok 再挂到媒介配置。
如果 AIX 主机数量多，建议按业务线建多个钉钉群，每个群一个机器人，告警时用脚本里的参数区分。这样数据库负责人只收数据库相关告警，系统负责人只收系统告警，避免全员轰炸。告警内容里最好包含主机名、IP、监控项、当前值、触发时间，方便值班同学直接定位。
6. 工具选型对比：Zabbix vs Prometheus 监控 AIX
6.1 核心差异对比
Prometheus 用 exporter 暴露指标，Zabbix 用 agent 主动或被动上报。对于 AIX 这种存量系统，Prometheus 需要额外安装 node_exporter，而 AIX 的 node_exporter 支持不如 Linux 完善。Zabbix 官方虽然没有专门的 AIX 模板，但 agent 源码可以编译，自定义 UserParameter 又非常灵活。两者都能做监控，但从落地成本看，Zabbix 在 AIX 场景下更省事。
如果团队已经用了 Zabbix，没必要为了少量 AIX 再搭一套 Prometheus。Zabbix 的告警聚合、报表、批量配置在传统企业里更顺手。而 AIX 上很多指标在社区 exporter 里找不到，比如 errpt、lsvg 状态，自己用 Go 交叉编译 exporter 又太折腾。相比之下，Zabbix 的 UserParameter + 脚本几乎能采任何数据。
6.2 从团队运维成本看选型
AIX 小型机数量通常不多，几台到几十台，用 Prometheus 还要维护 exporter 版本、告警规则和 PromQL，收益不大。Zabbix 的前端配置、模板关联、自动发现机制，对传统运维团队更友好。而且 AIX 机器的变更流程严格，agent 编译打包一次后可以重复使用，后续升级也不复杂。
如果团队标准是 Prometheus，实在要采 AIX，可以找社区版 aix_exporter，但它本质是封装 AIX 命令，稳定性需要自己测试。我建议保留 Zabbix 用于 AIX 特殊指标，其他系统继续走 Prometheus，两个平台通过统一告警网关对接。这种混合架构在实际项目里见过不少，重点是把数据源、告警路由理清楚，别让两套系统互相打架。
6.3 实际场景中的选择建议
总的来说，AIX 机组监控首选 Zabbix agent，这是风险最低、收益最高的方案。如果公司已经在用 Prometheus，并且 AIX 数量很少，也可以先用 SNMP 临时顶上。但要做 errpt、逻辑卷、日志监控这类深度需求，最终还是会回到 agent 模式。Zabbix 的模板和告警体系本来就是为“多平台统一监控”设计的，AIX 只是其中一个节点，没有必要另起炉灶。
我还见过有人用 Zabbix 配合 HMC 一起监控 Power 虚拟化环境。通过 HMC 采到 LPAR 的 CPU、内存配置，再结合 agent 采集 OS 内部指标，基本能覆盖小型机从硬件到操作系统的完整监控链条。这样的组合在关键业务场景里非常稳，也是我比较推荐的做法。
7. 实操心得与后续扩展建议
7.1 我踩过的坑
第一次给 AIX 装 agent 时，我图省事直接拷贝了 Linux 编译出来的二进制，结果完全跑不起来。后来老老实实在 AIX 上重新编译才解决。从此以后，任何跨平台二进制都不再信任，必须用目标系统源码编译。还有一次 errpt 告警配置好后，agent 日志不断报 command execution failed，原因是脚本里用了相对路径，改成绝对路径后立刻正常。这类坑都不深，但会让初次接触的人怀疑人生。
另一个容易忽略的问题是 agent 运行权限。很多公司安全基线要求进程不能用 root 运行。用普通用户运行 agent 时，要确保该用户对 /var/log/zabbix 目录有写权限，并能够执行 errpt、lsvg、lsps 这些命令。如果权限不足，建议通过 sudo 白名单放行，而不是直接把 root 密码交给监控账户。我在实施时经常帮客户设计最小权限方案，既满足安全要求，又不影响采集功能。
7.2 模板标准化和权限管理
建议在 Zabbix 里建一套统一的 AIX 模板，把 UserParameter 和触发器提前放好。新接入小机时直接关联模板，不用每次重写配置。模板里要区分基础性能模板和 AIX 专用模板，基础模板可以复用，专用模板按项目单独维护。触发器阈值统一用宏变量，比如 {$DISK_UTIL_MAX}、{$ERRPT_ALERT}，方便后续批量调整。
同时要做好每台小机的资产台账：主机名、IP、用途、维护窗口、负责人、应用端口。Zabbix 的主机备注和标签功能可以记录这些信息。告警时，前端展示的不仅是监控数据，还能看到这台机器是谁负责、什么时候可以重启，对值班处理非常有帮助。标签也可以用来做告警路由，比如“Database”标签的告警转到数据库群，“OS”标签转给系统组。
7.3 后续扩展
监控 AIX 不只是操作系统指标，扩展到 HMC、Power 虚拟化、存储和数据库中间件更有价值。Zabbix 可以通过 HMC 的 API 或 CLI 采集电源状态，也能通过 JMX 插件监控 WebSphere。如果公司有 UPS，也可以把 UPS 的 SNMP 数据接入同一个平台，形成数据中心基础设施监控的完整闭环。
最后再分享一个小技巧：AIX 的 agent 配置和脚本最好纳入版本管理。我在多个项目里都吃过亏，某个小机上手动改过 UserParameter，后来统一更新模板时差异对不上。把 /opt/zabbix/etc 下的配置放到 SVN 或 Git 里，每次变更留痕，比什么都管用。等你要排查“为什么这台机器采集不到数据”的时候，就会发现版本管理的价值。