Webhooks

After being introduced to REST APIs in your network automation journey, I’m sure you will hear about webhooks. Webhooks sound a lot more developer-centric and less about networking, but they can be a game changer when implemented correctly. In this post, we will talk about why, as network engineers, we should care about webhooks and the benefits/opportunities they can provide. This will not be a technical discussion. There are many online resources to how webhooks operate and how to configure them for specific products. I’ll include some useful links about webhooks in the references section of this post.

My first experience with webhooks came when I was trying to send Cisco Meraki alerts to a Cisco Webex Teams space. The idea was that I could reduce the number of steps in the standard alerting workflow and also allow for reactive remediation steps. For example, in a traditional monitoring scenario, your monitoring tool would recognize a threshold was breached (likely based on slow SNMP polls (~5 min intervals)), send the alert to your email, which then you’ve hopefully received, read, and began troubleshooting in a timely manner. By using webhooks, my idea was to send Meraki alerts (near real-time when the event occurred) directly to a Webex Teams space. After the alert is in the Webex Teams space, I could add additional logic and allow a user to interact with the issue directly in the space. This interaction could allow potential remediation directly in the space, which could help eliminate a lot of context switching between tasks and having to pull up multiple windows to troubleshoot. At the end of the day, this would help simplify the engineer’s life, which I think we can all agree is a great thing!.

I wanted to mention my first experience so that you could understand, at a high-level, how webhooks can help accomplish your goals. I think one of the biggest benefits to webhooks is the extensibility they offer. To understand the extensibility, I will explain how webhooks work at a high-level. Here’s a diagram I created to help visualize the workflow:

As you can see, the platform or “controller” must support webhooks. Many products these days already support them, but be sure to confirm. As it relates to networking, Cisco Meraki, DNA Center, SD-WAN, and many other Cisco products support webhooks. Keeping it basic, webhooks are essentially HTTP POST requests with a JSON payload sent from the controller to a configured HTTP/S endpoint. I included multiple HTTP POST requests in the diagram to illustrate that many requests can be sent to an endpoint. HTTP POST requests can have different JSON payloads for different types of alerts. Lastly, the data can be stored or sent directly to a service like Webex Teams or Slack using a trigger on the HTTP/S endpoint. There are many other actions that can be performed on the raw data once it reaches the HTTP/S endpoint, but I don’t want to get deep into data processing. The idea is that you understand the basic operation of webhooks. Now, let’s open up your imagination and look at the extensibility of webhooks.

With webhooks now demystified, you should begin seeing the limitless options and possibilities that exist with webhooks. Given the proper requirements, webhooks can be the glue between products in a closed-loop monitoring system. For example, you can send near real-time alerts to a monitoring system and an on-call system (if a certain severity condition is met), while also sending the necessary data to create a ticket in an ITSM tool. All of this data, automatically pushed to the correct systems with the necessary information to kickoff additional workflows is mindblowing. It’s more mindblowing when you try to think about how traditional monitoring protocols, such as SNMP, could (or couldn’t) accomplish the same automated workflow.

In recap, I hope I’ve been able to expose you to webhooks, their basic workflow, and how they can help network engineers. As we are beginning to be in a controller-based world, we need to begin thinking about how we can glue these products together and create automated workflows. Thanks for reading! See you next week!

References: