Positives and negatives splitting monitoring between production and non-production systems (#SCOM, #SYSCTR)

A little while back I was asked a question that I wanted to spend some time on answering with more than a quick reply. The question is below:

Why do you suggest that a parallel SCOM implementation always be set up to monitor a Quality Assurance/Development environment? My manager is trying to lighten our footprint, and is wondering.

The following are my thoughts on the positives and negatives to having a QA/Development environment (or test environment as I will refer to it during this blog post) for OpsMgr/SCOM.

 

Positives:

  • A test environment is required to provide a way to test changes in monitoring before they occur in production. 
  • Monitoring can be developed in one environment, and then migrated into the production environment.
  • A test environment provides a way to test Cumulative Updates and new versions of Microsoft management packs before they are rolled into production.
  • The alerts that appear in the production environment are production actionable alerts.
  • When all systems are together in one environment, situations occur where overrides need to be created for specific sets of servers specifically because they are not production systems. IE: I don’t want any alerts on my test systems, but send an alert if they are offline. Maintaining separate environments removes this issue.

 

Negatives:

  • There is additional overhead required to maintain the additional OpsMgr environment (patching, resources required, etc).  [To minimize this overhead, an all-in-one OpsMgr environment can be used which while it does not replicate the full configuration of the production environment, it provides most of the benefits of having a test environment.]
  • Having a test environment means that there will be different consoles which will need to be used to monitor depending on whether the system is or is not a production system.

 

Thank you to Blake Wilson, Paul Johnson and Stephen Leuthold for their insights!

 

How about you, have you seen additional positives or negatives or have a different perspective on one list above? If so, please let me know by adding a comment on this blog post!

3 thoughts on “Positives and negatives splitting monitoring between production and non-production systems (#SCOM, #SYSCTR)

  1. Reza

    Perhaps the footprint may not be lightened but Orchestrator surely deserves consideration if productivity improvement is an objective.

  2. vbpav

    I would concur with Cameron on the pros as well. As long as the organization has the capacity for multiple environments, this is indeed the way to go. My experiences with the Veeam MP for VMware helps lead me to this conclusion.

    The Veeam MP for VMware not only has a Management Pack component, but, it also has two infrastructure components; Enterprise Manager Server, and Collector Server. Typically, every single Veeam MP release will require an upgrade of these three different components (may I suggest always looking over the "Upgrade Procedure" section of our Veeam MP Installation Guide). It is extremely helpful to have an independent OpsMgr and Veeam MP Infrastructure for dev/test to verify not only a successful upgrade, but, to insure your previous customizations are still applicable.

    This level of testing is the best way to ensure a successful upgrade of the Veeam MP for VMware in your production OpsMgr environment.

  3. Michiel Wouters

    I fully support working with at least two environments. One for production and one for non-production.

    But beware that when creating management pack content with the Management Pack Templates in the Console, this delivers some challenges when exporting and importing the management pack in your production environment.

    Usually this requires some light modifications after importing the MP, like selecting an existing watcher nodes or selecting a Management Server Pool for Global Service Monitor items. But accepting these caveats, gives you two simular working environments.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.