An introduction to Domino Domain Monitoring (DDM)

If you're running Domino server version 7 or higher, it's likely that Domino Domain Monitoring (DDM), a free Domino administration tool, is automatically running on your servers and monitoring your system. This tip from Lotus Notes/Domino expert Michael Kinder explains what Domino Domain Monitoring is and how to best to use it to monitor your Domino environment. DDM is a built-in Lotus Notes/Domino monitoring tool that:

Monitors events that are registered during the Domino server logging process. Records information on a central server throughout your entire Domino domain. Arranges events into five categories of severity. Suggests how to fix server issues. Allows you to assign events to someone to fix any issues that exist. Allows those assigned to close the events, remove them from the problem list or enter their solution(s). Is easy to configure and run on your Domino server. Has little or no effect on the performance of your Domino server. Does not rely on or require any third-party software.

At Admin2008, attendees were asked if they had heard of DDM, whether they had implemented it or not, and if not, if they planned to implement DDM. Many attendees had not yet implemented the tool; however, by the end of the session, I believe most intended to. DDM differs from previous monitoring tools, such as Events and Reports. DDM leverages features in the Events database (EVENTS4.nsf) for configuration, but it monitors from within the DDM database. The actual file name of the DDM database is DDM.nsf. This database contains all of the log event records that DDM collects; it then arranges events using views that display information in different ways, like "By Severity" or "By Date." Unlike its predecessors, which required an administrator to configure it to monitor a Domino environment, DDM is preconfigured to detect common monitoring issues experienced in a Domino environment. The events are arranged in five severity levels: Fatal, Failure, Warning (High), Warning (Low), and Normal. Each event also comes with suggestions on how to rectify the problem. Generally, more than one corrective action is suggested -- leading you in the right direction to solve issues that arise. If none of these suggestions fix the issue, but something else does, you can add this solution and associate it to the problem type so that it's suggested the next time this problem occurs in your Domino environment. Domino Domain Monitoring can also "roll up" event records. DDM predecessors performed on a per-server basis. If you wanted to configure monitoring and view the results, you had to go to

each server to see it. With DDM, on the other hand, you can have all servers that DDM processes recording the same or different things, but have all the data "rolled up" into one viewing location (Figure 1).

Figure 1: A sample DDM Collecting Hierarchy Many Notes/Domino administrators roll up the data to their Administration server, but this isn't required. No matter how you choose to roll up the data, this isn't done until you configure it to do so in the DDM configuration interface, which is located inside Events4.nsf (Figure 2).

Figure 2: DDM Hierarchy Configuration dialog box

Configuring Domino Domain Monitoring (DDM)

You can configure Domino Domain Monitoring to monitor events that you want to keep a closer eye on or that most affect your Domino environment. IBM Lotus has also updated some core components of the Domino server to perform these tasks more efficiently. There are a some issues that frequently concern Lotus Notes/Domino administrators, including resource hogs, time-consuming tasks, missed replication schedules and error conditions. To address these issues, Lotus added some preconfigured probes in Domino Domain Monitoring (DDM) to monitor an environment to easily maintain your environment and the health of your applications. This tip from Lotus Notes/Domino expert Michael Kinder outlines preconfigured items and probes you can use to effectively configure DDM in a Lotus Notes/Domino environment. Preconfigured DDM items and probes:

Application code probes: Identify agents or Web services that are running behind schedule, using too much of server resources or running long. Database probes: Monitor database activities, report on their details and make suggestions on possible causes for errors as well as possible solutions. Directory: Monitors availability, directory processes and port health. Messaging: Monitors messaging processes and port health. Operating system: Monitors resources. Replication: Checks on the status of replication, reports on it and ranks errors. Security: Identifies practices that are best for security, monitors configurations and identifies possible trouble areas. Server: This will assist with administration. Web: Identifies best practices and monitors Web configurations.

Where are these preconfigured items located? The preconfigured DDM items reside in DDM Probes. These can be located in the DDM Probes subview of the DDM database. You can also access this subview via the Events4.nsf database (Figure 1). Although DDM Probes are disabled by default, they are already preconfigured.

Figure 1. Access the DDM probes subview via the Events4.nsf database. To enable a probe, select it from the view and edit the probe document. Once you are in edit mode inside the document, click Enable Probe. There are other items that can be configured when enabling the probe, such as the server(s) that the probe will run on; other configuration items are specific to the type of probes. Some examples are shown below:

Administration Probes: Explain errors that you'll want to monitor and close and also how long the error record should remain open. Application Code Probes: Denotes which process to probe and offers four levels of event-generation status for which the probe should monitor. Database Probes: Denotes the severity of the probe result and, in certain cases, errors to ignore as well as database properties changes you should monitor. Directory Probes: Denotes the severity of the probe result and additional specifics, depending on which Directory Probe you enable. Messaging Probes: Denotes the severity of probe results and other specifics -- depending on which Messaging Probe you enable. OS Probes: Shows the severity of probe results, which OS to monitor with the probes and specifics depending on which OS Probe you enable. Replication Probes: Tells which server(s) that selected databases need to replicate to, which database(s) to probe, which database(s) not to probe and details on each individual type of probe. Security Probes: Notes which server(s) that should be probed, which database(s) should be probed and, in some cases, which ones should not be probed. Server Probes: Denotes which server(s) should be probed and what Administration Requests to probe. Web Probes: Denotes which server(s) should be probed, which server configuration(s) should be probed and specifics on each probe you are working with.

Changes to many of the core components of the Lotus Domino server itself affect probes. These include the router, replicator and agent manager. For example, Application Code probes are an extension of the agent framework on the Domino server. They monitor issues related to agents or Web services (agents) that that agent manager handles. Not every feature of the Agent Manager is tracked in these Application Code probes. For example, before Mail Delivery agents in a mail file are not as they are managed by the Router task, any agents that the Event task runs (which is new in Domino 7) are not monitored by the Application Code probes either as they are managed by the Event task. Agents spawned from the server console are not monitored, as they are not controlled by the agent manager either. Caveats when configuring DDM:

Reporting intervals are not configurable Ranking of problems restarts each day Can collect a lot of information really fast, but only under the right circumstances<./li>

On the other hand, in DDM, only one duplicate probe will run and monitor issues and errors on more than one Domino server in a single interface, on a central server.