G3 System – Reporter

CESNET technical report number 14/2007
also available in PDF, PostScript, and XML formats.

Tom Košňar
3.12.2007

Keywords: network infrastructure monitoring, SNMP, user interface

1   Abstract

The G3 system is a network infrastructure monitoring system based on standard measurement methods (mainly SNMP) with non-standard measurement timing, specific data processing and hopefully advanced user interface. Additional experimental module was developed and added to G3 system in 2007 - reporter. This module aims at generating various hierarchical reports following configurations given by network administrators.

2   Introduction

G3 system is designed to provide large scale and continuous network infrastructure monitoring. Measurement mechanisms and data processing are able to keep and visualise some level of network dynamics. Data processing mechanisms ensure automated adaptability on real device reconfigurations and provide continuous and flexible mapping between technological (given by SNMP) and logical (human point of view) structure of measured devices. User interface is able (and does by default) to aggregate measured data while retrieving it from storage. Therefore the whole user interface is strictly designed as interactive.

Interactive mode of the user interface does not always meet expectations of all user groups. Administrators usually appreciate interactive mode - they need to have both overall view as well as detailed view on particular set of parameters or network components and they generally want to have absolute governance of such monitoring systems. On the other hand end users don't expect such complexity (and we also cannot expect high level skills and experience in network structure and network monitoring systems there). End users want to be sure that services they are using operate at expected level or are interested in utilisation of corresponding resources. They even don't require real real-time information, they accept semi-real time information, but what they require is easy and simple navigation. It means that not only clear and understandable information structure must be generated, but also the content must meet the level at which users understand what happened.

After analysing potential requirements on reports, expected variety of their structure, manners of visualisation (graphical vs. textual at least) and content on one side and G3 system capabilities on the other side, we decided to design and develop external stand-alone tool - reporter.

3   Reporter Description

There are two basic groups of information reporter relies on.

3.1   G3 System Saved Sessions

The first informational resource consists of saved configurations (sets of filtering conditions beside others) stored inside the G3 system as so called "saved sessions". G3 user interface was extended and users can save current state of their sessions. Stored data also contain filtering conditions (interface IP addresses, interface description substrings for example). It enables that desired objects (all network interfaces related to some service for example) are exactly selected when "saved session" is loaded back. It is shown in Figure. User sets filtering conditions and checks whether results correspond with his expectations. Then "saves session" giving a name to it. It means that filtering conditions (and other parameters) are stored for further use and everything is identified by appropriate name.

[Figure]

Figure 1: Creating "saved session" in G3 user interface.

3.2   Reporter Configuration

Second resource consists of per report configurations which are kept outside the G3 system configuration and storage structure. These configurations define the content of each report - saved sessions filtering rules, corresponding locations lists and optional background image parameters (for generating favourite click-able maps), parameters to show and required visualisation style.

Notice: This distributed configuration (and different manners of its administration) also naturally separates roles of human authorities. Working with G3 user interface and saving appropriate sessions means (in conjunction with reporter) to define WHAT are the real subjects (interface with description X, interface with configured IP-Y) that shall be reported as something (path or lines between City-A and City-B). This process corresponds with "SS" mark and blue arrows in reporter function chart - Figure. On the other hand administering specific reporter configurations means to define HOW they shall be reported. It illustrates cyan arrow marked as "RC" in reporter function chart - Figure.

Reporter is (from the G3 system point of view) something like "e-client" - it handles G3 user interface (which has been extended of course) in similar way as ordinary user does. Main difference is in calling G3 user interface program - ordinary user does it through WWW interface and CGI, while reporter does it directly. First version of this tool is focusing network line/path perspective (i.e. interface objects monitored), but is capable to visualise other object types in some way too.

[Figure]

Figure 2: G3 system reporter - function chart.

3.3   G3 System Extension

The G3 user interface was extended to support some new parameters on input. Some key functions of the user interface were extended to support new functionality. New output formats for specific data structure exchange were added. Module for visualisation is now able to build statically referenced output data in a single step.

New parameters and tied functions may cause (beside others) that extended user interface can store reported data outside the G3 system storage area. Such requests have to be operated carefully because they can affect at least data integrity, but may also have some security consequences. Therefore G3 user interface provides checks how it was called and strictly rejects all these special requests when operating in interactive mode through CGI.

3.4   Reporter Tasks

There are currently five basic groups of tasks that reporter is able to perform:

3.4.1   Objects count checks

Reporter relies on filtering conditions saved through G3 system user interface. There is always a possibility that network administrators may change real network configuration (some descriptive values or addressing for example) during everyday administration. Such changes may cause either loss of objects matching appropriate filtering rules or raising their number. Reporter is able to check objects count found against required value when configured in reporter configuration files.

3.4.2   Line/path utilisation

This is specific task - the only one tied together with particular object type and parameters (interfaces, interface speeds and volume of data transfered). This was initially the basic task for which the first versions of reporter were developed. However utilisation must work for specific network configurations (multi line environment in both channel or backup mode). Therefore utilisation computing was kept as a stand-alone task in next versions of the reporter.

3.4.3   Statistics computing

There are many other reports beside line utilisation that may be useful for different groups of users. Typically "network health" and similar statistics generally based on various types of errors are requested. But in hybrid CESNET2 network there are also requests for things like optical receive and transmit power as well as for FEC (Forward Error Correction) statistics at DWDM devices for example. This stand-alone reporter task is basically able to compute statistics of any parameter that G3 system measures.

3.4.4   Static reports generation

The essential part from user perspective. Reporter handles user interface of the G3 system in the same way as any user would in interactive mode. There is adequate number of visualisation parameters that can be set up in reporter configuration files to generate required report.

3.4.5   Static indexes generation

Index may be an entry point for navigation within a set of static reports generated according a single configuration. It can also be summary report containing computed statistics only. Typically it is both - the top of static report tree giving computed statistics overview.

Any of the basic tasks described above has its own time scenario (time step of processing, period of results validity). There is also no necessity to run them all. Each task is controlled by independent set of parameters and there is full freedom for users what to run - everything is given by report configuration. Reporter can be run once or act as daemon. Reporter instance may operate with one or more report configuration files or configuration directories. This is given by command line parameters.

3.5   Reporter Run Step by Step

In next paragraphs we try to go step by step through one run of the reporter to describe how everything works together.

3.5.1   Reporter Specific Configuration File

Reporter reads specific report configuration file containing all information needed to generate requested report (red arrow, number 1 in Figure). Configurations are stored outside G3 system storage. Reporter configuration files are textual (perl HASH reference syntax). Each report configuration file may import content of other configuration file and override just a small part of it. This is convenient in cases when multiple reports with different informational value shall be built over the same set of objects - network utilisation plus network health or other detailed statistics for example. Each of them may be built for different user groups or for different purposes but they can share major part of basic configuration.

3.5.2   Reporter Last Run Information

Reporter reads (when exists) aggregated information about objects and their states stored during its last (i.e. previous) run (rosewood colour arrow, number 2 in Figure). Data also contain information about "lost" (no longer valid) objects to keep the whole history. Also this information is stored outside G3 system storage.

3.5.3   Retrieving G3 Saved Sessions

Reporter calls directly G3 user interface program. Reporter identifies itself as a G3 user (whose stored sessions shall be used) and pushes parameters to retrieve complete list of stored sessions (brown arrows, number 4 in Figure).

3.5.4   Preparing G3 Saved Session

Reporter checks each retrieved session name against function stored in report configuration file and keeps all matching names for further processing. Session name is also parsed to get names of locations it points to (line end points for example).

3.5.5   Preparing Object Identifiers

Reporter takes each session name (one by one), calls directly G3 user interface program and forces it to "virtually load" appropriate saved session as ordinary user would. User interface program is also forced to return identifiers of retrieved objects (internal G3 objects descriptive structures - instance identification and corresponding storage identifiers). Retrieved object count is checked against configured count during this processing phase (when requested by report configuration). It usually means that we want to be sure that stored session points to exact number of interfaces (e.g. both ends of line or one side of multi line path etc.).

3.5.6   Statistics Computing

Having internal G3 object identifiers reporter is able (when requested by report configuration) to compute various statistics of requested parameters (which and how is also given by report configuration). Subjects of computation may be for example short-term line utilisation, line loads, error rates, packet rates, multicast rates, average packet lengths and many others. There is a configuration parameter (on link basis) causing multiple interfaces to be understood either as multi line channel or as backing up each other. These statistics are built directly with the help of G3 system libraries. Results of this process are kept to be further stored as reporter aggregated information for next run and may be also optionally used as data base for generating report index file during this run.

3.5.7   Static Report Generation

After finishing short-term checks and statistical computing reporter calls (when configured) G3 user interface program directly again to generate static report for each saved session. Reporter pushes to G3 user interface program additional information about paths, time periods, G3 object tree structure and others which is retrieved from report configuration and which override parameters stored with the session (brown arrows, number 5 in Figure).

3.5.8   Index File Generation

Reporter generates index file (olive arrow, number 6 in Figure) on the top of all generated static reports (when needed and requested of course - by report configuration content). Index may consist of both graphical and textual part. Graphical part (map) relies on specific stand-alone configuration containing path to background image file and list of all locations (including image coordinates) available for drawing something from or to. Arrows which are drawn can be coloured according to configured scheme - there may be different one for network health map and different for network load map for example. Arrows itself are drawn as active areas referring to corresponding static report. Textual part contains one or more tables with short-term computed statistics. Object descriptions are links referring to static reports too.

At the end of this step all generated reports (static reports and index file) are ready to be retrieved through HTTP server - dark yellow arrows, marked as "RR" in Figure.

3.5.9   Saving Actual Run Information

Finally reporter writes aggregated information about actual run for next use (rosewood arrow, number 7 in Figure). Then it sleeps till next run (when called as daemon) or processes next report configuration file or finishes.

3.6   Reporter output examples

First example - most common type is network utilisation report. There is index of reports example with active network map in Figure and aggregated path report in Figure. Static report shown in Figure corresponds with session saved according to Figure. Real network path consists of two separate lines which have basically character of multi-channel. Overall utilisation is computed according to configuration section example in Figure (multi-channel is default). Static reports can be generated either as aggregated (this example Figure) or separated (each line has its own graph). The only parameter making the difference is shown in Figure - requested G3 navigation tree template identifier that is pushed beside other parameters to G3 user interface.

[Figure]

Figure 3: Network utilisation - index example (truncated). (large image)

[Figure]

Figure 4: Network utilisation - static report example. (large image)

[Figure]

Figure 5: Network utilisation configuration section example - line/path utilisation. (large image)

[Figure]

Figure 6: Configuration section example - forcing aggregated. (large image)

Second example is rather detailed view on a part of E2E (End-to-End) service. Figure shows index and report is in Figure. Network utilisation example and this one are in principle the same. They differ in number of items shown in index - as they are configured in report configuration file. Also content of static reports differs. This is caused by different G3 view referenced in report configuration (views must exists within G3 system). Last difference is in active map background image and corresponding configuration (also referenced in report configuration). Relevant configuration section examples are in Figure and Figure.

[Figure]

Figure 7: E2E service - index example. (large image)

[Figure]

Figure 8: E2E service - static report example (truncated). (large image)

[Figure]

Figure 9: E2E service configuration section example - statistics to compute. (large image)

[Figure]

Figure 10: E2E service configuration section example - index configuration. (large image)

4   Conclusion

G3 system reporter is the first step in giving periodical information from G3 system outside the CESNET2 network administrators community. It is focusing network interfaces and corresponding information (lines, paths) in its first version. We expect to extend it in the future according to end users feedback and their requirements.

další weby:fond rozvojemetacentrumCzechLightpřenosyvideoservereduroameduID.cz