This page applies to an earlier version of the AppDynamics App IQ Platform.
For the latest documentation, see the 4.5 Documentation.

Skip to end of metadata
Go to start of metadata

The topic describes the AppDynamics Events Service, the data store for on-premise Application Analytics, End User Monitoring (EUM), and Database Monitoring deployments. 

About the Events Service

The MySQL database embedded in the Controller stores application metric and configuration data generated by the Controller. While the database provides effective storage for this type of data, the high-volume, performance-intensive nature of analytics-based data requires dedicated, horizontally scalable storage.

If you are installing the server components for the End User Monitoring, Application Analytics, or Database Monitoring, you will need to use the Events Service.

Database Monitoring uses the instance of the Events Service embedded in the Controller by default. For data redundancy and storage scalability, however, you can configure Events Service storage for Database Monitoring.

If using multiple AppDynamics components that depend on the Events Service, you should configure the components to use the same Events Service instance or cluster.

If you already have a deployment made up of an on-premise Controller that uses the SaaS EUM Cloud, but now want to take advantage of User Analytics features, you need to install the on-premise EUM Server and configure it to connect to the on-premise Events Service. For more information, see Use the On-Premise EUM Server.

Deployment Topology

You can deploy the Events Service to a single node or cluster. A cluster deployment is made up of at least three nodes. A cluster is horizontally scalable and redundant, as it maintains a single replica of the data. You can add nodes to the cluster as your data requirements grow. Using a single node for the Events Service is possible, but keep in mind that a single node lacks data redundancy. If maintaining a backup of the Events Service data is a requirement for your implementation, you should use a multi-node cluster.  

The Controller includes an embedded Events Service instance used by the Database Monitoring product. 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. It may be used, however, for short-lived, small scale environments intended for demonstration or learning purposes. Upgrading an on-premise Application Analytics or EUM installation that uses the embedded Events Service to a separate node or clustered Events Service is not supported.   

Each Events Service cluster node may run up to two processes:

  • The Events Service API-Store stores data and presents the search and storage API to Events Service clients
  • The Events Service ZooKeeper acts as the coordinator for the Events Service cluster

Single Node Events Service

In a single node Events Service deployment, both processes run on a single machine:

In this deployment, the Controller and other users of the Events Service 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. 

Clustered Events Service

A multi-node cluster is made up of three or more nodes. The first three nodes in the cluster should run both components of the Events Service, the Events Service ZooKeeper and API-Store. Additional nodes in the cluster can run the API-Store process only. For most scenarios, having three ZooKeeper instances for the cluster provides a sufficient level of redundancy.  

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 should distribute load to the Events Service cluster members. In a single node deployment, connect through a load balancer or directly to the Events Service.

The Controller and all nodes in the Events Service cluster must reside on the same local network and communicate by internal network. Do not place cluster nodes on separate networks, relative to each other or to the Controller or EUM Server.

As implied by this requirement, to use the Events Service on premises, the Controller and the EUM Server must be on premises as well. Hybrid deployments (with an on-premise Controller and SaaS EUM) must be migrated to an entirely on-premise deployment (or to entirely SaaS) to use the EUM analytics features.

As listed in the diagram, the default ports used by the Events Service are:

  • Events Service API Store Port: 9080
  • Events Service API Store Admin Port: 9081
  • Events Service ZooKeeper Port: 9050
  • Events Service ZooKeeper Admin Port: 9051

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, conf/

  • No labels