Discussion Feed

When planning instrumentation for deploying Analytics on-prem, how do I build the traffic profile?   Table of Contents How do I understand my traffic for sizing? How do I consider EUM usage when building my Events Service traffic profile?   How do I understand my traffic for sizing? Understanding the characteristics of your traffic is the foundation for successful sizing. To build a traffic profile, answer the following questions.   If I have Business Transactions (BTs) in an APM application I want to enable Analytics on: Is it a new or an existing APM application? Do I have Log Analytics licenses? Additional estimate methods    Am I seeking to enable Analytics on an existing or new APM application? Existing APM application Identify the BTs you need to instrument from the APM application page. For each BT, count how many tiers, and on average how many requests are going through each tier for a single origin BT. Each tier for a single BT produces at least one event if a request passes through the tier and node. Identify the peak sum of BTs per minute for all BTs and sum the count of events per those BTs to estimate the peak events per min. This enables you to size for the number of nodes and CPU. New APM application For a more accurate option, instrument and then go through an existing application. If not instrumented, you should try to access using the available number of requests coming through each tier by: count of log lines/timestamps existing database aggregations Q/A with application stakeholders Figure 1 shows an example of how many BT events per tier are generated. Figure 2 shows the estimated number of events per APM BT.     A tier can be called multiple times by originating BT, thus producing multiple events. If the request performs asynchronous calls on a single node then it's possible that a single request on a single tier could output multiple segments (events). Each async thread call becomes its own segment in the Java Agent. In .NET, results from an async call could be merged into one or more segments (events).    Figure 1:  Example of how many BT events per tier are generated     Figure 2: Estimated number of events per APM BT     Do I have Log Analytics licenses? If so, then: Collect log samples for a period of time per source. Determine the start and end times of each log Determine the file sizes which determine the required disk size for the Events Service footprint (which is approximately = file size * 1.7) Determine the number of lines or timestamps. Each is counted as one event Calculate the average number of events per minute for each log source Avg number of lines per source number 1 = (file 1 num of lines / (end time file 1 - start time file 1) + … + (file N num of lines / (end time file N - start time file N )) / number of files in source number 1 Then, sum the averages for an overall average number of log events Logs     You can also use these additional estimation methods: What licenses do you have? The limits on traffic that licenses specify serve as useful benchmarks when you estimate events later in the Instrument, Run, and Refine process. What is the shape of traffic over time? Is your traffic consistent or spiky? What times of the day, week, month, season, or year produce changes? You should plan your deployment to perform well at peak loads, or at least at the 90th percentile loads. What are typical numbers for concurrent users? Does this vary over time, and if so, what are the patterns? What are typical patterns of user behavior? Are users doing the exact same thing repeatedly, or taking diverse actions? How are the patterns concentrated or spread out over time? Mobile app crash rate If any, what is the typical crash rate for your mobile apps?     How do I consider End User Management (EUM) usage when building my Events Service traffic profile?  Unlike Business Transaction (BT) or Log Analytics licenses, the number of EUM licenses does not translate into a good basis to estimate what size machine can support a particular deployment. EUM performance depends on the number of beacons.   To accurately estimate expected beacons, you must understand: The millions of browser page views and/or IOT events allowed by the licenses can be distributed in many ways over the year. Temporal distribution of traffic is key.  Mobile licenses, by contrast, allow some thousands of mobile agents to connect per month—but any of those agents can send an unlimited number of requests. User behavior is key.   When building the traffic profile, you need detailed and accurate information. The following will help you determine the projected EUM Analytics load:    Browser Request User Monitoring (BRUM) EUM license types and their unit-to-beacon relationships     Browser Request User Monitoring (BRUM) How many page views? How many beacons per page view? Typically, it is one.  Typically, each beacon would produce one session event and one browser request event. Mobile Request User Monitoring (MRUM) How many session events per user event? Typically, it is one.  How many MobileSnapshots per user event? Typically, it is one.  How many crashes in a worst-case scenario? Review the MobileCrashReport. Internet of Things (IoT) How many devices and device types? What is a typical transmission rate per minute per device type?   This table lists the unit-to-beacon relationship for each EUM license type. EUM License Type Units Unit-to-Beacon Relationship BRUM one million page views/year One to one IoT TBD million IOT events/year One to one MRUM 5K mobile agents/month can connect No unit-beacon relationship can be derived because: Each mobile agent can send unlimited requests per month. The total number of mobile beacons is not limited. EUM license types and their unit-to-beacon relationships   Note: For up-to-date licensing information for EUM Analytics, click here .   Note: By default, each EUM Analytics event type is limited to 50GB per day. You can adjust that limit inside each Events Service node’s properties located in this directory: <Events-Service-Home>/conf/events-service-api-store.properties  in the  ad.es.event.maxDailyEventTypeBytesQuota folder ... View more

Overview To deploy analytics successfully, you should understand the following concepts: Events How Events Flow Through the System What Flows into the Events Service from the EUM Processor What Flows into the Events Service from the Analytics Agent Controller Queries Beacons Beacons, Sessions, and Metadata Beacons from Browser Actions  Beacons from Mobile and IoT Actions Resource Timing Snapshots Performance Considerations Analytics Trade-offs   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: Configure Page Identification and Naming for its description of(describes virtual and base pages, and iFrames) Configure Which Ajax Requests Are Sent to the Events Service   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: IoT Java SDK documentation IoT C/C++ SDK documentation   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, t he 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 . ... View more