Monitoring: A Suggested Roadmap for Choosing the Right Tool – Part 1

Back to news

The Problem

The primary purpose of a monitoring solution is to collect data over a wide area, to correlate, analyze, alert and to produce information for the purpose of communicating/ informing to a fairly broad audience, ranging from technical experts to company decision-makers.

Historically, different monitoring technologies have been deployed, dependent on the needs of the network, system and application teams, resulting in multiple, isolated information silos that are unable to communicate with each other, and to holistically control the availability and performance of IT services consumed by end-users. In response to this, some architectures attempt to bring these all together in a “Manager of Managers” approach; often expensive, and adding complexity overall.

Finally, let us remember that to give a full picture, a monitoring solution may need to integrate with the other software components engaged in delivering IT services: ticket management, environment documentation (CMDB, Configuration Management Data Base), centralised analytic reporting. And what about providers? They may comprise multiple niche players, with sometimes very different approaches to data collection and analysis. It is therefore sometimes difficult to choose between Open Source and commercial offers, Application Performance Management, SIEM systems, user scenario simulators…


In order to maximize the chances of success of a monitoring refresh project, and minimize costs, it is strongly suggested to create a monitoring roadmap, based on the following tenents:

A comprehensive audit of the processes, tools and teams charged with their configuration and use.

This audit provides an analysis of the existing software components: number, functionality, usage, configuration status, pros and cons experienced by users in their configuration and use, actual cost of use and maintenance of the software, quality of support, status of maintenance contracts, market position of the vendor, ability to integrate, etc.

Define the goal to be achieved, always accounting for the interdependent needs of tools, processes, and teams. The goal is described in terms of date, architecture, organization. ITIL best practice is a useful in this regard. It is crucial to identify monitoring KPIs. Finally, this goal must take into account the future of the IT infrastructure: on premise, private cloud, public cloud outsourcing, co-management, in -house? The teams in charge of the availability, performance and migration of information systems must be included at the heart of the project, both on the development side and on the operational / production side.

In our next article we will see how to choose, using a real example, the right monitoring tools.

UK ServiceNav Product Development Manager; my priority is to be needful of the particular requirements of all ‘English-speaking’ markets where ServiceNav is sold. I have over 20 years experience of the IT monitoring field - covering a wide variety of products and technologies.

More recent posts from the Servicenav team


ServiceNav 4.8 – Graph widget improvements, new icons, service templates

Graph Widget – Improvements Timeline synchronisation The timelines of the graphs displayed on the same dashboard are now synchronized. This feature makes it easier to… Read more


Monitoring VPN and VDI with ServiceNav

 What are VPNs & VDIs? In brief A virtual private network (VPN) extends a private network over a public network or the Internet. It allows… Read more


Monitoring in a time of Climate Change

F.MATTES – Plateau de la Molière – Massif du Vercors At a time when global climate change is visible on a daily basis , the… Read more