Snmptrap messages to EC look more verbose moving from 1.6 to 2.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.

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

People tell me the messages are coming out of python.

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.

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>)>)

I submitted a bug on this via the feedback email.

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

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