Exclude filesystem partitions from alerts with vRealize Operations 6.7

With the release of vRealize Operation 6.7, one of the little less known feature around alerting capabilities is the exclusion of filesystem partitions from symptoms.

Imagine you have a fleet of Windows of Linux Virtual Machines where you want to monitor the file system usage of the various logical partitions created by the guest operating system. In most of the cases, you don't care about general purpose partitions such as /log or /tmp partitions. Traditionally, any monitoring solution which have the capability of monitoring file system would alert you on each of these file system partitions and would create something commonly termed as ALERT FATIGUE.

To avoid this alert fatigue vRealize Operations provides a feature which allows you to "EXCLUDE" the partitions which you don't care about easily while creating symptoms. You can then use this special alert on one, few or all of your virtual machines to ensure that you do not get alerted on filesystem partitions you don't care about and reduce the alert volume to actionable alerts.

Here is how you would create such a symptom:

1- Login to vRealize Operations 6.7 with a user account who has privileges to create symptom definitions.

2- Click on Alerts, expand Alert Settings and click on Symptom Definitions.

3- Click on the + symbol to add a new definition. 

4- Configure the symptom definition as described in the screenshot below:

5- Click Save

Once saved, you can use the newly created symptom definition in your file system monitoring alerts. Here is the link to vRealize Operations 6.7 guide which can help you with the steps, if you have not done this before...

This exclusion rule can be applied to multiple use cases, such as exclusion of CPU instances, snapshot instances or any other instanced metric type where instances are generated based on occurences in the given object dynamically.

Hope this helps.

Share and Spread the Knowledge...

Did You Know #3 - Using Wait Cycles for Time Based Alerts in vROps!

In this part of the "Did You Know" series, I will provide you a tip, using which you can create time based alerts in vROps. I am happy to share that this was an output of a brainstorming session with a customer and at the end of the discussion the customer himself proposed this solution and I was immediately testing the idea in my lab with successful results.

The use case for the time based alert in our situation was to create an alert which would trigger if a virtual machine is running on a snapshot for more than 24 hours and if the snapshot space on that virtual machine is more than 0 GB.

The challenge with this requirement is around the time factor. Different workloads can have different impact of running on snapshots. For instance a web server running on a snapshot might not be impacted much from a performance standpoint, however an Oracle database VM running on a virtual disk snapshot would definitely not be a happy camper at the time it's running database transactions. Just to be clear, we are discussing vSphere snapshots here and not any other snapshot technologies. With vROps, there is no metric today which tracks the snapshot on the basis of time. While there are metrics which define the age of the snapshot, using these metrics for alerts become impossible, as for each snapshot a new directory is created, under which a snapshot drive is created and it increments in size. As soon as you delete this snapshot and take a new one on vCenter, vROps creates a new directory for this new snapshot and hence it is difficult to track hundreds of directories which keep changing, specially in an environment where snapshots are heavily used.

In order to overcome this situation, we will create a new alert. If you are new to Alerts in vROps, I would highly recommend that you watch this episode of my yearly long Webinar Series to get well equipped about vROps Alerts and Symptoms.

We will start by creating a new symptom & an alert definition:


1- Login to vROps with credentials having rights to create new Alerts/Symptoms (admin credential would be nice).

2- Click on Content -> Symptom Definitions. You will be under the metric/property symptom definitions category by default.

3- Click on the + sign to add a new Symptom.

4- Here is how you will define the new symptom. Refer to the screenshot for more details:

• Base Object Type : Virtual Machine
• Metric Name : Disk Space|Snapshot|Virtual Machine Used (GB)

5- Double click on this metric to add it to the right pane where we will describe this symptom.

6- Here is how will you provide the details:

• Static Threshold
• Symptom Definition Name : Virtual Machine is running on a snapshot for more than 24 hours
• Critical
• Condition : When Metric is > 0 (This is the size of the snapshot)
• Advanced : Wait Cycle - 288 (Each cycle is 5 minutes, hence the total minutes we will check for this condition is 1440 minutes which is 24 hours)
• Advanced : Cancel Cycle - 1 (Once the condition is false, the alert will be cancelled in 5 minutes)

7-  Click on Save to save this symptom. Once done we will create a new alert using this symptom.

8- Click on Content -> Alert Definitions. Click on the + sign to add a new Alert and provide the following details:

"1. Name & Description"

Name - Virtual Machine is running on a snapshot for more than 24 hours
Description - This alert will trigger when a virtual machine is running on a snapshot for more than 24 hours.



"2. Base Object Type"

Virtual Machine





"3. Alert Impact"

"4. Add Symptom Definitions"

Symptom Name : Virtual Machine is running on a snapshot for more than 24 hours

"5. Add Recommendations"

Add any recommendations from the available list or create your own.

9- Click on Save. This will create a new alert definition and this alert will be enabled on the default policy by default.


Please note that the Wait Cycle will start counting as soon as you create this alert definition, hence this alert will take atleast 24 hours to trigger. If you have VMs with snapshots (more than 24 hours old) in your environment, don't expect the alert to trigger immediately. The countdown to 24 hours will begin when you enable the alert in the policy.

You can see that we used a Time Based symptom to solve a key problem which emerges and could lead to a number of issues in a virtual environment. Hope this will give you ideas on  how you can create more time based alerts using metric based symptoms.

Hope this helps with day to day datacenter operations using vRealize Operations Manager.

Stay tuned for more goodies!

Exporting Content with vRealize Operations Manager Policies

Policies as we know are the control center of vRealize Operations Manager. In the vRealize Operations Webinar Series, we have been running for the entire year, we have seen that policies needs to be touched, configured, modified etc, with every feature or functionality available out of the box or being customized with vROps. This pretty much aligns with all the products of VMware. They all have a theme of Policy Based Control which allows you to built, run and operate the Software Defined Datacenter components by tying them down to your business policies.

With this article, I wanted to highlight, that policies is not about configuration only, they are also about content. In a recent project, I discovered that with vROps 6.2.1, you can utilize policies for exporting and importing content from one vROps instance to another. This includes:-

• Alert Definitions

• Symptom Definitions

• Recommendations, &,

• SuperMetrics

This in my opinion is a killer feature as it allows you to create content once and distribute the same by a simple export and import of a policy. This opens a lot of avenues to collaborate and share meaningful content with community.

While the above mentioned content can be exported & imported easily, things like Views, Dashboards and Reports still need to be exported and imported individually. I believe with time, VMware should work towards unifying & ease content management by making everything exportable and importable like LogInsight content packs.

I will not go into the details of how to Export & Import policies, since I have already done an article on this sometime back which is applicable today as well. I will utilize this feature and work on creating a collaborative content library where you can share content with policies.

Stay tuned for more fun on vROps!!!

vROps Webinar 2016 - Part 7 : Working with Alerts & Symptoms

Time to release the recording for the latest part of the vROps Webinar Series.  We completed the 7th session of the series where we spoke about vRealize Operations Manager Alerts and Symptoms. 

Alerts as we all know would always remain the heart and soul for the operations teams to run the data centers, whether old school or the modern software defined.

In all cases you need alerts and more importantly you need meaningful and actionable alerts. In this part of the series, Simon and myself concentrated on making you aware of the alert constructs in vROps and as usual share experiences around how we help customers leverage the strong feature set of vROps to customize alerts and related symptoms, recommendations and actions to drastically reduce the Mean Time to Resolution of issues.

The journey so far has been fantastic and we would continue to add more content as we progress into the rest of the year. 

Stay tuned for more and enjoy this recording!!!

Till next time.. Have a Good One!!

vROps Webinar 2016 - Announcing Part 7 : Working with Alerts & Symptoms

Time to announce the next part of the year long webinar series on vRealize Operations Manager. With the last part of the series, we started focusing on content withing vROps. We will continue the trend and talk about a major function of vROps a.k.a Alerts. Alerts is the most used and most ab-used part of vROps, and with this session we want to give you some insights on the entire life-cycle of the alerting function of vROps.

We will touch upon, defining alerts, making sure they are actionable, understand how they are manged within vROps and also talk about the components which make up an alert. 

Day & Date          : Friday, 29^th July 2016

Time                     : 1:30 PM - 2:30 PM  (SGT)

Event                    : vROps Webinar 2016

Topic                     : Part 7 : Working with Alerts & Symptoms

Speakers               : Simon Eady / Sunny Dua

WebEx Link          : JoinWebEx Meeting

NOTE - Don't forget to mark your calendars by saving the Date!! Feel free to forward the invite to anyone who might be interested. It's open to all!!


Sharing & Spread the Knowledge!!

Reset out-of-the-box content during vROps upgrade!

VMware recently release vRealize Operations Manager 6.2 (now 6.2a with the recent patch). If you are on a version of vROps 6.x or above and trying to upgrade to the 6.1 or 6.2, you will get an option during upgrade to reset out-of-the-box content when you install the software update.

Here is how the setting would look like during the upgrade:-

The release notes over here explain this setting:-

I have had many customers ask me the meaning of this statement as they are concerned about losing customizations they have done in their vROps environments. 

This statement means that, if you are using any of the out-of-the-box Alerts, Symptoms, Recommendations or Policies which came with the product when you first installed it, checking this option may reset them back to default (with newer settings wherever applicable).

This also applies if you have just renamed the out of the box content. A best practice would be to clone out of the box content and then do further customizations to avoid resets of your valuable customizations.

So if you have not modified the existing Alerts, Symptoms, Recommendations or Policies and have created everything from scratch then those configurations would not be harmed by checking this option. It is a good idea to check this option to get the latest and the greatest released with the product, however be CAREFUL and assess your Alerts, Symptoms, Recommendations & Policies before taking a call.

A GOOD PRACTICE to manage Alerts, Symptoms, Recommendations & Policies would be to NEVER customize the one's available out of the box, but to Clone from the existing one's and customize the cloned Alert, Symptom, Recommendation or Policy. This way you will never be dependent on the out of the box content and would never be impacted if VMware provides new updates to those in the upcoming releases. Another benefit is that, you will never mess up the original configuration in case you are trying to test drive stuff.

Share & Spread the Knowledge!