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. 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.
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.
Datastore usage on disk alarm in vsphere 7 how to#
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?Įnter 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. 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. 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.
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 VEBA, you can create a simple function that does something when this event occurs such as sending a notification to Slack. 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!?Īs 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. 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. Similar to the "triggers" that are supported with vSphere Events, the available options for extensibility in vCenter Server is super limited. 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. The benefits of VEBA can extend beyond just vSphere Events and can also be used with both new and existing vSphere Alarms. 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.
0 kommentar(er)
