Page History

...

• SystemMonitorNotification can contain several Notification definitions for notification of error or success conditions
  • Notification contain one NotificationMonitor
    • NotificationMonitor contains the configuration for delivery notifications to System Monitor and has the following attributes
      • service_name_on_error (optional) - Service name to send of error/recovery messages
      • service_name_on_success (optional) - Service name to send of success messages if order is successfully completed
      • service_status_on_error (optional) - Service status (e.g. CRITICAL or WARNING) to send of error messages. If not set - CRITICAL will be sended
      • service_status_on_success (optional) - Service status (e.g. SUCCESS) to send of success messages. If not set - OK will be sended
    • NotificationMonitor can has one of the following elements
      • NotificationCommand command line for calling of the extern script for system notification
      • NotificationInterface calling API for system notification (currently for NSCA notifications). This Element has the following attributes
        • service_host (required) - hostname for the host the notification are sent from (the way it is named at the System Monitor)
        • monitor_port (required) - port of System Monitor to receive notifications
        • monitor_host (required) - hostname of System Monitor
        • monitor_encryption (required) - specifies that the communication with the System Monitor is encrypted. NONE, XOR, TRIPLE_DES encryptions are available.
      • NotificationObject contains the configuration of objects, which will be sended to System Monitor
        • JobChains (optional) - can contain several JobChain definitions
          • JobChain (optional) - can contain several JobChain definitions JobChain has the following attributes
            • notifications (optional) - Number of notifications for the same problem. By default - 1
            • scheduler_id (optional) - JobScheduler instance with the given identification. By default - JobChain will be checked in all JobScheduler instances that logged into the same database
            • name (optional) - Job chain name including possible folder names. By default - all JobChains for defined scheduler_id are checked
            • step_from (optional) - Start Job node name for checking
            • step_to (optional) - End Job node name for checking
        • Timers (optional) - can contain several Timer definitions
          • Timer has the following elements
            • JobChains (optional) - can contain several JobChain definitions for performance notificatio
              • JobChain has the following attributes
                • notifications (optional) - Number of notifications for the same check. By default - 1
                • scheduler_id (optional) - JobScheduler instance with the given identification. By default - JobChain will be checked in all JobScheduler instances that logged into the same database
                • name (optional) - Job chain name including possible folder names. By default - all JobChains for defined scheduler_id are checked
                • step_from (optional) - Start Job node name for checking
                • step_to (optional) - End Job node name for checking
                  Sample Notification configuration using NotificationInterface

                  Code Block
                  language html/xml
                  .... <!-- notification message substitution in this case: All Environment variables e.g. %TEMP% or %JAVA_HOME% %ORDER_HISTORY_ID% ... table field name of result row for building message (see table definition SCHEDULER_MON_NOTIFICATIONS) --> <NotificationMonitor service_name_on_error="Error Service"> <NotificationInterface service_host="my_nsca_service_host" monitor_port="5667" monitor_host="nsca_server_host" monitor_encryption="XOR"> order history id=%ORDER_HISTORY_ID%, job chain=%JOB_CHAIN_NAME%, order id=%ORDER_ID%, step =%ORDER_STEP_STATE%, error=%ERROR_TEXT%, check = %CHECK_TEXT% </NotificationInterface> ...

                  <!--
                  For this concrete example and following the description from above (about the schema):

1. Configure for Notifications to a specific System Monitor: op5 Monitor
2. Specify the type of notification: "service_name_on_error" or "service_name_on_success"
3. Specify then the EXACT name of the service (the way it is named at the System Monitor): "OMS Mass Processing Problem Tracking"
4. Specify the EXACT hostname for the host the notification are sent from (the way it is named at the System Monitor): "OMS Interfacing Server"
5. Specify the port the application to receive passive checks is running on: "5667"
6. Specify the hostname of the System Monitor, that is the hostname for the host the notification are sent from: "dipsy.sos"
7. Define the type of encryption is used to send the information to the System Monitor: "XOR"
8. Specify how many notifications have to be sent to the System Monitor for a specific Job Scheduler object:"20" notfications for "MY_JOB_CHAIN_NAME"
9. The same as above in case there is configured a Timer for this Job Scheduler object:"20" notfications for the Timer for "MY_JOB_CHAIN_NAME"
   -->

Job Chains

Job Chains for these solutions have to be placed under \live\notification. Four Job Chains were implemented for this solution and they have the following functions:

• CheckHistory: reads JobScheduler database tables where the logging is placed, analyses them and writes results into another tables, the Notification tables.
• CleanupNotifications: deletes entries in the Notification tables. Currently this takes place once every day.
• ResetNotifications: sets Status for Notifications in the Notification tables (e.g. Acknowledge)
• SystemNotifier: responsible for notifiying the system Monitor about the current notifications. Moreover, this JobChain is responsible for updating the Notification tables after having notified the System Monitor.

...