Automation (LogIQ Engine)

The LogIQ engine runs runbooks An automated workflow that executes a series of steps or tasks in response to a triggered event, such as the detection of anomalous behavior generating an incident, a lifecycle event, or a manually executed runbook. when the platform creates a new incident A collection of one or more related triggers. Relationships that cause triggers to be combined into incidents include application, location, operating system, or a trigger by itself. from a detection One or more indicators that are correlated and may act as a trigger for incident creation or runbook execution.. The runbook executes an automated investigation and attaches the result to the incident report (for example, business impact, prioritization, and supporting data). That result gives you a single place to see what happened and what the system has already inferred. For how incidents are created and how runbook output appears on them, see Incident Generation and Runbook Execution and Incidents.

You configure which runbook runs for which type of detection on the Automation Management page. To add or change an automation (trigger plus runbook mapping), use the Add an Automation wizard. To build or edit runbooks, use the Runbook Editor from the Runbooks page.

Runbook selection

When Correlation produces a detection, the detection carries trigger A set of one or more indicators that have been correlated based on certain relationships, such as time, metric type, application affected, location, or network device. information (entity type, metrics, and similar). The LogIQ engine uses that information to choose which runbook to execute. Two layers determine selection:

• System-level incident triggers: Built-in triggers that align with the detection's entity type (for example, Device, Interface, and Application and Location). One runbook can be mapped to each system-level trigger.

• User-defined custom triggers: Refinements that narrow when a runbook runs (for example, run a specific runbook only when the application is DNS). You define these via the Add an Automation wizard.

The first automation whose conditions match the detection runs. For more on triggers and correlation, see Trigger and Correlation: Detections.

System-level incident triggers

Riverbed IQ Ops provides a set of system-level incident triggers. Each trigger corresponds to a type of detection (entity type and kind of issue). You map one runbook per trigger on the Automation Management page. Riverbed IQ Ops also ships with out-of-the-box incident runbooks you can use or customize. See Built-In Runbooks Overview.

The table below summarizes each system-level trigger. Details follow.

Trigger	Triggering entity	When it runs
Device Down Issue	Device (with properties)	Device unreachable or rebooted
Interface Performance Issue	Interface (with properties)	Interface down, unreachable, or performance degradation (congestion, packet errors, packet drops)
Multi Device Down Issue	List of devices (with properties)	Multiple devices unreachable at the same location
Application Location Performance Issue	Application and Location	Application performance degradation for users at a location (response time, retransmissions, lower network usage)

Device down issue

Fires when the platform identifies a single device as unreachable or the device has rebooted. The triggering entity is the device and its properties.

Interface performance issue

Fires when an interface is down or unreachable, or is exhibiting performance degradation (congestion, packet errors, packet drops). The triggering entity is the interface and its properties.

Multi device down issue

Fires when the platform identifies multiple devices as unreachable at the same location. The triggering entity is the list of devices and their properties.

Application location performance issue

Fires when an application has exhibited possible performance degradation for a number of users at a specific location (for example, response time, retransmissions, or lower network usage). The triggering entity is Application and Location.

User-defined custom triggers

Custom triggers let you refine system-level incident triggers so that a runbook runs only when certain conditions are met (for example, only when Application is DNS). You define them in the Add an Automation wizard by adding conditions. To edit an existing automation, use Edit an Automation from the Automation Management page.

You can base conditions on:

• Properties: For example, Application, Application Type, Application Version, Importance, Location, Location role.

• Metrics: For example, Round Trip Time, Throughput, % Retrans Packets, % Failed Connections, User Response Time.

• Trigger information: For example, Entity Type, Triggering Metric.