Linux Performance Reads and the systemd Journal

July 16, 2026 · InfraScout Team

Windows hosts have had structured observation for a while — performance counters read as a snapshot or a short series, Event Log channels queried with real filters. Linux hosts had a shell, which meant the same questions were answered by running top or journalctl and asking the AI to read the output.

That works, in the sense that it produces an answer. It is also the pattern we already know is wasteful: a text dump where three lines matter, parsed by a model that could have been given numbers instead. Two tools close the gap.

Performance metrics without parsing top

agent_perf_read_metrics samples a Linux host's vitals and returns them in the same shape the Windows counter tool returns — a per-instance series plus minimum, maximum, average, and last aggregates. That sameness is the point: a fleet-wide performance question reads identically whichever platform answers it, and comparing a Windows host to a Linux one does not mean reconciling two output formats.

What differs is how you ask. Windows counters are named paths you have to discover first, because what exists depends on what is installed. Here you name categories and the agent knows where the numbers live: CPU including I/O wait, total and per core; memory used, available, cached, and swap; disk throughput and IOPS per real device; network throughput and error rates per interface; load averages. Add processes and you get the heaviest ones by CPU and by memory.

Results carry a dotted path and an instance, so every value identifies itself — CPU usage on cpu0, read throughput on sda, receive throughput on eth0. Windowing works exactly as it does for counters: no duration is a snapshot, a duration samples over that window, and the ceiling is five minutes because this is a short read rather than a monitoring agent. Take repeated reads for longer observation.

The capability is probed rather than assumed. A non-Linux agent, or a Linux host where the agent cannot read the kernel's metrics interface, rejects the call with a clear not-supported error instead of returning something that looks like data and is not.

This completes a set. Log file reading, journal querying, and performance metrics now cover the three things an assessment reaches for on a Linux host, all of them structured, and all of them available to read-only delegated runs that are denied a shell by design.

The journal, queried properly

agent_query_journald is the systemd journal counterpart to the Windows Event Log tool. Every filter is pushed down into the journal itself rather than applied to text afterward, and entries come back as fixed-key objects, newest first, with priority names spelled out instead of numbered.

Filters compose the way you would want. Narrow to a unit, or to a syslog identifier for programs that log without one. Filter by severity — and note that this follows journald's own semantics, where naming a level returns that level and everything more severe, so asking for errors also gets you critical and above. Apply a regular expression to the message text. Ask for kernel messages only, which is the dmesg equivalent. Bound it by a relative window or an absolute pair.

The mode worth knowing about is counting. For a "how many" question, count_only skips paging entries entirely and returns a match count with per-priority and per-unit breakdowns. "How many failed SSH logins overnight, and where did they concentrate?" is answered with a number and a distribution rather than with two thousand entries the AI then has to tally.

Reading the system journal needs privilege the agent normally has, so the capability appears only where it can genuinely be exercised. And where a host's journal tooling is too old to push a regular expression down, the agent scans the newest entries itself and flags the response — so a partial answer is never presented as a complete one.

Try it

On a Linux host, ask "this box feels slow — sample CPU, memory and disk for thirty seconds and show me the top processes", or "how many sudo failures did this host log today, and for which accounts?"

Full reference in Agent Tools. Questions? info@infrascout.cloud.