[Pacemaker] pacemaker and snmptt

Fri Apr 1 10:13:30 EDT 2011

On Apr 1, 2011, at 4:04 AM, Andrew Beekhof wrote:

> On Tue, Mar 29, 2011 at 5:10 AM, Vadym Chepkov <vchepkov at gmail.com> wrote:
>> Hi,
>> 
>> I have been trying to have snmptt (http://www.snmptt.org/) catch pacemaker's traps, but haven't been successful so far.
>> 
>> snmpttconvertmib utility doesn't process PCMK-MIB.txt, complains it doesn't have any TRAP-TYPE / NOTIFICATION-TYPE lines
> 
> I have no idea what that means.
> But if there are some changes needed to the MIB then you're welcome to
> send a patch.
> 

I would, if I knew myself :) 

Here is excerpt from O'Reily book:

In an effort to standardize the PDU format of SNMPv1 traps (recall that SNMPv1 traps have a different PDU format from get and set), SNMPv2 defines a NOTIFICATION-TYPE. The PDU format for NOTIFICATION-TYPE is identical to that for get and set. RFC 2863 redefines thelinkDown generic notification type like so:

linkDown NOTIFICATION-TYPE
    OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
    STATUS  current
    DESCRIPTION
        "A linkDown trap signifies that the SNMPv2 entity, acting in an
         agent role, has detected that the ifOperStatus object for one
         of its communication links left the down state and transitioned
         into some other state (but not into the notPresent state). This
         other state is indicated by the included value of ifOperStatus."
    ::= { snmpTraps 3 }

PCMK-MIB does not define any NOTIFICATION-TYPE it seems.

And "generic" object is sent .1.3.6.1.4.1.32723.1 where all the values have to be extracted.
if, instead crm_mon.c sent .1.3.6.1.4.1.32723.2.1 for start, 1.3.6.1.4.1.32723.2.2 for stop and 1.3.6.1.4.1.32723.2.3 for monitor, for example, it would be easier to handle them in snmpttrap, at least as much as I understand.

Vadym

>> .1.3.6.1.4.1.32723.1

>> I am catching "unknown" traps:
>> 
>> Mon Mar 28 21:06:14 2011: Unknown trap (.1.3.6.1.4.1.32723.1) received from xen-2 at:
>> Value 0: xen-2
>> Value 1: 192.168.1.34
>> Value 2: 150:14:53:28.82
>> Value 3: .1.3.6.1.4.1.32723.1
>> Value 4: 192.168.1.34
>> Value 5:
>> Value 6:
>> Value 7:
>> Value 8:
>> Value 9:
>> Value 10:
>> Ent Value 0: .1.3.6.1.4.1.32723.1.2=apache_ldap
>> Ent Value 1: .1.3.6.1.4.1.32723.1.1=ce777942-c35b-48d6-8e60-b9a15378c031
>> Ent Value 2: .1.3.6.1.4.1.32723.1.3=monitor
>> Ent Value 3: .1.3.6.1.4.1.32723.1.4=not running
>> Ent Value 4: .1.3.6.1.4.1.32723.1.6=7
>> Ent Value 5: .1.3.6.1.4.1.32723.1.7=0
>> Ent Value 6: .1.3.6.1.4.1.32723.1.5=0
>> 
>> 
>> Mon Mar 28 21:06:16 2011: Unknown trap (.1.3.6.1.4.1.32723.1) received from xen-2 at:
>> Value 0: xen-2
>> Value 1: 192.168.1.34
>> Value 2: 150:14:53:28.84
>> Value 3: .1.3.6.1.4.1.32723.1
>> Value 4: 192.168.1.34
>> Value 5:
>> Value 6:
>> Value 7:
>> Value 8:
>> Value 9:
>> Value 10:
>> Ent Value 0: .1.3.6.1.4.1.32723.1.2=apache_ldap
>> Ent Value 1: .1.3.6.1.4.1.32723.1.1=ce777942-c35b-48d6-8e60-b9a15378c031
>> Ent Value 2: .1.3.6.1.4.1.32723.1.3=stop
>> Ent Value 3: .1.3.6.1.4.1.32723.1.4=ok
>> Ent Value 4: .1.3.6.1.4.1.32723.1.6=0
>> Ent Value 5: .1.3.6.1.4.1.32723.1.7=0
>> Ent Value 6: .1.3.6.1.4.1.32723.1.5=0
>> 
>> 
>> If pacemaker would use different OIDs for different statuses, like switches do, for example:
>> 
>> EVENT coldStart .1.3.6.1.6.3.1.1.5.1 "Status Events" Normal
>> FORMAT Device reinitialized (coldStart)
>> 
>> EVENT warmStart .1.3.6.1.6.3.1.1.5.2 "Status Events" Normal
>> FORMAT Device reinitialized (warmStart)
>> 
>> EVENT linkDown .1.3.6.1.6.3.1.1.5.3 "Status Events" Normal
>> FORMAT Link down on interface $1.  Admin state: $2.  Operational state: $3
>> 
>> EVENT linkUp .1.3.6.1.6.3.1.1.5.4 "Status Events" Normal
>> FORMAT Link up on interface $1.  Admin state: $2.  Operational state: $3
>> 
>> the it would be simple to write configuration file manually, but since it's the same for different statuses (not sure why this is the case),
> 
> Because its a "resource event" - there is insufficient context to
> classify it as an error or expected change.
> 
>> it's not so obvious. Did anybody have luck with integrating pacemaker and snmptt, by any chance?
>> 
>> Thank you,
>> Vadym
>> 
>> 
>> _______________________________________________
>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>> 
>> Project Home: http://www.clusterlabs.org
>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>> 
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker