|
Management Pack Specification and EVENT Log
Guideline
Overview
Chapter 1: Define
Specification
Functional Specifications.
Rules Specifications
Chapter 2: MOM Event
Provider
Windows Event Log
Provider
Application Log Provider
MOM Event Rules
Chapter 3: Develop an Eventlog Guideline
Available Instrumentation Technologies
Recommendation for creating Events for MOM
Appendix A: Windows Event Types
Appendix B: MOM Severity Levels
This
Document shows in the first Chapter the recommended sections of the functional
and the rule specifications for a custom Management Pack development.The
second chapter describes the MOM event Providers in more detail and the third
Chapter is a
recommendation for an Eventlog Guideline.
Chapter 1: Define
Specification
The
functional specification includes written descriptions and specifics for all
components of the Management Pack module. The following sections are
recommended:
Abstract
This
section provides a short summary of the proposed Management Pack.
Overview
and Purpose
This
section describes, in moderate detail, the purpose, function, abilities, and
limitations of the Management Pack. This section should be a good indication of
what the Management Pack module will provide.
Scope
This
section describes the scope of the Management Pack, including the key
requirements to be met and any requirements that will not be covered in the
specified release.
Licensing
This
section summarizes the end-user licensing model for the Management Pack, if
applicable.
Glossary
of Terms
This
section lists and defines the terms applicable to your specification.
Customer
Scenarios and Features
This
section provides a list of each of the software components that you want to
manage, along with their descriptions. Each of these components should be
prioritized.
Management
Instrumentation
This
section explains the types of management instrumentation that will be used,
including a summary of what could potentially be used to monitor each of the
software components in your product. For example, this list would include the
Windows NT log events, performance counters, and scriptable interfaces
that you could use.
Management
Pack Components
This
section describes the components that are contained within your Management
Pack. For example, it might list the number of computer groups, computer
attributes, processing rule groups, processing rules, public views, knowledge
base content, and notification groups that will be included in your Management
Pack module.
Management
Pack Documentation
This
section outlines the Management Pack documentation required in the following
areas:
-
Processing
rule group knowledge base
-
Processing
rule knowledge base
-
Release notes
-
Additional documentation that you will provide for your Management Pack
The rules specification is
similar to a developer specification and includes a complete list of each of
the Management Pack objects and what is required to implement them. It is
recommended to design the rules specification into a spreadsheet format, using
one workbook for each Management Pack object type and their individual
subtypes.
The spreadsheet should
include the following sections:
Computer Groups
This section lists each
computer group and the configuration details required for your processing rule
group and processing rules targeting.
Computer Attributes
This section lists the
computer attributes that are part of the Managed Computer rules used during the
MOM discovery process.
Notification Groups
This section lists the
notification groups used for your processing rule responses, such as e‑mail
and paging.
Processing rule group
This section lists the
processing rule group structure of your Management Pack, along with the
computer group associations that are required for processing rule group and
processing rules targeting. This section should also describe the knowledge
base content requirements and include an example.
Event processing rule
This section lists each
event processing rule included in the Management Pack, along with the
configuration details and location within the processing rule group structure.
This section should also describe the knowledge base content requirements and
include an example.
This section should also
list the following types of event processing rules in detail:
- Consolidation
- Collection
- Filter
- Missing
Alert Processing Rule
This section lists each
alert processing rule included in the Management Pack, along with the
configuration details and location within the processing rule group structure.
This section should also describe the knowledge base content requirements and
include an example.
This section should also
list the following types of alert processing rules in detail:
Performance processing rule
This section lists each performance
processing rule included in the Management Pack, along with the configuration
details and location within the processing rule group structure. This section
should also describe the knowledge base content requirements and include an
example.
Public views
This section lists each of
public views included in the Management Pack, along with the configuration
details and structure.
The Windows Event Log
Provider is one of the most commonly used providers in MOM. Out-of-the-box, MOM
provides providers that enable authors to monitor the follow Windows NT Event
Logs:
• Application
• System
• Security
• Directory service
• DNS Server
• File Replication Service
The Windows Event Log
provider is also extensible, so if new logs are added to Windows or
non-Microsoft applications, then custom providers can be created to access
them.
Application Log Provider
The Application Log
Provider is another provider in MOM that enables a Management Pack rule to use text
log file data for monitoring. Out-of-the-box MOM provides native support for
the following log types:
• Internet Information Server Web Server Log
• Internet Information Server FTP Server Log
• Internet Information
Server Internet Locator Server Log
•
Syslog Port
The Event rule is one of
the most commonly used rule types in MOM. This rule type has a number of sub
rule types which include:
• Event Rule
• Filter
• Detect Missing
• Consolidation
• Collection
Each of these rule types
are described in detail in the sections that follow.
Event Rule (Alert On or Respond To)
The Event rule, also known
as the "Alert On or Respond To" rule, is an Event rule sub type that
enables the analysis and collection of event data. Additionally, this rule sub
type enables a response to be executed when a criteria match occurs.
Filter Rule
The Filter rule is an
Event rule subtype that enables filtering of data based on the rules criteria.
There are two filters types, including:
• Database filter - This
filter type enables a response to be executed, but it prevents the event that
matches the rules criteria from being entered into the database.
• Conditional filter -
This filter type enables the event data to be collected in the database, and a
response to be executed only if another rule has matching criteria for the same
event.
Detect Missing Rule
The Detect Missing rule is
an Event rule sub type that enables a response to be executed when a specific
event does not occur as anticipated. For example, an end user might expect
"The Backup was successful" event to occur once day; however, in the
case where it is not clear that the backup was never run or possibly failed
without notice. The Detect Missing rule is perfect for handling the case. This rule
can be scheduled. Specifically, a range of times and days to look for the event
can be configured.
Consolidation Rule
Often, particular events
that authors want to monitor occur frequently. At times, events occur so
frequently as to cause excessive network traffic or possibly cause the MOM
database to become full of redundant data. In other cases, an author may want
to generate an alert when a particular event occurs X times in X minutes. A
Consolidation rule enables MOM to solve these issues.
A Consolidation rule
enables the MOM agent to collect a single instance of data that matches the
rules criteria, rather than each instance, for a specified period of time. This
period of time is configured as part of the Consolidation rule.
In addition to consolidating
the data, the rule will count how many instances of the criteria match occur,
which can be useful when the Consolidation rule is used in coordination with an
Event (Alert on or Respond To) rule. For example, an author might create a
Consolidation rule to generate an Alert when a criteria
match occurs 10 times is 5 minutes. In this scenario, the author creates a
Consolidation rule that consolidate and create a criteria match count for the
relevant event for 5 minutes. The author will then create a second rule, an
Event (Alert on or Respond To) rule, which generates an Alert response when the
"Repeat Count >= 10. The Consolidation rule will hold on to the event
for the specified time period and then submit the event, and count, to other Event
Rules for criteria match analysis. These rules will generate the appropriate
responses.
Collection Rule
The Collection rule
enables MOM to collect an event. This rule types can be useful when the
particular event data is not appropriate for any sort of responses, but is
useful for reports or views. This rule type does not have the ability to
execute a response.
Understanding Criteria
Event criteria
To identify specific
Windows events, you can specify the following criteria, and combinations of
these and other criteria:
Event source
Event number
Event type
Description text
User generating the event
Source computer
Source domain
Computer on which the event is logged
Domain in which the event is logged
There are several ways
that developers can make their applications easier to monitor from a MOM
Management Pack.
Most important, you should
always expose some form of event and performance information about your
application. An application that does not expose any form of instrumentation
data will be very difficult, if not impossible, to monitor.
Event log entries are
considered one of the best sources of data for MOM. Rules for Windows NT events
are easily created and the event entries usually offer sufficient information
to identify and correct problem conditions
Previous versions of
Visual Basic and Visual C++ offer easy-to-use libraries for writing to the
Windows event log. The .NET Framework Class Library also includes useful classes
and interfaces for writing to the Windows NT event log in the System.Diagnostics Namespace.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemDiagnostics.asp
WMI was designed
specifically for exposing and unifying access to computer hardware and
software, and a WMI provider allows your application to share data and events
through the existing WMI infrastructure and APIs. Because WMI allows users to
modify data, you might be able to provide opportunities for rules to
automatically resolve the problem using a script response. For more information
about creating a WMI provider, see Providing Information to WMI in the WMI SDK.
The System.Management.Instrumentation Namespace of
the .NET Framework Class Library includes classes and interfaces for creating WMI providers.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemmanagementinstrumentation.asp
Windows NT event log
entries should do the following:
- Define and agree of the location of the events. For Example Application, System , Security or a new EventLog
- Use a unique ID number for each type of event raised.
Do not reuse the same ID number to describe different error conditions.
Without unique ID numbers, your events will be ambiguous and other fields
must be examined to determine what condition the event represents.
- The source
field should always correspond to your application.
- The category
field should be used. It might be useful when filtering or grouping
MOM alerts.
- Do not rely on the description field as a replacement for other fields. The
performance on the server running MOM and computers running the MOM agent
is reduced when a complex pattern matching expression is applied to strings
in the description field. Beyond providing useful troubleshooting
information, the description field is necessary in certain MOM rules,
especially when consolidating similar events.
-
Event
types should be consistent in
the same way that MOM alert severities should have an agreed upon meaning.
Whenever possible, developers and MOM administrators should work together
to develop guidelines that make it easier to determine which events are
important and how the event type maps to alert severity levels.
-
Event
Knowledge Base
Authors
should add knowledge to every rule group and rule in their Management Pack. The
knowledge serves many purposes, but its primary function is to give operations
personnel detailed information on the rule group or rule.
Knowledge
is authored in HTML, which can be added to the knowledge template on the
Advanced Knowledge tab of the Rule property sheet. The Rules Knowledge template
includes the following sections:
•
Summary
•
Causes
•
Resolutions
•
External Knowledge Sources
•
Sample Event
•
Related Events
•
Other Information
•
Internal Comment
All
rules should contain information in the Summary section to describe the purpose
and function of the rule. If a rule is designed to generate an alert, the
Summary must describe the end user impact of the issue, and must include
sufficient information in the Causes and Resolutions sections.
Figure 1 : Eventlog, map
Category, Source and Event ID
There are five types of events that can be logged.
All event classifications have well-defined common data and can optionally
include event-specific data. The application indicates the event type when it
reports an event. Each event must be of a single type. The Event Viewer uses
this type to determine which icon to display in the list view of the log.
The following table describes the event types used
in event logging.
|
Event
type
|
Description
|
|
Error
|
An
event that indicates a significant problem such as loss of data or loss of
functionality. For example, if a service fails to load during startup, an
Error event is logged.
|
|
Warning
|
An
event that is not necessarily significant, but may indicate a possible future
problem. For example, when disk space is low, a Warning event is logged. If
an application can recover from an event without loss of functionality or
data, it can generally classify the event as a warning event.
|
|
Information
|
An
event that describes the successful operation of an application, driver, or
service. For example, when a network driver loads successfully, it may be
appropriate to log an Information event. Note that it is generally
inappropriate for a desktop application to log each time it starts.
|
|
Success
Audit
|
An
event that records an audited security access attempt that is successful. For
example, a user's successful attempt to log on to the system is logged as a
Success Audit event.
|
|
Failure
Audit
|
An
event that records an audited security access attempt that fails. For
example, if a user tries to access a network drive and fails, the attempt is
logged as a Failure Audit event.
|
Selected activities of users on can be tracked by
auditing security events and then placing entries in a computer's security log.
For more information, look up "auditing" in the online help provided
with Windows.
When an event or threshold
occurs that matches a processing rule, MOM associates the specified alert, and
the alert severity, to that event. The alert severity lets you quickly
determine the importance of the indicated condition.
|
Value
|
Name
|
|
10
|
Success
|
|
20
|
Information
|
|
30
|
Warning
|
|
40
|
Error
|
|
50
|
CriticalError
|
|
60
|
SecurityIssue
|
|
70
|
ServiceUnavailable
|
|
255
|
Unknown
|
| 
