The topic describes the AppDynamics Events Service, the on-premises data storage facility for unstructured data generated by Application Analytics, Database Visibility, and End User Monitoring deployments.
About the Events Service
The MySQL database embedded in the Controller stores application metric and configuration data generated by the Controller. While an embedded database is sufficient for storing this type of data, the high-volume, performance-intensive nature of analytics data requires dedicated, horizontally scalable storage. In an AppDynamics deployment, this role is served by the AppDynamics Events Service.
The Controller includes a bundled an Events Service instance, which is used by the Database Visibility product by default.
For data redundancy and storage scalability, however, or if you are using End User Monitoring or Application Analytics in an on-premises Controller deployment, you need to deploy a dedicated Events Service installation.
Multiple AppDynamics components that depend on the Events Service should use the same Events Service instance or cluster.
Deployment Topology Overview
You can deploy the Events Service to a single node or to a cluster of three or more nodes. Clusters are horizontally scalable, so nodes can be added as your data storage requirements grow. A cluster also provides data replication and redundancy, helping to ensure data integrity in the event of a node failure.
The Controller includes an embedded Events Service instance used by the Database Visibility product by default. However, the embedded Events Service is not meant to be used with production Application Analytics or EUM installations, since it runs on the same machine as the Controller and does not offer data replication or scalability. It may be used for small-scale environments, especially those intended for demonstration or learning purposes. Note however that it's not possible to migrate data from the embedded Events Service to an external Events Service instance if upgrading later.
Your Events Service can be deployed to support multiple Controllers, thereby becoming a shared Events Service.
Single Node Deployment
In a single node Events Service deployment, the Events Service runs on a dedicated machine. The Controller and other Events Service clients can connect directly to the Events Service node or through a load balancer. Deploying a single node Events Service behind a load balancer allows you to grow the deployment to a multi-node cluster easily, without having to modify the clients.
A multi-node cluster is made up of three or more nodes. With a cluster, the Controller and other Events Service clients, the EUM Server and Analytics Agent connect to the Events Service through a load balancer, which distributes load to the Events Service cluster members.
In a single node deployment, connect through a load balancer or directly to the Events Service.
The nodes in a cluster swap a large amount of data. For this reason, when deploying a cluster, make sure to install all cluster nodes within the same local network, ideally, attached to the same network switch.
Shared Events Service
You can connect multiple Controllers to a single on-premise Events Service deployment using the same procedure that is required to connect a single Controller. You would need to configure the Controller URLs for the Events Service to point to the shared Events Service, and make sure the Controller keys are correct. The Controllers can then handle syncing to the shared Events Service. There are no additional requirements.
When compared to a multiple Events Service cluster configuration, a shared Events Service configuration requires less maintenance and lowers cost. Since the Events Service is horizontally scalable, having a single large instance provides the same functionality as multiple instances.
There is no limit to the number of Controllers that can share an Events Service. However, it is recommended that you use separate Events Services for dev and prod. Work with your AppDynamics account representative if you plan to expand your shared Events Service cluster.
The default ports used by the Events Service are:
- Events Service API Store Port: 9080
- Events Service API Store Admin Port: 9081
The Events Service cluster members use additional ports for internal communication among the cluster members. All the ports used within the cluster are listed in the Events Service configuration file,