Snmptrap messages to EC look more verbose moving from 1.6 to 2.1

Troubleshooting
,
1

CMK version: 2.1.0p1
OS version:AlmaLinux 8.6

Error message:

Our snmptraps received in the event console are looking more verbose (migration from 1.6 to 2.1). I’m seeing:

PULSESECURE-PSG-MIB::logMessageTrap <bound method ObjectType.getUnits of MibScalar((1, 3, 6, 1, 6, 3, 1, 1, 4, 1), <ObjectIdentifier schema object, tagSet <TagSet object, tags 0:0:6>>)>(<bound method ObjectType.getDescription of MibScalar((1, 3, 6, 1, 6, 3, 1, 1, 4, 1), <ObjectIdentifier schema object, tagSet <TagSet object, tags 0:0:6>>)>)

and I think that used to just say PULSESECURE-PSG-MIB::logMessageTrap in the Application column. The full message is also very verbose.

2

It looks really strange i would say. More like a debug output from the MIB translation.

3

People tell me the messages are coming out of python.

4

This needs to be filed as a bug. Looks like printing in checkmk 2.1 for snmptraps is making assumptions that might have worked in Python 2. In my opinion.

5

Turning what shows up in the EC display from columns to rows. The Python messages usually indicate objects thrown to print that aren’t strings:

psa-b

pulseunmatched

PULSESECURE-PSG-MIB::logMessageTrap <bound method ObjectType.getUnits of MibScalar((1, 3, 6, 1, 6, 3, 1, 1, 4, 1), <ObjectIdentifier schema object, tagSet <TagSet object, tags 0:0:6>>)>(<bound method ObjectType.getDescription of MibScalar((1, 3, 6, 1, 6, 3, 1, 1, 4, 1), <ObjectIdentifier schema object, tagSet <TagSet object, tags 0:0:6>>)>)

SNMPv2-MIB::sysUpTime.0: 561070941 <bound method ObjectType.getUnits of MibScalar((1, 3, 6, 1, 2, 1, 1, 3), <TimeTicks schema object, tagSet <TagSet object, tags 64:0:3>, subtypeSpec <ConstraintsIntersection object, consts <ValueRangeConstraint object, consts 0, 4294967295>>>)>(<bound method ObjectType.getDescription of MibScalar((1, 3, 6, 1, 2, 1, 1, 3), <TimeTicks schema object, tagSet <TagSet object, tags 64:0:3>, subtypeSpec <ConstraintsIntersection object, consts <ValueRangeConstraint object, consts 0, 4294967295>>>)>), PULSESECURE-PSG-MIB::logID: SYS20704 <bound method ObjectType.getUnits of MibScalar((1, 3, 6, 1, 4, 1, 12532, 27), <OctetString schema object, tagSet <TagSet object, tags 0:0:4>, subtypeSpec <ConstraintsIntersection object, consts <ValueSizeConstraint object, consts 0, 65535>>, encoding iso-8859-1>)>(<bound method ObjectType.getDescription of MibScalar((1, 3, 6, 1, 4, 1, 12532, 27), <OctetString schema object, tagSet <TagSet object, tags 0:0:4>, subtypeSpec <ConstraintsIntersection object, consts <ValueSizeConstraint object, consts 0, 65535>>, encoding iso-8859-1>)>), PULSESECURE-PSG-MIB::logType: critical <bound method ObjectType.getUnits of MibScalar((1, 3, 6, 1, 4, 1, 12532, 28), <OctetString schema object, tagSet <TagSet object, tags 0:0:4>, subtypeSpec <ConstraintsIntersection object, consts <ValueSizeConstraint object, consts 0, 65535>>, encoding iso-8859-1>)>(<bound method ObjectType.getDescription of MibScalar((1, 3, 6, 1, 4, 1, 12532, 28), <OctetString schema object, tagSet <TagSet object, tags 0:0:4>, subtypeSpec <ConstraintsIntersection object, consts <ValueSizeConstraint object, consts 0, 65535>>, encoding iso-8859-1>)>), PULSESECURE-PSG-MIB::logDescription: critical - System()[][] - PSA-B - Sending iveMaxConcurrentUsersSignedIn [ iveConcurrentUsers='152' ] SNMP trap to checkmk-dc.example.com:162 <bound method ObjectType.getUnits of MibScalar((1, 3, 6, 1, 4, 1, 12532, 29), <OctetString schema object, tagSet <TagSet object, tags 0:0:4>, subtypeSpec <ConstraintsIntersection object, consts <ValueSizeConstraint object, consts 0, 65535>>, encoding iso-8859-1>)>(<bound method ObjectType.getDescription of MibScalar((1, 3, 6, 1, 4, 1, 12532, 29), <OctetString schema object, tagSet <TagSet object, tags 0:0:4>, subtypeSpec <ConstraintsIntersection object, consts <ValueSizeConstraint object, consts 0, 65535>>, encoding iso-8859-1>)>)
6

I submitted a bug on this via the feedback email.

Easy to test. Just enable snmptraps in checkmk and send an snmptrap message.

7

I can confirm this issue, and we are looking into this. :eyes:

8

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.