I’ve been to Portland for Monitorama this year and it was really interesting. Do you believe that, an entire event only for Monitoring, that’s awesome ! The conferences were very interesting and the level of the talks was also good.

Few weeks after this trip I was always thinking about this experience. Obviously I came back in France with much ideas. But not only that, I asked myself why there is not a lot of talks, conferences regarding monitoring in France.

Indeed we have plenty of open source events but what’s the place of open source monitoring in those events ?

That’s a good question dude !

Not enough speakers or talks ?

I know many people from french open source monitoring community who are used to answer to the call for participation.

So I guess the issue is not there. I think we have some good speaker in France even in Monitoring.

Talks are not relevant ?

Maybe the quality of talks are not enough relevant for those kind of events ? Ok maybe once but all the time ?? I can’t believe that, do you ?

Talks are product oriented ?

I had this kind of feedback few years ago. Well I think that was fair enough. Some friend of mine had the same feedback.

But when you see some talks regarding Docker, OpenStack, …

Those talks are product oriented, right ?

We all know the feedback “product oriented” was bullshit !! I’m really disappointed to see some people who give those kind of feedback and they can’t respect their “rules”.

We are not in the same “club” ?!

Where is the problem then ?

Well I guess the organizers of French events are not interested by monitoring. I don’t blame the events organizer because I know they need to have a lot of people and so on.

Monitoring is maybe less attractive than the other subjects.

Monitoring is often in “Devops” (buzzword) or “Sysadmin” tracks. And you could have plenty of subjects also in those tracks. How to deal with that case ?

Maybe organizers prefer talks about Cloud, Devops, Containers, Virtualization and stuff like that(other buzzwords). I’m pretty sure than less than 50% of projects/software in those topics are not in production.

Maybe that’s why there is no place for monitoring ! Maybe in their magic (or bullshit) topics, the monitoring is included by a brand new thing which is also magic.

Ok ok I’m done with trolls. (chuckles) Maybe not ;–)

In the real world !

In the “real world” when something goes wrong, people ask if the monitoring system detects the issue. So that means monitoring is very important for developers, ops, manager, …

Well that means monitoring is also important and even more important than standard services. You’re okay with that?

We’re talking about real things here and not about bullshit.

Come on ! We’re talking about production here !! I see the cloud everywhere !! please stop it !!

Enough is enough !!

I’ve got a point here isn’t ?

My feedback

During my trip in Portland I saw the difference between US and Europe regarding monitoring. US folks are thinking different and I found that very interesting. They have so many ways to monitor I was very happy to be there and to exchange with some of them.

I think some people in Europe and of course in France do the same but it’s a bit sad if they can’t share their experience of this subject during events.

This could push people to think that we are not good in this subject, I’m pretty sure that’s wrong, we have a lot of talented people in France !

Few weeks before my trip in Portland I made a talk at the first edition of Paris monitoring meetup and people were happy because “I think different”. I was very happy to share some information.

Few weeks after this trip, my company hosted the Paris monitoring meetup, a colleague made a talk regarding anomaly detection, a lot of people were interested. People were very happy to be there and to see there are some people who make different monitoring and they do interesting things like anomaly detection and prediction.

I think there are such good things regarding monitoring in France but unfortunately we don’t have a spot in big open source events. That’s very sad because monitoring is very important for each people.

We don’t have those issues with meetups. I guess it’s a positive thing.

The solution ?

Make a talk with a lot of buzzwords like devops, cloud, containers, micro services ?

Hell no ! Stop that bullshit !

Make talks in events in other countries because we can’t do it in France ?

I’m sure than all of you will not agree with me. It’s not so easy to make a talk in another country. It could be expensive if you don’t have a sponsor, you need to speak english or other language, …

The solution is not a solution and not even a workaround, it’s a kind of new path.

Why not create a kind of comitee to maintain a monitoring track during the big or small events ?

I think we should talk together and find a solution to allow us to have at least one or two talks regarding monitoring in France during some big events ?

It’s an open question, I’m available to discuss about that. I didn’t make this article to say open source events sucks in France but just for reconsider the place of monitoring in those events.

Few weeks ago I had this discussion with Olivier Jan. I think than Olivier have a pretty good idea on this subject.

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 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.


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:

./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:

/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 :

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.

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.

/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 :

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.

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.

/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:


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:


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