In the Cisco AppDynamics model, events represent a change in the state of a monitored application. An event can represent an error/exception generated by the application, the crossing of a performance threshold, or an operational change in the application (such as a JVM restart).

 You can use events to investigate application issues underlying performance problems. You can define policies that generate notifications or perform actions when an event occurs. See Alert and Respond.

View and Monitor Events

You can view and analyze events in the Controller UI. From the Database Visibility, Server Visibility, or user experience application pages in the UI, you can view events by clicking Events from the left navigation tree. 

The Controller displays a subset of the types of events generated in Cisco AppDynamics. You can access additional event types through the REST API. See Cisco AppDynamics APIs.

To view events for application monitoring:

  1. Navigate to Events on any business application, business transaction, tier or node dashboard to view events generated in the selected time frame. 
  2. Click Filters and select the type of event to display.
  3. Review information about an event 
    If the event is an application change, such as an application restart, the details contain a description of the event. 
    If the event is a slow transaction or an error, the details are transaction snapshots from which you can drill down to the root cause of the problem. 
  4. From the Event Details dialog, right-click an event to start a war room, delete or archive the event, or test action execution.

Archive Events

An event is purged after two weeks, at which point it is no longer accessible. To save an event beyond the default snapshot lifespan for future analysis, you can archive the event.  

Event Purging in Ephemeral Environments

Events associated with nodes that are deployed to machine instances in an ephemeral environment are subject to being purged. This occurs because the node associated with the events is identified by a label consisting of two discrete parts: a node name and a machine instance name. The node name is always fixed, but the machine instance name changes in ephemeral environments. Thus, when a node is redeployed to a new machine instance, the label identifying the node changes.

For example, the label for a node in an ephemeral environment might consist of the fixed node name "Node1" and the machine instance name "INSTANCE-M-T1": NodeINSTANCE-M-T1. When the node is redeployed to another machine instance, the label for the node could change because of the new machine instance to something such as "Node1INSTANCE-M-T2". If this occurs, the events associated with the first label "NodeINSTANCE-M-T1" could potentially be purged later.

Events Archived by Default

Cisco AppDynamics archives application configuration change events by default. In the Controller UI, these events display as Application Configuration Change. You can view the APPLICATION_CONFIG_CHANGE event type in the Controller UI or retrieve it with the Cisco AppDynamics REST APIs.

Once APPLICATION_CONFIG_CHANGE events are archived or deleted, you can no longer retrieve them through the Cisco AppDynamics REST APIs.

Manually Archive Events

To manually archive events:

  1. Select the event from the events list. 
  2. Click Actions > Archive Event.
  3. Click Archive to confirm the action. 

Thisindicates that an event has been archived. You can click the column heading to sort by archived events.

Modify Event Retention Period (On-Premises Controllers)

 For on-premises Controllers, administrators can modify the default two-week period by configuring the events.retention.period property in Administration > Controller Settings

Filter Custom Events

The Cisco AppDynamics REST API enables you to define custom events. You can then filter on those events by creating a custom filter: 

  1. Open the filter options on the Events page.  
  2. Navigate to Filter by Custom Events and click Add Property (+). 
  3. In the Add Custom Event Filter dialog, enter the name of the custom event type. 
  4. Optionally, specify filtering event properties as key/value pairs. The custom event needs to contain the property values you specify to satisfy the filter. If you add multiple properties, a matching value of All applies an AND operator to the list, meaning all properties need to match for the filter to be satisfied. Any indicates a logical OR, meaning at least one property must exist and match for the filter to be satisfied. 
    Add Custom Event Filter