Double down on Collectd, sunset "Applications"

I was looking at our “Applications” support and it is in really sad shape. Mostly, we have inherited this from the fork. I have been working on getting it in better shape, but I have realized it is a dead-end and we are just re-inventing the wheel.

I propose the following to improve our support.

  1. Stop re-inventing the wheel and double down on an existing solution such as collectd. (We currently support collectd and Munin!)
  2. Improve integration with the chosen agent. The goal would be to reduce the amount of manual configuration needed to be done in collectd and provide configuration options within LibreNMS WebUI when needed.
  3. Allow alerts to be configured for data.
  4. Support storage of data in rrd or InfluxDB. (LibreNMS won’t support graphing InfluxDB until v2)

Thoughts? Would you support this if this means that in the future, support for other methods, such as “Applications” and Munin are likely to be removed?

I’m not set on collectd and am just now exploring options, but it seems the likely winner. If there is something else I should evaluate, please suggest it.

2 Likes

Would this also get rid of SNMP extend scripts? If yes, then I vote against it. I don’t want to deploy another binary to all of my servers and potentially open new ports (?). All of my devices already have SNMP set up and if I want to check the output of various applications, extend scripts are a good way to go and transport their data well over existing snmp connections.

1 Like

I do agree with you somewhat. It is a pain to deploy a new binary. As for the port, collectd pushes data to the server, so you would only have to open a port on the server. It also supports encryption.

The reason I propose is I was looking at the scripts we have and it will take many hours just to get them in OK shape. There are many projects out there that do this such as collectd, munin, and ganglia; all of which support many more applications and have active communities. We currently support collectd and Munin.

I would be fine with leaving the existing application support, but I will not be spending much of my time on them. I would like to unify the display in that case so they all show in the same place.

I’m not a big user of the apps side (a few at home) so I have no personal opinion either way.

However I will say that re-inventing the wheel isn’t something we should do so moving to utilise a 3rd party tool to do the same thing would have my vote. Leaving the current system in place is probably do-able.

I’ve not looked into Collectd much so I don’t know if it’s the best choice but I trust your opinion @murrant :slight_smile:

I’m not set on collectd. I’m still evaluating, but it looks likely to be the best choice.

i think that collectd will do with some limitations on windows os (as there are not so many daemons besides ssc serv)

I think I’m going to write some docs for v1 then all unify all the “apps” for v2.

FYI
The other use of ‘apps’ is for web presentation. I have several modules that use the apps menu to display a global view of a module (see ntp). Yes its a hack, but its a use case that would need to be catered for if this was taken away.

Thanks,
Aaron

Thanks,. I’ve actually decided not to make any changes for the GUI. But when it is implemented in v2 I will make some changes.

In the meantime I plan to update the docs and steer people towards collectd.

A bit late to this thread, but I am happy to assist in any effort to polish and update your applications support. I don’t know much about munin, collectd or any agent atm, but I’m always happy to help.I really like LibreNMS, and individual application support is very much a must-have for my environment.

First steps as discussed:

  1. Test out collectd and munin (currently have integration) and others
  2. Improve docuementation for collect and munin
  3. Evaluate
1 Like

I plan to make a new post to track status in the projects category :slight_smile:

1 Like