During the installation of your monitoring platform, you probably install nagios plugins package which provide some basic plugins.

Until now everything is fine in this story but don’t expect for an happy end with Nagios … Troll inside

Indeed the Nagios plugins project was splitted in two different projects (Nagios plugins and monitored plugins), you’ll tell me “OK hum but why this split ? both teams can’t work together ? what is the difference between the two projects ?”

I won’t lie you, I don’t have the answer but let’s try to understand.

In the begining of the year, monitoring plugins published an article on its new web site to announce the new project name.

Nine days after, Nagios enterprise published an answer due to the lot of trolls on social networks. This answer is a kind of personal attack to a Nagios competitor.

There is a lot of misunderstanding around this event, I think we’ll never know the reason of this plit so let’s see the difference between the two projects.

The current stable version of Monitoring Plugins release is 2.1 and the current stable release of Nagios plugins is 2.0.3. You could see the commit activity of those projects on Github:

Changes on both projects are the same or nearly … Maybe in the future changes could be different or not … So I would like to say use your favorite project.

I don’t know how major distros like Debian or CentOS provide monitoring plugins package but I think there is repositories for each distro. The Nagios plugins package is also available on major distro repositories.

In some case basic plugins are not sufficient because people need to monitor some specific things and there is no plugins for that in the basic monitoring package.

Well how to find the additional plugins ? Packages are available like for the basic plugins? I think ewcomers could have those kind of questions.

Let’s see the different projects or website that allow you to find additional plugins. It’s very interesting to see those different methods used by the different projects.

I hope this will help users to find some additional plugins for their monitoring platform.

Icinga Exchange

Icinga create Icinga Exchange, this website is the new Monitoring Exchange platform.

On this website you can :

  • store plugins
  • rate projects/plugins
  • synchronize projects from GitHub

There is a detailed FAQ to help you to use this platform.

I like this approach but it could be a nightmare like Nagios Exchange.

Nagios Exchange

Nagios create Nagios Exchange, this website allow you to hosts Nagios Addons.

On this website you can:

  • store plugins
  • rate projects/plugins
  • store other addons like monitoring dashboard, icons, …

This site is very old and in my opinion a lot of plugins need to be rewritten.

Centreon plugins

Since last year Centreon works on One plugin to rule them all , this system must replace the former Centreon plugins.

One plugin to monitoring with thousand of checks, it’s a good idea but is it maintainable easier ? I can’t give you the answer.

You could find all available checks on project page

Shinken.io

Shinken.io is a platform which provides packs, modules for Shinken.

Packs are a small subset of configuration files, templates or pictures about a subject, like Linux or windows. Some packs provide plugins but not all.

You could install and search packs and modules through a CLI (shinken-cli). This system is limited to Shinken.

If you want to hae more information about shinken packs you could read its documentation.

I like this method because there is a CLI.

Thanks to Jean Gabès for his feedback.

GitHub

Yes really sometime you could find some plugins on GitHub.

My opinion

The goal of those platforms is good, but it’s really difficult to manage and to track bad plugins. Of course you could leave a comment to say “it doesn’t works for me” but I think we could could make it better.

Indeed if we could have some guys who could:

  • validate plugins and documentation for each plugins
  • help some people who pushed bad plugins to fix issues on their plugins
  • make some cleanup for avoid duplication

It’s a hard work and I think we need more than one guy for those kind of task.

I remember few years ago, when I had to download plugins from nagios exchange and take some time to fix issues on downloaded plugins …

The end

I hope you’ll enjoy my article.

Feel free to contact me if I forgot to quote a place where you could find additional monitoring plugins.

All plugins found on those platforms could be used with those monitoring engine: Shinken, Centreon, Icinga, Naemon, Nagios, …

Remember than you need to verify if the plugin works before deploy it on your production platform.

While Nagios® make some stupid things, in our case the Nagios Open Software License Version 1.3 for NPCA, I think it’s really the time to say good bye to some Nagios® products such as Nagios core, NSCA, NDO.

I’m sure you don’t know if you have to use nagios plugins or monitoring plugins. Personally I think it’s a nightmare for packagers and this is negative for open source monitoring.

Nagios® has been a major player in open source monitoring and made good things but projects are struggling to evolve.

During the same time, other projects have emerged and offer more interesting things.

That is why I say that Nagios is not part of the future of supervision, so yes it’s over for Nagios®.

I remember one of my conference and I was trying to pinpoint the supervision and various events that occurred around Nagios®. One person told me that it was sad, certainly but it is the reality.

While Nagios forks have emerged, other projects such as ELK (ElasticSearch Logstash Kibana), Sensu, Check my Website, Graphite, Packetbeat and so on are able to respond to certain monitoring needs.

With software like ELK stack, we are able to easily transform log lines into metrics it’s a new way to monitor. A new day has come and we see other possibilities for monitoring.

I’m using ELK to monitor the load of my proxies, I’ll write an article on this subject to show you how I did it.

Imagine a software than monitor your website from many sources or countries and allows you to show their status in your monitoring interface. It’s now possible with Check my Website, a software than allow you to monitor and improve your website.

Did you try to monitor your MySQL or PostgreSQL databases with Nagios ? I think this experience was painful since I discovered packetbeat. Packetbeat is an Open Source application monitoring & packet tracing system and it allows you to easily monitor your MySQL or PostgreSQL databases but not only that. Personally I monitor my monitoring databases with Packetbeat, I know it’s a young project but I think we could trust it.

After thoses examples we could say than open source monitoring evolves and people need to change their mind and accept than Nagios® is over.

I’ll not surprised to see a monitoring platform with:

For me it’s a new path for monitoring, a lot of amazing things could be done with a lot of software. As I said in my talk at LSM 2014 in Montpellier (France), for me the ideal monitoring platform is modular. So why not think in this way and build your monitoring platform like you build a house or anything else with your LEGO®.

I hope you’ll enjoy this new era for open source monitoring and share your opinion about it.

It’s not very easy to see your /var/log/messages when your poller receive a lot of check results and that’s why I wrote this post. This post only concern NSCA server and not the client.

The latest stable version of NSCA (2.7.2) doesn’t have syslog facility parameter. Syslog facility is implemented in the 2.9 release but it’s not yet stable, so I suggest you to use the 2.7.2 release.

Okay but what should we do to have syslog facility in the 2.7.2 release ?

You should apply all patches in the project page on SourceForge.

After applied these modifications, you could update your version by using the update_version script (provided on NSCA tarball) like in the following example:

1
./update_version 2.7.2-patched-by-you
Note: If you didn’t set a date the date of the day will be used.

The next step is to compile the new NSCA. Yes I know you need to recompile and reinstall your NSCA servers.

When the new NSCA version is installed you could verify the version with “/usr/bin/nsca —version” command. Example:

1
2
3
4
5
6
7
8
/usr/bin/nsca --version
NSCA - Nagios Service Check Acceptor
Copyright (c) 2000-2007 Ethan Galstad (www.nagios.org)
Version: 2.7.2-patched-by-you
Last Modified: 03-11-2014
License: GPL v2
Encryption Routines: AVAILABLE
TCP Wrappers Available

Great !!! We have the new version, let’s configure it to use a specific log file.

NSCA configuration

You need to add the following lines in your NSCA configuration file. I my case the configuration file is /etc/nagios/nsca.cfg :

1
2
log_facility=local0
debug=0
Note: It’s strongly recommended to enable debug just during debug session and not in normal mode.

Congrats you have configured your NSCA server, you could go to the next step.

Rsyslog configuration

To allow Rsyslog or its equivalents to manage your log files correctly, you need update your configuration to log NSCA messages in a specific file.

So you need to add the following lines in your rsyslog configuration file. Im my case the configuration file is /etc/rsyslog.conf.

1
local0.*                                          /var/log/nsca
Note: You could add this line at the end of the file.

That’s all for Rsyslog.

After you have made modifications, a restart of nsca and rsyslog is needed. You need to run the following commands to restart them.

1
2
/etc/init.d/rsyslog restart
/etc/init.d/nsca restart

Okay, you could check /var/log/nsca to see NSCA logs. If you don’t see anything in this file a restart of nsca could be performed to create events in log.

I was difficult ? Have fun with your NSCA log file. ;–)

NRPE haven’t got its own log file and writes its events in /var/log/messages. I will say yes why not but it will be a good idea to create a logfile for NRPE. In this post we’ll see how to create a specific log file for NRPE.

In a first time we’ll configure NRPE and in a second time we’ll configure Rsyslog configuration. It’s quite simple because NRPE have syslog facility.

Well stop the theory and let’s go !

NRPE configuration

You need to add the following lines in your NRPE configuration file. I my case the configuration file is /etc/nagios/nrpe.cfg :

1
2
log_facility=local1
debug=0
Note: It’s strongly recommended to enable debug just during debug session and not in normal mode.

Congrats you have configured your NRPE server, you could go to the next step.

Rsyslog configuration

To allow Rsyslog or its equivalents to manage your log files correctly, you need update your configuration to log NRPE messages in a specific file.

So you need to add the following lines in your rsyslog configuration file. Im my case the configuration file is /etc/rsyslog.conf.

1
local1.*                                          /var/log/nrpe
Note: You could add this line at the end of the file.

That’s all for Rsyslog.

After you have made modifications, a restart of nrpe and rsyslog is needed. You need to run the following commands to restart them.

1
2
/etc/init.d/rsyslog restart
/etc/init.d/nrpe restart

Okay, you could check /var/log/nrpe to see NRPE logs. If you don’t see anything in this file a restart of nrpe could be performed to create events in log.

I was difficult ? Have fun with your NRPE log file. ;–)

Last week Centreon 2.5 and centreon broker have been launched. After testing the beta it was time for me to migrate.

On this post I’ll give you some tips to make your migration easier.

First I recommend you to follow the instructions in the release note on centreon documentation.

At this step you have upgraded your central server but what about your pollers ?

We’ll see this point on the next part.

Poller update

Which packages need to be update or installed to complete your migration ?

If you are using centreon broker, you should update the broker modules on pollers. NDO users you could skip this step.

In the 2.5 release, Centreon introduced a new system for SNMP traps, so you need to install it on your pollers and on your central.

Centreon traps require the installation of centreon-perl-libs, new useful perl libraries for Centreon.

If you a re using Centreon Enterprise Server these packages come with the upgrade ofcentreon 2.5.

It’s strongly recommended to update you centreon plugins on your pollers. In this way you will have the same versions on your central and on your pollers.

It’s over ? No we go back on your central server.

Central server

In this new release of Centreon, centcore has changed. Indeed this centreon process is now using centreon perl libraries. After the update of the central, you didn’t restart centcore and it is not running with the new version.

That’s why I recommend you to restart centcore process and push your configuration on your pollers to verify if everything is ok.

Why did I put this step at the end of my article ? It’s just to force you to make the update on your pollers.

I’m testing Centreon 2.5 with Centreon broker since one week. That’s why I decide to write some lines about some interesting features or changes. In this way you will not be surprised when you’ll install this release. Centreon 2.5 release is out, I can publish these lines.

UI Notification

This is a new way to notify Centreon users when there is an alert. I like this feature because it’s not very easy to work with email and no more need of Nagstamon. You could havd sound with it like on Nagstmon but here everything is on Centreon Web interface.

So what is UI notification in Centreon ?

It’s this kind of popup that will be open in Centreon when you have an alert.

I like this feature and will play a lot with it.

Fix of metrics issues from NSClient++

If you are using NSClient++ with Centreon and Centreon Broker you should know there is an issue with disk graph. Indeed if you use alias_disk command (NRPE with NSClient), you may know that disk graph can’t be displayed in Centreon.

With Centreon 2.5 and Centreon Broker 2.6 it’s fixed ! Thanks a lot to Centreon’s developers for this fix, I owe you a beer guys.

Improvement of Logs menu

Last year I’ve wrote an article about logs menu which enable to see the historical of objects in Centreon. But now this menu was improved with colors. I like this menu and use it a lot everyday. I use this menu everyday, now with the color this menu is more fun and more readable.

You could see an example on the following screenshot:

Criticality configuration change

Since Centreon 2.4, you have the possibility to add a criticality level on services and hosts. This feature is only use for displaying in real time monitoring page (Monitoring tab). This option was available in an extra menu. In Centreon 2.5 this extra menu is no longer here. To see or set a criticality level you have to go on categories menu (Configuration>Services>Categories for example).

The categories menu is useful because it allow you to categorize your hosts or services. The categories are very interesting for configuring ACLs for example. Now on categories menu you could configure criticality level (severity parameter). For example you can add a criticality level on a category or just create a criticality level and so on.

You could see some examples on the following screenshots:

Specific menu for contact templates

Since Centreon 2.3 you could use contact templates like for hosts and services. In a first time this feature was just for notifications but since Centreon 2.4 it’s also for ACL. For me this feature is very useful, because when you have to add a lot of IT guys (for example) in Centreon you just have to use a template and it’s done. It’s quick and simple and I like that.

In Centreon 2.3 and 2.4 contact template was in the same menu than “normal” users, now you have a specific menu like for hosts and services. It’s simple and easy to make difference between templates and objects.

You could see it on the next screenshot:

Post restart command

I was very surprised when I’ve seen this menu but it could be interesting. Indeed now when you generate your configuration you run a post generation command. I didn’t use it yet but it could interest me in the futur.

you could configure your post-restart command in poller menu.

I didn’t play with all features in Centreon 2.5 but I hope you will enjoy my post.

Yesterday I wrote a post about centreon widget. Indeed the previous post was about customization to add service latency and execution time. Today we’ll speak about notification in centreon widget.

In my opnion it’s very interesting to have the number of notification for a service in its current state.

I’ve made a patch to add this feature in service monitoring widget. This patch work only with Centreon Broker, feel free to patch it for NDO or IDO.

I like this patch because, you could see your services order by number of notification.

You will find below a screenshot of the patched widget:

You could take this patch on Centreon’s forge:

https://forge.centreon.com/issues/5141

Feel free to give me your feedback. ;–)

See you soon for a new article.

You’re using Centreon widgets but need more information for administrators. For example: service execution time, service latency and so on.

Don’t worry, chuck has thinked about you. Indeed I’ve made a patch for service-monitoring widget which provides service latency and service execution time.

You could take this patch on Centreon’s forge:

https://forge.centreon.com/issues/4615

Feel free to give me your feedback. ;–)

See you soon for a new article.

New year, new blog ?

Yes! But this year, I will write blog post in english. It’s better for me because I could use these articles to help my colleagues.

Why a new blog platform?

My old blog was on Wordpress, but I wanted a “light” and simple system with Bootstrap and without database management system. I want to thanks rustx who tell me a lot of good things about Jekyll and Octopress.

comments powered by Disqus