Introduction

JS7 collects log output created by jobs and workflows:

• The Task Log is the log output collected from a job run.
• The Order Log includes Task Logs of any jobs included with a workflow. In addition, it includes information about JS7 - Workflow Instructions that have been executed.

JS7 provides a Running Log that displays output in near real-time.

Log View Window

The Log View window is available for order logs and task logs

• from the JS7 - Workflows view that displays the selected workflow's order history and task history,
• from the JS7 - Order History and JS7 - Task History.

Workflows View

Consider the given workflow that implements forking/joining of parallel branches in a workflow like this:

Explanation:

• The lower part of the screenshot displays the Order History that makes the order log available when clicking the Order ID.
• Right to the Order History users find the Task History that displays individual tasks executed for the given workflow. Clicking the job name will display the Task Log.
• Both logs are similarly available from the JS7 - Order History and JS7 - Task History.
• The size of the workflow's Order History and Task History can be changed in JS7 - Profiles - Preferences.

Order Log

For the given workflow the Order Log can look like this:

Explanation:

• The top of the screen offers a number of options:
  • and will expand and collapse log output of any jobs executed for the workflow.
  • and will expand and collapse output of the selected job.
  • Main: displays/hides lines holding information start times, job names etc. that are using the [MAIN] qualifier.
  • Success: displays/hides lines holding success messages using the [SUCCESS] qualifier. Such lines use the green color.
  • stdout: displays/hides log output from jobs written to the stdout channel.
  • Debug: displays/hides log output from JVM jobs writing debug messages, see JS7 - Job Classes.
  • Detail: displays/hides details about events, for example the timestamp when an order is forking and when child orders are joining. Such lines use the blue color.
• On the right side of the screen users find the icon that opens the navigation panel:
  • The panel displays jobs and other JS7 - Workflow Instructions in historical sequence.
    • If a job fails and is repeated then it will occur a number of times.
    • The navigation panel displays the hierarchy of workflow instructions.
  • and will expand and collapse the navigation panel for nested workflow instructions.
  • Clicking a specific job or instruction in the navigation panel will highlight the log output related to the instruction.
• If jobs are running on Agents that make use of different time zones, then users can specify timestamps in log output to be converted to their time zone, see JS7 - Profiles - Preferences. Otherwise the original timestamps of the Agent processing the job or Agent/Controller processing the instruction will be displayed.

Task Log

For a given job the Task Log can look like this:

Explanation:

• Use of checkboxes is similar to display of the Order Log.
• Outo

Running Log

A Running Log represents the fact that an Order Log or Task Log is displayed for a running order or task. Any output created by the order / task is immediately made available.

The Running Log is provided in near real-time, typically with a delay of 1-2s.

• Log output is created
  • from jobs that write to the stdout or stderr channels,
  • from events that signal processing of instructions such as a job start, forking / joining of an order etc.
• Log output is displayed in historic sequence.

Availability of Logs

Streaming of Logs

Log output is made available like this:

• Log output created by jobs running with Agents is streamed to the Controller. This prevents log files from being created in the Agent's file system.
• Log output forwarded by Agents and log output created by the Controller are streamed to the JOC Cockpit's JS7 - History Service. The service will persist log output to temporary files and to the JS7 - Database.

Streaming makes log output available to JOC Cockpit within 1-2s.

Factors that prevent timely availability of logs include:

• unavailability of the Controller. In this situation the Agent will store log output to its journal and will try to stream log output later on when a Connection is established by the Controller.
• unavailability of JOC Cockpit. In this situation the Controller will store log output to its journal and will try to stream log output later on when a Connection is established by JOC Cockpit.
• high load of the database.

Completion of Logs

Task Logs are completed when tasks are terminated. At that point in time the Task Log is persisted to the database by the History Service running in JOC Cockpit. 

Order Logs are completed when all tasks and other workflow instructions have been processed and when the order is completed. At that point in time the Order Log is persisted to the database.

Before completion Task Logs and Order Logs are stored to temporary files in the JOC Cockpit's <JETTY_BASE>/logs/history directory. This translates to the fact that only the active JOC Cockpit instance can serve to users the logs for which processes are still running. A standby JOC Cockpit instance has no access to temporary files.

Cluster Operation

The History Service of the active JOC Cockpit instance persists Task Logs and Order Logs.

This includes that the active JOC Cockpit instance in a cluster will receive log output from the Controller. When using a standby JOC Cockpit instance in a cluster then no Running Log is available and logs are not available before completion.

In a situation when we find a switch-over between an active and a standby JOC Cockpit instance, the Order Logs and Task Logs will be stored to the database in a compressed format and will be removed from the file system by the previously active JOC Cockpit instance. The newly active JOC Cockpit instance will extract related logs from the database and will store them with JOC Cockpit's file system.

In case of fail-over, for example in case of a crash of JOC Cockpit, the standby JOC Cockpit instance will become active and will ask the Controler to repeat delivery of log output for any Task Logs and Order Logs that have not been persisted in the database.