Log level

Universal Extensions support a configurable log level.  The log level can be specified at template level:

And overridden at task level:

This allows Extension code to be written with logging statements only print if the log level is set to an appropriate level (e.g. Debug).

For example, adding the following code to an extension under extension_start():

        # Display current log level.
        level = logger.level
        logger.critical("The log level is %s", level) 
        logger.critical("This is a critical log message.")
        logger.error("This is an error log message.")
        logger.warn("This is a warning log message.")
        logger.info("This is an info log message.")
        logger.debug("This is a debug log message.")
        
        logger.info("state: ")
        logger.info(state)

and setting the Log Level to Debug would produce the following output:

As you can see, in addition to printing the message passed to the logging function, valuable context information is added automatically like timestamp, file name, and line number.

Adding Debug level statements throughout your code that can be easily turned on and off as needed will go a long way towards finding problems.

Retrieve Output

If an Extension task completes with an unexpected result (and perhaps no output), perform a "Retrieve Output" and select "Standard Output and Standard Error".  Be sure to set a sufficient line count to ensure you get back everything:

This will ensure you are seeing everything that was produced by the execution of the Extension task.

Agent Cache Directory

As an alternative to retrieving the output from the Controller, you can go right to the cache directory on the target agent system.  The standard out and standard error for all tasks are written to these directories. 

The files have the format:

<UUID>_stdout

<UUID>_stderr

Where <UUID> is the UUID of the task instance.  For example:

1618409011646336487EAG8TLHASQSQ7_stdout
1618409011646336487EAG8TLHASQSQ7_stderr

Debugging Dynamic Choice Field

Dynamic Choice commands do not return stdout or stderr to the Controller. If the expected output does not show up in the Choice field drop-down, it may be difficult to understand what went wrong.  The information provided here will help you understand how to find the cause of problems.

Console

If a Dynamic Choice Command returns an error, the Controller will log the error message in its Console.  This will provide limited information but, in some cases, it will be all that is needed to determine the cause of the problem.  In other cases, it may be necessary to troubleshoot by reviewing files in the cache directory.

Choice Commands under the hood

When Choice Commands execute on the target agent system, an Extension instance is started in it's own Worker process to execute the command (just like with task execution).  A stdout and stderr file is created for the process under the agent's cache directory - again, just like with task execution. 

If a Dynamic Command encounters an unexpected error, stack trace information will be written to stderr and, therefore, be available in a <UUID>_stderr file in the cache directory. In the case of Dynamic Choice Commands, the UUID is the request ID of the message sent by the Controller to the target agent - not the UUID of the task from which it is issued.

Logging

The same logging facility described above for task execution is available to Dynamic Choice Commands:

        self.log.debug("This is a debug log message.")

While, the stderr file that contains the logged messages is not sent back to the Controller, it is available in the agent cache directory on the target agent system.

Debugging Dynamic Commands

Dynamic commands do not return stdout or stderr to the Controller so, if the expected output does not show up in the task instance, it may be difficult to understand what went wrong.  The information provided here will help you understand how to find the cause of problems.

Console

If a Dynamic Command returns an error, the Controller will log the error message in its Console.  This will provide limited information but, in some cases, it will be all that is needed to determine the cause of the problem.  In other cases, it may be necessary to troubleshoot by reviewing files in the cache directory.

Dynamic Commands under the hood

When Dynamic Commands execute on the target agent system, an Extension instance is started in it's own Worker process to execute the command (just like with task execution).  A stdout and stderr file is created for the process under the agent's cache directory - again, just like with task execution. 

If a Dynamic Command encounters an unexpected error, stack trace information will be written to stderr and, therefore, be available in a <UUID>_stderr file in the cache directory. In the case of Dynamic Commands, the UUID is the request ID of the message sent by the Controller to the target agent - not the UUID of the task instance from which it is issued.

Logging

The same logging facility described above for task execution is available to Dynamic Commands:

        logger.debug("This is a debug log message.")

While, the stderr file that contains the logged messages is not sent back to the Controller, it is available in the agent cache directory on the target agent system.

< Previous