Basic Performance Metric Collection for Group

Step 1:  Open SCOM Operator’s Console

Step 2:  Go to the Authoring Tab

Step 3:  Create New Rule

image

image

image

image

image

image

image

image

image

image

image

Advertisements
This entry was posted in Generic SCOM Information, Management Pack Authoring. Bookmark the permalink.

5 Responses to Basic Performance Metric Collection for Group

  1. Jonathan Almquist says:

    I don’t mean to sound nitpicky, but the use of groups for target anything other than an override is not best practice. I see this happen all the time, though. I’ve even done this in the past, but only because I didn’t realize the potential impact this could have on a management group. It is never necessary to create a monitoring workflow disabled and enable for a group. It is always possible to discover the computers you really want to target, and then create your monitor or rule enabled at that class or type.

    • randorfer says:

      Hey Johnathan,

      If you notice this whole post is done in the Operators Console. Not all of our application owners need to know about classes / discoveries. This post is targeted at that group of people (people who know what perf counter / event they want to collect and can define a group of servers based on naming standards to collect it for). It is all about making the initial steps into SCOM easy for our application owners and moving them along the steep SCOM learning curve as needed.

  2. Kevin Holman says:

    “Jonathan Almquist says:
    I don’t mean to sound nitpicky, but the use of groups for target anything other than an override is not best practice.”

    I just completely disagree with that statement. Groups are used for scoping views, notifications, overrides, used in reports, even used for monitoring by rolling up state.

    The simple use of targeting a generic class with a workflow as disabled, and enabling it for a group, is very much valid, in my opinion. It does have drawbacks, especially in relation to monitors and seeing this monitor in Health Explorer. Targeting a custom class is almost always better…. but this approach is certain not invlaid, and certainly a LOT simpler for a team to enable something as simple as performance collection for a group of servers, where a group already exists and a class does not.

  3. Jonathan Almquist says:

    Let me rephrase. The use of groups for targeting *monitoring workflows* is not best practice. I wasn’t referring to views, notifications, etc… We can agree to disagree, but I do understand that this is the easiest way to implement some types of monitoring or collection for a set of servers.

  4. Jonathan Almquist says:

    Incidentally, the reason it is not the best practice is because there are in fact some drawbacks. Think about where this workflow will be delivered after you create it. Whether the monitoring workflow is created disabled or enabled, the management pack will be delivered to all agents that have discovered the class your targeting. If you’re targeting some generic class for this collection rule, like Windows Operating System, now all your agents (except xplat) will have a copy of that MP and will get a new copy of that MP anytime *anything* changes in that MP. That’s a significant config update for something seemingly so harmless and basic.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s