AIX runs some of the most critical workloads on the planet — core banking, ERP, airline reservation systems, hospital records. Yet AIX monitoring is not the same job as Linux monitoring, and teams that treat it that way hit a wall. The native tooling assumes /proc, little-endian x86, and a node_exporter that nobody ever built for Power. This guide covers what actually matters on IBM AIX and Power Systems. You will see the metrics that count, the limits of the native tools, and how to bring AIX into a modern Prometheus, Grafana and Loki stack.
Why AIX monitoring is different from Linux
Most observability tooling is built x86-first and Linux-first. AIX breaks several of those assumptions at once, which is why generic agents either fail to compile or report misleading numbers on Power.
- A
/procthat isn’t for metrics. AIX does have a/proc, but it’s for process control — the system performance metrics (CPU, memory, I/O) live in thelibperfstatAPI and kernel structures, not in Linux-style/proc/stator/proc/meminfofiles. A Linux exporter scraping/procfinds nothing useful. - Big-endian ppc64. AIX runs big-endian on POWER. Binaries and agents built for little-endian x86 don’t simply “run anywhere.”
- The LPAR model. Logical partitions, Micro-Partitioning and shared processor pools mean CPU usage is not a single percentage. You have entitled capacity, physical consumption, and pool-level contention — concepts the commodity x86 monitoring world simply doesn’t model.
- SMT and the hypervisor. Simultaneous Multi-Threading and the PowerVM hypervisor change what “CPU busy” even means, so naive utilisation figures mislead.
- The ODM. AIX stores system and device configuration in a binary object database — the Object Data Manager — not in text files under
/etc. Tooling, or admin reflexes, that expect to parse config files don’t map to AIX.
The practical consequence: effective AIX monitoring has to be Power-aware from the ground up. Bolting a Linux agent onto an LPAR gives you numbers, but not the right ones.
What to monitor on AIX and Power: the metrics that matter
Comprehensive AIX server monitoring spans several domains. Each has Power-specific nuances that a generic monitoring setup will miss.
CPU: entitled vs capacity, pools and SMT
On a shared-processor LPAR, entitled capacity is only a floor — a guarantee, not a ceiling. For an uncapped partition, the real compute limit is its VP capacity: the virtual processors it can mobilise, as long as the shared pool still has cycles to hand out. A capped partition is different. It cannot exceed its entitlement, so there you watch consumption against entitlement directly. For an uncapped LPAR you watch two signals together. The first is how close it runs to its VP capacity. The second is whether the shared pool still has room to give. An LPAR pinned near its maximum while the pool is saturated is the real warning sign: it wants more cycles, and none are left.
Why AIX load averages look alarming (but aren’t)
Reading CPU load in isolation is the classic mistake. AIX load numbers also live on a completely different scale from Linux. A load average of several hundred is routine on a busy AIX system. Figures of 500 or 800 are not unusual, and partitions running that high do not crash — they work through the queue and restore normal response times. On a Linux box those numbers would mean catastrophe.
The reason is scale. AIX measures load against a massively multi-threaded reality: dozens of virtual processors, each running SMT threads. So the figure only means something relative to the VP capacity and SMT mode behind it. A load of 10 across 10 virtual processors in SMT8 is comfortable; the same load on 2 processors in SMT2 is saturation. Apply the Linux reflex (“load above core count = trouble”) to AIX and you get nothing but false alarms.
The shape of the curve matters more than the peak. A sustained plateau in the upper range signals a real constraint: CPU is the bottleneck and it isn’t clearing. A short spike that falls straight back down is healthy. The system absorbs a burst and releases it — exactly what the shared-pool model should do. A generic agent gets this distinction wrong. That is why a native AIX exporter that reads these Power metrics at the source matters.
Memory: numperm, paging and the file cache
A system that looks “full” is usually just caching files aggressively — and idle free memory is wasted memory, so that’s healthy. The mistake is reading “90% RAM used” as an alarm on its own. What an AIX admin actually watches is numperm — the share of memory held by the file cache — and where it sits between its minperm and maxperm bounds.
This also explains why high memory use is normal on AIX. A system at 100% memory with little or no paging is healthy — that is simply how AIX runs. Some UNIX variants demand large amounts of free memory, which only wastes it; AIX soaks up otherwise-idle memory as file cache. The real warning is a convergence, not a single number. Three signals line up: numperm driven down near minperm (the Virtual Memory Manager has already given back all the file cache it can), high RAM utilisation, and paging space filling with pages. When that happens, the machine is pushing computational pages to disk because no RAM is left — not because it is caching. Any one signal alone is usually fine. The three together signal true memory pressure.
How much paging is too much?
A practical starting point is 100–200 paging I/O operations per second per CPU, assuming paging space spreads well across fast disks. Below that, on a 100%-used system, you are likely sized about right. Sustained paging well above it, with numperm already at minperm, is the signal to act.
The fix is practical: either stop the process or application consuming memory abnormally — the root cause — or, if the Power server has spare capacity, add RAM to the live partition with Dynamic LPAR (DLPAR), no reboot required. For a deeper treatment of sizing AIX memory from real data, IBM’s guidance from Nigel Griffiths on determining optimal memory size from nmon data is the reference.
Disk, I/O and the SAN layer
Storage is where AIX performance problems hide, and the signal that matters is latency — not throughput or IOPS. On a well-built SAN you expect read/write service times around 0.3 ms. That figure depends heavily on fibre distance, so stretched, multi-site fabrics carry their own latency floor. A degraded path or a saturated SAN port shows up as rising latency long before the OS looks unhealthy.
The heart of SAN monitoring on AIX is multipath (MPIO) health — and not just “are the paths up.” What matters is the geometry of redundancy. Each vscsi device typically maps through a VIOS, which in turn attaches to a specific SAN fabric. So fault-resilient multipathing depends on spreading the right number of paths across the right VIOS and fabrics. The standard resilient design is two VIOS per Power frame, one VIOS per SAN fabric. A device with “enough” paths that all run through one VIOS or one fabric looks redundant but isn’t — a single fabric or VIOS failure takes it down. Effective monitoring checks the symmetry of that redundancy, not just the path count: watch path state per device (lspath) and the balance of paths across fabrics. A single failed path that the others quietly compensate for is the classic trap — invisible until one too many is gone.
One AIX advantage is worth noting here. Where Linux needs cryptic manual rescans — echoing into /sys to make a host adapter look for new devices — a single cfgmgr detects and configures new devices and paths, and realigns the in-memory drivers with the ODM. It’s not just simpler; it’s cleaner.
Logs and hardware errors: errpt
AIX records hardware and software events in its error log, which you read with errpt. The skill is separating signal from noise, because errpt logs a lot. What matters most is hardware: lost disk paths — errpt is where a failed SAN path announces itself, tying straight back to the storage section above — and serious faults such as a failed power supply on the Power frame. Alongside those, core dumps and application crashes. These are what you alert on across the estate.
Secondary housekeeping matters too, just at lower priority — for example a dump device that’s too small to capture a full system dump, and similar hygiene items.
For an application crash, errpt is the detection and capture layer: it flags the faulting binary and the core file, which you then route to the application or development team to diagnose. Monitoring’s job is to catch it and get it to the right people — not to fix code it doesn’t own.
The practical problem is that errpt is local to each LPAR. Parsing it by hand across an estate doesn’t scale. Shipping errpt entries into a centralised log system such as Loki — with an agent like the Loki agent for AIX — lets you search, correlate and alert on these events fleet-wide, instead of logging into each box.
Availability: PowerHA and VIOS
If you run PowerHA (clustering) or VIOS (virtual I/O), their health is part of the monitoring picture: cluster state and resource-group status for PowerHA. And the dual-VIOS design isn’t only about storage — the same two VIOS carry network redundancy through Shared Ethernet Adapters (SEA), which makes the VIOS layer the foundation of both SAN and network resilience. Monitor it accordingly: SEA failover state and shared adapter throughput, alongside the paging and I/O health of the Virtual I/O Servers the LPARs depend on.
Native AIX monitoring tools (and where they fall short)
AIX ships with genuinely good performance tools. The problem is not depth — it’s that they’re built for interactive, single-host troubleshooting, not fleet-wide observability.
- nmon — excellent both interactively and in recording mode, where captures are analysed afterwards (for example with nmon Analyser). Still per-host and file-based, with no live fleet view and no alerting.
- topas — a strong real-time terminal dashboard, but it’s a live screen for one box, with no history.
- vmstat / iostat / sar / mpstat — precise and scriptable, but you’re left stitching CLI output together yourself.
- svmon / lparstat / filemon — deep diagnostics for a specific question, not continuous monitoring.
- errpt — the right source for errors, but local to each host.
Put together, the gaps are consistent: no centralised history, no alerting, no shared dashboards, and no easy way to see a hundred LPARs at once. These tools answer “what is wrong with this box right now?” — not “what is the trend across my estate, and warn me before it breaks?”
Modern AIX monitoring: Prometheus, Grafana and Loki
The de-facto open standard for infrastructure monitoring is the Prometheus stack: Prometheus for metrics, Grafana for dashboards, Loki for logs. It gives you time-series history, alerting, and a single pane of glass across heterogeneous infrastructure.
For years this stack effectively skipped AIX, for the reasons above. No native exporter read libperfstat, so Power estates stayed on legacy or bespoke tooling. That gap has now closed. A native AIX exporter exposes AIX metrics in Prometheus format directly from the LPAR, and ships AIX logs (including errpt) into Loki. Power Systems finally sit in the same observability platform as the rest of the data centre, instead of in a silo.
Comparing AIX monitoring approaches
The main options for monitoring IBM AIX, and how they compare on the things that matter for a critical Power estate:
| Approach | History & trends | Alerting | Dashboards | Power-specific metrics | Setup effort |
|---|---|---|---|---|---|
| Native CLI (nmon, topas, sar) | Limited / file-based | No | No | Yes | Low |
| Generic agents (built for Linux) | Yes | Yes | Yes | Poor / often won’t run | High |
| Legacy enterprise suites | Yes | Yes | Dated | Partial | High / costly |
| Native Prometheus exporter | Yes | Yes | Grafana | Yes | Low |
A native Prometheus exporter is the only column that ticks every box: it reads AIX metrics at the source, so the Power-specific signals are correct, while plugging into the open, modern stack your team already uses for everything else. This is the approach AIXwatch takes.
How to start monitoring AIX in practice
A pragmatic path to AIX observability without a forklift project:
- Expose metrics on each LPAR. Run a native Prometheus exporter that reads
libperfstatdirectly, so you get entitled-vs-capacity CPU, numperm and paging, disk/adapter and SAN signals in Prometheus format. - Scrape with Prometheus. Point your existing Prometheus at the AIX targets alongside your Linux and cloud hosts — same scrape config, same retention.
- Visualise in Grafana. Use Power-aware dashboards so entitled capacity, shared pools and SMT are shown correctly rather than as a misleading single percentage.
- Centralise logs in Loki. Ship
errptand application logs into Loki so lost paths, hardware faults and software errors are searchable and alertable across the estate. - Alert on what predicts outages. Memory pressure (numperm at minperm with heavy paging), pool saturation, SAN path-redundancy loss and hardware errors — the leading indicators, not just “host down.”
AIXwatch does exactly this: a native Prometheus exporter and a Loki agent for AIX, written in C with zero external dependencies, deployable on an LPAR in minutes. You can read the AIX exporter details or start a free trial to bring your Power estate into Prometheus and Grafana.
Frequently asked questions
Can you monitor AIX with Prometheus?
Yes. A native exporter reads AIX’s libperfstat API and exposes metrics in Prometheus format. Prometheus then scrapes AIX LPARs just like any other target — including Power-specific metrics such as entitled vs physical CPU and shared pool utilisation.
What is the best tool to monitor AIX?
For one-off troubleshooting on a single host, native tools like nmon and topas are excellent. For continuous, fleet-wide monitoring with history, alerting and dashboards, a native Prometheus exporter feeding Grafana is the modern standard, because it combines Power-aware metrics with the open observability stack.
How do you monitor errpt on AIX?
Rather than parsing errpt by hand on each LPAR, ship its entries into a centralised log system such as Loki. There you can search them, correlate them with metrics, and turn them into alerts — so lost disk paths, hardware faults and software errors surface across the whole estate.
Does Grafana work with AIX?
Grafana itself is platform-agnostic — it visualises whatever is in Prometheus or Loki. The requirement is getting AIX data into those backends. Once a native exporter and a log agent are in place, AIX dashboards in Grafana work exactly like those for any other platform.