Scripting with logs

In this recipe, we will look into how logging works in scripting. You will learn how to create log entries and where they are stored.

Getting ready

We just need a working Orchestrator, and you will need the rights to create new workflows and run them. We will work with the Orchestrator Client.

Additionally, we need administrative (root) access to the Orchestrator's operating system.

How to do it...

We will split this recipe into two sections, Creating logs and Checking the log files.

Creating logs

We will now create log entries during a workflow:

  1. Create a new workflow.
  2. Drag all log elements from the Log section into the workflow and arrange them as shown here:

    Creating logs

  3. Create the following variables:

    Name

    Type

    Section

    Binds with

    logText

    String

    IN

    Transports error text

    logObject

    String

    IN

    Transports object text

  4. Bind each log element with the required in-parameter.
  5. Save and exit the workflow.
  6. Run the workflow and enter two different phrases, such as LogText and LogObject.

Checking log files

We will now check the logs:

  1. Go to the workflow execution.
  2. Check the Events tab.

    Checking log files

  3. Click on the Schema tab and then on Logs:

    Checking log files

How it works...

Logs are an important tool for programmers and for system administrators. Log files help programmers understand where a program went wrong or show them the values of variables during runtime. For system administrators, log files help them keep track of who ran what workflow, and when.

In logs generated by the execution of a workflow, you can copy the content (the copy icon), insert a *** line (the pencil icon), or delete the whole log (the red X icon) and filter by criticality, and even switch between pages.

The main difference between server and system logs is that server logs are stored in the Orchestrator database and system logs are stored in the system's log files. This is especially important if you work with Orchestrator clusters; see the recipe Building an Orchestrator cluster recipe in Chapter 3, Distributed Design.

The server log files get rolled as specified in the recipe Orchestrator log files in Chapter 2, Optimizing Orchestrator Configuration. Server logs are stored with the workflow execution until purged depending on user settings (see the recipe User preferences in Chapter 7, Interacting with Orchestrator). Server logs are persistent as they are stored in log files on the Orchestrator server.

A log event can have four categories:

Syslog value

Debug

Info

Warn

Error

Workflow element

-

Log

Warning

Error

Logs

[D]

[I]

[W]

[E]

JavaScript

System.debug (text)

System.log (text)

System.warn (text)

System.error (text)

Server.debug (text, object)

Server.log (text, object)

Server.warn (text, object)

Server.error (text, object)

Each of the four categories can be chosen at will. Any information that would be critical to troubleshoot a workflow several hours/days after it's run should be logged using the server.

Tip

Sending excessive logs to the server will dramatically increase the size of the Orchestrator database and slow down the orchestration engine performance, so it must be used wisely.

In JavaScript, using logs is quite a good way to fix bugs. A typical thing to do is to write out variables that exist only inside a script element, for example, System.log("Mark"), System.log("Log: "+variable).

Log file location

There are multiple ways to check the physical log files. The most common one is to check the log files on the Orchestrator OS. The one we are interested in is: /var/log/vco/app-server/scripting.log.

This directory also contains other log files that are discussed in the recipe Orchestrator log files in Chapter 2, Optimizing Orchestrator Configuration.

This directory contains all information about running scripts. When we look at it, we should see the following entry for our example workflow:

2016-04-22 23:38:04.140+0200 INFO  {[email protected]:40285c8c543d802d01543fe885a40127} [SCRIPTING_LOG] [05.01 Working with Logs (4/22/16 23:38:03)] LogText - LogObject

There is quite a lot of information, for example, what workflow (05.01 Scripting with Logs) was executed and also the Orchestrator user ([email protected]) who executed it.

Alternatively, instead of logging into the appliance, you can use the Control Center to access logs in two ways:

  • You can download the scripting.log from the Control Center file browser in the /app-server-logs folder
  • You can inspect a workflow and check the logs there

For the last two methods, please see the recipe Control Center titbits in Chapter 2, Optimizing Orchestrator Configuration.

Altering log elements

You can easily use log elements to delete the input variable out of it and then use scripting to fill in whatever you like.

See also

The example workflow, 05.01 Scripting with Logs.

The recipe, Redirecting Orchestrator logs to an external server in Chapter 2, Optimizing Orchestrator Configuration.

The recipe, Orchestrator log files in Chapter 2, Optimizing Orchestrator Configuration.

There is a nice example in the recipe, Building an Orchestrator cluster in Chapter 3, Distributed Design to show the difference between server and system logs.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset