Table of Contents
Advertisement
Sentinel treats both "services" and "applications" as abstract service end points that can readily
respond to asynchronous events. Services are "objects" that do not need to understand protocols or
how messages get routed to the peer services.
A.3 Architecture Overview
The Sentinel system is responsible for receiving events from the Collector Manager. The events are
then displayed in real-time in an Active View
At a high level, the Sentinel system uses a relational database and is comprised of Sentinel processes
and a reporting engine. The system accepts events from the Collector Manager as its input. The
Collector Manager interfaces with third-party products and normalizes the data from these products.
The normalized data is then sent to the Sentinel processes and database.
Historical analysis and reporting can be done using the Sentinel integrated reporting engine. The
reporting engine extracts data from the database and integrates the report displays into the Sentinel
Control Center using HTML documents over an HTTP connection.
Figure A-1
Section A.3.1, "iSCALE Platform," on page 442
Section A.3.2, "Sentinel Event," on page 444
Section A.3.3, "Event Source Management," on page 447
Section A.3.4, "Application Integration," on page 448
Section A.3.5, "Time," on page 448
Section A.3.6, "System Events," on page 449
Section A.3.7, "Processes," on page 450
A.3.1 iSCALE Platform
The Sentinel iSCALE
(SOA) that combines the advantages of in-memory processing and distributed computing. iSCALE
is a specialized message bus capable of handling high data volumes.
"Message Bus" on page 443
"Channels" on page 443
442 Sentinel 6.1 User Guide
Sentinel Architecture
architecture is built using a standards-based, service-oriented architecture
TM
and logged into a database for historical analysis.
TM
Advertisement
Table of Contents
