How to display full or short process name in LM

Depends on the datasource, but is the full name part of the description? If so, put the ##DSIDESCRIPTION## in the alert body. FYI: here are all the tokens you can put in an alert: https://www.logicmonitor.com/support/logicmodules/about-logicmodules/tokens-available-in-datasource-alert-messages

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 ?

What's the DS you're using? What does the instance tab look like? Is the data you need not in the description? Is it in the description, but it's cut off? If you're looking for pages of data, you might be looking in the wrong place as large blocks of text should be done using a config source.

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.

Let me clarify -- the LinusNewProcesses- module uses manual wildvalues based on the process name, not PID.  But it is buggy garbage (filed a new ticket on that earlier).  Others like the provided process check for puppet use AD for PID wildvalues, which is messed up.

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.

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
                }
        }

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).

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

claiming it represents a desire on my part for "a wide reaching application monitoring solution"

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.

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