The NIH Application Manager (NAppMan)

Computers have become indispensable for effectively performing the work we do at the NIH, but it is the applications running on those computers that ultimately allow us to be productive. We tend to take those applications for granted, expecting them to be always and conveniently available. When they are not, we are hamstrung and frustrated. Avoiding problems and ensuring that the applications are available all the time requires constant monitoring, but how can this best be accomplished? NIH has solved this problem by setting yet another application to the task; an application monitor.

Application Monitoring and NAppMan

Application monitoring is a key component in the overall support and maintenance of critical IT applications and allows system owners to view the accessibility of an application from a user’s perspective. The intention of the NIH Application Manager (NAppMan) is to alert a responsible individual when the application is not available or is suffering a problem of some sort.

How is NappMan different from other monitors?

NAppMan employs a “monitor of monitors” approach to ensure our applications are available when we need them. As a monitor of monitors, NAppMan does not directly monitor an application itself. Instead, it pulls or receives information from the underlying monitors – the monitoring software that directly monitors the application. NAppMan then summarizes the information and displays it using an HTML format.

NAppMan’s Dashboard

The first thing that a user sees when accessing NAppMan is the dashboard (see Figure 1 below), a summary display of all information collected by NappMan. The dashboard provides data on the status of a number of applications, listed on the screen as systems. The systems that are currently available are those provided during the initial introduction of NAppMan on August 31, 2005. The systems are identified by name under the first column of the dashboard.

Figure 1 - The NAppMan Dashboard

The second column shows the “Service Status” of the system or application. Color-coded state buttons indicate the level of availability for a particular application. If, for example, the application can be successfully accessed, then the state button is set to green. To check the service status the underlying monitor must execute a synthetic login by emulating what a user would do to get to the application. If for some reason the application is not available, the state button is set to red. The legend at the bottom of the screen explains what each color of the state button represents.

The third column on the dashboard depicts the “Connectivity Status” for a given application. Connectivity refers to the availability of the pathway on the NIH network necessary to access the application. The column is a summary of more detailed data that is available by clicking on any state button under the column and drilling-down, or accessing a more detailed level of information, as shown in Figure 2.

The screen in Figure 2 presents each of the applications as well as their connectivity status as relayed from a remote probe that checks the pathway on a regular basis. The probes are positioned at strategic locations on the network. If the pathway is clear, the state button is green. If a firewall issue or a faulty router is causing a problem, the state button is red. Often a red condition is caused by timing issues (some type of hold-up on the network). If the probe does not receive a response within a predetermined amount of time, it complains by presenting a red status button for that application.

Figure 2 - Connectivity Screen

The fourth column on the dashboard displays the “Component Status” - the summary status of the individual components that the application contains. The state buttons under this column provide a drill-down capability as well. Figure 3 depicts the screen that is provided during this drill-down process. This “Detail View” screen identifies the various components that make up the application as well as providing the operational status for these components.

What happens when a problem is identified?

If an underlying monitor detects a problem with an application, it presents an alert state to NAppMan. If an alert status exists (only red or yellow), NAppMan will send an e-mail message to a predetermined list of individuals. In addition, NAppMan opens a Remedy Action Request System (Remedy) service ticket for the problem with the NIH Help Desk. The network probes are an exception to this rule. When a probe discovers a problem, NAppMan represents this status on the screen, but no alert state is raised.

The third and fourth columns on the screen in Figure 3 denote this information. The service ticket number is available under the column labeled, “Remedy.” If a technician acknowledges the service ticket, that information is made available in the form of a checkmark under the column labeled, “Acknowledged.” Although the function is configurable, in most cases NAppMan will automatically close the service ticket when the condition is cleared. NAppMan relies on the underlying monitor to clear a condition it has set.

Figure 3 - Detail View Screen

Who uses NAppMan?

Armed with the information NAppMan supplies, NIH Help Desk staff can be more effective when taking calls regarding application problems. NIH executives can check on the condition of our Enterprise Systems from one convenient place. In the near future, application owners will utilize NAppMan statistics to help justify their application’s service levels. In general, NAppMan can provide some value to anyone who has access.

What’s next?

The NAppMan team will be adding existing systems and applications, ultimately making NAppMan available to all NIH enterprise systems. Once this is achieved, NAppMan will continue to grow as our systems grow.

Contact Information

If you have an interest in NAppMan representing your monitored application, please contact:

Doug Meyer, ESM Project Manager,
Division of Enterprise and Custom Applications, CIT
Phone: 301-402-5314. E-mail: meyerd@mail.nih.gov