Log Insight 3.3: Webhooks

In this post, I would like to drill into the new webhook alert option available in Log Insight 3.3. Read on to learn more!

li-logo

Defining webhooks

My colleague Alan Castonguay put it well when he said, “Webhooks are user-defined HTTP callbacks. Something happens in an application (e.g. alert fired, change made, commit merged, etc) that some remote service cares about. It doesn’t matter why they care, they just want to be told that some event happened. It could be for auditing, or to start a workflow, or something else.”

Given how generic the webhook definition is, webhooks provide a lot of flexibility, but also incur some administrative overhead — more on this in a minute.

Configuring webhooks in LI

There are two places in LI where webhooks can be configured:

  1. For system notification: under the General page in the Administration section
    li-33-system-webhooks
  2. For user alerts: while creating a new user alert or by editing an existing user alert
    li-33-user-webhooks

In both cases, a space separated list of webhook URLs should be specified. Note that authenticated webhooks are not supported in the LI UI as of version 3.3. You can of course send traffic over HTTPS, but the destination cannot require authentication.

Output of a LI webhook

The output of a LI webhook depends on the type of webhook (i.e. user or system) and type of query (user only). Let’s see an example for each:

System

User: Message Query

User: Aggregation Query

Sending a LI webhook to a 3rd party

If you read the release notes, you will see mention of third-party applications like Slack. If you go ahead and enable an incoming webhook in Slack and then leverage the new test alert option for user alerts in LI, you will receive the following error:

li-33-webhook-server-error

Wait, I thought LI webhooks allow me to send notifications to third-party solutions? They do, but since LI sends a webhook in its own proprietary format and third-party solutions expect incoming webhooks to be in their proprietary format we have a problem. The solution is to write shim between LI and the third-party solution which translates LI format to third-party format. I will talk about how to write shims in a future post.

Requesting more LI webhook functionality

You might look at the existing LI webhook capability and wish for some additional functionality (e.g. built-in shims, authentication support, etc). If so, please head over to the Log Insight Community and file or vote for a feature. Note the LI team wanted to get this feature out early so feedback could be gathered and more functionality could be added (welcome to agile development!) so please be sure to participate in the community.

Summary

LI webhooks provide further extensibility for alerts in LI. They are simple to enable, but as of LI 3.3 do not support authentication and require a shim be written in order to translate the outputted format into a third-party understandable format. For suggestions on future enhancements to the webhook functionality, be sure to head over to the Log Insight community.

© 2016, Steve Flanders. All rights reserved.

2 thoughts on “Log Insight 3.3: Webhooks

  1. Thanks Steve. Is this webhook mechanism a potential replacement for the laborious task of vCenter alarm creation / management?

    For one client alone, we have 35 independent vCenter platforms. Each alarm in each vCenter must be modified to generate an SNMP trap and if we want to create a custom alarm – we have to do it 35 times.

    • Thanks for the comment! Well I guess it depends — what are you creating alerts for? If the data is available in either ESXi syslog events or can be collected from the VC database then yes LI can be used for this (with or without webhooks), but if no then you will need the alerts so you have an event you can trigger on (in which case I would recommend some automation for VC like PowerCLI). I hope this helps!

Leave a Reply