Getting Data In

How are Windows instance numbers for two processes with the same name determined?

petenetwork
Explorer

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

Now 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 sourcetype=WinHostMon😞

  • ProcessId, or
  • StartTime (of the process), or
  • CommandLine

... or is it randomly assigned? Is there any way of mapping an instance number to a particular running process on a host?

Tags (3)
1 Solution

MuS
Legend

Hi petenetwork,

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.

Regarding the #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 ¯\_(ツ)_/¯

cheers, MuS

View solution in original post

DalJeanis
Legend

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.

petenetwork
Explorer

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 sourcetype=WinHostMon.

0 Karma

MuS
Legend

Hi petenetwork,

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.

Regarding the #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 ¯\_(ツ)_/¯

cheers, MuS

petenetwork
Explorer

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.

0 Karma

MuS
Legend

done, Thanks 🙂

Get Updates on the Splunk Community!

Splunk Platform | Upgrading your Splunk Deployment to Python 3.9

Splunk initially announced the removal of Python 2 during the release of Splunk Enterprise 8.0.0, aiming to ...

From Product Design to User Insights: Boosting App Developer Identity on Splunkbase

co-authored by Yiyun Zhu & Dan Hosaka Engaging with the Community at .conf24 At .conf24, we revitalized the ...

Detect and Resolve Issues in a Kubernetes Environment

We’ve gone through common problems one can encounter in a Kubernetes environment, their impacts, and the ...