Monitoring "a la carte" - TimeMap flexible architecture

"you cannot deliver a service if you cannot monitor it". Creating a monitoring system may be a tough job, and you may end into the need to monitor your monitoring system itself. So we aksed ourselves "how can we monitor some fundamental network performance parameters, like latency and jitter, we decided to play with a completely different approach: create an architecture where we really minimise the need to develop new tools or write new software, and just use existing generic building blocks instead, with minimal "glue" to turn them into a specific system. TimeMap was created as an easy to setup environment where most of the building blocks were already existing tools, and a bit of glue. This simple but efficient architecture has nearly zero maintenance, because its tool integrated into it already has its own maintenance, and in case self-monitoring system, etc. It did not took long to realise that the TimeMap monitoring architecture can indeed monitor anything which can provide some data by answering to any kind of query via some protocol. We also applied the architecture to Time and Frequency distributions networks, where even most of the devices and the parameters we need to monitor are often developed by the users themselves or by some very specialised company developing the equipment together with the users. The same building blocks used for latency and jitter were quickly re-used for any other feature an OTFN has. But indeed now users are approaching the monitoring of anything they need to keep under control... for example the clocks drifts between distant locations when it comes to put in synch different observing facilities. And with close to zero maintenance cost, because it integrated tool is already maintained, as we said. An approach which likely can find many cases to be applied.

Tema: Sys.trek

Radionica