Monitoring has been part of the IT landscape for a long time and we often forget that deploying a monitoring solution needs to follow precise rules.  Due to the fact that a large number of solutions are proposed in open source, or just because monitoring isn’t always considered to be a full-blown project, many monitoring solution users get bogged down in complex situations when the time comes for deployment. We paid a visit to technical support and, with the Centreon technicians, we have listed the most common errors leading to failing (guaranteed) monitoring implementation projects.

1. Not assigning the correct skills to the project (an intern is more than enough)

Many monitoring projects begin with tests carried out on a solution available in open source. If a monitoring requirement is identified, open source is a way to access a complete solution quickly and free of charge, but also to become part of a community. One thing leading to the next, the test becomes a project which is assigned to a passing intern. Like all projects, the monitoring project scope must be defined and a sufficient number of suitable resources assigned to it. Even if the intern is a genius, alone and without sponsorship, the project will fast become difficult to manage and maintain.

 2. Not getting trained (it’s pointless, this is open source)

The open source universe is well aware of this. There is a real tendency to forget training whenever the use of open source tools is considered.  Is it because the products are free or because of the reputation of a community that users are driven to pose as “self-made-monitoring-pros”?  It will indeed be possible to achieve one’s ends, but it’s such a shame to waste two hours adding a new plugin when you only need a couple of minutes if you had training.  By failing to use all the product’s possibilities, the project can suffer and be deprived of the solution’s full added value.

3. Monitoring everything now (only chickens chicken out…)

There’s an old saying, “don’t bite off more than you can chew”. The power monitoring solutions offer shouldn’t incite you to put the horse before the cart. Going too quickly, too far and too fast can lead to the project being abandoned through lack of financial or human resources. A monitoring project must remain ambitious but be deployed at a suitable rhythm, step by step, to make sure the project succeeds, and to be able to manage the changes.

4. Over-customizing the monitoring solution (because I can…)

One of the strengths of a solution like Centreon is the possibility for its users to customize and code while benefiting from a common base. This openness, which is behind the solution’s success, should not lead to the excessive customization of the solution’s platform. Perfect is the enemy of good… Indeed, here the risk is to wander astray of standards and lose the benefits of standardization and the updates and upgrades proposed by the software company.  Among the direct results of ultra-customization one can note significant migration times, or specific features that aren’t compatible when an upgrade comes along.

5. Keeping it to yourself (I don’t talk to strangers)

The open source community is a bottomless source of information and shared experiences which it would be a shame to deprive yourselves of.  Monitoring is a constantly changing trade, and even more so for the past few years with the DevOps trend that is driving in-depth changes in IT practices. Discussing with the software company and the community is an essential aspect of pulling off a successful monitoring project

6. Duplicating the previous project (which is 10 years old, but it worked)

Duplicating the previous project using a different tool risks at best reproducing the same mistakes, and at the worst failing to complete the project’s deployment. Processes are also defined according to the tool that was selected. Changing tools is also an opportunity to take a good look at monitoring practices and improve their performances. Rethinking your processes makes it possible to improve them, but also to benefit from the power and features of the new tool.

7. Oversizing the project (because I want to)

With ever more powerful and automated monitoring tools, we can be tempted to see things big. So big that the monitoring project finishes up by being oversized…. Of course, that way you can give yourself a thrill, but it won’t meet the expectations of the IT and business users …

8. Collecting data without knowing what to do with it (I won’t need to look for what I’ve already got)

Data has become the be all and end all for business and for Information Systems. It’s important to collect data to then be able to analyze it, correlate it, and produce the right indicators, for the right people at the right place. We can therefore be tempted to collect everything we can, without thinking and anticipating the future uses for the data. Too much data kills the data! It’s important to anticipate what use will be made of the data, so that we only store what’s needed. We can eventually define a retention period for reporting, log or digital data for performance charts.

9. Only thinking technical (what could marketing possibly understand about IT?)

As information system performance increasingly impacts business, monitoring now has an essential role in business IT systems.  IT quality of service and availability have a direct impact on business, and business teams need access to their own indicators about the performance levels of their tools.

10. Only trust yourself (the software company? What software company?)

software companies develop turnkey solutions, tested by different users and deployed in various contexts. They have an overall vision of the possibilities of their tools and they master the core business.  They have developed genuine expertise in their field, resulting from the experience of all their clients. Expertise they really want to share with all their clients.

Also read:

Tags :