A debug system is in place which enables you to see the output from php errors, warnings and notices along with the MySQL queries that have been run for that page.

To enable the debug option, add /debug=yes/ to the end of any URI (I.e /devices/debug=yes/) or ?debug=yes if you are debugging a graph directly.

You will then have a two options in the footer of the website - Show SQL Debug and Show PHP Debug. These will both popup that pages debug window for you to view. If the page itself has generated a fatal error then this will be displayed directly on the page.

If this is related to your web service for LibreNMS then this has been tracked down to an issue within php which the developers aren't fixing. We have implemented a work around which means you
shouldn't be seeing this. If you are, please report this in issue 443.

This occurs either when a counter resets or the device sends back bogus data making it look like a counter reset. We have enabled support for setting a maximum value for rrd files for ports.

Before this all rrd files were set to 100G max values, now you can enable support to limit this to the actual port speed.

rrdtool tune will change the max value when the interface speed is detected as being changed (min value will be set for anything 10M or over) or when you run the included script (./scripts/tune_port.php) - see RRDTune doc

SNMP ifInOctets and ifOutOctets are counters, which means they start at 0 (at device boot) and count up from there. LibreNMS records the value every 5 minutes and uses the difference between the previous value and the current value to calculate rate. (Also, this value resets to 0 when it hits the max value)

Now, when the value is not recorded for awhile RRD (our time series storage) does not record a 0, it records the last value, otherwise, there would be even worse problems. Then finally we get the current ifIn/OutOctets value and record that. Now, it appears as though all of the traffic since it stopped getting values have occurred in the last 5 minute interval.

So whenever you see spikes like this, it means we have not received data from the device for several polling intervals. The cause can vary quite a bit: bad snmp implementations, intermittant network connectivity, broken poller, and more.

This is most commonly due to the poller not being able to complete it's run within 300 seconds. Check which devices are causing this by going to /poll-log/ within the Web interface.

When you find the device(s) which are taking the longest you can then look at the Polling module graph under Graphs -> Poller -> Poller Modules Performance. Take a look at what modules are taking the longest and disabled un used modules.

If you poll a large number of devices / ports then it's recommended to run a local recurisve dns server such as pdns-recursor.

Running RRDCached is also highly advised in larger installs but has benefits no matter the size.

Set a max repeater value within the snmp settings for a device.
What to set this to is tricky, you really should run an snmpbulkwalk with -Cr10 through -Cr50 to see what works best. 50 is usually a good choice if the device can cope.

This is indicating that the device has rebooted within the last 24 hours (by default). If you want to adjust this
threshold then you can do so by setting $config['uptime_warning'] = '84600'; in config.php. The value must be in seconds.

If you are moving from one CPU architecture to another then you will need to dump the rrd files and re-create them. If you are in
this scenario then you can use Dan Brown's migration scripts.

If you are just moving to another server with the same CPU architecture then the following steps should be all that's needed:

- Install LibreNMS as per our normal documentation, you don't need to run through the web installer or building the sql schema.
- Stop cron by commenting out all lines in `/etc/cron.d/librenms`
- Dump the MySQL database `librenms` and import this into your new server.
- Copy the `rrd/` folder to the new server.
- Copy the `config.php` file to the new server.
- Renable cron by uncommenting all lines in `/etc/cron.d/librenms`

If you have service snmp description set in your config then this will be why, please remove this. For some reason Ubnt have decided setting this
value should override the sysDescr value returned which breaks our detection.

If you don't have that set then this may be then due to an update of EdgeOS or a new device type, please create an issue.

If you are monitoring a linux server then net-snmp doesn't always expose all disks via hrStorage (HOST-RESOURCES-MIB). We have additional support which will retrieve disks via dskTable (UCD-SNMP-MIB).
To expose these disks you need to add additional config to your snmpd.conf file. For example, to expose /dev/sda1 which may be mounted as /storage you can specify:

disk /dev/sda1

Or

disk /storage

Restart snmpd and LibreNMS should populate the additional disk after a fresh discovery.

There is a known issue for net-snmp, which causes it to report incorrect disk size and disk usage when the size of the disk (or raid) are larger then 16TB, a workaround has been implemented but is not active on Centos 6.8 by default due to the fact that this workaround breaks official SNMP specs, and as such could cause unexpected behaviour in other SNMP tools. You can activate the workaround by adding to /etc/snmp/snmpd.conf :

Under the device, click the gear and select Capture.
Please provide the output of Discovery, Poller, and Snmpwalk as separate non-expiring https://p.libren.ms/ links.

You can also use the command line to obtain the information. Especially, if snmpwalk results in a large amount of data.
Replace the relevant information in these commands such as HOSTNAME and COMMUNITY. Use snmpwalk instead of snmpbulkwalk for v1 devices.

These commands will automatically upload the data to LibreNMS servers.

Thanks for asking, sometimes it's not quite so obvious and everyone can contribute something different. So here are some ways you can help LibreNMS improve.

Code. This is a big thing. We want this community to grow by the software developing and evolving to cater for users needs. The biggest area that people can help make this happen is by providing code support. This doesn't necessarily mean contributing code for discovering a new device:

Web UI, a new look and feel has been adopted but we are not finished by any stretch of the imagination. Make suggestions, find and fix bugs, update the design / layout.

Poller / Discovery code. Improving it (we think a lot can be done to speed things up), adding new device support and updating old ones.

The LibreNMS main website, this is hosted on GitHub like the main repo and we accept use contributions here as well :)

Hardware. We don't physically need it but if we are to add device support, it's made a whole lot easier with access to the kit via SNMP.

If you've got MIBs, they are handy as well :)

If you know the vendor and can get permission to use logos that's also great.

Bugs. Found one? We want to know about it. Most bugs are fixed after being spotted and reported by someone, I'd love to say we are amazing developers and will fix all bugs before you spot them but that's just not true.

Feature requests. Can't code / won't code. No worries, chuck a feature request into our community forum with enough detail and someone will take a look. A lot of the time this might be what interests someone, they need the same feature or they just have time. Please be patient, everyone who contributes does so in their own time.

Documentation. Documentation can always be improved and every little bit helps. Not all features are currently documented or documented well, there's speeling mistakes etc. It's very easy to submit updates through the GitHub website, no git experience needed.

Be nice, this is the foundation of this project. We expect everyone to be nice. People will fall out, people will disagree but please do it so in a respectable way.

Ask questions. Sometimes just by asking questions you prompt deeper conversations that can lead us to somewhere amazing so please never be afraid to ask a question.

LibreNMS can and is developed by anyone, this means someone may be working on a new feature or support for a device that you want.
It can be helpful for others to test these new features, using Git, this is made easy.

cd /opt/librenms

Firstly ensure that your current branch is in good state:

git status

If you see nothing to commit, working directory clean then let's go for it :)

Let's say that you want to test a users (f0o) new development branch (issue-1337) then you can do the following: