Forum Discussion

mnagel's avatar
mnagel
Icon for Professor rankProfessor
8 years ago

text data display improvements

Right now, certain types of monitoring are literally impossible with LM because everything must either be a number an enum (mapped to a predetermined list of status results).  Some valid monitoring results are best represented as text and useless without it.  For example, we check for Cisco IOS crashes as follows:

/usr/lib/nagios/plugins/check_snmp -C %snmp_community:public% -o .1.3.6.1.4.1.9.2.1.2.0 -H 10.1.113.1 -l "Reload Reason" -R "reload|power-on|power cycle|Stateful Switchover|redundancy reset|\"\""

Not having a text output method leads either to "it cannot be done" or contortions to try to map text to enums somehow, if that even makes sense.  I do understand this is non-trivial with time series data, but it is not impossible.  It could be done with a simple compression algorithm using a generated index valuer assigned to each new text string and numbers still used for time series.  The difference is each number could be remapped to its original text later for display purposes.  In the above example, we could still monitor for an abnormal restart, but we would have no way to know what the restart reason was in LM -- you would have to login to the device or manually pull the OID to do so.

 

Thanks,

Mark

  • mnagel's avatar
    mnagel
    Icon for Professor rankProfessor
    8 years ago

    Please update the documentation for the Script EventSource to include this boilerplate/sample code... Would have saved me a lot of research and debugging time :).

    import groovy.json.*

    def events = [events:[]];
    if (condition) {
       events.events << [happenedOn:new Date(), severity:'error', message:errorMessage]
    }

    if (!events?.empty) {
        println new JsonBuilder(events).toString()
    }

    Thanks,
    Mark

  • Matthew_Dunham's avatar
    Matthew_Dunham
    Former Employee
    8 years ago

    Hi Mark --

    This one of the many use-cases for our Scripted EventSource feature. In this case I'd suggest using a Groovy SNMP script to query the SNMP OID and represent the output as a text-based event. You'll be able to view any triggered events on the corresponding EventSource entry within your device tree.

  • mnagel's avatar
    mnagel
    Icon for Professor rankProfessor
    8 years ago

    Aha!  I will definitely give that a shot -- not sure how I missed that one.  Thanks!

    Mark

     

  • mnagel's avatar
    mnagel
    Icon for Professor rankProfessor
    8 years ago

    Now that I have this working, I am confused about the output format.  It looks exactly like the sample shows, but why if I am sending a 'message' field is that not the contents of the Message field in the event?  And displaying the happenedOn and severity fields seems redundant and messy.  Is there a plan to overhaul that?

    Thanks,
    Mark

     

  • Mosh's avatar
    Mosh
    Icon for Professor rankProfessor
    8 years ago

    I also don't like the way the message property is handled. I would like the "message" attribute from a Script EventSource to become the "value" of an alert.  The "happenedOn" and "severity" should be mapped to the actual alert fields and not repeated in the Value field.  It should be possible for us to pass back exactly the text we want to show in the alert Value field from the script.