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
|
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
The following components can currently utilize the collector, all other components still communicate directly with their respective actions:
•Agents
•Heartbeat Service
•Network Services
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 entire installation only spans a single host
2.The agents have a direct connection with the database or email server
3.Data sent from the agent to the action is already transmitted over a secure network
4.Data sent from the agent to the action is already transmitted over a fast network where compression provides little or no benefit
5.The action (e.g. database) is reliable and has little or no downtime
6.Installing and/or maintaining one or more collectors is not desirable
Since the collector is potential single point of failure (SPOF), EventSentry offers the following features to ensure maximum availability:
•Agent store all data in a persistent local cache if they cannot reach the collector. Data is resubmitted as soon as the collector is reachable.
•The collector caches all data if it cannot reach an action (e.g. database, email server) in memory and is flushed to disk when the collector service is stopped. Cached data is paged to temp files if the in-memory cache (aka queue) exceeds either a hard limit or is unusually high based on previous usage.
The collector logs event id 210 when paging starts followed by event 214 when paging is disabled. The collector requires at least 500Mb of free disk space on the %SYSTEMROOT% drive in order to support disk paging.
•Multiple collectors can be configured for additional redundancy.
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.
