Download PDF
Download page Events Service Deployment.
Events Service Deployment
Related pages:
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 Cisco AppDynamics deployment, this role is served by the Events Service.
When you install an Events Service on a different host than the Enterprise Console host, it is a dedicated Events Service. You require a dedicated Events Service to:
- Install the server components for EUM, Application Analytics, or Database Visibility.
- Set up data redundancy and storage capability.
- Use EUM, Application Analytics, or Database Visibility in your Controller deployment.
You can deploy the dedicated Events Service as a single node or a cluster of three or more nodes based on your requirements. Additionally, you can add nodes to a dedicated Events Service after the installation. We recommend that you do not add the Controller host as part of the cluster. See Administer the Events Service.
Multiple 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, 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.
Single node deployment is recommended for test environments only. Production environments should deploy a multi-node cluster (see below for details).
Multi-Node Cluster
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.
We recommend multi-node clusters for production environments. Multi-node clusters provide the following benefits:
- Safeguards against data loss: multi-node clusters replicate your data. If one node goes down in production, you would have at least two more nodes storing your data. Additionally, the Events Service continues to run as long as one node runs. Should a node go down in a single node deployment, the Events Service stops running and you would lose your data.
- Provides redundancy: in a multi-node cluster, you can swap nodes.
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. For more information, see:
Supported Deployments
Use this table to determine the supported deployment type and environment for the Events Service.
| Deployment Types | Development Environment | Production Environment |
|---|---|---|
| Multi-Node Clustered Events Service (3+ nodes) (version 20.2 or later) | Yes | Yes |
Shared Events Service
You can connect multiple Controllers to a single on-premises 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 customer support if you plan to expand your shared Events Service cluster.
Default Ports
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, conf/events-service-api-store.properties.
Secure the Events Service
By default, the ad.es.node.http.enabled property in the Events Service configuration file is set to false. To debug or troubleshoot issues with the Events Service, you or the Cisco AppDynamics Support team can enable this property and allow HTTP requests (such as node stats) in ElasticSearch by changing the setting to true. Following the debugging session, immediately disable this property to prevent any (potential) security vulnerabilities and restart the Events Service. The downtime is dependent on the hardware and the service will be unavailable until it restarts.