

Juggling Large Message Systems
AppManager's major modules include the Console, the Management Server, the Management Client and the Repository. The AppManager Console is the administrator's interface where jobs are run, Knowledge Scripts are configured and modified, events are acknowledged and graphs are generated. The interface is colorful, intuitive and well-planned, with multiple viewing panes. The Treeview Pane shows all monitored Exchange servers and their components. A discovery process is performed automatically during initial system configuration to gather information about a particular server. The Knowledge Script Pane lists jobs available by c
ategory (category names include Action, Discovery, General, Exchange and NT). The List Pane shows all events--Exchange monitoring jobs where thresholds have been exceeded and services are down, for example. Clicking on the graphs tab reveals a list of jobs that can be graphed. Dragging the entry to the Graphs Pane display
s the data in graphical form. The interface is fully customizable.
The Management Agent resides on the Exchange server, autonomously monitoring and collecting information. The agent continues to monitor the system and store data locally so that, in the event of a network outage, the system can still communicate the results of the query when service is restored. The Management Client (NetIQmc) is the NT service associated with the agent.
The Repository (also known as the Query Database, or QDB) is a Microsoft SQL Server 6.5 database that stores Knowledge Scripts, event, job and graph data. AppManager automatically configures the database and creates all the required tables. Basically,
all you do is establish a database on the server, configure its size and the number of connections, and AppManager takes it from there.
The Management Server is an NT service (NetIQms) that manages communications between the Console and Management Agent. The Management and SQL Servers use Open Database Connectivity (ODBC) to communicate with each other, while a Microsoft remote procedure call (RPC) is used between the Management Server and the Console. All the components can reside on separate networked machines or all on the same machine. Typically, however, the Repository and the Management Server reside on the same SQL Server machine. We ran the Repository on a separate server and everything else on the Exchange server.
The ability to detect that an NT or Exchange service has stopped and to restart the service automatically is a key feature of AppManager Suite. In our tests, we selected the "Down Exchange Service" and requested e-mail notification. Sure enough, AppManager discovered the downed ser
vice, dropped a message in the mailbox and quickly restarted the service. It would be helpful if the system also provided a "Service Restored" notification to stop the administrator from needlessly performing additional diagnostics.
The ability to automatically restart a service in incremental steps would enhance AppManager
's functionality. For example, the system might go through several restart attempts before ultimately paging the on-call person. Also, if several services are down, the user should be able to define a restart sequence so that the System Attendant, for example, would be the first to restart, then the Information Store and so on until all the services were again functioning properly.
A job, the basic work element consisting of the running of a Knowledge Script on a server or application component, entails associated properties, such as a schedule, various thresholds for different elements monitored, an event severity notification, a list of monitored objects and actions to take when
thresholds are exceeded. Available actions are no action, send Messaging Application Programming Interface (MAPI) or Simple Mail Transfer Protocol (SMTP) mail, send a Simple Network Management Protocol (SNMP) trap, generate DOS commands, send console message, and perform multiple actions to provide better alert coverage. The alert message contains the Knowledge Script name such as "Exchange_Connectivity" (to monitor whether an Exchange server can be reached by sending a message to itself) and a detailed event message.
To start a job, you select a job icon and drag it to the server or application component that you want monitored. For instance, if you drag the ExchangeISsize job and drop it on an Exchange Information Store, AppManager takes a look at the current file size of the store, places the data in the Repository and creates an entry in the graph list. The job can then be dragged to the graph window and the properties of the chart defined.
By clicking on any graphical element in the chart, AppMa
nager takes you to the data from which the chart was constructed. The data may show a single value such as the number of messages or, in the case of a report on the top 10 message users, it shows a list of user names, total messages and total number of bytes. This output isn't well-formatted and you can't print the report from the
screen, so the reporting tool achieves only half its potential. You can, however, output the report to a text file or another application, such as Excel. You can work with the graph to enhance its appearance, giving it 3-D effects or shadows. You also can bring the data from more than one job onto the same graph. Graphs are in real time, so you can see the size of your Information Store fluctuate throughout the day if you keep the graph active.
|