Create Filters and Monitor Events with SolarWinds Log & Event Manager
Uploaded by solarwindsinc on 02.03.2012
Transcript:
[Music playing]
[SolarWinds]
[Effectively Creating Filters and Monitoring Events with Log & Event Manager]
Filters are mechanisms designed for capturing events, which take place on our networks.
We sometimes refer to these events as alerts.
[Event Alert] As far as the LEM console is concerned, the terms are interchangeable.
Filters and their events can be found and viewed on the "Monitor" tab of the LEM console.
A filter captures events in real-time as they happen based upon specific conditions we build into the filters.
Conditions are the logic of a filter and are used to limit or restrict the events to be captured by the filter.
Filters can only display the events they were built to capture.
This is a major difference between filters and rules.
Rules look for events, correlate them, and then perform some type of action.
Filters only display the events they captured based upon the limiting conditions that we applied.
For example, let's take a quick look at the pre-configured "AllAlerts" filter.
This filter is wide open and has no conditions, which limit the events it will capture.
As a result, it will capture each and every event being monitored on the network,
regardless of what that event might be or the device reporting it.
In contrast, the pre-configured user "Log-on" filter consists of conditions
which limit it to capturing only user log-on events, not user log-offs or user log-on failures, only user log-ons.
There are a number of filters, which come pre-configured with the LEM console,
but there are also many other events which might warrant a filter.
Change management is a hot topic for everyone these days, especially the auditors.
We should all be aware of the changes being made to our network.
High volume events, such as sudden spikes in network traffic, might also warrant building a filter,
especially when those occur during off-peak hours.
Perhaps you just want to track certain events just to see how often they're occurring.
User logon failures or failed authentication events are good candidates for such a filter.
You can even use a filter to test the ability to track very specific events,
which may help you in the future as you build a rule.
For example, can you see enough specific data to perform some action
against one particular device or user without disrupting the activities of another?
You can also build filters to help you track down those one-off situations, which typically change from day-to-day.
The possibilities are virtually endless.
Since change management is such a hot topic for us all,
let's see how to create a filter to track all manner of change management events on the network.
We'll start by CLICKING the Add "+" button directly above your list of filters
and then SELECTING "New Filter."
This brings us to the "Filter Creation" window.
We'll name our filter "Change Management Events."
We can leave the description field blank, as the name of our filter is self- explanatory.
All of the components necessary to build a filter
are located in the column on the left-hand side of the filter creation pane.
These components are used to build the limiting conditions of a filter.
There are also components, which can notify us when a filter has captured an event, both visually and audibly.
The conditions of a filter will always begin with a single alert or a group of alerts.
In our scenario, we need to track a large number of change management events,
such as group and domain policy modifications, changes in group attributes,
new groups being added, users being created, and other related events.
Rather than add these individual alerts to our conditions one by one,
we can use a pre-configured alert group which already contains all of these related events.
That group is the "Change Management Events" alert group.
For now, we're not concerned about any specific data within those events.
We want to see them all, regardless of whom or what is involved.
So, we can drag and drop the entire "Change Management Events" alert group into our conditions.
The logic or conditions of our new filter now reads
"if a change management event exists, display it" in our filter.
This is all we need to do to create a filter to capture change management events on our network.
So we can SAVE our filter and automatically be returned to the "Monitor" tab.
Here, we can see that our filter has captured a number of change management events.
To view their specific details, simply CLICK on the event of interest
and examine its details here in the "Alert Details" pane.
[SolarWinds] [Visit.www.solarwinds.com to learn more!]
For more information on how to easily customize LEM for your environment,
please visit www.solarwinds.com.
[COPYRIGHT 2012 SOLARWINDS WORLDWIDE, LLC. ALL RIGHTS RESERVED.]
[SolarWinds]
[Effectively Creating Filters and Monitoring Events with Log & Event Manager]
Filters are mechanisms designed for capturing events, which take place on our networks.
We sometimes refer to these events as alerts.
[Event Alert] As far as the LEM console is concerned, the terms are interchangeable.
Filters and their events can be found and viewed on the "Monitor" tab of the LEM console.
A filter captures events in real-time as they happen based upon specific conditions we build into the filters.
Conditions are the logic of a filter and are used to limit or restrict the events to be captured by the filter.
Filters can only display the events they were built to capture.
This is a major difference between filters and rules.
Rules look for events, correlate them, and then perform some type of action.
Filters only display the events they captured based upon the limiting conditions that we applied.
For example, let's take a quick look at the pre-configured "AllAlerts" filter.
This filter is wide open and has no conditions, which limit the events it will capture.
As a result, it will capture each and every event being monitored on the network,
regardless of what that event might be or the device reporting it.
In contrast, the pre-configured user "Log-on" filter consists of conditions
which limit it to capturing only user log-on events, not user log-offs or user log-on failures, only user log-ons.
There are a number of filters, which come pre-configured with the LEM console,
but there are also many other events which might warrant a filter.
Change management is a hot topic for everyone these days, especially the auditors.
We should all be aware of the changes being made to our network.
High volume events, such as sudden spikes in network traffic, might also warrant building a filter,
especially when those occur during off-peak hours.
Perhaps you just want to track certain events just to see how often they're occurring.
User logon failures or failed authentication events are good candidates for such a filter.
You can even use a filter to test the ability to track very specific events,
which may help you in the future as you build a rule.
For example, can you see enough specific data to perform some action
against one particular device or user without disrupting the activities of another?
You can also build filters to help you track down those one-off situations, which typically change from day-to-day.
The possibilities are virtually endless.
Since change management is such a hot topic for us all,
let's see how to create a filter to track all manner of change management events on the network.
We'll start by CLICKING the Add "+" button directly above your list of filters
and then SELECTING "New Filter."
This brings us to the "Filter Creation" window.
We'll name our filter "Change Management Events."
We can leave the description field blank, as the name of our filter is self- explanatory.
All of the components necessary to build a filter
are located in the column on the left-hand side of the filter creation pane.
These components are used to build the limiting conditions of a filter.
There are also components, which can notify us when a filter has captured an event, both visually and audibly.
The conditions of a filter will always begin with a single alert or a group of alerts.
In our scenario, we need to track a large number of change management events,
such as group and domain policy modifications, changes in group attributes,
new groups being added, users being created, and other related events.
Rather than add these individual alerts to our conditions one by one,
we can use a pre-configured alert group which already contains all of these related events.
That group is the "Change Management Events" alert group.
For now, we're not concerned about any specific data within those events.
We want to see them all, regardless of whom or what is involved.
So, we can drag and drop the entire "Change Management Events" alert group into our conditions.
The logic or conditions of our new filter now reads
"if a change management event exists, display it" in our filter.
This is all we need to do to create a filter to capture change management events on our network.
So we can SAVE our filter and automatically be returned to the "Monitor" tab.
Here, we can see that our filter has captured a number of change management events.
To view their specific details, simply CLICK on the event of interest
and examine its details here in the "Alert Details" pane.
[SolarWinds] [Visit.www.solarwinds.com to learn more!]
For more information on how to easily customize LEM for your environment,
please visit www.solarwinds.com.
[COPYRIGHT 2012 SOLARWINDS WORLDWIDE, LLC. ALL RIGHTS RESERVED.]