ELM Enterprise Manager Components
The central processing engine for ELM Enterprise Manager is the ELM Server. It receives, inserts and processes the data collected by the Agents. The majority of the resources required for real-time monitoring, alerting and reporting are efficiently localized at the ELM Server.
The ELM Console is the primary user interface for configuring ELM and displaying the data. The familiar tree structure and “right click” methodologies of this Microsoft Management Console Snap-in flattens the learning curve and accelerates the time to value.
The ELM Dashboard is a network accessible dynamic display. It presents visual alerts and performance bottlenecks for each monitored system. In addition, the recent event logs collected by theses Agents are available in a highly responsive table.
The primary role of the Agent is to collect data, encrypt it and reliably transfer it to the ELM Server. On Windows systems, a Service Agent is installed locally. For Syslog and SNMP supported devices, Virtual Agents are installed as a component of the ELM Server.
The Licenses are the commercial component of the ELM Enterprise Manager. They are functional sets of Collectors, Monitors and Receivers grouped to support specific objectives and price points. They control the scope of monitoring available to each individual Agent. With this granularity, multiple License Types can be assigned within a single ELM deployment.
For resiliency and reporting responsiveness, ELM supports three databases. The Primary Database receives data in real-time directly from the ELM Server. To manage its size, monthly Archive Databases can be created to retain some or all of the aging data.
When the Primary Database is unavailable, the data is inserted into the Failover Database. This fault tolerance ensures continuous monitoring and alerting even when the Primary Database is unavailable. Once the Primary returns to full operation, the Failover data is merged.
All three of these databases require Microsoft SQL Server. Depending on the event volume, user provided Microsoft SQL Server-Enterprise, Standard or Express editions can be used. Alternately, the run-time databases provided with the ELM download will support most Failover Database or Monitoring/Alerting-Only applications.
The ELM n-Tier Architecture can be used to efficiently monitor distributed networks separated by size, geography and application. In this architecture, the local ELM deployment monitors and reports on their systems. Then, using the Event Forwarding Notification Method, transfer the critical events to a Central ELM Server.
This ELM Server/ELM Server alerting options supports the same urgency, fault tolerance and encryption technologies as the Agent/ELM Server communication.
The ELM DMZ Architecture provides a secure option for minimizing the activities and communications through the network firewall. Using the Event Forwarding Notification Method, only a single TCP ports is required to transfer filtered event logs to an ELM Server in the DMZ.
The ELM Standby Architecture provides fault tolerance for support of disaster recovery policies. Under this configuration, when any Agent is unable to confirm the events are stored in a database, it will independently redirect them to the Standby ELM Server. Once the issues are resolved, the Agents will return to their Home ELM Server.
The Standby ELM Server can be used only as dedicated standby server or can operate as a Home and Standby ELM Server for subgroups of Agents.
Like the Standby Architecture the local Agents can report to more than one ELM Server. This option supports the Active/Active Architecture where duplication of monitoring and data storage are required. In addition, it provide the tools to migrate an ELM Server without delays or loss of data.