Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

Understanding EUM and Events Service Concepts

Overview

To deploy analytics successfully, you should understand the following concepts:

 

Events

In the AppDynamics model, each major service produces its own types of events. That includes services not relevant here such as Application Monitoring, Database Visibility, and Server Visibility. 

 

Note: Sizing analytics for database visibility is treated as a special case. If you have questions, contact your AppDynamics representative.

 

In this example, we'll look at End User Monitoring and Analytics services, and their respective events.

Service

Event Definition

End User Monitoring

Change in the state of a web, mobile, or IoT front-end

Analytics

Change in the state of:

  • Business Transaction
  • Application log
  • Custom-defined event created for analytics purposes

 

Sometimes it makes sense to distinguish between EUM and Analytics events. However in this discussion, we'll treat both types of events as Analytics events. 

 

Event Categorization by Behavior

Another way to categorize events is to consider how they behave in the system. This yields two broad categories of event types described in the following table:

Event Category

Event Type

How the Event Behaves

Examples

Upsert, also known as Update

Transaction Analytics, Browser Session, Mobile Session

Freshly creates something that is modifiable, or modifies that thing; often events with multiple segments or components

An Upsert could modify or create:

  • Business Transaction (BT) which has multiple segments, each associated with a different tier
  • Browser session which has multiple variables, such as one that is modified when the user clicks a radio button

Publish

Log, Snapshot, Crash Report, IoT, Custom API

Creates immutable artifacts

A Publish event could create a log entry

 

How the Events Service is provisioned in terms of hardware, OS tuning, and network tuning, determines the limits of Events Service's ability to handle incoming events, and the quality of its performance. Hardware includes cores (CPUs), memory, and disk storage.

 

How Events Flow Through the System

Events come to the Events Service in two flows:

  • from the EUM Processor
  • from the Analytics Agent

 

The Events Service also handles queries from the Controller. Even though Controller queries are not events, theybut still contribute to load on the Events Service.

 

What Flows into the Events Service from the EUM Processor

Demand on the EUM Processor consists of the sum total of clicks and other actions that occur in browsers, or on mobile or IoT devices. We cannot limit that demand because we have no control over what flows into the EUM Processor.

 

However, we do control what flows out of the EUM Processor, and thus can limit the demand that the Events Service and other parts of the system must handle.

 

The process is: 

  • AppDynamics agents in browsers, and on mobile and IoT devices, generate a snippet of data called a beacon for every click or other action.
  • The agents send the beacons to the EUM Processor.
  • The EUM Processor determines whether the beacons are valid, based on configurable rules.
  • Based on beacon content, the EUM Processor generates snapshots, session information, and metadata and then sends these to the Events Service.

 

Based on configurable rules, the EUM Processor decides whether the event that the beacon represents should be discovered or not. Events that are not discovered are dropped from the system; the Events Service is never aware of them.

 

What Flows into the Events Service from the Analytics Agent?

The Analytics Agent

  • Forwards Business Transaction events to the Events Service
  • Generates Log events and sends them to the Events Service

 

Controller Queries

The Controller persists metadata, which includes license and account information, and event schemas. It then synchronizes the metadata with the Events Service. This enables AppDynamics to process licensing rules and limits, honor expirations, and authenticate publish/query calls using the account name and access key.

When the user creates Analytics queries in ADQL, the Controller sends them to the Events Service—these are Controller Queries.

 

Controller Queries also originate from EUM and DBMon dashboards and screens.

 

Beacons

When an AppDynamics Agent, or SDK instrumented code, detects an action in the browser or on a mobile or IoT device, it sends a beacon (a JSON file which contains keys and values) to the EUM Processor. 

 

Beacons, Sessions, and Metadata

Each incoming beacon includes an event ID from its originating medium (browser, mobile, or IoT). A series of events are considered part of the same session when they share the same event ID.

The EUM Processor uses event IDs to determine whether each beacon belongs to an existing session, and if not, creates a new session. As a result, every Resource Timing Snapshot that the EUM Processor sends to the Events Service can be paired with a session ID.

Internal components of the EUM Processor (implemented as threads in the EUM Processor process) interact with storage mechanisms (AWS Kinesis and S3) and the Analytics Agent to accomplish these tasks.

 

Beacons from Browser Actions 

The JavaScript Agent generates a beacon for every browser action. The EUM Processor determines which page type the beacon represents. Page types are virtual page, base page, iFrame, and Ajax call

According to the default page naming rules:

  • Virtual and base pages and iFrames are discovered
  • Ajax calls are not discovered, because they generate more requests than other page types

When you want to constrain which pages to discover, work with page naming rules. For example, to direct the system to only discover pages from the host server1, you would write the rule hostname = server1. 

For more details, see:

 

Beacons from Mobile and IoT Actions

The Mobile Agent generates a beacon for every action (represented by a network request) on a mobile device. The IoT Java Agent generates a beacon for every action on an IoT Java device. 

 

Use the C/C++ or Java SDK to specify the events to send.

 

For more details, see:

 

The EUM Processor inspects the beacons and applies rules based on the characteristics and content of the network requests.

 

Resource Timing Snapshots

AppDynamics Agents collect load times for each resource on a web page, and send the load times to the EUM Processor. The EUM Processor packages up a percentage of the page-load events as a Resource Timing Snapshot and sends that to Analytics. Analytics uses Resource Timing Snapshots to tell AppDynamics users which resources use the most time to load.

 

Performance Considerations

For browser traffic, the more resources in a web page, the more CPU EUM processor uses.

Upserts are more expensive on Events Service side. 

 

Analytics Trade-offs

As you add new applications to your Analytics deployment, you can control resource consumption by making strategic trade-offs. 

 

Understanding Analytics trade-offs begins with the following concept:

Anytime we acquire or generate more information to analyze, that costs something. Conversely, by choosing not to acquire or generate unimportant information, we can realize savings. 

 

To make a trade-off, you take an action that either increases or decreases the amount of information that Analytics must process.

 

Ask yourself:

Does the potential benefit of the action justify the cost, for the customer's particular situation?

 

Costs or savings can be in terms of:

  • Licenses
  • Hardware
  • Energy use

 

The following table shows important trade-offs to consider:

Action

Benefit

Cost

When is the cost justified?

Discover Ajax calls More information about activity in the browser Many more requests for the system to handle  When there is a web front-end that depends heavily on Ajax
Restrict discovery to pages of a specific type or pages that satisfy particular rules Limit burden on the Events Service Less information about activity in the browser When knowing about the excluded information adds little value, and/or unnecessarily complicates your picture of application behavior
Restrict Analytics BT events Limit burden on the Events Service Less information about BTs
Restrict Analytics log events Limit burden on the Events Service Less log information to search when troubleshooting


For more details, see
Configuring Application Analytics.



Version history
Revision #:
5 of 5
Last update:
‎01-17-2020 10:25 PM
Updated by:
 
Labels (1)


Found this article helpful? Click the Thumbs Up button.
Have an additional comment? Post it below.
0 Kudos