Difficulty setting up snmptrap

[Fabio-Scoppetta]

I configured the snmp trap as the example above but when I send the snmtrap through the command it appears the following message below

service name too long (33)

I am using Centos 7 and sensu version 0.26.5-2.x86_64

Can you help me?
look at example message below

snmptrap -v 2c -c public localhost:1062 "" NET-SNMP-EXAMPLES-MIB::netSnmpExampleHeartbeatNotification netSnmpExampleHeartbeatRate i 123456

and apperars

{"timestamp":"2017-02-06T09:30:15.118198-0200","level":"debug","message":"v2-Trap caught"}
{"timestamp":"2017-02-06T09:30:15.118462-0200","level":"debug","message":"trapdef [1.3.6.1.4.1.8072.2.3.0.1]"}
{"timestamp":"2017-02-06T09:30:15.118587-0200","level":"debug","message":"trap [1.3.6.1.4.1.8072.2.3.0.1]"}
{"timestamp":"2017-02-06T09:30:15.118923-0200","level":"info","message":"SNMPTrap is processing a defined snmp v2 trap oid:SNMPv2-SMI::enterprises.8072.2.3.0.1"}
{"timestamp":"2017-02-06T09:30:15.119341-0200","level":"debug","message":"checking trap definition for key/value template pairs"}
{"timestamp":"2017-02-06T09:30:15.119508-0200","level":"debug","message":""heartbeatrate", [1.3.6.1.4.1.8072.2.3.2.1]"}
{"timestamp":"2017-02-06T09:30:15.119872-0200","level":"debug","message":"[#<SNMP::VarBind:0x000000018fc4f0 @name=[1.3.6.1.2.1.1.3.0], @value=#<SNMP::TimeTicks:0x000000018fc568 @value=105221434>>, #<SNMP::VarBind:0x000000018f3378 @name=[1.3.6.1.6.3.1.1.4.1.0], @value=[1.3.6.1.4.1.8072.2.3.0.1]>, #<SNMP::VarBind:0x000000018f2928 @name=[1.3.6.1.4.1.8072.2.3.2.1], @value=#<SNMP::Integer:0x000000018f29a0 @value=123456>>]"}
{"timestamp":"2017-02-06T09:30:15.120234-0200","level":"debug","message":"discovered value of heartbeatrate is '[name=SNMPv2-SMI::enterprises.8072.2.3.2.1, value=123456 (INTEGER)]'"}
{"timestamp":"2017-02-06T09:30:15.120401-0200","level":"debug","message":"template fields are: {:source=>"127.0.0.1", :hostname=>"localhost", "heartbeatrate"=>#<SNMP::Integer:0x000000018f29a0 @value=123456>}"}
{"timestamp":"2017-02-06T09:30:15.120503-0200","level":"debug","message":"looking for source in snmp-trap-{hostname}"}
{"timestamp":"2017-02-06T09:30:15.120604-0200","level":"debug","message":"looking for source in 1"}
{"timestamp":"2017-02-06T09:30:15.120722-0200","level":"debug","message":"looking for source in {heartbeatrate}"}
{"timestamp":"2017-02-06T09:30:15.120898-0200","level":"debug","message":"looking for source in default"}
{"timestamp":"2017-02-06T09:30:15.120995-0200","level":"debug","message":"looking for hostname in snmp-trap-{hostname}"}
{"timestamp":"2017-02-06T09:30:15.121112-0200","level":"debug","message":"looking for hostname in 1"}
{"timestamp":"2017-02-06T09:30:15.121227-0200","level":"debug","message":"looking for hostname in {heartbeatrate}"}
{"timestamp":"2017-02-06T09:30:15.121354-0200","level":"debug","message":"looking for hostname in default"}
{"timestamp":"2017-02-06T09:30:15.121451-0200","level":"debug","message":"looking for heartbeatrate in snmp-trap-localhost"}
{"timestamp":"2017-02-06T09:30:15.121547-0200","level":"debug","message":"looking for heartbeatrate in 1"}
{"timestamp":"2017-02-06T09:30:15.121657-0200","level":"debug","message":"looking for heartbeatrate in {heartbeatrate}"}
{"timestamp":"2017-02-06T09:30:15.121850-0200","level":"debug","message":"looking for heartbeatrate in default"}
{"timestamp":"2017-02-06T09:30:15.121957-0200","level":"debug","message":{"name":"snmp-trap-localhost","status":1,"output":" 123456","handler":"default"}}
{"timestamp":"2017-02-06T09:30:15.122083-0200","level":"debug","message":"sending SNMP check event: {"name":"snmp-trap-localhost","status":1,"output":" 123456","handler":"default"}"}
{"timestamp":"2017-02-06T09:30:15.122350-0200","level":"debug","message":"opening connection to settings[:client][:socket][:bind]:settings[:client][:socket][:port]"}
{"timestamp":"2017-02-06T09:30:15.122498-0200","level":"error","message":"service name too long (33)"}

[warmfusion]

Interesting.

I've not been doing much with snmp traps recently - I've been rebuilding my home lab, and our production deployment is undergoing some serious change too.

Once I've got my local environment back on track I'll take a look at this closely.

The log output looks detailed enough for me to investigate further - the trap is clearly handled and reprocessed but fails on outbound...

it might be sensu itself, it might by my extension. Could you perhaps try and replicate on sensu 0.25 to check its not a version incompatibility?

[Fabio-Scoppetta]

Thanks for help ..
I do not have version 0.25 installed, but I will install it on a test machine and after that test I'll let you know.