Introduction to syslog collector
The goal of the Syslog Collector
architecture designed by LUTEUS is to provide a scalable solution for
handling huge quantities of syslog messages and to help
administrators to filter and browse them. Alarms can be sent on critical
or severe messages.With the syslog collector agent you can collect syslog
messages, filter them in real time, browse and search log files.
With the syslog manager provided in LoriotPro you can
apply filters rules on syslog agents from a single
location.
The Syslog system provides the
transport and storage mechanisms for event notification messages, in the
form of Logs. Syslog is a de-facto standard defined by
RFC3164 for logging system events. It was commonly and initially used by
Unix systems (The unix syslog daemon syslogd), later on by network devices
(router syslog, switch syslog, firewall syslog). It will be very efficient
in a Cisco device architecture for the collection of PIX syslog and Cisco
syslog generated by routers and switches)
The product has been designed based on the following
issues:
Overview of the syslog console and the syslog file
browser
![syslog collector](SyslogMain.gif)
Syslog collector architecture description
The architecture is built around two components:
the syslog agents and the syslog manager.
The syslog manager is a program running exclusively on
our LoriotPro monitoring solution.
Syslog messages are collected by syslog
agents called, in our terminology Syslog Collector Agents.
Syslog agents are designed to collect a large throughput of Syslog
messages and to process them according to advanced filtering rules.
Filtered messages can then be displayed on a viewer, the agent taking on
the role of a simple Syslog server. Messages can be stored locally in
files or forwarded to the central management system. Critical messages can
be sent to the centralized management system either as LoriotPro
proprietary-formatted event messages or as Syslog-formatted messages. Syslog
agents can be cascaded to build a hierarchical architecture of
Syslog message relays.
Syslog agents can be used as a standalone solution and
act as a Syslog server or Syslog relay. Our LoriotPro NMS and the Syslog
manager are not necessary in this case. Syslog filtering
rules can be defined from the syslog agent GUI
and applied. Actions taken on conditions defined in the syslog filtering
rules can be displayed on a viewer, stored in files or forwarded to
another Syslog server.
The Syslog Collector Manager is
responsible for the management of the agents from a centralized location.
Syslog filtering rules are defined on the manager and pushed to the agent.
The manager is also able to retrieve a filter rule previously loaded onto
an agent. Syslog filtering rules are stored in local text-only files.
The syslog agent manager is also able to upload Syslog
files previously stored on the agent. The syslog files can be compressed
on the fly during uploading, sparing precious bandwidth of WAN links or
on-demand links. The manager works on top of our LoriotPro NMS as a
Plug-In Service.
As we have stated previously, the messages sent by the Syslog Collector
Agents can be in the LoriotPro event format. The LoriotPro Event Manager
receives them and processes them. They are first displayed in the Event
Log window and if necessary, they trigger actions based on predefined
conditions. Actions can send messages, start programs, play sounds, etc.
A simple view of the concept behind our solutions is
presented below.
![Syslog collector concept](SyslogColv2.gif)
Devices with Syslog capabilities (routers, Unix
systems, etc.) are configured to send their Syslog messages to the closest
Syslog Collector Agent. The syslog agent filters syslog
messages and forwards them either to the LoriotPro console or to a Syslog
server. LoriotPro is necessary in order to have centralized
management of filter rules. Filter rules are pushed to the agent after
authentication.
The hierarchical and/or distributed concept of agents
allows the administrator to design an architecture that fits their
topological and network constraints. As in our example below with a
two-level hierarchy of agents, Syslog messages are collected for a
predefined area on the second level agents, then the most critical ones
are forwarded to the first level agent for each country and finally they
are forwarded to the central Syslog Server or LoriotPro Manager. Traffic
is optimized and adapted to the network topology, WAN bandwidth is
preserved and unnecessary messages having local significance are not
forwarded to upper levels but stored locally.