Section 5.3. Maintenance


5.3. Maintenance

The extent to which a MOM 2005 implementation is self-maintaining depends largely on the volume of data flowing into and being removed from the operations database. The "Versions" section in Chapter 2 explains how data is groomed out of the operational database at configurable intervals. These intervals need to be coordinated with the DTS data transfer job that runs from the reporting server and copies (not deletes!) data from the operations database to the data warehouse database. In a nutshell, you want to be certain that data is copied to the data warehouse database more frequently than it is groomed (deleted) from the operations database. The default configuration is to copy data from the operations database to the data warehouse every day at 1:00 a.m. You can configure the grooming process in the Database Grooming section of the Global Settings node. The OnePoint database grooming will not occur if the daily DTS transfer has not completed successfully, so you are protected from losing data.

Figure 5-27. Configuring the default agent to management server communication port


5.3.1. Database Grooming

Deleting data from the operations database happens differently for alert data than it does for performance or event data. The difference is that alerts must be in a resolved state before they can be deleted out of the database. After all, it wouldn't be very helpful to delete an alert that has been assigned to a vendor for resolution before the vendor fixes the problem. The default configuration for deleting data out of the operations database is to delete resolved alerts and event and performance data that is more than four days old. This is shown in the "Groom data older than the following number of days" setting in Figure 5-28. Alert grooming is a little more complicated. MOM 2005 includes preconfigured SQL jobs that automatically resolve alerts after they have aged beyond the configured time limit defined in the "Specify when alerts are automatically resolved" box. For example, all alerts that are created with the default severity of Warning will have their alert resolution state changed from New to Resolved after one day unless an operator manually changes the alert resolution state from New to something else. Once the alert is in a Resolved state, it will be groomed out of the operations database after the four-day default limit.

You can edit individual auto-resolve time limits by selecting them in the Database Grooming tab and clicking Edit (see Figure 5-29). To determine if these values are adequate for your environment, you need to keep a close eye on your database size and the successful (or unsuccessful) completion of the database reindexing jobs and grooming jobs. If your operations database is rapidly growing to an unmanageable size, you can decrease the grooming time factor as well as the auto-resolve alert time factor.

Figure 5-28. Database grooming default settings


You may want to want to alter these values if you need more than four days to triage alerts. It really depends on how long you need to keep the data in the operations database "live." For details on database maintenance, see Chapter 7.

Figure 5-29. Editing the time limits for auto-resolving alerts


Notice in Figure 5-29 that the AlertLevel is referred to by its number in the Attribute Value field, not its name. In this case, the auto-resolve time limit for an Error alert is edited to have an Attribute Value of 40. Table 5-1 shows the default alert severity levels and their corresponding numbers.

Table 5-1. Alert severities and their internal numerical values

Alert severity name

Alert severity number

Success

10

Information

20

Warning

30

Error

40

Critical Error

50

Security Issue

60

Service Unavailable

70


Notice that even though the Inactive state is listed as "Auto resolve inactive Alerts" in Figure 5-28, it is not an alert severity level. This is a tip-off that MOM will not groom out any alert that is in an active state, regardless of its severity or age.

5.3.2. Operational Data Reports

Just as Microsoft included automated error reporting in their current OSes and Office applications, they have chosen to build in the generation and transmission of semi-scrubbed operational reports in MOM 2005. Basically, if you elect to send these reports to Microsoft (which they recommendgosh, there's a surprise), they will collect summary information on the number and type of alerts, your basic management group configuration, number of deployed agents, which management packs are deployed, and how long you are taking to resolve alerts.

View a sample of the data that Microsoft collects at http://www.microsoft.com/technet/prodtechnol/mom/opreport/samplereport.mspx.

If you don't have the MOM 2005 reporting feature installed, then it will take some effort to collect the same information on your environment for your own use. Microsoft should have provided this basic type of reporting in the Operator console out of the box.




Essential Microsoft Operations Manager
Essential Microsoft Operations Manager
ISBN: 0596009534
EAN: 2147483647
Year: N/A
Pages: 107
Authors: Chris Fox voc

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net