We’ve overhauled macOS monitoring in the latest Netdata release. Netdata already collects system metrics on Macs at per-second resolution; this release completes the picture with logs and hardware telemetry, areas that previously required users to run CLI tools like log show and powermetrics. The new collectors read this data through Apple’s own frameworks, allowing users to trace application and OS errors and catch hardware issues early.
This revamp has been a long time coming. Apple silicon has changed the Mac’s place in production. Build and CI farms run on Mac minis, MacBooks are ubiquitous in software companies because they enable cross-platform development, and Mac Studios, with unified memory reaching hundreds of gigabytes, serve rendering pipelines and local LLM inference. Workloads like these need the same monitoring depth we already give Linux, and now they have it.
With these changes, users can:
- explore unified logs, queried through OSLog
- track battery, UPS, and power-source health
- watch SMC/IOHID sensors, fans, and thermal pressure
- follow GPU utilization, clock, power, temperature, and performance state
- break down resource usage per application, with automatic process grouping
- check storage health via smartctl and native IOKit NVMe SMART
- map network connections and topology with Darwin’s libproc backend
macOS unified logs
The Logs tab now works on Macs the way it does on Linux and Windows. The default view provides a severity-colored histogram and facets driven by the common OSLog fields, and supports full-text search across every field, pagination, and live-tail mode. We expose all the fields OSLog provides, including the deeper ones that some tools drop:
| Fields | Meaning |
|---|---|
| LEVEL | severity, from Debug to Fault |
| PROCESS, PID, SENDER | which program emitted the entry, from which binary |
| SUBSYSTEM, CATEGORY | how Apple and third-party software organize their logging |
| ENTRY TYPE | regular log line, activity, signpost, or boundary |
| MESSAGE, FORMAT STRING | the composed message and the template behind it |
| THREAD, ACTIVITY, SIGNPOST identifiers | the detail to trace one operation across entries |
Instead of parsing the output of log show or keeping log stream continuously around, we use Apple’s OSLog framework directly. To minimize resource consumption, all queries are bounded by the visible time range and a result limit, and cancelled as soon as the user navigates away. For filtering, we identify and push down the predicates the local OSLog runtime supports natively. We handle the rest at the agent’s faceting layer to ensure results are correct.
Power, sensors, and thermals
We collect these metrics from three different sources. Batteries and UPS devices come from the IOKit power-sources API, the same information behind the macOS battery menu. Temperature, voltage, current, power, and fan-speed readings come from the SMC (the chip that manages power and cooling on every Mac) and from the HID services Apple silicon also provides. Thermal pressure comes from Apple’s powermetrics, which we run through a privileged helper.
For every battery and UPS in the system, we chart capacity, voltage, current, cycle count, and temperature. Capacity is the battery’s charge percentage, and cycle count is its wear indicator. Apple rates each battery for a fixed number of cycles, so on an aging laptop fleet this chart tells users which machines need a battery service.
By default, sensors are summarized per hardware subsystem, and users who need a specific sensor can enable per-sensor charts or check the sensors function, which lists every discovered sensor with its current reading. Everything publishes under the same contexts hardware sensors use on our other platforms, so in a mixed fleet, Mac and Linux sensors appear side by side and the same alerts apply to both.
Thermal pressure is macOS’s report of its own thermal mitigation, with five states: nominal, moderate, heavy, sleeping, and trapping. Each state denotes how aggressively macOS is limiting performance in order to bring down the system’s temperature. We also chart the SMC’s per-subsystem thermal levels (cpu, gpu, io) and processor-hot assertions.
GPU on Apple silicon
On Apple silicon, we build five GPU charts from three separate sources. Utilization, clock frequency, and performance-state residency come from the GPU’s performance-state residency counters combined with the chip’s frequency table. Power draw comes from the SoC’s energy counters. Temperature comes from the hardware temperature sensors, read through IOHID with the SMC as a fallback.
Utilization is active residency: the percentage of time the GPU spent in any active performance state instead of idle or powered down. It measures how busy the GPU is. How hard it worked is answered by the clock frequency chart, which shows the time-weighted average of the frequencies the GPU ran at while active. A high value means the power manager escalated to the fast, power-hungry states to meet demand.
Reading them together allows users to understand whether the GPU was occupied with a light or a heavy task, e.g. light UI compositing can show 100% utilization at a low clock, while a heavy compute task shows the same utilization at a high clock:
| Utilization | Clock | Meaning |
|---|---|---|
| High | High | GPU-bound workload (rendering, ML, games) |
| High | Low | Constant light load (UI compositing, video playback) |
| Low | High | Bursty demanding work that boosts and sleeps |
| Low | Low | Mostly idle |
While the clock frequency chart compresses the GPU’s behavior into a single number, performance state residency provides more detail by showing how the GPU’s active time was split across each of its available speed steps.
On Apple silicon, the CPU and GPU live on the same package and draw from a single thermal and power budget. Sustained GPU work consumes budget the CPU also needs, and can be the reason everything else on the chip slows down. The power draw and temperature charts allow users to identify such cases.
Per-application metrics
On macOS, launchd spawns hundreds of Apple helper processes. apps.plugin brings per-application visibility into CPU, memory, and disk I/O consumption, with a new automatic grouping logic that matches Apple’s conventions. Processes that do not match a group in apps_groups.conf are now grouped by their executable path:
| Executable | Group |
|---|---|
Application bundles (*.app, *.appex), Apple or third-party | one group per application (Finder, Xcode, …) |
| Apple framework helpers | system-frameworks |
| Apple standalone daemons | system-daemons |
Driver extensions (*.dext) | driver-extensions |
| Third-party frameworks | one group per framework |
| Third-party plain binaries | one group per process name |
Configuration wins over the automatic grouping, so any aggregated component can be re-exposed individually by naming it in apps_groups.conf. The stock configuration already does this for well-known macOS components such as windowserver, spotlight, coreaudio, and timemachine.
Storage health and network visibility
For storage health we added two paths. The smartctl collector now runs on macOS through ndsudo, our privileged helper, so installing smartmontools from a package manager is enough. For NVMe drives there is also a native path with no external tools, reading each drive’s health log directly through IOKit.
The native path produces the standard NVMe health set: estimated endurance, available spare, composite temperature, power-on time, power cycles, unsafe shutdowns, data read and written, media errors, error-log entries, and the drive’s own critical warning flags. Estimated endurance is the drive’s account of how much of its rated life has been consumed, making it the chart to watch on build machines that write to their SSDs all day. Everything publishes under the same nvme contexts as our Linux NVMe collector, so dashboards and alerts treat a Mac’s SSD like any other drive in the fleet. Apple’s internal storage does not always expose SMART through these interfaces; when no SMART-capable service exists, the charts simply do not appear.
For network visibility, we brought the network viewer to macOS with a backend built on Darwin’s libproc. It provides live network connections with their owning processes, TCP and UDP protocol statistics, and an interactive topology view of which processes talk to which endpoints. macOS privacy controls can hide other processes’ sockets from an unprivileged viewer; when that happens, the results carry a warning that they may be incomplete, along with the exact permissions that fix it.
Next steps
We thank our users for the feedback and support that keep shaping Netdata. Netdata is now better than ever at monitoring macOS systems, and we remain committed to improving our support for the platform.
For anyone who wants to try the new features, installing or updating the Netdata Agent on a Mac is one command:
curl https://get.netdata.cloud/kickstart.sh > /tmp/netdata-kickstart.sh &&
sh /tmp/netdata-kickstart.sh
The agent installs under /usr/local/netdata, with dependencies handled by Homebrew. The new charts appear under the Hardware and macOS sections, and the unified logs in the Logs tab.