WMI Sensors

NetCrunch offers a collection of WMI sensors. Basic sensors are designated to serve specific purposes such as monitoring perfmon, process, shares, or time difference. The advanced sensor is more general and allows us to explore WMI classes or create custom WQL queries.

WMI sensors do not require a Windows OS monitor to be enabled on the node. In such a case, you must select an appropriate credential profile for each sensor.

Basic Sensors

These sensors don't require any knowledge about WMI or CIM. In particular, WMI Perform resembles the object names and counter names of the Perfmon.

wmi-perfmon

WMI Perfmon

WMI performance data comes from the perfmon provider, so we decided to use the same UI for WMI performance monitoring as perfmon. You don't need to use cryptic class names to get to the data. The sensor does this job. If you feel using class names is necessary, use the WMI Data sensor.

file-shares

File Shares

This sensor monitors the status of Windows Share. You can enter the share name manually or from the list.

process-group-summary

Process Group Summary Sensor

The sensor extends the Process sensor functionality by tracking multiple processes and using the wildcard (*) in the process name. It also supports monitoring child processes of a specified process when the Include child processes option is enabled, allowing you to view combined metrics for an entire process tree.

Selecting Processes by Name

You can specify multiple processes and separate them by commas. You can also use partial names using *. For example, 'nc*' will select all processes starting with 'nc'.

Include Child Processes

In addition to tracking top-level processes, the Include child processes option lets the sensor monitor all child processes spawned by a given parent process. This is particularly useful for monitoring services or applications that create multiple subprocesses or worker threads under distinct process identifiers.

Key Points:

  • Automatic Child Detection: When Include child processes is enabled, the sensor recursively identifies child processes based on parent process ID relationships.
  • Aggregated Metrics: Child processes are monitored alongside their parent, and performance data is aggregated, providing a single set of metrics for the entire process group hierarchy.
  • Flexible Configuration: You can enable or disable Include child processes for any specified process name or pattern, allowing you to focus on what is most relevant to your environment.
Counters Tracked

When monitoring either individual or grouped processes (including child processes), the following counters are available:

  • % Processor Utilization: The combined CPU usage for all selected processes.
  • Handles: The total number of open handles, including those from child processes.
  • Instances: The count of currently running process instances matched by the selection criteria.
  • Memory Working Set (bytes): The sum of working set memory used by the parent, including child processes.
  • Threads: The total number of threads across the process group.
  • Virtual Bytes: The total virtual memory size utilized by the selected processes.
  • Private Bytes: The total amount of memory allocated exclusively to the selected processes.

Note: Process names are case-insensitive in WMI.

By leveraging the ability to group processes and include their children, you gain a comprehensive view of resource usage and performance, simplifying monitoring complex applications and services that rely on multiple subprocesses.

process

Process Sensor

The Process Sensor allows you to monitor the health and performance of a specific process running on a target machine. By tracking various system resource counters, you can ensure that critical processes remain stable, efficient, and responsive over time.

Key Performance Counters

The sensor provides detailed insights into several performance metrics, including:

  • % Processor Utilization: Shows the percentage of CPU time the process is consuming.
  • Handles: Reflects the number of open handles (to system resources such as files, registry keys, etc.) that the process holds.
  • Instances: Indicates how many instances of the monitored process are running.
  • Memory Working Set (bytes): Represents the amount of memory currently used by the process.
  • Threads: Displays the number of active threads within the process.
  • Virtual Bytes: Identifies the process's total virtual memory.
  • Private Bytes: Reports the process's total memory allocated.

These counters help you proactively detect unusual resource consumption, such as memory leaks, CPU spikes, or excessive handle usage, enabling timely troubleshooting and corrective action.

Process Identification Methods

When multiple processes share the same executable name or run with similar parameters, uniquely identifying the correct process instance is essential. The Process Sensor supports multiple identification methods to ensure accurate and reliable selection:

  • By Name:
    Specify the process name (e.g., chrome.exe) to monitor. The sensor will generate a monitoring issue by default if multiple instances are found unless further criteria are provided.

  • By Name and Parameters (Regular Expression):
    Combine the process name with command-line parameters to distinguish between different instances. A regular expression can be applied to the full process name (including extension) and its command-line arguments, helping you isolate a specific instance when multiple identical processes are running.

  • By Command Line Regular Expression:
    Instead of relying on the process name, use a regular expression directly on the command-line arguments. For instance, you might match a particular Java application instance by its unique JAR file name or a specific parameter that differentiates it from other JVM instances.

Ensuring Unique Identification

The sensor will report a monitoring issue if more than one process instance matches the specified criteria. This safeguard prevents ambiguous situations where the sensor cannot determine which process instance to track.

To avoid conflicts:

  • Refine your regular expression to match a unique parameter.
  • Use a more specific process name if possible.
  • Assign a unique Sensor ID when relying on name-based matches. This step is beneficial if you need to monitor multiple similar processes and want to track each one as a distinct entity in your monitoring environment.

By leveraging these identification methods and tracking critical performance counters, the Process Sensor helps maintain stable and predictable operations, offering a clear path to identifying and resolving performance-related issues with key processes in your infrastructure.

ad-replication

AD Replication Sensor

This sensor checks a Windows Domain Controller for replication errors. To use this sensor, add it to the machine, which is Domain Controller, and provide the credentials necessary to access the root\MicrosoftActiveDirectory namespace. The sensor shows one status per each one discovered AD partition.

Microsoft documentation about AD partitions

Statuses:

The total number of statuses depends on the Domain Controller configuration. Three statuses always occur:

  • Domain Partition Replication Status
  • Configuration Partition Replication Status
  • Schema Partition Replication Status

Each status contains below data (properties):

  • NumConsecutiveSyncFailures - number of consecutive sync failures
  • IsDeletedSourceDsa - If the source is deleted
  • TimeOfLastSyncAttempt - time of the last sync attempt
  • LastSyncResult - result of the last sync
  • TimeOfLastSyncSuccess - time of the last sync success
  • ModifiedNumConsecutiveSyncFailures - number of modified consecutive sync failures
  • ReplPendingOp:PositionInQ - number of pending replication operations
  • DisableScheduledSync - If the scheduled sync is disabled
Default Alerts:
  • "Alert on any partition replication error" - This alert will be generated if any status value changes to "Error," - which means replication has failed.
Credentials

You can use any credential that allows access to the root\MicrosoftActiveDirectory namespace. Administrative rights might be required.

pending-reboot

Pending Reboot Sensors

Check if the machine is waiting for a reboot because of the updates.

windows-updates

Windows Updates

The sensor monitors the status of Windows updates on a computer. Allows triggering an alert on a failed update.

registry

Registry Sensor

This sensor uses WMI to monitor Windows Registry objects specified by path.

The registry sensor alerts you when a subkey or value list is changed.

Possible alerts:

  • Registry key does not exist
  • The list of subkeys has changed
  • The list of values has changed
  • Specified subkey exists or does not exist
  • Specified value exists or does not exist
  • Alert on selected value content

registry-counters

Registry Counters Sensor

This sensor uses WMI to get and monitor numeric values from the Windows Registry.

  • to the numeric value - the sensor returns one counter with this value
  • to the key - each numeric value is an instance of the counter

This sensor can utilize thresholds in NetCrunch to monitor different scenarios:

  • The port of the application saved in the registry should match exactly a given value by using a "Flat Value" event condition that is different from what is set in the alert
  • Value of key that should be '0' and is set to '1' - this can be monitored by 'State trigger' as an event condition

remote-ping

Remote Ping

The sensor checks connectivity from a remote system by running Ping remotely.

It allows setting a threshold on the following counters:

  • % Availability
  • Response Time

time-difference

Time Difference

The sensor checks the time difference between a remote machine and the reference machine (NetCrunch Server or NTP server).

The sensor provides one counter, which is Difference sec.

wmi-hdd-health

WMI HDD Health

This sensor can monitor the HDD disk health state if the disk implements SMART technology, predicting disk failure.

It allows many counters, which depend on specific vendor implementation.

battery

WMI Battery

The sensor monitors the battery connected to the computer system. It can be a battery or any external battery (like UPS) connected to a computer.

Sensor alerts:

  • When AC power is lost, the battery is discharged
  • On battery hardware error
  • When the battery level is low

windows-task-scheduler

Windows Task Scheduler Sensor

The sensor monitors the status of Windows Task Scheduler tasks. It allows triggering an alert if task configuration has changed or if a task was not run on time.

You can use various alerts to monitor tasks.

  • task enable/disabled
  • task configuration has changed
  • The last task run has failed
  • the task has not been run since the specified amount of time
Additional Info:

One sensor can monitor several tasks specified by name or regular expression.

iis-application-pool

IIS Application Pool

The sensor monitors the state and performance of the selected IIS Application Pool, providing insight into its operational status, resource utilization, and error conditions. This enables administrators to address issues proactively before they impact end-users.

Possible alerts:
  • Application Pool is not running: Triggered if the monitored Application Pool becomes unavailable.
  • The application pool has been restarted: Indicates that the pool was recently restarted, which may occur due to resource constraints, deployment changes, or configuration updates.
  • Worker process failures: Alerts if worker processes (w3wp.exe) encounter errors or terminate unexpectedly.
  • Alert on connection error: Notifies administrators if the Application Pool cannot accept or establish connections.
  • Alert on authentication error: Indicates that client requests fail due to authentication issues.
Data Collector

IIS Application Pool Data Collector – This collector provides key performance counters and operational health metrics for the selected Application Pool. It includes:

  • Worker Process Counts: Monitors the number of active worker processes, helping you understand resource allocation and concurrency.
  • Worker Process Failures: Tracks the frequency of worker process crashes or failures, allowing early detection of problematic deployments or configuration settings.
  • Basic Health Indicators: Gathers status information, including whether the Application Pool is currently started or stopped, enabling timely intervention when problems arise.

By leveraging these metrics, you can ensure your IIS Application Pool remains stable, responsive, and securely accessible to users.

Advanced Sensors

These sensors require a bit of knowledge about querying WMI objects.

wmi-data

WMI Data

The sensor allows the selection of the WMI class and instance key to retrieve object properties. The sensor enables processing multiple objects (and that's why it needs an instance key property).

The sensor allows setting alerts only on performance counters. Each numeric property of the selected class becomes a counter.

Beware that some classes may return large datasets as the sensor does not filter any instance.

Example

another way to monitor processes

Namespace
root\CIMV2
WMI Class
Win32_Process
Instance Key
Name

wmi-object

WMI Object

The sensor monitors a specific WMI object without writing a WQL query. So, in addition to the WMI Data sensor, an instance value must be set. It is compared for equality, so you can't filter objects by several properties.

The sensor also allows setting alerts on performance counters and treats each object's numeric property as a counter. Additionally, it allows for tracking status properties.

Status alert tracks change from one value to the other. You have continuously tracked status values and set them to appropriate ones.

Finally, you can store the last object data in the program database. Widgets or UI can later access these data.

wql-query$object

WQL Query:Object

The WMI Object sensor has some limitations. For example, you can filter instances by a single field only. Unfortunately, simple things tend to be limited, while flexible ones quickly become complicated.

Example

another way to monitor the process

Namespace
root\CIMV2
wql-query
WQL Query
SELECT * FROM win32_Process WHERE name = 'NCServer.exe'

Now, you can access counters of the given process or set the status alert for property changes.

You can use State Trigger to track value changes if the property is numeric and has discrete values.

batterychargefilehddmicrosoftobjectperfmonpingqueryregistryremoteschedulersharessmartsummarytaskupswindowswmiwql