The VMware Event Broker Application/Appliance (VEBA) solution makes it extremely easy for customers to build Event-Driven Automation that can react to over 1800+ vSphere-based Events using your favorite scripting or programming language of choice that includes PowerCLI, PowerShell, Python and Go to just name a few.
The benefits of VEBA can extend beyond just vSphere Events and can also be used with both new and existing vSphere Alarms. In fact, vSphere Alarms is just another a type of vSphere Event, which then makes it super easy to work with if you are already familiar with VEBA. Similar to the "triggers" that are supported with vSphere Events, the available options for extensibility in vCenter Server is super limited.
In addition to the limited options for extending vCenter Server, there are also valid security concerns with resource utilization and opening up access to run arbitrary scripts directly on the VCSA, which we all know is a bad practice for so many reasons. What if we could easily extend the actions to a vSphere Alarm to send notifications to Slack or Microsoft Teams, automatically file an IT Ticket or run specific automation or remediations tasks!?
As mentioned earlier, there are are number of vSphere Alarm Events, but the one that we are going to focus on is the AlarmStatusChangedEvent which is triggered when a configured vSphere Alarm condition is met such as vSphere Datastore reaching a specific capacity threshold. Using VEBA, you can create a simple function that does something when this event occurs such as sending a notification to Slack. One challenge that folks may find when working with vSphere Alarms is that the events themselves do not contain the complete details of the configured alarm, which can be useful to understand the context in which a specific alarm is triggered.
Using our vSphere Datastore example, I may have configured the datastore threshold to warn when usage is greater than 5% but this information is not part of the event when it is triggered as shown in screenshot below using the new Easy vSphere CloudEvent Viewer UI which is included in VEBA. The closet property that we see that is related to this information is the "To" and From" color state and users would need to connect back to the vCenter Server to get the additional details.
Imagine if we could retrieve the additional alarm information and automatically include that as part of the alarm event which users can then consume without needing to connect back to vCenter Server and more importantly, understanding how to use the vSphere API to retrieve this information in a scalable and efficient manner?
Enter the vSphere Alarm Server Service which is a tiny Kubernetes service using Knative that can be deployed to VEBA and will automatically "enrich" all vSphere Alarm events with additional information and makes it available for end users to build their VEBA functions. As a function author, you do not have to know anything about this service, other than keying off of a specific property value to ensure you are receiving the enriched alarm events.
The vSphere Alarm Server was also built to demonstrate some of the the advanced Knative Flow features such as Sequences and Parallel, enabling customers to control the processing of specific events and also performing fan-out to various Knative services.
If we now take a look at our "enriched" alarm event using the Easy vSphere CloudEvent Viewer UI, we can see a new property called AlarmInfo which contains a ton more information about the underlying vSphere Alarm and its configuration which can now be used by VEBA function authors.
To demonstrate how easy it is to interact with vSphere Alarm Events using VEBA, we have created the following function example https://github.com/vmware-samples/vcenter-event-broker-appliance/tree/development/examples/knative/powershell/kn-ps-slack-vsphere-alarm which uses PowerShell to send a Slack Notification when the disk utilization of a vSphere Datastore go above a certain threshold.
To use the example, simply setup a basic vSphere Alarm using the Datastore Disk Usage trigger and setting the value to something that can easily be triggered such as 5% in the example below. Once the vSphere Alarm has been configured, you can refer to the Github repo for the deployment instructions and further function customizations based on your requirements.
Here is what the Slack notification will look like when it is sent and as you can see from the handler.ps1 script, the only code that customers need to write is the act of sending the Slack notification or any other "business logic" that you wish to perform when a vSphere Alarm is triggered. This is the power of Event-Driven Automation and just how easy it is using the VEBA solution!
Lastly, if you prefer to see this example live in a video format, Michael and I did a VMware {Code} Power Session that goes over this demo along with other new features in our latest VEBA v0.6.1 release which I highly recommend folks check out.
Thanks for the comment!