You are here

Deleting SNMP Trap Exceptions

14 posts / 0 new
Last post
peter.kronfuss_88080
peter.kronfuss_88080's picture
Deleting SNMP Trap Exceptions

Hello,

after some time "playing" with SNMP Traps we have collected a huge amount of TRAP Exceptions (>700). How can we bulk delete them? Clicking each of them and select delete may take some time.. :)

With regards,
Peter

Duncan Ferguson
dferguson's picture
I have brought this to the

I have brought this to the atention of the Product Manager as a missing in Opsview Monitor v5.x.  Until this is fixed within the product, you can truncate the table runtime.snmptrapexceptions.

  Duncs

peter.kronfuss_88080
peter.kronfuss_88080's picture
Hi!

Hi!

I have truncated the table and all trapexceptions are deleted now.
Thank you!

With Regards,
Peter

Anders Karlin
anders.karlin's picture
I did the same thing and all

I did the same thing and all trap exceptions was deleted. The problem now is that no new exceptions are displayed on the website even though they appear in the runtime.snmptrapexceptions table.

In the SNMP trap Summary it says:
SNMP trap exceptions: 8

... but none are showen in the list.

Any suggestions?

Duncan Ferguson
dferguson's picture
The opsview-web app may have

The opsview-web app may have cached some data in memory regarding what is in the table.  Can you restart opsview-web and see if that makes a difference?

  Duncs

Anders Karlin
anders.karlin's picture
I coundn't find opsview-web

I coundn't find opsview-web under /etc/init.d so I restarted opsview-watchdog, opsview-notifyd, opsview-authkt and in the end the whole server but snmp trap exception list is still empty although there is rows in table snmptrapexceptions in database runtime.

I'am running Opsview Monitor Atom Edition 5.2.0 on Hyper-V.

How can I troubleshoot this problem? I don't understand why the exceptions in the table isn't shown when pressing the (i) button show SNMP Trap Summary with info about SNMP trap exceptions: 8 ?

One of the rows in the table looks like this:

1475738996127.0.0.1SNMPv2-MIB::coldStart5
localhost UDP: [127.0.0.1]:56094->[127.0.0.1]:162 DISMAN-EVENT-MIB::sysUpTimeInstance 0:0:15:44.14 SNMPv2-MIB::snmpTrapOID.0 SNMPv2-MIB::coldStart SNMPv2-MIB::sysContact.0 Hello World

Duncan Ferguson
dferguson's picture
Managing Opsview Monitor

Managing Opsview Monitor processes is now done via the watchdog - there are details on this here: https://knowledge.opsview.com/articles/faq16-checking-opsview-processes-...

I haven't been able to replicate your problem on my server, so can you run these commands and let me know what you get back?

As the nagios user, run this on the command line, swapping in the correct password:

opsview_rest="/usr/local/nagios/bin/opsview_rest --username=admin --password=initial --pretty"

Then, query the API to see what data is available.  This is the Rest API call to get the summary information:

$opsview_rest GET snmptrap/summary

This is to pull back all the exceptions:

$opsview_rest GET snmptrap/exceptions

Let me know what these return to help track down where the issue is

  Duncs

Anders Karlin
anders.karlin's picture
$opsview_rest GET snmptrap

$opsview_rest GET snmptrap/summary
{
  hosts_tracing            => 2,
  hosts_with_traps         => 0,
  servicechecks_snmptrap   => 2,
  snmptrapdebug_count      => 0,
  snmptrapexceptions_count => 1,
}

$opsview_rest GET snmptrap/exceptions
{
  list => [
    {
      hostip => "127.0.0.1",
      hostname => undef,
      id => 1,
      packet => "localhost\nUDP: [127.0.0.1]:44954->[127.0.0.1]:162\nDISMAN-EVENT-MIB::sysUpTimeInstance 0:2:33:55.03\nSNMPv2-MIB::snmpTrapOID.0 SNMPv2-MIB::coldStart\nSNMPv2-MIB::sysContact.0 Hello World!",
      reason => 5,
      time => 1475755369,
      trapdebug => undef,
      trapname => "SNMPv2-MIB::coldStart",
    },
  ],
  summary => { page => 1, rows => 1, totalpages => 1, totalrows => 1 },
}

 

 

 

Anders Karlin
anders.karlin's picture
$opsview_rest GET snmptrap

$opsview_rest GET snmptrap/summary
{
  hosts_tracing            => 2,
  hosts_with_traps         => 0,
  servicechecks_snmptrap   => 2,
  snmptrapdebug_count      => 0,
  snmptrapexceptions_count => 1,
}

$opsview_rest GET snmptrap/exceptions
{
  list => [
    {
      hostip => "127.0.0.1",
      hostname => undef,
      id => 1,
      packet => "localhost\nUDP: [127.0.0.1]:41083->[127.0.0.1]:162\nDISMAN-EVENT-MIB::sysUpTimeInstance 4:0:23:52.68\nSNMPv2-MIB::snmpTrapOID.0 SNMPv2-MIB::coldStart\nSNMPv2-MIB::sysContact.0 Hello World",
      reason => 5,
      time => 1476104640,
      trapdebug => undef,
      trapname => "SNMPv2-MIB::coldStart",
    },
  ],
  summary => { page => 1, rows => 1, totalpages => 1, totalrows => 1 },
}

Anders Karlin
anders.karlin's picture
$opsview_rest GET snmptrap

$opsview_rest GET snmptrap/summary
{
  hosts_tracing            => 2,
  hosts_with_traps         => 0,
  servicechecks_snmptrap   => 2,
  snmptrapdebug_count      => 0,
  snmptrapexceptions_count => 1,
}

 

 

$opsview_rest GET snmptrap/exceptions
{
  list => [
    {
      hostip => "127.0.0.1",
      hostname => undef,
      id => 1,
      packet => "localhost\nUDP: [127.0.0.1]:41083->[127.0.0.1]:162\nDISMAN-EVENT-MIB::sysUpTimeInstance 4:0:23:52.68\nSNMPv2-MIB::snmpTrapOID.0 SNMPv2-MIB::coldStart\nSNMPv2-MIB::sysContact.0 Hello World",
      reason => 5,
      time => 1476104640,
      trapdebug => undef,
      trapname => "SNMPv2-MIB::coldStart",
    },
  ],
  summary => { page => 1, rows => 1, totalpages => 1, totalrows => 1 },
}

Duncan Ferguson
dferguson's picture
We had a report of the same

We had a report of the same issue in our support portal which I have been trying to investigate.  However, by the time I looked on their system the issue had resolved itself.

I take it you are still not seeing any traps within the UI?

  Duncs

Anders Karlin
anders.karlin's picture
Still no traps in the UI.

Still no traps in the UI.

* Sorry about the multireplay. It toke days to get the replay published *

Duncan Ferguson
dferguson's picture
I have found the bug.

I have found the bug.

It looks like when you truncated the table you were not on the first page of the SNMP trap exceptions - the page you were on was cached, e.g. that you were looking on page 2 (or more). 

After the table was truncated and you viewed the page again, your last cached page was shown, rather than the first, which then displayed no traps.  If you wait long enough for more traps to come in, you will eventually see the traps again.

The workaround is to change the number of rows displayed on the page - this resets the cached page and goes back to the first page of exceptions.

I am raising this with Engineering to get fixed.

  Duncs

Anders Karlin
anders.karlin's picture
Thank you for your help. It

Thank you for your help. It works great now.