On windows, many and multiple processes are run under svchost.exe. Sometimes a seperate excutable is run, but other times it's a windows internal component like a DLL. Currently, it's not documented if it's possible to get metrics for internal DLL components and threads. It is however fairly easy in the normal case where a service runs an exe.
Examples
1) exe
To look into the Winlogbeat service, the following registry key is applicable:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\winlogbeat
And key of interest
ImagePath = "C:\Program Files\Winlogbeat\\winlogbeat.exe" -c "C:\Program Files\Winlogbeat\\winlogbeat.yml" -path.home "C:\Program Files\Winlogbeat" -path.data "C:\\ProgramData\\winlogbeat"
For metric beat, it would be as simple as using this in the config
metricbeat.modules:
- module: system
processes:
- 'winlogbeat'
2) DLL
To look into the Windows Remote Management Service usage, for example, the following registry key is applicable:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinRM
From here, two registry key values are of interest:
ImagePath = %SystemRoot%\System32\svchost.exe -k NetworkService
Description = @%Systemroot%\system32\wsmsvc.dll,-102
So in order to know how many resources the WinRM service uses, one needs to drill into it further.
PS > Get-Process svchost | Select-Object -Property ProcessName,Id,Threads,Modules -ExpandPropert
y Modules | Where-Object {$_.ModuleName -eq 'wsmsvc.dll'} | Format-List
ProcessName : svchost
Id : 452
Threads : {448, 392, 520, 492, 564, 1144, 1164, 1192, 1388, 1792, 1908, 1920, 1988, 1256, 1380, 2312, 47776,
41092, 46888, 45644}
Modules : {System.Diagnostics.ProcessModule (svchost.exe), System.Diagnostics.ProcessModule (ntdll.dll),
...
System.Diagnostics.ProcessModule (wsmsvc.dll), System.Diagnostics.ProcessModule (miutils.dll),
...
System.Diagnostics.ProcessModule (wevtfwd.dll), System.Diagnostics.ProcessModule (CRYPTNET.dll),
System.Diagnostics.ProcessModule (wecsvc.dll), System.Diagnostics.ProcessModule (FirewallAPI.dll),
...}
ModuleName : wsmsvc.dll
FileName : c:\windows\system32\wsmsvc.dll
BaseAddress : 140736241139712
ModuleMemorySize : 2625536
EntryPointAddress : 140736243099904
FileVersionInfo : File: c:\windows\system32\wsmsvc.dll
InternalName: WsmSvc.dll
OriginalFilename: WsmSvc.dll.mui
FileVersion: 6.3.9600.16384 (winblue_rtm.130821-1623)
FileDescription: WSMan Service
Product: Microsoft® Windows® Operating System
ProductVersion: 6.3.9600.16384
Debug: False
Patched: False
PreRelease: False
PrivateBuild: False
SpecialBuild: False
Language: English (United States)
Site :
Container :
Size : 2564
Company : Microsoft Corporation
FileVersion : 6.3.9600.16384 (winblue_rtm.130821-1623)
ProductVersion : 6.3.9600.16384
Description : WSMan Service
Product : Microsoft® Windows® Operating System
At this point, how to get metricbeat to select the CPU/Memory/IO usage by just the WsmSvc.dll module is unclear. It's not a process name attribute. It has to be filtered in another way.
I know that SysInternal ProcessExplorer is able to get some info. However, it get's very messy. Here's a rough list of tasks on how to do it.
- Search all svchost processes and find the process(es) with the module / DLL of interest, eg wsmsvc.dll.
- From the PID(s) found in step one, get the memory locations, e.g.
BaseAddress,ModuleMemorySize, etc, to know which memory range(s) the module is loaded into - From the PID(s) find the threads that have entrypoints within the address range from step 2
- Collect and aggregate the resource usage for those threads
Given the above complexity, I'm assuming metric beats doesn't cater for this? At least not yet?
Workaround / Simplification
Configure the service to run in it's own isolated svchost process and then get metrics from just that?
Sc config <service name> type=own
However, this may have unintended consequences? E.g. suppose services interact, e.g. Windows event collection depends on WinRM.
- wsmsvc.dll (WinRM / Windows Remote Management)
- wecsvc.dll (Windows Event Collector)
Splitting these two will force separate process memory spaces, and performance advantages from shared memory and threading, etc would be lost?
. Maybe in the next days I can open a PR. But it's very at the beginning.