2 state Trap SNMP monitor in my "Kevin Holman's like" MP - how to ? RRS feed

  • Question

  •  Hi all !

     I build my own MP, based on a famous Kevin's SNMP Traps MP, to collect SNMP traps , issued by my Prometheus Alert manager. So I am able to catch those traps by rules, but I have to to add monitor there for some needs. Well , I just found a way to copy XML text (a short fragment to be short) for a standard two-state trap monitor and insert that fragment into my MP. After all I imported my MP with no errors and monitor was succesfully initialized..and that's all , it doesn't change its state either, it doesn't work either. Alright, I supposed that the monitor  would get data right from my object but then I realized that every rule in the MP has a section <DataSources> where clearly described which OID, device and DataProvider must be applied to get the data from traps. Here is an example -

     <DataSource ID="DS" TypeID="SNMP!System.SnmpTrapProvider">

    Accordingly to my thoughts the same way is good for monitors also. Simply add the section and my monitor start to work. No way. When I added the section to my monitor and tried to import it , my SCOM raised an error 


     XSD verification failed for the management pack. [Line: 2189, Position: 10]
    The element 'UnitMonitor' has invalid child element 'DataSources'.


    So I have a problem now, how to get a  data from a simple SNMP class instance , gotten from a CSV file into my monitor ?

    Here is a text of my monitor (without string resources though):


    <UnitMonitor ID="UIGeneratedMonitorae1bf343544c423f9dd56fce7aab6a7c" Accessibility="Public" Enabled="false" Target="CSV.SNMPDevice.Class" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" TypeID="SystemNetworkManagementLibrary73131420!System.NetworkManagement.SnmpTrapProvider.2SingleEvent2StateMonitorType" ConfirmDelivery="false">
            <AlertSettings AlertMessage="UIGeneratedMonitorae1bf343544c423f9dd56fce7aab6a7c_AlertMessageResourceID">
              <OperationalState ID="UIGeneratedOpStateIdd4b5a9b13c9c4c3e923ef16aa08eab36" MonitorTypeStateID="SecondEventRaised" HealthState="Error" />
              <OperationalState ID="UIGeneratedOpStateIdab4c187f79334d059674cdb6f16b4bb4" MonitorTypeStateID="FirstEventRaised" HealthState="Success" />
                    <XPathQuery Type="String">/DataItem/SnmpVarBinds/SnmpVarBind[1]/Value</XPathQuery>
                    <XPathQuery Type="String">/DataItem/SnmpVarBinds/SnmpVarBind[1]/Value</XPathQuery>


    Any help would be appreciated.



    Friday, May 29, 2020 7:20 AM

All replies

  • First,  the reason why you don't need a datasource here is because for monitors, the datasource is contained in the UnitMonitorType that the monitor uses. In your case, the Unitmonitortype is System.NetworkManagement.SnmpTrapProvider.2SingleEvent2StateMonitorType and you'll find  that the datasource is like this : 

          <DataSource TypeID="NetworkLibrary!System.NetworkManagement.SnmpTrapProvider" ID="FirstDataSource">
          <DataSource TypeID="NetworkLibrary!System.NetworkManagement.SnmpTrapProvider" ID="SecondDataSource">

    Then, why is not working?

    There could actually be quite a few reasons :

    • Sometimes, devices are sending traps in a different snmp version than the one used for polling. YOu can simply delete the <FirstVersion> and <SecondVersion> lines, it will make the monitor accept all versions
    • Are you 100% certain that the OID is right and that it's indeed the first parameter in the trap (SnmpVarBind[1]) that contains the value you want to monitor?
    • Your First expression checks for "critical" and your second expression checls for "OK", but in the operational states it's the opposite : "FirstEventRaised" is "Success" (=monitor goes green when the first expression matches) and "SEcondEventRaised" is "Error" (=monitor goes red when the second expression matches)

    • Edited by CyrAz Friday, May 29, 2020 8:49 AM
    Friday, May 29, 2020 8:47 AM
  • CyrAz, thanks a lot for your answer. It gave me a lot of knowledge about monitors buldings ..but it didn't help me after all 8(

    Let's put things in order.

    1. Thanks for a notice about SNMP version . I had known about before I wrote the letter here, but it is VERY useful, so I did it.

    2. I am sure about SNMP version, and a VarBind number, because I have a rule to catch all the traps from Prometheus in the same MP and it works nice. It shows me all the info in  varbinds . The Varbind 1 contains such kind of info -


    Status: critical

    Error Prometheus scrape




    Status: OK

    The Scrape works perfectly


    So I just need to find strings OK or critical there to set my monitor state.

    3.Your third notice was the most reasonable for me, I changed my monitor settings, it was my mistake, thanks a lot ! 

    But it couldn't help me to put my monitor into working state. 8(

    Thank again anyway.

    Friday, May 29, 2020 5:38 PM
  • Do you have more than one scom server in your network resource pool? any of them can be the one elected to receive the traps at any given moment, so the traps have to be seent to all the servers in the pool.

    Did you check if you have any error messagein the operations manager event log that could indicate some kind of conflict between snmp trap rules running on the same server? I think I've already seen that in the past

    Saturday, May 30, 2020 2:04 PM
  • Hi CyrAz !

    Do you have more than one scom server in your network resource pool?

    No, I don't. Only one server, which is listening for incoming traps. Literally I follow Kevin 's  article at all points. he noticed there that only one server must be included into the MP pool to get the traps.

     Did you check if you have any error messagein the operations manager event log that could indicate some kind of conflict between snmp trap rules running on the same server?

    Again don't, but it gives me an another point to check my SNMP there. Will do it .

    Thanks a lot !



    Sunday, May 31, 2020 4:49 PM
  • I have checked an OpsManager log on those SCOM who is in charge of SNMP trap catching. No unusual record at all 8(

    A really tricky case, isn't it ? 8(

    Monday, June 1, 2020 6:43 AM
  • A bit tricky yes, but especially so when I'm not the one doing the troubleshooting... I often spot details that will lead me to the solution or have new ideas when I'm actually in front of the server :D

    Did you restart the SCOM healthservice on the server before checking the event log? If there is a conflict, you will more likely see an event when the rules/monitors are loaded.

    To go further with the troubleshooting, you still have a few options : 

    - Use MPSimulator (but that requires opening your MP in Visual Studio with the VSAE authoring extensions)

    - Create a "debugging" unitmonitortype that will dump anything that is captured by the SNMP Trap datasource, but that's a whole different story... basically the idea is to have a monitor type that will get the data from the datasource, pass the full propertybag to a powershell writeaction using $Data$ variable and have the powershell script dump the propertybag in a text file so you can see exactly how it looks like (if it is received at all).

    Monday, June 1, 2020 5:47 PM
  • Thanks a lot !

     The idea about dump monitor creation looks pretty good, I am going to work on it . Sooner or later I win 8)



    Tuesday, June 2, 2020 12:17 PM
  • I wrote a blog about that trick but it's in French -but you can sill have a look at the code samples- and... quite frankly it's a very interesting trick but not a great article :o


    Tuesday, June 2, 2020 12:59 PM
  • Bonjour, CyrAz !

    Pas du problemmes , je comprene Francais 8) 

    Merci beaucoup


    Friday, June 5, 2020 7:55 AM