Application disabled by discovery then Application enabled by discovery (SNMP extend based)

Tags: #<Tag:0x00007f3b82675768> #<Tag:0x00007f3b82675588> #<Tag:0x00007f3b82675358>

When asking for help and support, please provide as much information as possible. This should include:

  • Steps to reproduce an issue.
  • The output of ./validate.php

If it’s an issue with the WebUI then please consider including a screenshot and the browser version you are using.

If you are having troubles with discovery/polling include the pastebin output of:

./discovery.php -h HOSTNAME -d | ./pbin.sh
./poller.php -h HOSTNAME -r -f -d | ./pbin.sh

If you need to post any text longer than a few lines, please use a pastebin service such as https://p.libren.ms using non-expiring pastes.


Hi All, hope the day is well and you and yours are safe!

Have an interesting “flap” issue:
Polling and discovery of SNMP “extended” v3 Applications are working wonderfully, but Application discovery (enable -> disable -> enable ) flap is causing gaps or removal of data from graphs.

Adjusted to 7 minutes on the crontab since latency is a bit extreme on a few nodes (need to set up distributed pollers, but goal is to solve flap issue before expanding the problem).

Output that may be of merit:

Flap_of_snmp_based_discovery

BEGIN output of ./validate.php

$ ./validate.php

====================================
Component | Version
--------- | -------
LibreNMS  | 1.62-123-g83dd1f0a1
DB Schema | 2020_04_13_150500_add_last_error_fields_to_bgp_peers (164)
PHP       | 7.2.24-0ubuntu0.18.04.4
MySQL     | 10.1.44-MariaDB-0ubuntu0.18.04.1
RRDTool   | 1.7.0
SNMP      | NET-SNMP 5.7.3
====================================

[OK]    Composer Version: 1.10.5
[OK]    Dependencies up-to-date.
[OK]    Database connection successful
[OK]    Database schema correct

END output of ./validate.php

BEGIN cat /etc/cron.d/librenms

$ cat /etc/cron.d/librenms

# Using this cron file requires an additional user on your system, please see install docs.

33   */6  * * *   librenms    /opt/librenms/cronic /opt/librenms/discovery-wrapper.py 1
*/7  *    * * *   librenms    /opt/librenms/discovery.php -h new >> /dev/null 2>&1

*/7  *    * * *   librenms    /opt/librenms/cronic /opt/librenms/poller-wrapper.py 8

*    *    * * *   librenms    /opt/librenms/alerts.php >> /dev/null 2>&1
*/7  *    * * *   librenms    /opt/librenms/poll-billing.php >> /dev/null 2>&1
01   *    * * *   librenms    /opt/librenms/billing-calculate.php >> /dev/null 2>&1
*/3  *    * * *   librenms    /opt/librenms/check-services.php >> /dev/null 2>&1

# nagios service checks
*/3 * * * * librenms /opt/librenms/services-wrapper.py 1

# Weather map plugin
*/6 * * * * librenms /opt/librenms/html/plugins/Weathermap/map-poller.php >> /dev/null 2>&1

# Daily maintenance script. DO NOT DISABLE!
# If you want to modify updates:
#  Switch to monthly stable release: https://docs.librenms.org/General/Releases/
#  Disable updates: https://docs.librenms.org/General/Updating/
15   0    * * *   librenms    /opt/librenms/daily.sh >> /dev/null 2>&1

END cat /etc/cron.d/librenms

edit: for syntax formatting.

Self reply to hopefully to hopefully help our LibreNMS community.

TL;DR - [SOLVED] via Dispatcher-Service

TL -
Conducted a fresh deployment using the Dispatcher-Service:
https://docs.librenms.org/Extensions/Dispatcher-Service/

Feedback is a simple “wow!”. We’ve been able to drop polling time to the 60 second range with most devices being polled in sub 10 second times (even a few grumpy devices). Applications “just work” and no longer flap.

Suggestion is put forward that, “Dispatcher-Service should no longer be (RC) instead mainline”.

Hope this helps.

[EDIT: Forgot to mention the load on DNS queries has dropped drastically too ]

1 Like