Ad Widget

Collapse

Template LLD Discovery OID unique situation

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Drew Leavitt
    Junior Member
    • Dec 2019
    • 5

    #1

    Template LLD Discovery OID unique situation

    Hello, I am trying to create a template to monitor RMS Boards by Exeltek and they do something different with their OID's that I haven't seen other vendors do. Due to this difference, I am having difficulty creating a discovery workflow. Any assistance would be helpful.

    Most OIDs from most vendors are formatted with the changing variable at the end such as 1.3.6.1.4.1.21749.3.2.1.1.1.1, 1.3.6.1.4.1.21749.3.2.1.1.1.2, 1.3.6.1.4.1.21749.3.2.1.1.1.3, etc.
    This vendor has the last portion of the OID as a 0. with the variable before it changing such as. 1.3.6.1.4.1.21749.3.2.1.1.1.1.0, 1.3.6.1.4.1.21749.3.2.1.1.1.2.0, 1.3.6.1.4.1.21749.3.2.1.1.1.3.0, etc

    I am hoping there is a way to specify in the discovery or with some sort of filter/ processing rule that will allow me to ignore the .0 at the end when trying to discover.

    Thank you,
  • Rudlafik
    Senior Member
    • Nov 2018
    • 144

    #2
    Hi,

    the item 1.0, 2.0, 3.0....N.0 are same type? (set of temp. sensors, fans etc.)
    Do you try "Discovery rule" as discovery[{#SNMPVALUE},.1.3.6.1.4.1.21749.3.2.1.1.1]
    What answer the item test?

    I "catch" tem. sensor indexes for example:

    ([{"{#SNMPINDEX}":"1.1","{#SNMPVALUE}":"CPU One"},{"{#SNMPINDEX}":"1.2","{#SNMPVALUE}":"BBU"}, {"{#SNMPINDEX}":"1.3","{#SNMPVALUE}":"System Board"},{"{#SNMPINDEX}":"1.4","{#SNMPVALUE}":"SAS Expander"},{"{#SNMPINDEX}":"1.5","{#SNMPVALUE}":"L eft Riser Card"},{"{#SNMPINDEX}":"1.6","{#SNMPVALUE}":"Ambie nt"},{"{#SNMPINDEX}":"1.7","{#SNMPVALUE}":"Midplan e One"},{"{#SNMPINDEX}":"1.8","{#SNMPVALUE}":"Midpla ne Two"},{"{#SNMPINDEX}":"1.9","{#SNMPVALUE}":"Exhaus t Fan One"},{"{#SNMPINDEX}":"1.10","{#SNMPVALUE}":"Exhau st Fan Two"},{"{#SNMPINDEX}":"2.1","{#SNMPVALUE}":"CPU One"},{"{#SNMPINDEX}":"2.2","{#SNMPVALUE}":"BBU"}, {"{#SNMPINDEX}":"2.3","{#SNMPVALUE}":"System Board"},{"{#SNMPINDEX}":"2.4","{#SNMPVALUE}":"SAS Expander"},{"{#SNMPINDEX}":"2.5","{#SNMPVALUE}":"L eft Riser Card"}])

    And than I use it for definition of "item prototypes":

    Name: Category of Alert {#SNMPINDEX}
    Key: scAlertCategory[{#SNMPINDEX}]
    SNMP OID: .1.3.6.1.4.1.674.11000.2000.500.1.2.46.1.6.{#SNMPI NDEX}

    Mayby way is make from last two no. "index"...

    Comment

    • Drew Leavitt
      Junior Member
      • Dec 2019
      • 5

      #3
      Yes, these items are all alarm sensors on this device. If I can get over this hurdle, the next one will be voltmeters, etc.

      normally, when I test it (using discovery OID: discovery[{#ALARMNAME},.1.3.6.1.4.1.21749.3.2.1.1.1]) I get
      [{"{#SNMPINDEX}":"0","{#ALARMNAME}":"Door"}]
      - for some reason, it is pulling the name from the 5th alarm.

      when trying with the discovery OID as the one you recommended: discovery[{#SNMPVALUE},.1.3.6.1.4.1.21749.3.2.1.1.1] I also get
      [{"{#SNMPINDEX}":"0","{#ALARMNAME}":"Door"}]

      I did try discovery[{#SNMPVALUE},.1.3.6.1.4.1.21749.3.2.1.1.1.1] and I got
      [{"{#SNMPINDEX}":"0","{#SNMPVALUE}":"Bad"}]
      - which is correct as being the first alarm, but I would expect it to show me all 5 alarms when I run the discovery test.

      I have attached a picture that shows what the values are supposed to look like using SNMPB. ( I have confirmed this through standard snmpwalk as well)

      I do agree if I can get the index to be 1.0, 2.0, 3.0. etc, that would most likely work across the board for these devices. I just don't know how to tell it to do so.
      Attached Files
      Last edited by Drew Leavitt; 01-10-2021, 21:29.

      Comment

      • Rudlafik
        Senior Member
        • Nov 2018
        • 144

        #4
        Hmm.

        I have theory that is vendor wrong/bad imlementation SNMP. But, super, that opinion dont help you. :-)

        Viewpoint A:

        - have you vendot MIB? Didi you try make LLD with using MIB key name(s) of SNMP OIDs?
        - can you plaese send picture/details with supgroup/childgroupe of "rms200alarms" I see only first two names of supgroupe.
        - every rms200alarmNname are same subkeys as name of group. 5x rms200alarm groups. That is interesting is that groupe "rms200alarm1name" has same count of subkeys as is count of all groupe on same level as "rms200alarm1name" ("rms200alarm1name","rms200alarm2name","rms200alar m3name""rms200alarm4name","rms200alarm5name") with INDEX "0"!!! I excpect .1, .2 (I describe what you writhe in your ask.)

        I think that is wrong implementation. You monitoring device has 5 sensors every with only one output value. (Bad, Generator, No Con, No Con, Door) Every with index "0". For me, for an incomprehensible reason, these values are repeated for all group names. I expect you to show me the same output on the output from alarm200 name 3, 4 and i 5. The same values the same indexes. That's why I think it's a bad SNMP implementation. Adding new HW extends the measurement only by the alarm200name6name group and the index value .0. Apparently something is cycled there and repeated. The question is whether a firmware upgrade or the current MIB or a question to support the manufacturer would not help.

        Why I have this theory? Becouse for examples: OID .1.3.6.1.4.1.674.11000.2000.500.1.2.10.0 (Device serial number), .1.3.6.1.2.1.1.3.0 (Uptime) OID end "0". This is the parental OID defined by "0" and the index defines their children at level 1 - N.1-N. When OID end 0 then it is basically defined as a parent with index 0.

        OK I LOOK ON PROBLEM FROM OTHER WAY

        Viewpoint B:

        - you have device with 5th moduls.
        - This 5 moduls has 5th sensors.
        - Sensors in all 5 moduls send output with same value (Bad, Generator, No Con, No Con, Door)

        Variable for you in rms200alarmNames group are ("rms200alarm1name","rms200alarm2name","rms200alar m3name""rms200alarm4name","rms200alarm5name") (1.3.6.1.4.1.21749.3.2.1.1.1.1, 1.3.6.1.4.1.21749.3.2.1.1.1.2, 1.3.6.1.4.1.21749.3.2.1.1.1.3, 1.3.6.1.4.1.21749.3.2.1.1.1.4, 1.3.6.1.4.1.21749.3.2.1.1.1.5) index is No 1 - 5. You have to set LDD proces on parents rms200alarmNames 1.3.6.1.4.1.21749.3.2.1.1.1, or rms200alarm 1.3.6.1.4.1.21749.3.2.1.1
        - Than work with preprocesing of observer OID or value. mayby on both side: in "discovery rule" and too "item prototype" try add to index ".0" To 1.3.6.1.4.1.21749.3.2.1.1.1.N.0 than get name of alarm: (Bad, Generator, No Con, No Con, Door)
        Do you expect alarm names to increase or change frequently? That you will need to discover them? But it's actually more a question about the implementation of monitoring and you didn't ask about that ;-).

        I hope that both my views at least inspired you in a new view of the problem.


        Comment

        • Drew Leavitt
          Junior Member
          • Dec 2019
          • 5

          #5
          I can agree that this method of implementing SNMP seems to be a bad choice as well.
          I do have the MIB file from the vendor and have tried intermittently with the MIB Key names as opposed to numeric OID's. sadly no change there.
          I have added pictures of the other groups underneath rms200alarms


          I can definitely look into a firmware upgrade to see if they have fixed the .0 bit at the end.


          with preprocessing, I have not found a guide that helps me with either adding a .0 to the index or stripping it away. do you have any recommendations from that standpoint?

          I do not expect tnames in increase or change frequently. TBH, I can likely get around this whole issue by creating all the item templates manually as opposed to going through discovery. I just wanted to make the template as clean and simple as possible.

          Yes your viewpoints have been helpful, thank you.
          Attached Files

          Comment

          • Rudlafik
            Senior Member
            • Nov 2018
            • 144

            #6
            I look on you attached file - one world - mess. Totaly mess in SNMP.
            Same results in implementation of SNMP v1, v2 and v3? (sorry now "i cook from water" (czech idioms for i dont have idea but try it this...))
            Preprocesing - my mistake, sorry this process work only with results. This is comback to start and yours note obout filtering. Ther you can by regular expression select only discovered item without .0 This is only my assumption. I havent work with it yet Or "The Override tab allows setting rules to modify the list of item, trigger, graph and host prototypes or their attributes for discovered objects that meet given criteria."

            Or use Dependent item and ure reg. exp. in take separete value from lotoff values from one result. You can use one master item and generate forked items from one master item where results is more values/words/sentences/mumbers and it isnt in JSON/XML.
            Mayby this is point for your way for clear profesional template. Or make fixed item in template. It is not wrong solution. Sometimes is this only one way for usefull template. (yes I dont talk about JSript preprocesing but this is other level, not for me :-))

            Comment

            • Drew Leavitt
              Junior Member
              • Dec 2019
              • 5

              #7

              I tried v3 but something wasn't working properly and I couldn't get it to walk right. may have been a setting on my end or something to do with the device.
              I did try with v1 and got the same results however.

              Based on the feedback you have provided and how bad this vendor's implimentation of SNMP is, it may be best to create manual Item templates for these as opposed to discovery templates.

              Thank you for your insights, it has been very helpful in determining a way forward for me.

              Comment

              Working...