![]() |
AMS alerts you to network conditions and events that are useful to know about or that require action to resolve a network problem. AMS provides you with tools and back-end services to help you use, distribute, and manage this information. The AMS component is also fully integrated with other ZfS components to provide access control through the role-based services (RBS) component and report generation through the reporting functions. AMS provides a centralized location for processing and viewing the events and alarms generated by devices and systems throughout your network.
You can view tabular lists of statistical data for active and historical alarms received by AMS from any management console. This makes it easy to handle alarms and track network events and recurring alarm conditions. In addition, real-time notification of alarms occurring on your network is provided by the following:
You can also assign an action, such as automatically launching a program when an alarm is received, or sending an e-mail message to notify remote users of events.
AMS is comprised of multiple components for processing, storing, and viewing alarms. All alarms that are received by AMS are processed and sent to all applications that subscribe to them. The ZfS management console, by default, subscribes to AMS and receives updates as soon as an alarm is processed.
The following figure illustrates the AMS components:

The main components that make up AMS are as follows:
SNMP receives traps from network management agents and passes them to the SNMP trap forwarder and the SNMP trap injector.
After the SNMP trap forwarder receives a trap, it checks the alarm manager database to determine whether the trap has an SNMP trap forwarding disposition. If the trap has a forwarding disposition, the SNMP trap forwarder forwards the trap. Otherwise, the SNMP trap forwarder ignores the trap.
The SNMP trap injector converts the trap to an alarm and passes the alarm to the alarm injector.
The alarm injector receives alarms from the SNMP trap injector as well as from other applications and passes them to the inbound processor.
The alarm processors include processors for receiving, archiving, and dispatching alarms to subscribers. The inbound processor applies alarm templates to incoming alarms. The alarm template is based on SNMP trap definitions or other proprietary definitions for handling the AMS management and display criteria. After inbound processing is completed, the alarm is sent to the archive processor, which facilitates logging and storage of the processed alarm data in the alarm manager database. The archive processor sends the alarm to the outbound processor, which sends the alarms to the subscription server and disposition server.
The alarm manager database is a repository for alarm information, including the following:
The processed alarm data that is stored in the alarm manager database is supplied to management consoles through the alarm query server. The alarm data is used for alarm presentation and reporting.
Templates are applied to each alarm received by the inbound processor. Alarm templates are created for SNMP traps from the trap definitions in the MIB. When you compile a MIB, the trap definitions are used to create an alarm template that provides a method for presenting and managing alarm data. Proprietary alarms are handled in a similar way; the templates are based on proprietary definitions. For example, when a user tries to log in to a server with an incorrect password, an alarm is generated and forwarded to the management server. The management server processes the alarm by identifying the trap object identifier (OID) and assigning the associated alarm template.
An SNMP trap sent by a device that does not have a recognizable OID is assigned a default template and is categorized as unknown. In order for a trap OID to be recognized by AMS, you need to compile the device's MIB into the MIB Pool on the management server. See ZENworks for Servers Installation and Setup for more information.
AMS allows you to configure the automatic handling of an alarm by defining it in the alarm disposition. Alarm dispositions govern the handling characteristics for each type of SNMP trap or proprietary alarm. The automatic handling functions include specifying an application to launch when an alarm is received, sending e-mail notification, forwarding processed alarms to other ZfS management servers, or forwarding SNMP traps to other network management systems. You can also set options for alarms, such as audible beeps.
The following three archivers add data to the alarm manager database:
The alarm archiver stores alarm statistics and data in the alarm database. By default, all alarms are archived. If you do not want an alarm archived, you must edit the alarm disposition to disable archiving of the alarm. See Archiving Alarm Statistics for more information.
The disposition archiver receives the alarm disposition from the Disposition Console and saves it to the alarm manager database.
The template archiver receives alarm templates from a MIB compiler and saves them to the alarm manager database.
The management console shows two views of alarm data: the Active Alarm view and the Historical Alarm view. Active alarms are also displayed in the Summary view when a server is selected from the left pane of ConsoleOneTM.
The Active Alarm view displays statistics in the management console for events occurring on your network. Alarms displayed in the Active Alarm view can either be owned by you or assigned to a group. The tasks that you can perform on an alarm from this view depend on the access rights allowed through the role-based services. The Active Alarm view continually appends incoming alarms to the list, providing you with the most current alarms. After an alarm is acknowledged, it is removed from the Active Alarm list.
The Alarm History view allows you to track alarms received by AMS to verify their handling status. Information about assignments and ownership is also available from this view.
![]() |