Overview
To deploy analytics successfully, you should understand the following concepts:
EUM and Analytics 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 do Events flow through the system?
Events come to the Events Service in two flows:
The Events Service also handles queries from the Controller. Even though Controller queries are not events, but they still contribute to load on the Events Service.
What flows into the Events Service from the EUM Server?
Demand on the EUM Server 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 Server.
However, we do control what flows out of the EUM Server, 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 Server.
- The EUM Server determines whether the beacons are valid, based on configurable rules.
- Based on beacon content, the EUM Server generates snapshots, session information, and metadata and then sends these to the Events Service.
Based on configurable rules, the EUM Server 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 Server.
Beacons, Events, and Sessions
A beacon is a network request from an EUM agent that includes an agent ID and metadata about the events or activities that were reported.
A session consists of a series of beacons that share the same agent ID and which occurred within a configured period of time. The default configured period is five minutes. A session ends and a new one is created if there was no activity during that configured period of time.
For example, if a series of beacons are sent within the default configured period of five minutes with no inactivity and have the same agent ID, the events reported in those beacons are included in the same session. If an event occurs outside of the configured period of inactivity, however, a new session is created.
Beacons from Browser Actions
The JavaScript Agent generates a beacon for every browser action. The EUM Server 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 = servers.
For more details, see:
Configure Page Identification and Naming for its description of virtual and base pages, and iFrames
Beacons from Mobile and IoT Actions
The Mobile Agent generates a beacon for every action or event on a mobile device. The IoT Java Agent generates a beacon for every action on an IoT device.
Use the C/C++, Java SDK, or the REST API to specify the events to send.
For more details, see:
The EUM Server 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 Server. The EUM Server 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.
