Application log files are an important component of any application and they are especially helpful troubleshooting an issue. When requesting OneCloud support, our team generally needs the following:

  • A description of the problem you are encountering and the expected result

  • The support user to be enabled in your OneCloud tenant

  • A link to the Chain execution that experienced the problem

  • When using a GroundRunner, the logs from your GroundRunner deployment

In this post, we provide instructions on how to build a Chain to automatically collect OneCloud GroundRunner logs and email them to the OneCloud administrator. This solution provides a self-service mechanism to gather the logs and is intended for OneCloud users that do not have direct access to the GroundRunner installation path. After you collect the logs, you can provide our support and engineering teams the information they need to help resolve any issues faster.

To better understand the Chain, let’s take a closer look at the OneCloud GroundRunner installation. When the GroundRunner is installed, a number of executables and directories are created. Within the root installation directory, the executables are installed. Consecutively, two subdirectories that are created. The first subdirectory is for data processing and the names of this directory is the token specified when installing the GroundRunner. The second subdirectory is the log directory. This is where the GroundRunner log is saved.

Below is a sample Windows installation:

Root installation directory: C:\oneloud\groundrunners\production\OneCloud-Documentation

Notice the log subdirectory within the root directory.

Now that we have insight into the infrastructure, let’s explore how a Chain can retrieve the GroundRunner logs. In summary, the Chain will prompt the user to indicate which logs should be collected (current log or all logs) and then retrieve, compress, and email the archive to the appropriate party.

Ask All or Current

OneCloud leverages an automatic log rotation mechanism that automatically archives logs after a certain size is reached, or when the service is restarted. This means that the log directory can have files for both the current log as well as archived logs. To allow for this differentiation, the Chain should be configured with a Runtime Input to determine if all logs or just the current active log needs to be collected with a simple dropdown field. The values ‘Current’ and ‘All’ are created as options with Current as the default option as this is the more prevalent choice.

GroundRunner Path

The Runtime System Variable InstallationDirectory provides the path to the GroundRunner program (ocrunner). With the - Render Text Template Command - from the Handlebars BizApp we can parse this system Variable and extract the aforementioned GroundRunner root installation directory.

In addition, Variable Transformation is used to parse the Runtime System Variable. For this step, we will utilize the - Split Variable - transformation to create a list that contains the root installation directory and the GroundRunner program name (ocrunner). Next, we will use the Pick from List transformation to return the first element in the list. The below represents a Windows deployment.Note that this needs to be modified for a Linux deployment.

Set Dynamic Chain Variable

The - Set Dynamic Chain Variable Event - is leveraged to set the value of a Dynamic Chain Variable (GR_Root_Dir) to the root installation directory which was previously derived in the GroundRunner Path step. We utilize this approach since the root installation directory is used in multiple nodes of the Chain. Rather than deriving this information within each Command, we will set a Dynamic Chain Variable once and use throughout the remaining Commands.

Current Only

To evaluate the Runtime Input value selected, we utilize a Conditional. The Success branch accounts for when a user selects Current while the Failure branch accounts for when the user selects All Logs.

Zip - Current Only

The - Zip Command - of the File Utilities BizApp is used to create an archive for the current GroundRunner log (output.log). Notice the use of the Dynamic Chain Variable GR_Root_Dir and Variable Transformation on the Runtime Variable Chain.ExecutionDateTime which creates an archive name with a date and time stamp that is file name compliant.

Zip - All

Similar to the Zip - Current Command, we will utilize the - Zip Command - of the File Utilities BizApp for Zip - All. In this case, the Source files parameter specifies the entire GroundRunner log directory. This means that all files in the directory will be added to the archive created by this Command.

Get File - Zip

We utilize the - Get File Command - of the File Utilities BizApp to retrieve the zipped archive created by either the Zip - Current Only, or Zip - All node.

📓 The file we are retrieving has the same name as the archive name in both Zip nodes.

Branch Conditions

Because the conditional can only complete one of the zip branches, we need to indicate whether to Execute on Skip for both of the branches that connect to the Get File Command.

Email Log

Finally, the - Send Email Command - from the Email BizApp will allow us to easily send the zipped archive to the appropriate parties. We utilize the Email BizApp, because the embedded OneCloud email notification service does not allow you to send file attachments when utilizing a GroundRunner.

As a matter of leading practice, we added the Runtime Input Trigger value to the subject line, and the output of the Get File Command to attachment parameters.

📓 Log Distribution

In this Chain, we chose to email the zipped archive; however, we could also opt to move the archive to a network or cloud storage location. This final step should be configured to meet your organizational needs and security requirements.

Did this answer your question?