Product Knowledge Base

Space shortcuts

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Overview

This solution is about monitoring JobScheduler and its objects such as Jobs, Job Chains and Orders. Here you get an overview of how JobScheduler monitoring works. This feature will be available starting from general availability release 1.8.

 

These are some of the features of the architecture of this solution:

  • JobScheduler: The architecture establishes a partition between:
    • Detecting errors: A Job Chain analyses the JobScheduler logging and checks whether the monitored Job Scheduler objects had errors or warnings.
    • Sending alerts: Another Job Chain is responsible for sending the alerts to the corresponding System Monitor. The difference here, is that not all alerts are only incidents, but also events, as in occurrences, for example, the alert that a specific Job Chain was executed and which result it ended up with.
  • JobScheduler: This architecture allows to analyze the Log History of more than one JobScheduler.
  • System Monitor: JobScheduler is able to connect to more than one System Monitor at the same time.

Definitions

  • System Monitor: A System Monitor is an instrument to inform the Service Desk (1st Level Support) about incidents in IT systems. It does not serve for the analysis of the incidents, but merely for the information about the incidents, in order to be able to forward and scale these informations.
  • Passive Checks: These kind of checks are the ones that are sent remotely from an external host (from the point of view of a System Monitor) to the System Monitor. Otherwise, the ones that are carried out periodically by the System Monitor are called active checks.
  • Alerting: An Alert is an alarm, i.e. the message about an event. An alert does not provide every relevant information of an event, but it informs about the existence of the event. An alert can be either positive or negative.
  • Notification: The notification of a specific alert. Not every alert will be notified, just the ones that are so configured will be notified. Notifications are therefore a subset of the alerts and can be either positive or negative too.
  • Acknowledgement: Is the confirmation of an alert and it has the meaning, that the alert has been seen and/or is well known and the incident is trying to be recovered. An acknowledgement is always manually executed, that means, there is always someone that has realized there is a Critical service and this person acknowledges the services (usually by the Service Desk or 1st Level Support). It is never an automatized step.

Benefits

The benefits of the new solution are:

  1. There is no changes to be done in your JobScheduler configuration (Jobs, Job Chains, etc.) in order to get this solution working. You have to add the corresponding Job Chains for the monitoring but do not have to modify your current ones.
  2. The whole architecture lies at JobScheduler side and the solution is then independent from the monitor that the alerts are sent to. The solution works for every monitor that can receive passive checks.
  3. Processing of Jobs and Job Chains in JobScheduler is not affected or modified by the monitoring, neither in sense of performance nor in sense of stability.
  4. The level of detail in a message of a Service in the System Monitor is much higher with this solution. JobScheduler logs very exact what the error is about and this information is sent as a passive check to the specific Service, which shows the log message that JobScheduler logged.
  5. The criticality of an error is immediately recognized in the System Monitor. JobScheduler has all information about errors and this information is sorted out and sent to different Services in the System Monitor for every specific case. Through this feature, the Service Desk is immediately able to set its priority for recovering errors. For example, it does not have the same Criticality to recover an error of Performance (low) than when Documents could not be generated (high). Here you go a representation of this feature:

Functionality

  • Job Chain and Order Monitoring: Job Chains in JobScheduler can be with the new solution monitored. Actually, the elements that are monitored are the Orders that trigger these Job Chains.
  • History Notifications: Not only critical alerts are monitored, but also the positive ones. The history of a specific service is also monitored, to see exactly if a specific workflow was executed or not and what result it ended up with.
  • Timers for Job Chains: There are also Timers that measure the performance of a Job Chain. In case it takes too long for a Job Chain to end, a critical alert will be sent to a System Monitor.
  • Acknowledgment: Once a service in the System Monitor is critical, there is the possibility to acknowledge this service. That action will add an Order to the JobScheduler, so that JobScheduler does not send more notifications to the System Monitor for this service.

Installation and Configuration

As we have seen, the architecture lies at the JobScheduler side, therefore most of the installation and configuration has to be done at the JobScheduler side.

Database Tables

Three database tables have to be set at the JobScheduler database:

  • SCHEDULER_MON_NOTIFICATIONS
  • SCHEDULER_MON_RESULTS
  • SCHEDULER_MON_SYS_NOTIFICATIONS

Java Program

The following JAR file has to be included in your <scheduler_home>/lib folder for JobScheduler:

com.sos.scheduler.notification.jar
jsendnsca-2.0.1.jar


This JARs are currently not included within the JobScheduler installation.

 

XML Schemas

XML Schemas and XML files (see examples below) have to be placed together at \config\notification. The schemas are the ones that define which values are allowed in your XML files for the JobScheduler monitoring. That means, you just have to modify your XML files in order to configure the JobScheduler objects you want to monitor and which System Monitor you want to use for that goal, but the XML schemas do not have to be modified.

Schema: CheckHistoryConfiguration_v1.0.xsd

Description:

  1. Specifies the JobScheduler objects that should be monitored for error and success conditions:
    1. Jobs, Job Chains and Orders eligible for monitoring.
    2. The monitoring of JobScheduler objects is independent from the System Monitor that will be used and applies to all notifications to System Monitors.
    3. For settings that are specific for notifications see the below configuration for System Monitors => Link
  2. Specifies checks to measure the performance of JobScheduler objects:
    1. Timers checks if timeouts for job and job chain execution have been exceeded or expired.

Example: CheckHistoryConfiguration.xml

Here you go an example of an XML file used for the monitoring of a specific JobChain:

 

  • No labels