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.6 – Azure/AWS Monitoring, Dataviz, Configuration, Service Templates

In brief Monitoring of Azure and ASW PaaS objects Use case: You manage an infrastructure on the Azure  and / or AWS Cloud. You want… Read more


Cloud and IT Monitoring

Cloud, just a fad? A fashionable term for many years, the Cloud has become an essential component of any IT infrastructure. The promises are many:… Read more


ServiceNav 4.5 – Dataviz Enhancements, Extended Tag Management, New Plugins

Summary Dataviz – Enhancements New Dataviz enhancements are here! Gauge widget – Minimise mode – 100% use of available space The display of the value… Read more