Using SCOM for VMware monitoring: Experts’ Tips

Cameron FullerMicrosoft System Center MVP

Alec KingProduct Management Director at Veeam Software

Pete ZergerMicrosoft System Center MVP

What’s in?

Monitoring with the “virtualization stack” in mind

Data sources and solution architectures

Actionable alerts vs. “alert noise”

Creating a dynamic user experience

Reporting for trending, capacity planning and forecasting

Override behavior and 4 Tips for proper override tuning

Storage monitoring

Storage monitoring solutions can be very esoteric and expensive.

A virtualization monitoring solution that points SCOM and VMware administrators to problems at this layer is a welcome addition indeed.

When SCOM is blind

There are aspects of the virtual infrastructure that are not visible to SCOM through its agents:

vSphere‐specific metrics for the VM such as balloon memory and CPU wait time;

Important components of vSphere including ESX(i) hosts, clusters and vCenter Server;

Automation within vSphere directly affecting VMs, such as Distributed Resource Scheduler (DRS), vMotion and High Availability (HA)

Continuous Visibility

Without visibility of vSphere as a whole, it is impossible to monitor such critical aspects of vSphere as:

Physical hardware status

VM status and location

ESX(i) host performance

“Virtualization stack”

Byyou can effectively combine the power of SCOM and vSphere monitoring to provide a more comprehensive monitoring solution.

monitoring with the virtualization stack in mind,

Data sources and solution architectures

You can get information on vSphere performance from different data sources, including:

SNMP; Syslog; VMcontrol-based APIs; Web Service SDK;

It is important to understand which sources expose the data needed to quickly identify and isolate common issues and to understand the PROs & CONs of each approach.

SNMP & Syslog: PROs & CONs

SNMP Syslog

PRO

vSphere is SNMP-enabled, and SNMP monitoring is configurable through the System Center Operations Console UI (user interface).

Syslog messages from vSphere are a rich source of hardware monitoring data, and rules that utilize Syslog can be configured using the UI wizards in the System Center Operations Console.

CON

Many VMware Infrastructure 3 (VI3), vSphere4 and vSphere 4.1 events and performance metrics are not exposed via SNMP.

VMware is no longer focusing on management via SNMP.

Messages tend to be cryptic, and most are of little use to most operators without time-consuming translation to a human interpretable error message.

vmcontrol-based APIs & Web Service SDK

vmcontrol-based APIs (including vmPerl / vmCOM)

Web Service SDK (requires vCenter Server)

COM was deprecated some time ago, so you should avoid using this altogether.

While vSphere does offer an SDK for Perl, Perl is not a Windows-friendly option, and is probably the least documented in terms of samples on the Internet.

This is the richest source of vSphere performance data with the lowest impact on host and guest performance.

It provides the most complete picture of infrastructure and application performance and health with the best scalability from a vSphere perspective.

Other methods

There are also various methods available for monitoring servers in the virtual infrastructure.

For more practical information on the other monitoring methods and the PROs & CONs of each of them, please, refer to the full version of Veeam’s featured White-Paper

“Best Practices for Monitoring VMware with SCOM”

available at www.veeam.com/whitepapers.html

Catch the problem before it grows

The best thing to keep in mind for productive VMware monitoring is:

“catch the little problems before they become major issues that cause service interruptions”

To bring this principle into reality you should set critical alerts appropriately.

“One Man’s Trash Is Another Man’s Treasure”

The goal of SCOM is to notify administrators of issues before they become a major problem.

But with all the alerts SCOM is way too “noisy” (at least in some environments).

“Noise” is generated when alerts (usually sent via email) are created by SCOM for situations that are not actionable, relevant or unique.

When SCOM is “noisy”

When someone tells you SCOM is “noisy” you should remember, that…

1. …you can generate alerts that are only displayed in the SCOM console and are not necessarily sent by emails.

2. …the SCOM management packs are designed to be used by organizations that range from relatively small to large-scale enterprise environments and thus should be configured accordingly.

3. …SCOM requires a proper tuning to match the requirements of an organization fully — and it’s perfectly tunable (See slide 15 for a hint)!

Crucial Alerts vs. “Alert Noise”

Tune up the SCOM alert system to provide only actionable alerting matching the needs of your business.

That way you ensure that the notifications that are sent will be acted upon and not regarded as “alert noise”.

Customize your User Experience

The SCOM console needs to be targeted to show only the information that is relevant to the specific user, including the user’s servers and applications.

Dynamic User Experience

Using user groups is a great way to ensure that every operator is getting information relevant to his\her responsibilities.

There are 2 general categories of groups in SCOM:

Static groups are created by adding specific entities to the group as explicit members. Static groups are useful when there are no specific criteria that define group membership.

Dynamic groups are created by setting criteria that define what entities are members of the group. Entities matching those criteria are automatically added to the group.

Capacity Trends

The SCOM Data Warehouse provides reports on the trends over a significant period of time that is customizable to your business requirements.

By integrating performance data into SCOM we can generate trend reports on custom metrics (such as CPU Wait Time) to see if additional capacity is currently required.

Capacity Planning & Forecasting

In order to identify and resolve an issue before it affects the users, SCOM should be able to not only see trends on performance metrics but also to forecast on metrics based upon the history of the data.

However, SCOM lacks an off-the-shelf report for forecasting and capacity planning.

To make projections of future resource consumption you need to integrate an additional reporting software, such as, e.g., Veeam Reporter™.

Veeam Reporting Solution

Veeam Reporter, now available as a part of Veeam ONE™ solution, provides extensive capacity planning & change management functionality.

It discovers, documents and analyzes your entire virtual infrastructure and maintains a complete history of all objects, settings and changes.

Armed with knowledge of your virtual environment’s configuration and its past and current utilization, it makes recommendations for resource allocations and acquisitions.

Overrides

When customizing SCOM for VMware monitoring don’t forget about the overrides:

Overrides are used to enable, disable or modify monitoring elements in a management pack (rules, monitors, discoveries, and so on);

Override precedence is a “rule of the road” regarding override behavior with multiple overrides present on a single rule, monitor or discovery.

Override precedence: rules of the road

Take these “rules of the road” into consideration to control override precedence:

The most specific override takes precedence. An enforced override takes precedence. Overrides in unsealed management packs take

precedence. Class overrides from contained or hosted instances

take precedence over class overrides of the instance. Instance overrides with the higher relative depth take

precedence over those with a lower depth.

Taking full control over Overrides

Override precedence is just one thing. To take full control over overrides, keep the following 4 tips in mind when tuning your SCOM environment:

1.Use classes where possible

2. Target overrides to a group VS. an entity

3.Use dynamic groups when possible

4.Create relevant groups for entities

If a class already exists that meets your requirements, use the class instead of a custom group (unless you need to create the group for other reasons such as customizing the user experience).

Tip #1. Use classes where possible

Tip #2. Target overrides to a group VS. an entity

Using groups allows these overrides to be portable so that they can be moved between SCOM environments.

This approach also minimizes the number of overrides required by gathering similar systems and applying a single override to the group.

Tip #3. Use dynamic groups when possible

Static groups require maintenance to add and remove members of the group as agents are deployed or removed from the environment.

Dynamic groups do not require this added maintenance.

Tip #4. Create relevant groups for entities

Groups can contain any type of entity, not just servers. SCOM automatically provides an alert when the default application pool or default website is not running.

While removal of these websites and application pools are the recommended approach, you can instead generate a group that contains the entities that match the name and then disable the monitor for that group of entities.

Got more questions?

For more details downloadfree White Paper

“Best Practices for Monitoring VMware with SCOM”

Get more free content(webinars, white papers, product demos):