I have already touched on alerts, but I really want to deep-dive into them including into some of the features I have not discussed yet. Read on to learn more!
Log Intelligence features alerts in the UI. They are shown both on the home page:
As well as the Recent Alerts page:
All available alerts in Log Intelligence are shown on the Alerts Definition page:
By default, this page is populated by built-in content for the SDDC. In short, you will find alerts from the vSphere, VSAN, NSX-v and NSX-t content packs from Log Insight. You can of course save your own alerts as well. By default, all alerts are turned off. Admin users can enable and configure alerts as desired. It should be noted that the naming standard for built-in content is such that all “critical” (read: you should enable) alerts are at the top and start with “_CRITICAL”.
If you select an alert then you have options to view/edit the:
- Notification — who receives triggered alerts (email and webhook available today)
In addition, you can see the returned results for the given query and the trigger line:
In the top right, you will find actions available as well including:
- View on Explore page
The triggers for an alert are very similar to Log Insight:
In order to receive alert notifications outside of the UI you either need to use email or webhooks. By default, Log Intelligence uses a built-in email configuration. You do have the option to change this to your own email server as well:
In addition to email, Log Intelligence supports webhooks for alerts. This allows you to communicate with any third-party system that has an API. Since Log Intelligence is a SaaS service, webhooks can only communicate to systems available on the Internet (expect this to change in the future). In short, you need to specify a destination URL and the payload you wish to send. Log Intelligence comes with built-in parameters that can be used as part of the payload definition:
Note this implementation is a bit different from Log Insight in that you must specify your own webhook payload. The reason for this is because every third-party system has a different requirement on API payload. To better support this, Log Intelligence allows you to specify the payload desired. This behavior is very similar to what vROps does today. Any parameters used are automatically expanded.
You may notice an Advanced Settings section header. This can be selected to expand and provide more configuration options:
As you can see, Log Intelligence defaults to the following:
- Content Type: JSON
- Action: POST
These can be changed. In addition, authorization information can be provided if required and custom headers can be added. Again, these all depend on the third-party system you are trying to integrate with and what it requires.
For those of you familiar with Log Insight or vROps you may recall the webhook shims. Does Log Intelligence require webhooks shims? No (Log Insight does). Might you still want to use webhook shims with Log Intelligence? Yes. Why? Well, while you can define a custom webhook payload the system is still fire and forget. Let’s assume for example that you want to integrate with a ticket/incident management system. In this case, you likely want to check for already open tickets/incidents before opening a new one. Log Intelligence does not natively support this today, but you can do it via the webhook shims.
As you can see, Log Intelligence provides everything you would expect from an alerting perspective. What other features would you like to see?
© 2018, Steve Flanders. All rights reserved.