RMM Data Sources Compared to ETW

Remote Monitoring and Management (RMM) tools collect system health metrics, deploy patches, run scripts remotely, and alert on threshold conditions. The data sources most RMM platforms rely on are WMI queries and the Windows Event Log. This post compares those data sources to Event Tracing for Windows (ETW).

WMI polling

WMI (Windows Management Instrumentation) is the standard health-monitoring data source for RMM agents. A typical agent polls WMI every 30 to 60 seconds for CPU usage, memory consumption, disk space, and service status. This produces a sampled snapshot of system state at the poll interval.

A process that spikes CPU to 100% for 8 seconds inside a 60-second window may or may not be captured by a single poll at that interval. Aggregate metrics report "average CPU was 85%" without the cause, exact timing, or correlated activity.

Complex WMI queries also have measurable overhead. Enumerating all running processes with thread counts and I/O statistics through WMI consumes CPU and memory on the target machine.

Windows Event Log

Windows Event Logs capture application errors, security events, and system warnings written by applications that choose to log. The log records that an event occurred but does not include the kernel-level context preceding it.

Event ID 1000 records that app.exe crashed with an access violation and includes the faulting module and offset. The Event Log does not include preceding kernel activity such as memory pressure, failed page allocations, or thread pool state. That class of event is exactly what the Microsoft-Windows-Kernel-Memory ETW provider records.

What ETW captures

Event Tracing for Windows operates at the kernel level and is a subscription-based real-time event stream. Disk I/O, network connections, process creation, memory allocations, and driver operations are emitted with microsecond timestamps.

Examples of ETW data that is not present in WMI or Event Log output:

Disk latency attribution. WMI reports disk utilization percentage. ETW emits per-I/O records that include the originating process, file path, operation size, and latency.

Thread-level CPU. WMI reports process-level CPU. ETW emits per-thread execution and context-switch records that identify which thread is executing or blocked and on what synchronization object.

Network connection lifecycle. ETW emits records for TCP handshakes, TLS negotiation, retransmission counts, and per-connection byte counts.

Memory allocation patterns. ETW emits a timeline of heap allocations, working-set changes, and memory-pressure transitions.

Data volume

A Windows server under moderate load emits 10,000 to 100,000 ETW events per second across all providers. At roughly 200 bytes per event, the raw stream is 2 to 20 MB per second per host. For a fleet of 500 hosts the aggregate is 1 to 10 GB per second.

Shipping raw ETW data to a centralized platform at that volume is not cost-effective. The standard alternative is to start traces on demand, capture for short windows, and analyze locally.

Local correlation

An alternative to either shipping raw data or skipping ETW entirely is to process ETW events on the host and transmit only correlated output.

A local correlation engine subscribes to ETW providers, applies matching rules, and emits summaries. When CPU exceeds a threshold, the engine captures thread stacks. When disk latency increases, the engine identifies the responsible processes and files. When a process crashes, the engine captures the preceding seconds of kernel activity.

The output volume is several orders of magnitude lower than raw ETW (kilobytes per minute versus megabytes per second), while preserving the records used in root-cause analysis.

Correlated output can be sent to a central dashboard in the same channel as traditional health metrics. An alert payload can include the contributing kernel-level evidence rather than only the threshold value.

Example scenario

A web application reports degraded response time between 2 and 3 PM daily.

WMI-based approach: CPU, memory, and disk metrics in the affected window are within normal ranges (CPU around 60%, memory and disk utilization moderate). The metrics do not identify the cause.

ETW-based approach: Correlated output for the same window shows that between 2:00 and 2:05 PM the IIS worker process received a burst of 2,300 concurrent requests (3x baseline), triggering ASP.NET thread pool starvation. Thread pool growth was throttled by the default 500ms injection rate, taking 45 seconds to scale from 25 to 80 threads. Request queue depth reached 150 and average response time rose from 120ms to 8.4 seconds. The burst correlated with a scheduled task on an upstream application server that triggered bulk API calls.

Kernel-level security events

Ransomware and post-compromise tooling generate kernel-level activity that polling cannot observe between samples.

A WMI-poll view of a ransomware encryption sweep:

• CPU: elevated (encryption is compute-intensive)
• Disk write rate: elevated (files being overwritten)
• Memory: normal
• Services: normal (backup services may have already been stopped)

A threshold alert at the next poll fires 30 to 60 seconds after the sweep began.

Kernel-level ETW evidence for the same activity:

• File renames. The kernel emits a FileIORename event for every file rename. A process renaming hundreds of files to a known ransomware extension matches at the rate the renames occur.
• Shadow copy deletion. vssadmin delete shadows /all is logged by the process ETW provider at exec time, including the command line.
• Backup service registry changes. Registry writes that disable VSS, WBEngine, or third-party backup agents are emitted by the registry ETW provider at the time of the write.
• Process ancestry. Office processes spawning cmd.exe or PowerShell are visible in the process ETW stream as parent/child records.

Detection at the rate kernel events are emitted allows downstream automation (such as Windows Firewall isolation) to run during the active sweep rather than after it completes.

Linux parity

The same data-source distinction exists on Linux. RMM agents that poll /proc, parse top, or read journald entries on a fixed cadence sample state at the poll interval and do not have kernel event subscriptions. The Linux kernel equivalent is eBPF. Programs attached to scheduler and syscall tracepoints (sched_process_exec, sys_enter_openat, sys_enter_connect) emit process, file, and network events at kernel speed. The local-correlation model applies the same way.