bc_thesis/en/chap01.tex

\chapter{Motivation}\label{ch:motivation}

%First, we need to further specify, what Birdvisu should be. This section
%describes what is the missing project and why such project would be useful.

In this chapter we explore existing solutions for visualising and monitoring
network systems and describe the requirements of network administrators. From
this we derive a set of properties Birdvisu should fulfil.

\section{Existing approaches to network monitoring}

Several approaches to network monitoring and status visalisation already exist.
These can be approximately split into several types: visualisation of existing
data, traffic visualisation, host monitoring systems and integrated system
management platforms. We \X{uuuuuuuuuu}.

\subsection{Visualisation of existing data}

Tools in this category do not collect any data on their own, rather only
focusing on visualising data from other tools. These projects are often small,
can be easy to run and allow visualisation of various data, but they require
other infrastructure to provide the data. For example, the Network
Weathermap\cite{weathermap} project can be used to provide overview based on
data in Cacti or other tools. Grafana\cite{grafana} provides many different
methods of visualising data from various databases.

This does not seem to be usable for visualising OSPF state, because we are not
aware of any collectors of OSPF state data.

\subsection{Traffic visualisation}

Various software packages can collect and graph utilisation of network links.
This often provides information about link state, but requires collection of
data on all hosts. Also, in some cases, this might not provide accurate data of
the system state, as we will see in section~\ref{s:net-broken}.

These projects usually store a time series of utilisation and therefore need to
be deployed on some central server as long-running services.

Examples of this approach include Cacti\cite{cacti} and Munin\cite{munin}.
Although both mentioned projects can graph other data, plugins for data
collection are available, so this differentiates them from the previous group.

\subsection{Host monitoring systems}

Projects in tis category do not necessarily consider the whole network system,
but check state of individual hosts. It is possible for them to run locally, as
is the case for Plotnetcfg\cite{plotnetcfg}, or check the host over the network
(CaLStats\cite{calstats}, Icinga\cite{icinga}), but they do not provide
overall picture. The capabilities of these tools also differ, from just
checking reachability (CaLStats) to being able to retreive various details from
the hosts (Icinga, plotnetcfg).

This approach can also miss some issues with the system, as described in the
section~\ref{s:net-broken}.

\subsection{Integrated system management platforms}

Some network administrators have created platforms for managing the hosts
across the network system. These systems usually know various aspects of the
system and may provide features like configuration generation or topology
visualisation\cite{nodewatcher-paper}. However, many of these are tailored for
the specific system and are therefore not reusable in other environments.

Also, since large number of people need to access such platforms, they are
usually server based with web interface\cite{nodewatcher-paper}.

\subsection{Topolograph}

We are aware of the only project that would allow visualisation of OSPF
topology, Topolograph\cite{topolograph}. While it does not collect its own
data, its companion project, Ospfwatcher\cite{ospfwatcher}, is able to retrieve
current topology data from a Quagga\cite{quagga} routing daemon. The deployment
involves setting up Logstash\cite{logstash}, so this is only suitable to be run
on a server.

Also, we find the interface of Topolograph impractical to use in Firefox 116.0b2.

\subsection{Summary of existing tools}

\X{table}

\section{Goals of Birdvisu}

\begin{itemize}
\item\X{TODO}
\end{itemize}