locked
Management pack tuning observations - Reasons I have seen for modifying a MP RRS feed

  • General discussion

  • I'm a dedicated SCOM support person for a large enterprise environment. A coworker and I were discussing the large amount of work that we have put into the vendor supplied MP's that we use. We typically end up disabling, modifying, or overriding a large percentage of these rules and monitors. Not to discount the level of work that went into these MP's including the product knowledge provided, discovery framework, data collection, reports and everything else that goes into these MP's. Obviously, even the best MP's will always require some customization.
     
    I thought I'd share some of our observations in the hope that they may be useful to others and as feedback to the product team. Please note that these observations are from a large, highly customized environment where all alerts are filtered through a single first-line support team.

     

    Reasons why we recreate MP rules and monitors:
     
    1. To gain access to settings that are not made available in the overrides.
    2. To add a repeat count, recovery, or other means to reduce alerts on temp conditions or reduce frequency.
    3. To consolidate multiple alerts for the same issue
    4. To consolidate alerts with the same troubleshooting steps
    5. To reduce alerts during maintenance, software updates, backups, network outages, and other factors.
    6. To convert a rule to a monitor or vice versa to access available functionality.
    7. To replace poorly worded alert messages names or descriptions.
     
    Reasons why we disable rules:
     
    1. We disable all warning or critical level alerts that are informational or successful in nature.
    2. We disable all monitoring that is duplicate with base server monitoring (hardware, OS, custom).
    3. We disable all monitoring that doesn't relate to actionable troubleshooting steps (if we can't fix it we don't want to see it).
    4. We disable a lot of external dependency monitoring. For example, Exchange alerts on AD availability that is duplicate to monitoring from the AD MP)
    5. We disable all 'baseline' alerting from the Exchange MP.
    6. We disable any alerts that are determined not to be a real issue in our environment; or any environment. (Including that alerts nobody seems to know the root cause or fix)
     
    Reason why we implement overrides:
     
    1. To disable auto resolution on all monitors due to alerts being routed to a seperate alert management tool.
    2. To modify the priority or severity to meet our alerting needs.
    3. To disable rules and monitors...either to prevent alerting or recreate with changes.
    4. To modify thresholds when available; though the meaning of the overridealbe thresholds is sometimes unclear.
     
    Overrides that don't appear to be possible or are rarely available:
     
    1. Modify the alert name and description.
    2. Modify the custom fields and alert suppression criteria.
    3. Ability to add recoveries and diagnostics to sealed rules and monitors.
    4. The ability to add views to sealed management packs as an override.
    5. Common overrides are often not made available like priority and severity; in some MP's.
     
    Recommendation:
     
    1. Increase the number of default overrides that are on every rule\monitor in addition to enable\disable.
    2. Set all overridable settings to enabled by default in the authoring console and admin console when creating new monitoring. (Basically, more override options = less work for guys like me)
     
    Thursday, October 30, 2008 4:26 PM

All replies

  • Hi,


    Thanks for sharing the information with us. It's very useful for both SCOM users and SCE users.

    Tuesday, November 4, 2008 9:41 AM
  • Thanks for the insight, we are actively working on coming up with a happy medium. Something that works for Essentials out of the box and can be easily customized if needed by the admin. Your suggestions are something we will look into incorporating in our next version of Mps.

     

    Thanks and appreciate you taking your time to share your thoughts.

     

    Tuesday, December 9, 2008 12:58 AM
  • I wish there were ways to modify severity and priority levels. It seems very limited to me that severity can only be "Information", "Warning" or "Critical". I'd like to see a severity level saying "Mayor" or "Severe".
    Maybe anyone has experience with using custom severity and priority levels for alert notifications. Any ideas are welcome.
    Wednesday, January 14, 2009 6:10 PM
  • Do you disable the alerts as they come in or do you proactively go through the management packs and disable the rules as you see fit?

    Thanks for the post it is a good read!
    Thursday, January 21, 2010 9:06 PM