Cisco Elastic Services Controller monitors the
VM to detect any erroneous condition. ESC uses one of its monitoring methods to detect
actions on a VM, and passes this information to the rules service for processing. The
monitoring request comes from the northbound client along with VNF deployment requests.
There are two sections
in the datamodel xml file which define the events and rules: KPI and Rule.
Based on the monitors
and actions, rules are triggered.
In the example above,
an event is sent to check whether the VM is alive. The VM is pinged at regular
intervals, and based on the result VM_ALIVE event is sent to the rules engine
along with the details of the VM.
The rules engine
receives events from the monitoring engine. The rules engine can handle simple
to complex events. Based on the event received an action is triggered.
If the VM is not
alive, based on the event the actions defined in the <rule> section are
triggered. This can be found in the dep.xml datamodel.
<action>FALSE recover autohealing</action>
The rules section describes the actions to be
executed once a monitoring event has been detected. The dynamic mapping API drives the
rules based on keywords.
In the above example,
the following actions are performed based on the given condition:
Whether the event is pingable or not, the details are logged.
TRUE servicebooted.sh: The action
identified by this keyword in the dynamic mapping API is triggered when the VM
moves from a non-pingable to a pingable state. The serviceboot script informs
ESC that the VM is “alive” allowing it to transition the VMs state.
autohealing: The action identified by this keyword will be triggered and the VM
will be recovered without the administrator's intervention.
Monitoring log files
for troubleshooting are available at