Collector

<< Click to Display Table of Contents >>

Navigation:  Working with EventSentry >

Collector

The EventSentry Collector, introduced in version 3.2, enables a 3-tier architecture between an action (e.g. database, email server) and the EventSentry agents. When enabled, the collector will provide functionality similar to a proxy server (although with significantly more functionality), and communicate with a support EventSentry action on behalf of a remote agent. The collector supports compression as well as secure TLS encryption.

 

The collector can be enabled during the installation (default behavior), or configured after an installation or upgrade. An action will be routed through a collector under the following circumstances:

 

A collector is configured (and running) in the "Collector" settings

The action can be routed through a collector (see "Supported Actions") and configured to use a collector

 

info_32

It is possible and supported to only route some actions through a collector but configure other actions for direct agent-to-action communication.

 

Supported Platforms

The collector is available as a 64-bit (x64) and 32-bit (x86) binary. The 64-bit binary is recommended and installed by default on 64-bit Operating Systems.

 

Supported Actions

The following actions can routed through a collector:

 

Database

Email (SMTP)

Syslog

File

 

All other actions either communicate directly with the remote action (e.g. HTTP action) or execute locally (e.g. process action).

 

Supported Components

Only the monitoring agents can currently utilize the collector. All other components still communicate directly with their respective actions:

 

Heartbeat Service

Network Services

Web Reports

Database Import Utility

 

Advantages

Utilizing the collector has the following benefits:

 

1.Communication between the agents and the collector can be encrypted for increased privacy, useful for hosts transmitting data over an insecure network (e.g. laptops)

2.Communication between the agents and the collector can be compressed to reduce bandwidth consumption

3.Security can be increased by restricting actions, such as a database or email server, to only allow access by the collector instead of all agents

4.Database: All data is cached by the agent when the collector is temporarily unavailable. Only event log data is cached when not using a collector while the database is unavailable

5.Database: Although automatically managed by the EventSentry agents, ODBC drivers do not need to be installed on the agents

6.Database: The database login credentials do not need to be transmitted to the agents since they are not directly connecting to the database

7.Agent Management: The collector can automatically transmit configuration and agent updates to remote agents

 

Disadvantages

In some cases the traditional method where agents communicate directly with an action may be preferable. The collector provides little benefit in the following scenarios:

 

1.The agents have a direct connection with the database or email server

2.Data sent from the agent to the action is already transmitted over a secure network

3.Data sent from the agent to the action is already transmitted over a fast network where compression provides little or no benefit

4.The action (e.g. database) is reliable and has little or no downtime

5.Installing and/or maintaining one or more collectors is not desirable

 

Redundancy

Since the collector is potential single point of failure (SPOF), EventSentry offers the following features to ensure maximum availability:

 

An agent stores all data in a persistent local cache if it cannot reach the collector. Data is resubmitted as soon as the collector is reachable.

The collector stores all data in a persistent cache if it cannot reach an action (e.g. database, email server).

Multiple collectors can be configured for additional redundancy.

 

info_32

Cached data is usually stored in a non-persistent cache first but flushed to a persistent cache if the service (agent or collector) is stopped.

 

Performance

The collector service is designed to support both a large number of clients as well as large amounts of data in real time. For database actions, the collector uses multiple (~20) concurrent db connections to ensure a high throughput. The current status of the collector can be reviewed in the web reports under the Tools/Maintenance menu section ("Collector Status") if "Collect statistics" is enabled.