On this page: Related pages:
On this page:
- Use a supported Windows- or Linux-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 Java 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.
The following table shows sizing recommendations and describes the size of the cluster used for testing. This does not mean you are limited to a seven-node event service. If you need to go beyond seven nodes, contact your AppDynamics account representative to ensure proper sizing for your specific environment.
|Event Type||AWS Machine Instance Type|
|i2.2xlarge (61 GB RAM, 8 vCPU, 1600 GB SSD)||i2.4xlarge (122 GB RAM, 16 vCPU, 3200 GB SSD)||i2.8xlarge (244 GB RAM, 32 vCPU, 6400 GB SSD)|
|1 node||3 nodes||5 nodes||7 nodes||1 node||3 nodes||5 nodes||7 nodes||1 node||3 nodes||5 nodes|
|Transaction analytics license units||20||37||44||63||22||41||84||113||53||94||120|
|Log analytics license units||7||10||17||19||16||19||32||44||39||116||270|
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 work load. Real world work loads 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.
Sizing for EUM and Database Visibility Analytics
End User Monitoring and Database Visibility include analytics-related features that can also 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 Visbility analytics events are equivalent to that for Log Analytics, with the raw events size being about 2 kilobytes on average.
Calculate the Sizing for EUM
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.
|Browser Record Type||Memory Requirements Per Event||Optional||Default Retention|
|base page, iframe, virtual page||1 KB / 1.5 KB (with sessions enabled)||No||8 days|
|Ajax requests||1 KB||Yes|
Ajax requests aren’t stored in the Events Service by default.