Log Analyzer (LA) includes the ability to trigger an Orion Alert based on log or SNMP Trap data, which has been a long standing feature request. I'd like to walk you through the steps involved in creating an Orion Alert via LA.
In order to create an Orion Alert from Log Analyzer, you first need to create an LM Rule from the Log Processing Configuration page. I'm going to use a BGP Peer Down alert as an example.
Creating a Log Rule
I've created a rule to monitor for syslog which contains '%BGP-5-ADJCHANGE' and 'down':
Creating an Orion Alert from a Log Rule
In addition to adding tags, running an external program and discarding messages, LA includes an option to 'Send a Log Fired event to Orion Alerting'. Enabling this option creates an event which Orion Alerting can use to trigger an alert.
You can create the alert directly from the Log Rule configuration. Options are limited to assigning a name to the alert, setting the severity and reset conditions. In order to add additional conditions, time of day sets and trigger actions you'll need to do this from the Orion Alerting configuration. We've made it really easy to access the alert, which I'll walk you through shortly. Once you've created the alert, it behaves in the same way as any other Orion alert.
Adding Additional Conditions and Actions to your Alert
In order to access the Orion Alert that you've just linked to your rule, you can do so by clicking on 'Trigger Orion Alert' on the Rule Summary page. From here you can then add additional conditions and actions. Worth noting that you can assign multiple alerts to one log rule. If you have multiple alerts assigned, these will be displayed in the 'Linked Alerts' also.
The trigger condition will look like this. You can add additional conditions here if you wish:
Configuring Reset Conditions for polled data is usually pretty straight forward, e.g. if CPU drops below 90% automatically reset the alert. Resetting alerts based on log data can be a bit more challenging as oftentimes there isn't a follow up log/trap to let you know that an issue is resolved. So, what are your options?
Automatically Reset the Alert after X - this option allows you to automatically reset the alert after a specified period. For example, the BGP Peer Down alert has triggered but you could like to automatically reset the alert after 60 minutes.
No Reset Condition - The alert will be triggered each time the associated Log Rule triggers.
No Reset Action - The alert remains active and is never reset. To re-trigger the alert, the alert must be manually cleared from the Active Alerts view.
Create a Special Reset Condition for this Alert - This option is particularly useful in the case where you want to reset the alert based on a 'happy log/trap' being received. For example, if you want to reset the BGP Peer Down alert as soon as a BGP Peer Up event is received. Worth noting that the Node is taken to consideration automatically, so the alert will only reset if the log is received from the same node that triggered the initial alert.
When your alert triggers it will be displayed in the 'All Active Alerts' resource along with all with all your other Orion Alerts, whereby you can acknowledge alerts, view alert details and clear the triggered instance of an alert.
You may be wondering what happens if an alert triggers but the same syslog or trap keeps coming into LA. In that scenario, the alert is aggregated for a one minute time span. This ensures that you don't get bombarded with alerts/e-mail notifications each time a Log Rule fires. You can view the number of times the alert has triggered over the last minute within the 'Top 10 Objects by Trigger Count of this Alert' resource on the Active Alert Details page.
I hope this post provides with all the information you need to begin with Log Analyzer and Orion Alerting integration. If you have any questions, comments or feedback please feel free to drop them into the comments section below.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community.
More than 150,000 members are here to solve problems, share technology and best practices, and directly
contribute to our product development process.
Learn more today by joining now.