With the release of vRealize Network Insight 6.4 – something awesome was added: the databus. In its essence, the databus is a feature that exports data out of vRNI using REST API webhooks. These webhooks deliver the data over HTTP[S] to an endpoint that can then parse and process the data. There are several message groups, which you can subscribe an endpoint to. The message group decides what type of data is exported and with the initial databus feature, you can subscribe to: Application updates (newly discovered, updated, or deleted apps), and Problems (alerts). The latter open up event-based automation, which is what this post is about. 🙂
Event-Based Automation
Simply put, Event-Based Automation lets you instantly react to an event that happens in your environment. The reaction could simply be notifications, or it could be changing the environment to limit the impact of an event that indicates danger. Let’s say an NSX Edge VM is powered off: vRNI would generate an alert and the automation could power it back on. Or someone changes a firewall rule to allow everything instead of deny everything; the automation could switch it back to deny. I was lucky enough to host a VMworld session around this very topic and how VMware’s networking products are going towards this state.
VMware Event Broker Appliance (VEBA)
If you’ve not heard about VEBA before, I suggest taking a look. It’s an open-source appliance that enabled easy event-based automation. VEBA ingests Cloud Events and routes them to subscribers. Subscribers are functions that you can write and load yourself. These functions are subscribed to an event name to have them react on specific events only. Because these functions are code (Python, PowerShell, Go, Java, you name it) that run on the appliance, you can do anything. From sending notifications to changing configuration in the environment.Â
By now, you’ve probably guessed it from the title of this blog, but you can configure the vRNI databus to send events to VEBA and run functions to react on the vRNI alerts (or application updates).
Setting up VEBA
I recommend the series of Patrick Kremer to get started with VEBA. This posts focuses on setting up the function that receives the events from the vRNI databus. After deploying VEBA, configure your local environment to work with Kubernetes on VEBA. Also, make sure there’s a wildcard DNS record present. Then head to GitHub and clone the project using git.
Now that you’ve got a local copy of VEBA, take a look at the examples directory. Specifically: examples/knative/powershell/kn-ps-vrni-databus. That directory has the example function that will receive the data from vRNI, parses it, and sends it on to the broker. We need to get that running before thinking about functions that react on events.
Installing the Function
There’s a more extensive guide in the readme of the function, so I’ll stick to the quick start guide. 🙂
# export TAG=1.0
# export DOCKERHUB_USERNAME=yourusername
# docker build -t ${DOCKERHUB_USERNAME}/kn-ps-vrni-databus:${TAG}
# docker push ${DOCKERHUB_USERNAME}/kn-ps-vrni-databus:${TAG}
# cat function.yaml | sed "s/image: us.gcr.io\/daisy-284300\/veba\/kn-ps-vrni-databus:1.0/image: ${DOCKERHUB_USERNAME}\/kn-ps-vrni-databus:${TAG}/g" > function.yaml.new && mv function.yaml.new function.yaml
# kubectl -n vmware-functions apply -f function.yaml
Make sure to change the DOCKERHUB_USERNAME value to your own. Above commands build the container to support the function, pushes it to DockerHub, updates the image URL to DockerHub, and finally deploys the function to VEBA.Â
If you’d like to have a look at the code, check out handler.ps1 and vrni-functions.ps1. Handler.ps1 processes requests to the webhook URL. And vrni-functions.ps1 parses the incoming vRNI databus webhooks.
Get Subscriber URL
Speaking about the webhook URL…Before we can subscriber on the vRNI Databus, we need to get the URL for it. Run this:Â Â
# kubectl get ksvc -n vmware-functions NAME URL LATESTCREATED LATESTREADY READY REASON kn-ps-vrni-databus http://kn-ps-vrni-databus.vmware-functions.veba.vrni.cmbu.local kn-ps-vrni-databus-00001 kn-ps-vrni-databus-00001 True
In my environment, the subscriber URL that I need is http://kn-ps-vrni-databus.vmware-functions.veba.vrni.cmbu.local. It’ll be different in your environment, depending on what DNS you used and if you changed the function name.
Now the subscriber function is all set and running, take the subscriber URL and set up the vRNI Databus.
Subscribing to the vRNI Databus
Last step! Configuring databus subscribers is done using the API. You can add subscribers to one or more message groups and there’s a maximum of 25 subscribers per group. The point is, the databus can send events to multiple subscriber URLs. 🙂
Instead of using the raw API, I’ll give you an example with PowervRNI.Â
PS /Users/msmit> Import-Module PowervRNI
PS /Users/msmit> $creds = Get-Credential
PowerShell credential request
Enter your credentials.
User: [email protected]
Password for user [email protected]: *************
PS /Users/msmit> Connect-vRNIServer -Server pre-ga.vrni.cmbu.local -Credential $creds
Server AuthToken AuthTokenExpiry
------ --------- ---------------
pre-ga.vrni.cmbu.local 7m60uCgwtFAKxlMEDGicYw== 11/29/2021 19:53:41
PS /Users/msmit> New-vRNIDatabusSubscriber -MessageGroup problems -URL http://kn-ps-vrni-databus.vmware-functions.veba.vrni.cmbu.local
id message_group url
-- ------------- ---
063cdfa6-8763-4a9d-80a4-300cda4deb64 problems http://kn-ps-vrni-databus.vmware-functions.veba.vrni.cmbu.local
PS /Users/msmit>
New-vRNIDatabusSubscriber is what adds a new subscriber. I’ve added the problems (alerts) message group here, but that parameter also takes the other message group types as an argument (only applications for now).Â
If you’d like a walkthrough of doing this, check out this video:
After adding the subscriber, you’ll see the events coming into VEBA. Check it out using the embedded Sockeye interface that you can find at https://your-veba/events. It’ll look like this:
Subscribing to vRNI Events in VEBA
So, you’ve got VEBA set up with the function to parse incoming databus webhooks. You’ve also got vRNI set up to send events, and you’ve verified that they’re coming in. What’s next?
In a future post, I’ll show some examples on how to get Slack alerts for these problems. In the mean time, know that there are 4 event types that functions can subscribe to:
com.vmware.event.router/vrni.problem.opened.v0Â (alerts)com.vmware.event.router/vrni.problem.updated.v0Â (alerts)com.vmware.event.router/vrni.problem.closed.v0Â (alerts)com.vmware.event.router/vrni.application.v0Â (application updates)
Then in the event data, the vRNI alert name is also defined. In the Sockeye screenshot above, you can see there’s an alert called NSXTEdgeNodeStatusDegradedEvent and a ton of context that you can use around it. All alert names are self-explanatory and have this context around recommendations, the related entity (the entity ID can be resolved using the API), and more.
Stay tuned for more content around this!
Â
Leave a Reply