Configure Dual Write for Distributed Alert Server

Dual write is for distributed Alert Server deployments in which the Data Server hosting alerts is on a different system from the Central Alert Server and client. This configuration mitigates the delays with Alert Table updates which occur in this type of deployment. However, this setup also causes the data in the Alert Table to be temporarily out of sync with the master alert data. Consider the limitations of this feature before using it.

By default, this feature is disabled.

Default Behavior
When a user clicks the Own, Suppress, Unsuppress or Close button in the Alert Table, the associated command executes on the selected alert in the Data Server that is hosting the alert. The hosting Data Server updates the alerts and pushes the updated alert data to the Central Alert Server. The Central Alert Server then pushes the updated alert data to the client hosting the display and the Alert Table gets updated.

Dual Write Enabled Behavior
When dual write is enabled, the command is applied directly to the Central Alert Server alert cache--before the action is executed on the Data Server that is hosting the alert. This reduces the delay between executing the action and seeing the result in the Alert Table.

To Enable Dual Write:

  1. Open the RTView Configuration Application and go to the General>CUSTOM PROPERTIES tab.

  2. Add a property using the following for the Name and Value fields:

    3. name=sl.rtview.sub
    value=$rtvUserEnableAlertDualWrite:1

  3. Click icon_saveOk00008.gif to close the Add Property dialog and icon_save00009.gif (in title bar) to save your changes.

  4. Click cui_requires_restart00010.gif to apply changes.

Limitations
The following limitations apply when dual write is enabled:

  1. If an alert is cleared, clicking on Suppress or Unsuppress updates the Central Alert Server cache, but not the actual alert. The suppressed state of an alert cannot change after the alert is cleared.

  2. Clicking on the Close button immediately updates the Cleared value in the Alert Table, but the Cleared Reason value does not update until the server hosting the alert closes the alert and sends an update.

  3. If the server hosting the alert sends an update between the time you click on one of the buttons listed and the time that server processes the associated action, the value in the table toggles between the new value and the old value. For example, you select an alert and Suppress it. At the same time, the alert severity changes in the back-end server. The table initially updates with old severity with Sup set to true, then updates with the new severity with Sup set to false, and then updates with the new severity with Sup set to true. If your Central Alert Server is configured to notify when the Sup column changes, you receive notifications for all three of these changes (true, false, true).

  4. If the server hosting the selected alert is not connected or not enabled when you click Own, Suppress, Unsuppress or Close, the value in the Alert Table updates but that value is not applied to the real alert. When the server hosting the alert connects again, the value reverts to the previous value. This is not likely to occur because the Own, Sup­press, Unsuppress or Close buttons are disabled with the server hosting the selected alert is not connected or is not enabled. However, it is possible that you perform the action just as the server hosting the alert is exiting before the buttons are disabled.