Introducing
Microsoft System Center Operations Manager 2007
Modern organizations of any size all have one thing in
common: their computing environment isn’t simple. Everybody’s world contains
hardware and software of different vintages from different vendors glued
together in different ways. Managing this world—keeping these diverse,
multifaceted systems running—is unavoidably complex.
Despite this complexity, two fundamental management requirements
are clear. The first is the need to monitor the hardware and software in the
environment, keeping track of everything from application availability to disk
utilization. The operations staff that keeps the environment running must have
a clear and complete picture of the current state of their world. The second
requirement is the ability to respond intelligently to the information this
monitoring produces. Whenever possible, this response should avoid incidents by
addressing underlying problems before something fails. In any case, the
operations staff must have effective tools for fixing failed systems and
applications.
The goal of Microsoft’s System Center Operations Manager
2007 is to meet both of these requirements. The successor to Microsoft Operations
Manager (MOM) 2005, the product is focused on managing Windows environments,
including desktops, servers, and the software that runs on them. It can also be
used to manage non-Windows systems and software, devices such as routers and
switches, and more. Released in early 2007, Operations Manager aims at
providing a solution for monitoring and managing a Windows-oriented computing
world.
The
Challenges of Monitoring and Management
Think about what’s
required for effective monitoring and management in an enterprise computing
environment. Keeping track of what’s happening on the myriad of machines in an
organization means dealing with diverse software, including desktop and server
operating systems, databases, web servers, and applications, together with all
sorts of hardware, such as processors, disk drives, routers, and much, much
more. All of these components must inform the people managing this world of
their status.
This is bound to
generate lots of information. The operations staff will certainly need some
kind of dedicated interface that organizes this plethora of data into
understandable graphics and numbers. They’d also probably like a Web version of
this interface, an option that would increase their ability to manage this
world remotely. And for some scenarios, such as creating scripts, a command
line interface is the best choice. Yet while a variety of user interfaces are
required for working with management data as it’s generated, the ability to
generate reports on historical data is also essential. How can the people
responsible for maintaining this environment know how they’re doing without
some way to track their history? Real-time interfaces are certainly important,
but so is an intelligent way to examine long-term trends.
Here’s another challenge: No single organization—vendor or
end user—can afford to have people on staff who are expert in managing each
part of a complex IT world. Instead, a management and monitoring tool must
provide a way to apply packaged expertise via software. The product must also
be capable of providing a platform for third parties to create this kind of
package.
And there’s more. The
IT Information Library (ITIL) and the Microsoft Operations Framework (MOF) both
promote an IT Service Management (ITSM) approach. Rather than focusing solely
on the details of managing individual technologies, ITSM emphasizes the
services that IT provides to the business it’s part of. Given that the business
people who pay for it see IT entirely in terms of these services, this approach
makes perfect sense. Yet doing it successfully requires explicit support for
defining and monitoring distributed applications as a whole. An organization’s
email service is made up of many parts, for example, including email server
software, database software, and the machines this software runs on. Providing
a way to monitor and manage this combination as a single service improves IT’s
ability to offer the performance and reliability that the
business expects.
Effectively
monitoring and managing a modern computing environment requires addressing all
of these problems. The next section gives an overview of how Operations Manager
does this.
Addressing the Challenges: What System Center Operations Manager 2007 Provides
While Operations Manager provides a variety of functions,
three of them stand out as most important: providing a common foundation for
monitoring and managing desktops, servers, and more; taking a customizable,
model-based approach to management; and supporting service monitoring of
complete distributed applications. What follows describes each of these three.
A Common Foundation for Monitoring and Managing Desktops, Servers, and More
Despite the diversity of enterprise computing, a single
product can provide a broad foundation for a significant part of an
organization’s management challenges. Understanding how Operations Manager does
this requires a basic grasp of the product’s architecture. The figure below
shows its major components.
As the diagram shows, the software that comprises
Operation Manager is divided into servers and agents. The
servers, which run on Windows Server 2003 and the forthcoming Windows Server
codename “Longhorn”, divide into two categories:
n
The Operations Manager management
server. This server relies on an operational database, and it’s the
primary locus for handling real-time information received from agents. As the
diagram shows, it also provides an access point for the product’s various user
interfaces.
n
The Operations Manager reporting
server. This server relies on a data warehouse, a database capable
of storing large amounts of information received from agents for long periods.
The reporting server can run predefined and custom reports against this
historical data.
Unlike management and reporting servers, the Operations Manager
agent runs on both client and server
machines. This agent runs on Windows 2000, Windows XP, and Windows Vista
clients, as well as Windows 2000 Server, Windows Server 2003, and Windows
Server codename “Longhorn”. To manage non-Windows devices, such as routers and
switches, Operations Manager managers and agents can connect to them using SNMP
or the newer WS-Management protocol. There’s also an option that allows
retrieving basic management information from Windows systems that aren’t
running agents.
Agents send four primary kinds of information to
management servers:
n
Events, indicating that something
interesting has occurred on the managed system. An agent might send an event
indicating that a login attempt has failed, for instance, or that a failed
hardware component has been brought back to life.
n
Alerts, indicating that something
has happened that requires an operator’s attention. For example, an agent might
send an event for every failed login, but send an alert if four failed logins
occur within three minutes on the same account.
n
Performance data, regularly sent
updates on various aspects of the managed component’s performance.
n
Discovery data, information about discovered
objects. Rather than requiring an operator to explicitly identify the objects
to be managed, each agent can discover them itself, a process that’s described
later in this paper.
All of this information is sent to the operational
database and/or the data warehouse, and all of it can be accessed through Operations
Manager’s user interfaces. Operations staff will most often rely on the
Operations Manager console, a Windows application that can display
events, show alerts, graph performance over time, and more. A large subset of
the Console’s functions can also be performed through the Operations Manager Web
console, providing browser-based access to this information. And for
creating scripts or for people who just prefer a command line interface, the
product also allows access via the Operations Manager command shell.
This broad foundation is essential for modern monitoring
and management. It’s not enough, though—more is required. How, for instance,
can a single product address the diversity of managed components in a typical
enterprise? How Operations Manager addresses this is described next.
Customizable, Model-Based Management
Any attempt to address the broad problem of monitoring and
management in a single product faces an unavoidable limitation: No one vendor
can have all of the specialized knowledge required to handle the wide range of
software and hardware that its customers use. Instead, what’s needed is a
generalized framework for packaging specialized management knowledge and
behavior, packages that can then be plugged into a common management foundation.
This is exactly what’s provided by Operations Manager’s management
packs (MPs). Each MP packages together the knowledge and behavior required
to manage a particular component, such as an operating system, a database
management system, a server machine, or something else. These MPs are then
installed into Operations Manager, as the figure below shows.
Since creating an MP requires specialized knowledge about
managing the component this MP targets, each one is typically created by the
organization that knows the most about that component. As the figure above
suggests, for example, Microsoft has created MPs for client and server versions
of Windows as well as for Exchange Server, SQL Server, and other Microsoft
products. Other vendors have created MPs for non-Microsoft software and
hardware about which they have specialized knowledge. Hewlett-Packard provides
an MP for its ProLiant server machines, for example, while Dell offers MPs for
its servers.
As the figure shows, each MP can contain several things,
including the following:
n
Monitors, letting an agent track
the state of various parts of a managed component.
n
Rules, instructing an agent to
collect performance and discovery data, send alerts and events, and more.
n
Tasks, defining activities that can
be executed by either the agent or the console.
n
Knowledge, providing textual advice
to help operators diagnose and fix problems.
n
Views, offering customized user
interfaces for monitoring and managing this component.
n
Reports, defining specialized ways
to report on information about this managed component.
When an MP is installed, its various parts wind up in
different places. The monitors and rules, for instance, are downloaded to the
agents on the appropriate machines, while the knowledge and reports remain on
the management and reporting servers. Wherever its contents are used, the goal
is always the same: providing the specialized knowledge and behavior required
to monitor and manage a particular component.
To get a sense of how the various components of an MP
might work together, imagine that an application running on some managed system
notices that it lacks sufficient disk space to function. This application
writes an event into the system’s event log indicating this, then shuts itself
down. The Operations Manager agent on this system continually monitors the
event log, and so it quickly notices this event. If the application’s MP
contains an appropriate rule, the agent will send a specific alert to the
management server when this event occurs. The operator sees the alert in the
Operations Manager console, and he also sees the MP-provided knowledge
associated with this alert. Reading this knowledge, he learns that he should
direct the agent to run a task that deletes the temp directory on the
application’s machine, then restart the application. This entire process, from
detection of the problem to its ultimate resolution, depends on the information
contained in the MP.
Of course, it would be better to avoid this problem in the
first place. One way to do this is to keep an eye on things such as free disk
space on the machine hosting this application, then inform an operator when a
problem looms. Doing this requires creating a model of what a healthy managed
component looks like, then indicating any deviation from its normal state. In
Operations Manager, this is exactly what monitors are for. Each MP defines a
set of objects that can be managed, then specifies a group of monitors
for those objects. These monitors keep track of the state of each object,
making it easier to avoid problems like application crashes before they occur.
In the language of Operations Manager, the set of monitors for a managed object
comprise a health model for that object. By tying together the health
models for the various objects on a system, an overall health model can be
created that reflects the state of the system as a whole.
Allowing
each MP to define its own set of managed objects makes sense. Yet the best an
MP’s creators can do is define generic objects; they can’t know exactly what’s
on any given system. For example, the SQL Server MP defines an object
representing a database. When this MP is installed on a real system, that
machine might have one, two, or more actual databases. How are these concrete
instances of the MP’s generic object type found? One approach would be to
require an operator to identify each instance manually, a task that nobody
would enjoy. Instead, Operations Manager allows each MP to include specific discovery
rules (also called just discoveries) that let the agent locate these
instances. The goal is to make finding the things that need to be managed as
straightforward as possible.
Providing this generalized approach to defining management
knowledge and behavior requires a common technology to create these
definitions. Like other products in the System Center family, Operations
Manager relies on an XML-based language called the System Definition Model
(SDM) to do this. All MPs are expressed in SDM, providing a standard
format for their creators to use. Defining MPs with SDM also implies a more
general, less Windows-specific infrastructure for management. Although
Operations Manager remains a Windows-oriented product, it’s significantly less
wedded to the Microsoft world than was its predecessor.
In
fact, SDM is the basis of an in-progress standard known as the Service
Modeling Language (SML). Embraced by Microsoft, BEA, BMC, CA, Cisco, Dell,
HP, IBM, and Sun, SML will provide a vendor-neutral foundation for describing
managed systems. The value of a model-based approach to this problem is clear,
and it’s a fundamental aspect of Operations Manager.
Service Monitoring for Distributed Applications
The goal of virtually every IT department is to provide
services to the organization it’s part of. Monitoring and managing the various
parts of the IT environment is an essential aspect of doing this. Yet business
people don’t really care about the state of individual components. Instead,
their concern is for the services they see. Can they send and receive email?
Are the applications they need right now running effectively? This
service-based concern makes sense, since it reflects what’s most important to
the organization as a whole. Yet each service is likely made up of a number of
underlying components, including both software and hardware. Looking at each of
an application’s components separately isn’t enough.
What’s needed is a way to monitor and manage a distributed
application—the combination of components that underlie a particular service—as
a whole. Operations Manager provides this through service monitoring.
The diagram below illustrates this idea.
Think, for example, about a custom ASP.NET application. As
the figure suggests, this application’s main components might include IIS, the
application itself, SQL Server, a specific database, the network used to
connect these components, and more. From a technology point of view, all of
these are distinct pieces, and without some way to group them together, an
operator would be hard pressed to know that they actually comprise a single
distributed application. From the perspective of a business user, however, all
that matters is the service this entire application provides. If any part of it
is malfunctioning, the entire service is likely to be unavailable. Letting the
operator know that, say, a failed disk drive is actually part of this
business-critical application can help that operator understand the importance
of getting it back on line as quickly as possible. Rather than viewing their
world as discrete components, operations staff can instead have a perspective
that’s closer to what their customers see: a service-based view.
Getting a grip on Operations Manager requires
understanding a number of different concepts. None of these ideas are more
fundamental than management servers and agents, and so the place to begin is by
looking more deeply at these bedrock parts of the product.
Understanding Management Servers
Management servers are at the center of Operations
Manager. Agents send them alerts, events, performance data, and more, and
they’re also the access point for the product’s user interfaces. While the
basic architecture is straightforward, as shown earlier, understanding Operations
Manager requires knowing a bit more about management servers. This section
takes a slightly more detailed look at this important part of the product.
Root Management Servers
Every agent communicates with exactly one management
server. While many organizations could potentially meet their needs with a
single management server, it’s common to install two or more management
servers, then divide agents among these servers. In this case, the first server
that’s installed becomes the root management server. This root server
communicates with any other management servers that have been installed, and it
also communicates with its own agents.
The root management server performs several unique
functions. All of Operations Manager’s user interfaces connect only to the root
management server, for example, as shown earlier. Given this central role, it’s
common to cluster a root management server. (All of these connected management
servers rely on a single operational database, so it’s also a good idea to
cluster it.) If a root management server fails, an administrator can promote
another management server, allowing it to become the new root.
Management Groups
A collection of Operations Manager servers and agents is
known as a management group. Each management group contains one root
management server, zero or more other management servers, an operational
database, and zero or more agents. The figure below illustrates how the various
parts of a management group fit together.
Operations Manager can support many agents in a single
management group—the exact number depends on a variety of factors--but
organizations that need more than this can install multiple management groups.
And although it’s neither required nor shown in the diagram, a management group
can also contain a reporting server.
As
mentioned earlier, each agent is assigned to one primary management server. If
its assigned server becomes unavailable, an agent will automatically begin
communicating with another management server in its management group. When its
primary management server reappears, the agent will switch back to it. In both
cases, no administrative intervention is necessary. While an administrator can
explicitly control which management server an agent should communicate with if
its primary server fails, this isn’t required.
Another option is to create tiered management
groups. With this approach, the root management server in a local
management group is associated with the root management server in a connected
management group. Once this is done, it’s possible to monitor and manage the
connected group from the console of the local group. There are some
limitations—the console doesn’t support performing all administrative actions
in the connected group—but this option can make sense in some situations. For
example, creating tiered management groups can be a useful way to connect
groups within any large Operations Manager deployment. It can also make sense
when connecting a management group at headquarters with a subordinate
management group in a branch office, particularly if the branch is accessed via
a lower-speed connection.
Especially in large enterprises, installing more than one
systems management product is common. Making a multi-vendor management
environment work well can require connecting these products together. To allow
this, Operations Manager includes the Operations Manager Connector Framework
(MCF). MCF allows other management products to exchange alerts and other
information with an Operations Manager management server, making it easier to
use multiple tools in a single organization.
Some organizations, such as government agencies, have a
legal requirement to track failed logins, multiple login attempts, and other
security-related aspects of their IT environments. To provide direct support
for this, Operations Manager includes the Audit Collection Service (ACS). This
service relies on its own database maintained by a management server. If ACS is
used, relevant security information is sent to the ACS database rather than to
the standard operational database, making it simpler for organizations to
comply with their legal mandate.
Understanding Agents
Management servers are an important part of Operations
Manager, but they’d be useless without agents. This section takes a closer look
at what agents do and how they do it.
Installing Agents
Before an agent can do anything useful, it must be
installed on a target computer. One option is to install agents manually on
individual machines. Yet especially in a large organization, installing agents
individually on all of the managed systems can be an onerous task. To make
installation easier, Operations Manager provides a wizard that lets an operator
query Active Directory for machines matching some criteria, then install agents
on all of them. And for organizations that use Microsoft Systems Management
Server (SMS) or its successor, System Center Configuration Manager 2007, either
of these products can also be used to install agents.
However it’s installed, a new agent needs to determine
which management server it should communicate with. For installations that use
Active Directory, the wizard allows specifying the management server each agent
should talk to. For manually installed agents, the person performing the installation
can explicitly specify a management server. If no server is specified, a
manually installed agent as well as one installed by a tool such as
Configuration Manager will contact Active
Directory when it first starts running to learn which management server it
should communicate with.
How Agents Gather and Send Information
Once it’s installed, an agent’s behavior is defined
entirely by the management packs that are downloaded to that machine. The
monitors, rules, and other information in each MP tell the agent what objects
it should monitor and determine what information it sends to a management
server. To acquire this information, agents can do several things, including:
n
Watching the event log on this
machine. An agent reads everything that’s placed in this log.
n
Accessing Windows Management
Instrumentation (WMI). WMI is an interface to the Windows operating system that
allows access to a variety of information about the hardware and software on a
machine. This interface is Microsoft’s implementation of the Web-Based
Enterprise Management (WBEM) standard created by the Distributed
Management Task Force (DMTF).
n
Running scripts provided by a
management pack to collect specific information.
n
Accessing performance counters.
n
Executing synthetic transactions. A
synthetic transaction accesses an application as if it were a user of that
application, such as by attempting to login or requesting a web page. In some
situations, such as with applications that generate little useful management
information, synthetic transactions are the best way to learn about an
application’s state. They can also be used to determine current
characteristics, such as whether the login process is taking an abnormal amount
of time.
Based on the rules and monitors in the management packs installed
on its system, an agent sends events, alerts, and performance data to its
associated management server. The management server writes all of this
information to both the operational database and the data warehouse, making it
available for immediate use and for creating reports. Management servers can
also communicate with agents, instructing them to do things such as change a
rule in a management pack, install a new management pack, or run a task.
With MOM 2005, 90% of the traffic between an agent and a
management server was commonly performance data sent by rules. To minimize this
traffic (and the storage requirements it implies), Operations Manager allows
setting the relevant rules in a management pack so that no new performance
information is transmitted unless a value has changed by, say, at least 5%. The
management server can then infer that nothing has changed significantly if it
receives no new information. For example, think about an agent that’s
monitoring free disk space on a server. This number is likely to be the same
over many hours, and so it makes sense to send performance information only
when a significant change occurs.
It’s worth pointing out that not every shutdown of an
application or machine indicates a problem; scheduled maintenance can require
scheduled downtime. To prevent an agent from sending needless alerts in this
case, an operator can put some or all of the objects on a system into maintenance
mode. If just one database needs fixing, for example, that single object
could be placed into maintenance mode. Similarly, an entire application or an
entire machine can be placed in maintenance mode if necessary. The goal is to
avoid distracting operators with meaningless alerts during scheduled shutdowns.
Like any other software, agents execute under some
identity. A simple approach would be to have the entire agent run under a
single identity using a single account. While this works, it’s not an optimal
solution (although it is what’s done in MOM 2005). The problem with this is that
the agent’s identity needs to have the union of all permissions required by the
management packs installed on that system. The result is that agents tend to
have identities with lots of privileges, something that doesn’t make most IT
operations people especially happy. To avoid this problem, Operations Manager
introduces the idea of run-as execution. Rather than assign a single
identity to an agent, an administrator can instead define individual
identities—separate accounts—for different things this agent does. If
necessary, individual parts of a management pack, such as a monitor or a rule,
can be assigned specific identities, then run as that identity. Rather than
assigning agents a single account with many privileges, each function the agent
performs can instead have only the permissions it needs.
Agents communicate with management servers using a
Microsoft-defined protocol. Each agent maintain a queue of information to be
sent, which allows prioritizing traffic—alerts always go to the front of the
queue. If connectivity is lost, the queue stores information until the
management server is reachable again. The communication protocol between agents
and management servers also provides compression to reduce the bandwidth
required, along with Kerberos-based security. Both the management server and
the agent must prove their identities using Kerberos mutual authentication, and
information sent between the two is encrypted using the standard Kerberos
approach.
For agents that aren’t part of a Windows domain, such as
those running on web servers in a DMZ, security between agents and managers can
use certificates installed on both sides rather than Kerberos. A management
server can also use certificate-based security to communicate with another
management server. Referred to as a gateway server, this second
management server might be in an untrusted Active Directory forest, for
example. This option is also useful for a service provider that wishes to
manage other organizations by connecting to their management servers across the
Internet.
Working with Many Agents: Managing Clients
Managing desktops is different from managing servers in a
number of ways. One of the most important—and most obvious—is that there are a
lot more desktop machines than there are servers. To allow operators to work
effectively with large numbers of clients, Operations Manager provides a couple
of options.
One approach, called aggregate client monitoring,
exploits the fact that operators typically don’t need to monitor the exact
state of every client machine. Instead, an operator can define client groups,
then keep track of the state of the entire group. She can still run tasks and
do other things to individual machines, but having a single state available for
all of the machines in the group makes monitoring easier. This option also
allows running reports on client groups showing things such as the percentage
of machines that have acceptable performance each month or the number of
systems that experienced down time when upgraded to Office 2007. In fact, it’s
likely that most organizations will find that the ability to create these broad
reports is the most valuable aspect of aggregate client monitoring.
A second option for working with clients effectively is mission-critical
client monitoring. Here, an operator chooses specific desktop machines to
monitor directly. Operations staff in a financial services firm might choose to
include each trader’s desktop machine, for example, while those in a retail
environment might specify all of the critical point-of-sale systems. This
approach lets the most important clients be monitored directly without
requiring that every desktop machine get this level of attention.
Combining the two approaches is also possible. IT
operations staff might use aggregate monitoring to manage most desktops in
groups, for example, while still choosing specific clients for mission-critical
monitoring. And like most things in Operations Manager, how a client is
monitored is determined by the management pack that’s installed on that system.
Working with No Agents: Agentless Management
Not everything that needs to be managed is capable of
running an Operations Manager agent. Because of this, it’s also possible to
manage systems without agents. The absence of an agent limits what can be done,
but this approach can still be useful in some situations.
One option, agentless exception monitoring (AEM),
relies on the Windows Error Reporting client, a standard part of Windows,
rather than an Operations Manager agent. This client notices application and
operating system crashes, then asks the user for permission to send this
information to Microsoft (a prompt with which most people are familiar). With
AEM, this information can be sent to Operations Manager servers, letting
operations staff examine it, create reports based on it, and decide whether it
should be forwarded to Microsoft’s main database. While AEM provides only
limited information about Windows machines, it does offer a way to track some
important aspects of a machine and the applications running on it.
Another option, one that targets non-Windows devices, is
the ability to monitor other systems using SNMP or WS-Management. Using this
approach, Operations Manager can work with routers, switches, printers, and
anything else that supports either of these standard protocols. The diagram
below shows a simple illustration of how this might look.
As the diagram shows, both management servers and agents
are capable of monitoring devices (although agents are the most common choice).
While Operations Manager provides built-in support for SNMP and WS-Management,
this kind of monitoring also requires installing a management pack that knows
how to work with the device being monitored. Management packs that allow this
are available for equipment from Cisco, HP, and other vendors.
It’s fair to say that the focus of Operations Manager is
monitoring and managing Windows desktops and Windows servers. Still, the
ability to work with other kinds of devices can also be important. The
product’s support for SNMP and WS-Management, together with the appropriate
management packs, makes this possible.
Agents generate a large amount of information. To let
operations staff use this information effectively, Operations Manager provides
two options: immediate access via interactive user interfaces and the ability
to run historical reports. This section looks at both.
User Interfaces
As shown earlier, Operations Manager includes three
distinct user interfaces: the console, the Web console, and the command shell.
All three are useful, and understanding Operations Manager requires knowing
something about each one.
The Console
The Operations Manager console is the primary interface
for most users of the product. Information sent by agents, including events,
alerts, and performance data, can be written into this database, and so the
console presents a current view of what’s happening in the environment.
Operations staff can also run reports from the console, providing them with a
historical perspective.
Presenting the vast amount of available information in a
coherent way is challenging. Operations Manager addresses this challenge by
displaying monitoring information in a number of different views, each
accessible through the console. The best way to get a sense of what this looks
like is to see some of the most important of these views.
The screen shot below shows the console’s State view. This
example shows the state of SQL Server’s database engine, but State views are
available for many objects in the environment. As this screen shows, this view
provides a quick way to see what parts of the object are healthy (those with
green labels) and which are not (those with red labels). The content of this
view is derived from information sent by the monitors defined in the management
pack for this component.
Having a summary
picture of an object’s state is useful. It’s also important to know when
something has happened to an object that requires attention. The console’s
Alerts view provides this. As the screen shot below illustrates, this view
shows the active alerts in this managed environment. In this example, two
databases are offline, and so two alerts are displayed. Details for one of these
alerts are shown in the lower pane, including knowledge supplied by the
management pack for this component. As described earlier, the goal of this
knowledge is to help the operator resolve whatever is causing this alert.
Both monitors and
rules can send an alert, and either one can also send an event. Operations
Manager provides an Events view to display these events, although that view
isn’t shown here. Performance data, however, is sent solely by rules. To
display this information, the console provides a Performance view, an example
of which is shown below. This example graphs the performance of a server
machine’s processor, but management packs can include rules that send a variety
of other performance data.
Having different
views is nice—in fact, it’s essential—but being able to see several things at
once is also useful. To allow this, the Operations Manager console lets its
users create Dashboard views. Each dashboard shows a customized combination of
other views. For example, the screen shot below shows a dashboard created to
monitor SQL Server, and it includes state information, performance data (this
time showing free disk space), and more. In a typical organization, dashboards
are likely to be a common approach to monitoring the computing environment.
The Web Console
Most often, an operator will use the Operations Manager
console, which typically runs on a machine that’s inside an organization’s
firewall. Yet what happens when the operator is at home or in a hotel room, but
still needs access to Operations Manager? The Web console was created for
situations like these. Using this tool, an operator can perform a (large)
subset of the functions possible with the main Operations Manager console.
Like the main console, the Web console provides a variety
of views, including a State view, an Alerts view, a Performance view, a
Dashboard view, and more. In general, these views look much their counterparts
in the main console. Here’s the Web console version of the Alerts view, for
instance:
As in the main console Alerts view, this one shows active
alerts, then allows a closer look at an alert’s details. This once again
includes any knowledge supplied by the management pack about how to resolve
this alert. Other Web console views provide similar information with similar
layouts to the corresponding main console view.
The Web console isn’t intended to replace Operations
Manager’s main console. Instead, providing a Web-based option lets some of the
most important management functions be performed from any place with an
Internet connection. The goal is to make life better for the people who keep
distributed environments running.
The Command Shell
Graphical interfaces are usually the right choice for
monitoring an environment. How else could a range of diverse information be
displayed in an intelligible way? Given this reality, it’s fair to say that the
Operations Manager console and the Web console will be the most popular
interfaces to this product. Yet there are cases where a standard graphical
interface isn’t the best option. While it’s great for displaying information, a
point-and-click approach can be inefficient and slow for running commands or creating
scripts. In situations like this, a traditional command line interface can be a
better choice.
To allow this, Operations Manager provides the command
shell. Built using Microsoft PowerShell, it gives users a command line
interface as well as the ability to create programs called cmdlets.
Operations Manager provides a set of built-in cmdlets, such as get-Alert to
access alerts on a particular managed component, get-ManagementPack to learn
about an installed management pack, and others. Its users can also create their
own cmdlets. For example, suppose an operator wishes to disable all rules in
all management packs that target databases. Doing this manually via the console
would be possible, but it would also be painful. Writing a script for this,
perhaps relying on one or more built-in cmdlets, would probably be easier.
Other Options
With three user interface options—the console, the Web
console, and the command shell—it might seem like Operations Manager covers all
of the possible bases. But what if a third party, such as another software firm
or in-house developers at a large organization, wishes to create a custom
interface to the product? To allow this, Operations Manager provides a software
development kit (SDK). This set of programmable interfaces makes available all
of the functionality provided by the console, and so third parties can create
software that does anything the console allows. While this approach probably
won’t be a mainstream choice, it’s an important option to have in some cases.
Interactive user interfaces are certainly
important—they’re essential—but nobody spends all of their time in front of a
screen. Yet problems can arise that require attention even when no one sees an
on-screen alert. To handle cases like this, Operations Manager allows operators
to determine which alerts should send notifications. For example, an operator
might wish to receive a notification for any alert generated by a Windows
server system in her firm’s main office that has remained unresolved for more
than 60 minutes. This notification might be sent as an email, an instant
message, an SMS text message, or something else, and it provides a way to reach
an operator who’s not currently sitting at the console. The goal is to allow
people to learn about problems that need their attention no matter where they
might be.
Reporting
Interactive access to management information is
fundamental to effective management. Yet seeing trends and understanding
long-term behavior of the managed components requires more than an interactive
interface. The ability to generate reports is also essential.
As shown earlier, reporting in Operations Manager depends
on a reporting server. This server is built on SQL Server Reporting Services,
although it makes some additions to this base technology. Relying on the
Operations Manager data warehouse, a reporting server can be installed on the
same machine as a management server or on its own machine. Management servers
send data directly to the data warehouse—there’s no need to move it manually
from the operational database before running reports.
Operations Manager provides a number of built-in reports.
Among others, these generic reports include:
n
Performance reports, which can
display the performance of various things over a specified period of time.
n
Alert reports, providing a view
into the alert histories of managed components.
n
Event reports, allowing long-term
tracking of events sent by a component.
n
Availability reports, showing the
history of availability for managed components.
For example, the performance report below shows CPU
utilization on a Windows Server machine over a ten-day period. As in SQL Server
Reporting Services, reports can be created as PDF files, as shown here, or in
other formats.
For all of the built-in reports, IT operations staff can
determine the components that should be included in the report, set the time
span covered (including defining relative dates, e.g., “two days ago”), and
control other options. Once they’re defined, reports can be run on demand or
scheduled to run regularly. A performance report might be set to run at 10 pm
each Sunday night, for example, while availability reports might run daily or
at other intervals.
Operations Manager reports can also be used in other ways.
A report can be interactive, for instance, so someone looking at an
availability report might click on a particular machine in that report, then be
presented with the console’s current State view for this machine. It’s also
possible to see other views, execute tasks, and run other reports directly from
within the current report.
Although reports must be run from the console—the Web
console can’t be used—their output can be accessed directly from the Web. A
report can be sent to a document library in Windows SharePoint Services, for example,
making it easier for IT managers and others who don’t commonly have direct
console access to view them. In fact, some of Operations Manager’s built-in
reports are specifically targeted at IT managers rather than more technically
oriented operations people.
Reporting is a core part of most management technologies,
and Operations Manager is no exception. By providing its own data warehouse,
the product allows an organization to maintain large amounts of historical data
about the computing environment. By providing a range of built-in reports, it
lets operations staff and others access this information in useful ways.
Controlling Access: Role-Based Security
Operations Manager potentially allows access to anything
in the managed environment. Yet letting every user of this tool have full
access to everything isn’t what most organizations want. There must be some way
to control who can access information, run tasks, and do other management work.
The approach Operations Manager uses to do this is called role-based
security.
A role is defined as the combination of a profile
and a scope. A profile defines what operations someone can do, while a
scope specifies the objects on which she’s allowed to perform these operations.
The intersection of the two yields a limited set of objects on which an
operator is allowed to perform only a defined set of operations.
For example, a profile might allow someone to view alerts
and run tasks, but not allow him to change any rules in management packs.
Operations Manager provides a group of built-in profiles, including the
following:
n
Administrator: A user with this
profile can do anything—all operations are allowed on any objects (in fact,
scopes don’t apply to administrators). This profile will typically be limited
to a small number of people in an organization, since most operations staff
won’t need this level of power.
n
Author: As the name suggests, a
user with this profile can make changes to the environment. This includes
things such as creating and modifying rules and monitors in installed
management packs. An author can also monitor the environment, viewing events,
alerts, and other information
n
Operator: Users with this profile
are expected to focus primarily on monitoring the environment. Accordingly,
they can view events, alerts, and other information, but they’re not allowed to
create new rules, define new management packs, or make other changes.
Whatever profile a role is based on, a person in that role
can only perform operations on the objects specified by its scope (with the
exception of roles where scopes don’t apply, such as administrator). For
example, someone whose job was solely focused on keeping the email system
running might be given a role with an operator profile and a scope containing
only Exchange Server objects, views, and tasks. A co-worker whose
responsibilities were focused on managing an SAP application might be given a
role with an author profile and a scope containing only SAP-related objects,
views, and tasks. Standard roles are also defined, such as a Report Operator
role that controls the ability to run reports of various kinds. Used
intelligently, roles can give an organization fine-grained control over what
their operations staff is allowed to do.
Operations Manager provides a general foundation for
monitoring and managing systems and software. This foundation knows nothing
about how to do these things for specific components, however. Providing this
specialized knowledge is the responsibility of management packs.
As mentioned earlier, each MP is described using the
XML-based SDM. The Operations Manager console provides an authoring view that
can be used to create MPs, and Microsoft has announced plans to provide a
standalone MP authoring tool. And since they’re just XML, a determined author
could theoretically create an MP using Notepad, although this isn’t likely to
be a very productive approach. The important thing to understand is that an MP
primarily contains configuration information, not executable software.
Each MP is installed into the operational database, with
different parts of its contents then downloaded and used by different parts of
Operations Manager. It’s worth nothing that the MP format used by Operations
Manager isn’t the same as that used by its predecessor, MOM 2005. Because of
this, MPs created for this earlier technology must be converted using a
Microsoft-supplied tool, then re-installed into the operational database.
MPs are the brains of Operations Manager, determining
exactly how monitoring and management happen for each managed component.
Understanding them requires knowing something about what they contain and how
they function. The rest of this section digs a bit deeper into the structure
and contents of this important aspect of Operations Manager.
What Management Packs Do: Some Examples
To get a sense of what management packs do and of how
diverse their functions can be, it’s useful to look briefly at a few examples.
In all of these cases, the MPs provide information about the availability of
this component—is it running?—and basics such as how much space is left on the
disk it relies on. Each one also provides performance information about the
component it targets. Beyond these basics, however, different MPs provide quite
different things.
For example, MPs that target Windows server operating
systems let an operator determine things such as which Windows services are
running, which applications (if any) are crashing repeatedly, and whether IP
address conflicts are occurring. Operations Manager also provides MPs for
Windows client systems that let an operator learn whether this machine can
access the Internet, read from and write to file servers, and perform other
functions.
Just as Operations Manager supports both server and client
operating systems, it also supports MPs for applications running in both
places. Once again, the basics are the same, which each MP able to report
whether an application is running, monitor its performance, and provide other
standard information. Each one also provides application-specific information
as well. For example, the MP for Exchange Server lets an operator see detailed
information about mailboxes and messages, while the SQL Server MP provides data
about the number of deadlocks that occur, the execution of stored procedures,
and more.
Microsoft also provides an MP for Microsoft Office that
lets an operator see whether Office applications are crashing or hanging,
measure their resource consumption, and determine how responsive they are. He
can also determine whether they’re working normally, such as checking whether
Outlook can send and receive mail. All of these things are vitally important to
users, and so they’re also important to operations staff.
Describing What’s Managed: Objects
Every management pack defines a model, described in SDM,
of the component that it’s managing. This model is expressed as one or more classes,
each representing something that can be monitored and managed. A class also
defines attributes, values that can describe an object of that class.
When an MP’s information is sent down to an agent, the agent relies on specific
discovery rules in the MP to find the actual instances of the classes
this pack defines. To discover these instances, an agent might look for a
specific registry key, query WMI, or perform some other action. However it's
done, the result is a hierarchy of objects, each of some class and with a
specific set of attributes, representing the things this MP targets.
A note on terminology: When talking to management pack
authors, Microsoft uses the terms “class” and “instance”, concepts that are
familiar to developers. In the Operations Manager console, however, the terms
“target” and “object” are used instead. This paper uses “class” rather than
“target”, but the terms “instance” and “object” are used interchangeably
throughout.
When an agent is first deployed, it knows that it’s
running on a Windows computer. Accordingly, it creates an instance of a Windows
computer object, then asks its management server for all rules (including
discovery rules), monitors, and other relevant aspects of the Windows MP. Once
they’re downloaded, the discovery rules can find other objects on this machine,
such as SQL Server or a DNS server. The agent then requests that the rules,
monitors, discoveries, and so on for these classes also be downloaded from the
various MPs in which they’re contained. This process of progressive discovery
continues until all managed objects on the system have been found.
Using this approach, an agent constructs a hierarchy of
managed objects from multiple MPs. The figure below shows a simple picture of
how this might look.
The MP for the Windows Server operating system defines a
class for the computer it runs on, while the SQL Server MP defines classes representing
a SQL Server database and an instance of SQL Server itself. In this simplified
example, the computer object appears directly above two instances of SQL
Server. One of these instances has two SQL Server database objects below it,
while the other has only a single database object. All of this, along with
populating the attributes associated with each object, is created automatically
by the agent. And to catch any changes that occur, the discovery process is
regularly re-run, including each time the machine reboots or the agent on that
machine is restarted.
One more aspect of the figure above requires explanation:
the green checks in each object. This symbol represents the object’s state, as
illustrated in the console’s State view earlier. Each object’s state provides a
quick summary of its condition. One object’s state can affect another, however,
allowing a more intelligent perspective on what’s really happening. All of this
depends on monitors, and how it works is described next.
Tracking Object State: Monitors
A primary goal of management is keeping software and the
hardware it depends on running well. One way to do this is to wait until
something fails, then fix it. This approach can work, but it’s usually not the
best solution. Just as with our personal health, avoiding problems before they
happen is much better. Rather than just react to potentially catastrophic
failures, we can keep track of the health of the objects we’re managing to
prevent serious problems whenever possible. In other words, we can create and
monitor a health model for a component.
Operations Manager relies on monitors to do this. Each
monitor reflects the state of some aspect of an object, changing as that state
changes. For example, a monitor tracking disk utilization might be in one of
three states: green if the disk is less than 75% full, yellow if it’s between
75% and 90% full, and red if the disk is more than 90% utilized. A monitor
tracking a particular application’s availability might have only two states:
green if the application is running and red if it’s not.
The author of each management pack defines what monitors
it contains, how many states each monitor has, and what aspect of the managed
object this monitor tracks. A monitor can determine what its state should be in
several different ways. It might examine particular performance counters every
90 seconds, for example, or regularly issue a particular WMI query. A monitor
might also watch the event log for events that affect its state. Think, for
example, about a monitor representing whether an application can communicate
with a particular database. The application might write an event to the event
log when this communication fails, causing the monitor to change its state to
red. When communication is restored, the application might write a new event
indicating this, causing the monitor to change its state back to green. This
example illustrates an important fact about monitors (and about application
manageability in general): Applications should be written in certain ways to
make themselves manageable—they should be instrumented—and the creators
of management packs must know how to take advantage of this instrumentation.
Whenever a monitor changes its state, this change is sent
to both the operational database and the data warehouse. This information
allows the operator to see the current state of an object or group of objects.
The console State view shown earlier is just a window into the set of monitors
that represent the state of one or more managed objects.
All of the monitors for a particular managed object are
organized into a hierarchy. Every monitor hierarchy has four standard monitors
that live just below its root: performance, security, configuration, and
availability. Each monitor defined by a management pack appears below one of
these four, with the choice made by the management pack’s author. Any change in
a monitor’s state can cause a change in the state of the monitor above it. This
allows problems to bubble up through the hierarchy of monitors and the objects
whose states they represent.
The figure above, which uses the same simple set of
objects shown earlier, illustrates how monitor states can percolate through a
hierarchy of managed objects. In this example Database 1 has a problem: perhaps
a disk drive has failed. The monitor that watches this aspect of the database
notices this and sets its state to red. This state change causes the standard
availability monitor for this object to also set its state to red, which in turn
sets the monitor for the object’s overall state to red.
The monitor for the database’s overall state also appears
in the monitor hierarchy for its parent object, SQL Server 1. This object has
two databases, however, only one of which has failed. Accordingly, this
object’s availability monitor is set to yellow rather than red, a decision that
was made by the author of the SQL Server management pack. This is once again
reflected in the overall state for this object, the state of which is also set
to yellow.
Just as the overall state of the database appeared in the
SQL Server 1 monitor hierarchy, the overall state of this SQL Server instance
appears in the Computer object. (Recall that Computer is defined in a different
MP from the other objects shown here—MP boundaries don’t limit this kind of
monitor interaction.) The Computer object also sets its availability monitor
and its overall state to yellow, indicating that while the computer is
functioning, there is a problem that needs attention.
Along with state changes, monitors can also send alerts,
events, and even performance data. Their primary role, however, is to provide
an accurate representation of state. By allowing the state of an object to
depend on the state of objects below it, monitors provide an intelligent way to
model the health of an entire system. Yet doing this requires creating an
effective set of monitors and relationships between those monitors. Put another
way, the people who create each management pack must be able to define an
appropriate health model for the component this pack targets. To do this for
its own products, Microsoft relies on input from the teams that create them,
from its customers, and from its own services group.
Other Elements of Management Packs
Monitors are essential to every management pack. As
mentioned earlier, however, MPs can also contain a number of other things. This
section gives brief descriptions of these, including rules, tasks, knowledge,
views, reports, and synthetic transactions.
Rules
Monitors and the health models they enable are fundamental
to how Operations Manager does its work. There are cases, however, where
monitors aren’t appropriate. Suppose a system needs to collect data regularly
from several performance counters, for instance, then send this information to
the management server and data warehouse. Because they’re designed to model
states, monitors aren’t capable of doing this.
To address this kind of problem, MPs include rules. A
simple way to think about rules is as an if/then statement. For example, an MP
for an application might contain rules such as the following:
n
If a message indicating that the
application is shutting down appears in the event log, send an alert.
n
If a logon attempt fails, send an
event indicating this failure.
n
If five minutes have elapsed since
the last update was sent and the new value is more than 2% different from the
previous one, send the value of the machine’s free disk space performance
counter.
As these examples show, rules can send alerts, events, or
performance data. Rules can also run scripts, allowing a rule to attempt to
restart a failed application. Even the discovery process described earlier
depends on specialized sets of discovery rules.
The distinction between monitors and rules can seem
subtle, but it’s not: monitors maintain state, rules don’t. Unlike monitors,
rules are just expressions of things an agent should do. If something changes
the state of an object, it should be modeled using a monitor. If it doesn’t
change an object’s state, an MP is likely to use a rule instead.
Tasks
A task is a script or other executable code that runs
either on the management server or on the server, client, or other device
that’s being managed. Tasks can potentially perform any kind of activity,
including restarting a failed application, deleting files, and more, subject to
the limitations of the identity they’re running under. Like other aspects of an
MP, each task is associated with a particular managed object. Running chkdsk
only makes sense on a disk drive, for example, while a task that restarts
Exchange Server is only meaningful on a system that’s running Exchange. If
necessary, an operator can also run the same task simultaneously on multiple
managed systems.
Monitors can have two special kinds of tasks associated
with them: diagnostic tasks that try to discover the cause of a problem, and
recovery tasks that try to fix the problem. These tasks can be run
automatically when the monitor enters an error state, providing an automated
way to solve problems. They can also be run manually, since automated recovery
isn’t always the preferred approach.
Knowledge
While tasks can help diagnose and fix problems, they
aren’t much good to an operator unless she knows which ones to use in a
particular situation. And like it or not, the skill level and experience of
operations staff isn’t always what their managers would like it to be. By
providing pre-packaged knowledge, a management pack can help less capable staff
find and fix problems more effectively.
As shown in an earlier screenshot, knowledge appears as
human-readable text in the console, and its goal is to help an operator
diagnose and fix problems. Embedded in this text can be links to tasks,
allowing the author of this knowledge to walk an operator through the recovery
process. For example, the operator might first be instructed to run task A,
then based on the result of this task, run either task B or task C. Knowledge
can also contain embedded links to performance views and to reports, giving the
operator direct access to information needed to solve a problem. And as with
every aspect of a management pack, an MP’s knowledge must be created by people
who deeply understand the component this pack addresses. If this isn’t the
case, the information it contains isn’t likely to be of much use to the
operators who depend on it.
Views
The Operations Manager console provides standard views for
State, Alerts, Performance, and more, as shown earlier. Yet a particular MP
might find it useful to include specialized views of its own. Since each pack
defines its own unique set of objects, its creators might also choose to
provide customized views that show only these objects, or only alerts on these
objects, or some other more specialized perspective. MPs can contain custom
views to address cases like these, and the people who create those MPs
frequently take advantage of this ability: custom views are common.
Reports
Just as a management pack can contain views customized for
the objects that MP targets, it can also contain custom reports. For example, a
management pack might include a customized definition of one of Operations
Manager’s built-in reports, specifying the exact objects that the report should
target. The creator of a management pack can also build custom reports from
scratch with the Report Definition Language (RDL) used with SQL Server
Reporting Services. More complex reports can also have stored procedures, use
indexes, and more, allowing reports that access lots of data to offer better
performance.
Modifying an Installed Management Pack
No matter how good the creators of a particular management
pack might be, there’s no way that they’ll set everything perfectly for all of
the environments that MP will be used in. Maybe a particular rule doesn’t make
sense in an organization, or perhaps an unnecessary alert is being sent. If an
MP allows it, operators with the right security permissions are able to change
some or all of what this MP defines to match their requirements. An MP can also
be sealed, however, which means that it can’t be directly modified. All
Microsoft-provided MPs are sealed, for example, as are some provided by third
parties.
Whether or not an MP is sealed, an operator can create overrides.
Rather than permanently changing the MP, an override makes a change without directly
modifying the underlying monitor or rule or other element. This lets the
operator revert to the MP’s original settings if necessary, an option that’s
often useful to have.
In the beginning, systems management focused on managing
servers. Today, this focus has expanded to include clients, applications, and
more. Yet in most cases, the real goal is to manage the services that people
actually use: email, line-of-business applications, and others. All of these
services are provided by combinations of hardware and software, and so managing
them as a whole requires some way to group together the relevant components
into a single manageable entity. This is exactly what Operations Manager’s
service monitoring allows.
Using the Distributed Application Designer, a tool
accessible via the authoring section of the Operations Manager console, an
administrator can define the various components that make up a service. This
designer provides standard templates for defining common application types,
such as messaging and line-of-business applications. These templates can be
customized as needed to reflect the details of a particular service. Once the
definition is complete, the tool generates a management pack for this service,
complete with a monitor-based health model. This MP can then be installed on
the relevant agents just like any other MP.
The screen shot below shows an example of how a
distributed application defined in this way might look. Using the console’s Diagram
view (which can also be applied to other aspects of the managed environment),
it shows the various components that make up this particular service: a web
application, the database it depends on, and more. As with any other health
model, this one shows a hierarchy of objects, each with a state. In this
example, one of the databases is in a red state, a problem that bubbles up to
the overall state for this service.
Monitoring and managing individual components of a service
is clearly useful. Yet adding the ability to manage all of these components as
a unified group with a single health model can provide significantly more
business value. As systems management continues to move toward ITIL-based IT
service management, tools that directly support this service-oriented view
become more important.
Conclusion
The computing environment of most organizations gets more
complex every day. The tools IT operations staffs use to monitor and manage
this environment must keep pace, adding the capabilities people need to do
their jobs. This evolution has been reflected in Microsoft’s offerings. From
its beginning as Microsoft Operations Manager 2000, a product focused on
managing servers, System Center Operations Manager 2007 now supports client
management, the ability to view distributed applications as unified services,
state-based management with health models, and more.
It’s a safe bet that information technology will continue
to advance. Even when those changes are improvements—and they usually are—they
still increase the management complexity of the environment. Given this, no one
should expect System Center Operations Manager 2007 to be the last word in
systems management. Yet for organizations with a significant investment in Microsoft
software, this tool can play a useful role in monitoring and managing their
world.
No comments:
Post a Comment