How to display full or short process name in LM

Thanks Stuart,

I have add the tokens already and able to monitor process, but its  only showing first few string of the process (not form the discription). is there any way we can pull the last few string text of the process name. 

process name text is very long around 4k. any groovy scripts technique ?

If the DS is one of the regular SNMP modules, this data would not be available typically (need to enable and define automatic instance properties).  OTOH, process monitoring with the normal SNMP method is nearly useless since they use the process ID as the wildvalue and the process ID sometimes changes for perfectly good reasons. We just ran into this with Puppet_Agent_Process after a bunch of alerts following maintenance reboots.  Ideally, datapoints could include a trigger capability to (for example) cause AD to run (like if a reboot has happened).  Since that is not possible without API integration we just scrapped that module and wrote our own. We still track PID so we can detect flapping, but not as the wildvalue.  There is a module called LinuxNewProcesses- you may want to look at as an example -- if there are fields not stored as auto properties, they could be added and then referenced as tokens.

Ok the issue is something like below-

1. we are monitoring the process by using the DS called LinuxNewProcesses.
2. we have added wildvalues  token at the beginning of process, that is displaying Pid at the beginning process name. for Example : 12345-processsssssss_tool_java.conf  

Issue facing : as the process name is very long it not garbing full name from 12345 to conf. its only displaybing like 12345-proce.


What we have to do to get the full name or specific portion of the process name to be displayed as instance name.

On 11/16/2022 at 6:07 AM, mnagel said:

LinuxNewProcesses does not require the PID in the wildvalue, at least I see nowhere in the code it would be used as in input parameter (nor should that ever be needed -- that would be super fragile).  It requires (in the current buggy version) the full process path AND the process arguments (the latter is the bug -- code should hopefully be fixed in the repo soon as I did receive confirmation from support they were able to see the problem). If you want to fix it locally in the meantime, the impacted code is in the run() method (changes highlighted with >>> prefixes.

    static run(String hostname, String processName, out)
    {
        def startTime = new Date().getTime()
                def processArg = processName.tokenize( \"||\")
>>>                def processParam;
                def processPath = processArg[0]

                if(processArg.size() == 2) {
                        processParam = processArg[1]
                }

        // Get all of the data at the same time to minimize
        def processPaths = Snmp.walkAsMap(hostname, OID_NAME, null, 20000)
        def processParams = Snmp.walkAsMap(hostname, OID_PARAM, null, 20000)

        List<String> cpuValues
        List<String> memValues
        List<String> statusValues

        List<String> pids = [];

        processPaths.each {
            pid, name ->
>>>                if((name == processPath) && (processParam == null || processParams[pid] == processParam)) {
                    pids << pid
                }
        }

 

I was saddened to find that the developers rejected this fix to allow for optional argument matching, claiming it represents a desire on my part for "a wide reaching application monitoring solution".  I feel like they have perhaps hit their collective heads, but I have no option but to never import that module again.  And before anyone says "CSM" -- been there, no help (no response actually).

2 minutes ago, Stuart Weenig said:

Found out my portal doesn't have OpenMetrics enabled for a similar reason: we didn't get any licenses for the apm feature and "OpenMetrics would only ever be used by a developer". SMH. Can anyone spell "IoT"? Don't get me started on ARM.

We just had a demo presented on APM to one of our clients.  It was so poorly received I was informed they are going to be moving entirely from the platform now.  So I have been suitably trained now to not show clients new features

On 11/23/2022 at 7:15 PM, mnagel said:

I was saddened to find that the developers rejected this fix to allow for optional argument matching, claiming it represents a desire on my part for "a wide reaching application monitoring solution".  I feel like they have perhaps hit their collective heads, but I have no option but to never import that module again.  And before anyone says "CSM" -- been there, no help (no response actually).

I have two DataSources I've attempted to put up on the Exchange that use Regular Expression to pick and choose with processes one monitors -- we've leveraged it to a large degree of success so far, and was the only favorable way I could find to leverage process monitoring via SNMP at scale. Here are the locator codes:

JDCMLM (SNMP version)
9YLFYE (SSH version)

These are presently under Security review (and have been since I uploaded them September 07, 2022), so I don't know if they're actually visible on the Exchange. Maybe @Stuart Weenigcan enlighten us to whether or not they're viewable while in Security Review ?

I will say that, as a matter of principle, checking process health by whether it's running or not really isn't appropriate -- it should only be viewed as a stop-gap. Querying the processes directly for their health is 100% the only correct path to take (though not always available). Anyone who argues that this type of monitoring constitutes 'wide-reaching application monitoring solution' really doesn't have an understanding as to what 'application monitoring' actually means, and I, too, would strongly question their motivation for making such an argument. 

2 hours ago, Austin Culbertson said:

Anyone who argues that this type of monitoring constitutes 'wide-reaching application monitoring solution' really doesn't have an understanding as to what 'application monitoring' actually means, and I, too, would strongly question their motivation for making such an argument. 

It's a money grab. LM APM is a different license bucket with different costs. They're trying to draw the line between infrastructure monitoring and application monitoring. I'm curious (DM me) about your thoughts because I had thought that individual process monitoring should be done on a deeper level, a la APM. Some of it is LM's origins as a device monitoring system. Multi-instance was probably only thought of for cases of interfaces, drives, etc., not something that can be as ephemeral as processes.

28 minutes ago, Stuart Weenig said:

I'm no longer at LM. I don't have visibility into that anymore. Besides, the only visibility I had was to ping @Michael Rodrigues

Oh, well then! Congratulations upon your career development, then!