Sisense alerts are generated from your application server. In a high availability configuration, you can designate one of your query nodes as the Alerts node. The Alerts node is responsible for sending alerts to your users when the other query nodes are down or in the processing on attaching the latest version of the ElastiCube from your build node.
The diagram below describes a common high availability configuration in which the query node on the left represents the Alert query node in the ElastiCube Set. If either of the query nodes on the right fail, the Alert query node continues to send alerts.
To add Sisense Pulse to your high availability configuration, you must configure three Sisense configuration files on each of the non-Alert query nodes. The configuration files of the non-Alert query nodes should point to the Alert query node that supports Sisense Pulse. To enable communication between the Alert node and the rest of the query nodes, the credentials of the Alert node should be copied to each of the query nodes.
Note: You cannot add ‘localhost’ to an ElastiCube Set. Instead, you can add your localhost as a new server with its IP address as the server name and then add ElastiCubes from it to an ElastiCube Set.
The following files must be configured:
This file is located at …\Program Files\Sisense\PrismWeb\vnext\config
The db_server and port fields should be set to the IP address and port of your Alert query node.
To allow your query node to communicate with your Alert query node, the following details should be copied from your Alert query node to each of your other query nodes. The AppUser is the Sisense application database user.
This file is located at …\ProgramData\Sisense\PrismServer
The value of the RabbitMQServer parameter should be changed to 0 on each non-Alert server. This prevents the query node from sending alerts. This value is not changed on the Alert query node as it will be the server that sends alerts.
As of Sisense V6.7, the following limitations for Sisense Pulse in high availability configurations are in place:
- Build alerts are not supported
- Dashboards supported by query nodes that are currently down, may receive alerts from the Alert query node based on updated data not displayed in the dashboard supported by the query node that is down.
- If the Alert query node is down, and then returns to service, alerts may be sent late depending on how long the Alert query node was offline.
Hey! Was this article helpful?
Questions? Ask the community.