Notification service
The Notification events generation service of the IBM® Security Guardium® Key Lifecycle Manager agent periodically checks the status of the Db2® HADR setup and the connectivity between the master servers. If the service detects a failure or an issue, it generates a notification event. You can create or use an existing notification consumer, such as a REST service or a utility, that takes the notification events as input and triggers email notifications.
Overview
As an administrator, you can use the notification event information to determine issues in the Multi-Master setup and resolve them.
Notification events are generated based on certain scenarios that occur in a Multi-Master setup such as the primary master server is unreachable from the principal standby master server or another master server in the cluster, a standby master server is unreachable from the primary master server, and so on.
Accessing notifications
Every notification is recorded in an XML file (notification_<date-time-stamp>.xml). A notification file is created for each run of the Notification events generation service.
SKLM_INSTALL_HOME\agent\notifications(Windows) C:\Program Files\IBM\GKLMV42\agent\notifications
(Linux) /opt/IBM/GKLMV42/agent/notificationsIf the primary master server is offline, the notifications are stored on the other master servers of the cluster.
The default period between two subsequent runs is 5 minutes. You can configure this period in the notification.svc.interval property of the SKLMConfig.properties file. The file is located in the WAS_HOME\products\sklm\config. Do not directly edit the configuration file. Instead, use Update Config Property REST Service to update the properties.
Specify the value of this property in seconds. For example,
notification.svc.interval=120
Where 120 means 120 seconds.
You can use them as input to a notification consumer, such as a REST service or a utility, that will trigger email notifications.
Using notifications
You can use the notification details to determine issues in the Multi-Master setup and resolve them.
- Notification event: specifies the message ID and message text that you see in the notification event.
- Scenario: specifies the issue and scenario in which the event is generated.
- Severity: indicates the urgency of resolving the issue that is mentioned in the scenario.
- Event source: specifies the master server in which the event occurs.
- Suggested actions: provides the actions that you must take to resolve the issue that is mentioned in the scenario.
| Notification event (Message ID and message) | Scenario | Severity | Event source | Suggested actions |
|---|---|---|---|---|
CTGKM3385IPrimary master server hostname is unreachable from master server hostname. Check the network connectivity between these master servers. For more information, see the Notification service topic in the product documentation. |
The primary master server is unreachable from another master server (not principal standby) of the cluster. | Low | Master server | Check the network connectivity between the primary master server and the other master server of the cluster. |
CTGKM3386IStandby master server hostname is unreachable from the primary master server hostname. Check the network connectivity between these master servers. For more information, see the Notification service topic in the product documentation. |
The standby master server is unreachable from the primary master server. | Medium | Primary master server | Check the network connectivity between the standby master server and the primary master server. |
CTGKM3387IDb2 HADR setup is down on the master server hostname. Check whether Db2 and Db2 HADR operations are running on the master server. If not, start them. For more information, see the Notification service topic in the product documentation. |
Db2 HADR setup is down on the primary or standby master server. | Medium | Primary or standby master server | Check whether Db2 and Db2 HADR operations are running on the master server. If not, start them. Check whether synchronization is running between the primary and standby master servers. For more information, see the Multi-Master cluster section in the technote: https://www.ibm.com/support/pages/node/881734 |
CTGKM3388INon-HADR master server hostname is unreachable from the primary master server hostname. Check the network connectivity between these master servers. For more information, see the Notification service topic in the product documentation. |
A non-HADR master server is unreachable from the primary master server. | Low | Primary master server | Check the network connectivity between the primary master server and the non-HADR master server of the cluster. |
CTGKM3568IThe primary database is unreachable from the standby master servers. The Multi-Master cluster will operate in read-only mode. Key serving will continue but you cannot add or modify existing data. Resolve the issue with the primary master server or promote the principal standby master server to primary. For more information, see the Notification service topic in the product documentation. |
The primary database is unreachable from the standby master servers. | Low | Standby master server | Check whether the primary master server is down or for a network issue between the primary master server and principal standby master server. For more information, see Recovering a Multi-Master cluster from a read-only state. |
You can create or use an existing notification consumer, such as a REST service or a utility, that takes the notification events from the XML files as input and triggers email notifications.
Sample notification consumer
A sample utility that automatically triggers emails on occurrence of a notification event is available for your use. You can customize this utility further according to your requirement.
Click here to download the utility (SKLM_SampleNotificationConsumer.zip file).