I have several
svchost.exe processes running on a Windows host. In Splunk in the
Perfmon:Process sourcetype I have events of the following form (apologies for the United States of America date format, it is confusing as it is not in a logical ordering of units like ISO8601, but unfortunately this is the way events are stored in Splunk, the dates below are the 12 May, not 5 December as anyone might logically interpret them, I understand Splunk is used by people worldwide and to use a confusing date format is not helpful):
05/12/2018 15:20:41.325 +0000 collection=Process object=Process counter="Working Set - Private" instance=svchost Value=2404352 05/12/2018 15:20:41.325 +0000 collection=Process object=Process counter="Working Set - Private" instance=svchost#1 Value=774144 05/12/2018 15:20:41.325 +0000 collection=Process object=Process counter="Working Set - Private" instance=svchost#3 Value=10354688
svchost#3 is using too much memory. Elsewhere I have logs that record the PID of all the running processes but not the instance number. So what does the
#3 refer to, how is it determined?
I've tried to guess, perhaps that number #3 is allocated in order of (as found in
StartTime(of the process), or
... or is it randomly assigned? Is there any way of mapping an instance number to a particular running process on a host?
Not a real answer that's why it is a comment 😉 The date can be fixed by using /en-GB/ in the URI of Splunk.
#NumberHere issue, why do you think this is Splunk? Actually this in Windows logging this way, and to make it even worth, as you can read here https://blogs.technet.microsoft.com/askperf/2010/03/29/perfmon-identifying-processes-by-pid-instead-... , those numbers are not static. They can change dynamically, or at least back in the days it was like that ... if this is still the case, who knows
Thank you MuS, I believe that answers my question. I'd be happy to credit you with the answer if you wish to repost your comment as an answer.
I've discovered that the
sourcetype=Perfmon:Process counter="ID Process" counter maps instance to ProcessID (
Value), the command line of which can be looked up using
Have to agree that ISO date format (2018-05-12) is better because it cannot be misinterpreted. The word "logically" doesn't really come into it... MM/DD/YYYY and DD/MM/YYYY are mere competing cultural/historical standards that are both silly as well as ambiguous. medium-small-large or small-medium-large both make no sense in terms of modern usage.