Events Service Requirements

This page describes general hardware and software requirements for the machines that host Events Service nodes.

General Requirements

• Determine which version of the Events Service that is compatible with your other platform components.
• Use a supported Windows 64-bit or Linux 64-bit based operating system supported by the platform. (See Platform Requirements.)
• Solid-state drives (SSD) can significantly outperform hard disk drives (HDD), and are therefore recommended for production deployments. Ideally, the disk size should be 1 TB or larger. 
• The Events Service must run on dedicated machines with identical directory structures, user account profiles, and hardware profiles.
• For heap space allocation, AppDynamics recommends allocating half of the available RAM to the Events Service process, with a minimum of 7 GB up to 31 GB.  
• When testing the events ingestion rate in your environment, it is important to understand that events are batched. Ingestion rates observed at the scale of a minute or two may not reflect the overall ingestion rate. For best results, observe ingestion rate over an extended period of time, several days at least.  
• The Events Service requires JVM 1.8.
• Keep the clocks on your application, Controller, and Events Service nodes in sync to ensure consistent event time reporting across the AppDynamics deployment.
• Your firewall should not block the Events Service REST API port 9080, otherwise, the Enterprise Console will not be able to reach the Events Service remotely.

About Hardware Capacity and Resource Planning

When estimating your hardware requirements, the first step is to determine the event ingestion rate (for transaction analytics) or the amount of data being indexed (for log analytics). This helps you to determine the number of analytics license units you will need.

Once you determine your license units requirements, it is important to consider other factors that affect the hardware capacity, such as the processing load of queries run against the Events Service and the actual type of hardware used. A physical server is likely to perform better than a virtual machine. You should also take into account seasonal or daily spikes in activity in your monitored environment in your considerations. 

An event is the basic unit of data in the events service. In terms of application performance management, a transaction analytics event corresponds to a call received at a tier. A business transaction instance that crosses three tiers, therefore, would result in three events being generated. In application performance management metrics, the number of business transaction instances is reflected by the number of calls metric for the overall application. In End User Monitoring, each page view equates to an event, as does each Ajax request, network request, or crash report. 

Events Service Node Sizing Based on License Units

The data in this section can help you plan your hardware requirements. It describes recommended hardware configurations (in the context of Amazon EC2 instance types) corresponding to the number of license entitlement units for log and transaction analytics. See License Entitlements and Restrictions for details about license units for log and transaction analytics. 

The hardware shown for each license amount represents the hardware capacity of a theoretical combined load of both transaction analytics and log analytics events. The numbers used were derived from actual tests that were performed with an uncombined load, from which the following numbers were extrapolated. Note that the test conditions did not include query load and so may not be representative of a true production analytics environment.

It is to be noted that the retention can be 8, 30, 60 or 90 days which will directly affect storage requirements.

The following points describe the test conditions under which the license units-to-hardware profile mappings in the table were generated: 

• Average log event size in bytes: 350
• Average size of business transaction event: 1 KB
• Tiers in business transaction: 3 

The tests were conducted on virtual hardware and programmatically generated workload. Real-world workloads may vary. To best estimate your hardware sizing requirements, carefully consider the traffic patterns in your application and test the Events Service in a test environment that closely resembles your production application and user activity.

Database Visibility Events Service Sizing

Database Visibility features use the Events Service for storage. The ingestion capacity and sizing profile Database Visibility analytics events are equivalent to that for Log Analytics, with the size of the raw event being about 2 kilobytes on average.  

End User Monitoring Events Service Sizing

End User Monitoring includes analytics-related features that send data to the Events Service.

In End User Monitoring, each page view equates to an event, as does each Ajax request, network request, or crash report. There can be a few dozen Ajax requests for every page load. In general, the ingestion capacity and sizing profile for EUM or Database Visibility analytics events are equivalent to that for Log Analytics, with the size of the raw events being about 2 kilobytes on average.

To calculate the sizing for EUM, multiply the peak number of browser records in a day by 12 KB. If peak capacity is reached, the Events Service simply starts dropping traffic.

The table below provides details about the memory and storage of different types of browser records. The default retention period is configurable.