vROPS: Beware of a Whole Lotta Metrics creating the Spaghetti Incident

When doing consultancy at organisations I often find a vRealize Operations, vROPS (or vCOPS) initial deployment left alone because of the IT operations department responsible persons are overwhelmed by the information you (can) receive from vROPS (manager and optionally other suite components). Mostly this is because of the lack of time invested in getting to know the product as admins are busy with reacting to operational actions/issues and operational processes. The downside of this is that perfectly useful pieces of information, recommendations and actions are left alone and the virtual infrastructure (and the IT admins) suffers from neglect. Which in turn only increases the stated problem and were all going down the same roundabout round and round without getting to leave at the vROPS successful exit. This is what we don’t want.

But start at the why we want vROPS in the first place:

  • Continual visibility gained across virtual and physical infrastructure.
  • Pro-actively identify and solve emerging issues with predictive analytic and smart alerts and re-mediation.
  • Reclaim unused resources and capacity, getting the other VM’s happier while saving on unnecessary investments (assets and people).
  • Unified IT Management, complete visibility in one place, across applications, cloud, storage and network devices; with an open and extensible Operations Manager architecture.

With the latter, that extensible OPS architecture, start moderately! Just adding products and management pack after management pack will get you in a spaghetti incident. And lots of metrics, alerts and headaches…..

To help from overwhelming information here are a few pointers you can follow in deployment of vROPS in your environment:

  • Determine beforehand what you want to learn and like to see from your environment. What policies do you currently have for your virtual infrastructure and their application workloads, are those sufficient, and is the information presented out-of-the-box close to these policies.
  • Get to know the out-of-the-box insights and policies that vROPS offers. Stop here and take a breather before wanting to customize every aspect.
  • After implementation let vROPS gather metric data for minimal one week, but preferably longer, before there can be trusted analytic’s.
  • Start with virtual infrastructure components and then move to next levels.
  • Determine what information you would like next to vSphere and in what particular phase you want to introduce this information. Again; go easy here and take your time. Introduce one adapter (or other vROPS components) at a time. Familiarize yourself with the specific insights offered by this specific adapter (for example what is collected) and after a proven success move on to a next. 
  • Familiarize yourself with the basic vROPS Architecture and where collectors and data flow moves in the architecture. A model that I created recently with the data flow in a vROPS basic architecture can be helpful in understanding:

vROPS 6 - Data Flow

  • When designing a vROPS architecture with multiple physical sites, determine where you users connect to and where the data needs to go. When trying to achieve a single pane use a distributed architecture with remote collectors for the connected physical locations. When using a per physical site vROPS instance the users connect to that local vROPS UI with data of that collected site. There is no single pane and metric data is not transferred between instances, ergo complexity your IT operations needs to handle accordantly.

– vROPS is to be enjoyed as it gives you very valuable information and let’s IT ops get from reactive mode to a proactive mode, not get headaches from!

Sources: vmware.com