- [Instructor] EEM or Embedded Event Manager
is a subset of Cisco's IOS that provides real time
network event reporting and tracking.
This is a way that you can also
automate certain tasks on a network using applets
and scripts, the main advantage of using EEM
is that it's embedded just as the name implies.
So this is all contained within the local device,
for example, a Cisco router.
So there's no need for any external control,
or any external scripting or monitoring in many use cases,
although external scripting
can certainly be used if that's desirable.
Applets and scripts are the two main types of EEM policies.
Applets are the more simplified option
consisting of a series of commands
that you defined within the CLI.
Scripts also perform defined actions,
but they are created with an interpreter language
called Tcl or tickle as some refer to it.
Tcl is a very simple programming language
that's not specific to EEM.
EEM uses what are referred to as event detectors
to determine when a notable network event has occurred.
These event detectors provide a connection between
what's being monitored and the EEM policy actions
that should be taken against the device.
A few common event detector examples include SNMP,
syslog messages, interface counters, timers
and IP SLA that we've examined earlier.
Also NetFlow data would be included in that
and there are many, many more.
When an event detector reports a notable event,
an EEM event action will be performed
using either applets or scripts with CLI based applets.
The only actions that can be taken
are dependent upon your specific IOS release.
So not every action and not every event detector
is available in every single version of IOS.
So that's something to be aware of
when you're setting this up for yourself.
Applets offer a self-contained solution using only the CLI,
but those options may be more limited
than using scripts created with Tcl depending on your needs,
the main structure where all of this is contained
is called an EEM policy
or also referred to as an event subscriber.
The policy will define the event
that is based on event detectors,
and which actions should be taken
when the event is detected.
The basic steps for creating an EEM policy
involve first determining a specific event
for which the policy is dedicated,
defining the details of the event detector
and those options, so in other words,
what is an event and how is that monitored?
Are we going to monitor through SNMP or through syslog,
and so on and finally,
what action will be taken when we detect
that particular event.
Let's take a high level graphical view
of all this information
to see more clearly how the pieces fit together.
At the top we can see EEM applets and EEM scripts,
either or both methods could be used
to create an EEM policy or event subscriber,
we see that both of these feed into our EEM policy,
which defines what an event is
and what actions should be taken against those events.
The policy is contained within the Embedded Event Manager
itself on our Cisco device, connected to our EEM,
we also see event detectors.
A few examples here are syslog,
our timers and CLI detectors.
And finally, we have what we call our event publishers.
Those are the places where our detectors are gathering data.
In the case of syslog,
the data is gathered from the syslog message queue,
the timer is going to collect from hardware timers,
and the CLI detectors are going to gather from the IOS
parser text, in the beginning I pointed out
that there are many, many options for event detectors.
These are just a few examples laid out here.
So that's an overview of the structure and usage
of Embedded Event Manager.
In our next video we'll take a look at how we can configure
an EEM applet to automate tasks on our local device.