Defining logs

When designing logs, make them easy to read and easy to parse.

Log files store messages issued from various application and system components.

Logs need to be easy to read, understand, and parse. Keep the log file readable, clean, and descriptive. Show the data being processed and show its meaning. Show what the bot is actually doing. Good logs can serve as a great documentation of the bot itself.

Logs help people and machines to:

  • Determine if a process completed successfully.
  • If a process does not complete, review information about why a process failed to complete.
  • Determine if the bot is performing as expected.
  • Interactively follow the logs.
  • Parse the logs with a tool or import the logs into Excel to gather and analyze metrics.
  • Import the logs into a database.

The following is a set of standards to ensure logging is properly executed.

Types of logs

  • Process/Informational—The process log is meant to be an informational log. It can be used for monitoring normal operation of a task, but more importantly, it can be used for auditing. Using the process log for an audit trail can be an excellent method for determining if a business process was completed properly. For example, was an order placed, or a ticket completed without error.
  • Error—The error log is for detailed error messages. When an error occurs in a task, place the notification that an error occurred in the process log. Place detailed information about the error in the error log.
  • Debug—Store debugging information in its own log file and turn debug collection off when in production mode. Use an isProductionMode variable to turn these statements off when the bot is moved to production.
  • Performance—Performance logging can either go into either the process/informational log or the performance log. In some cases, it is useful to store performance message in its own log file.

Types of messages

  • ERROR—Something terribly wrong had happened, that must be investigated immediately. The task cannot perform its function properly here. For example: database unavailable, mission critical use case cannot be continued, file is busy and cannot be opened.
  • WARN—The task might be continued, but take extra caution. For example: Task is running in development mode. The task can continue to operate, but always justify and examine the message.
  • INFO—Important business process has finished. The information message, sometimes cryptically, states information about the application. For example:
    1. Application action complete. Best case for an airline booking application, it issues only one INFO statement per each ticket, and it states [Who] booked ticket from [Where] to [Where].
    2. Application changes state significantly. Database update or External system request
  • DEBUG—Any information that is helpful in debugging a bot, typically for use by the bot developer. These messages do not go into the process log. Use an isProductionMode variable to turn these statements off when the bot is moved to production.
  • PERFORMANCE—Performance logging can either go into the process/informational log or it can go into the performance log, if a separate performance log has been created. Performance tracks how long it takes to perform specific steps, but avoid too much granularity. In most cases, limit performance logging to an overall business process. For example, how long it took to complete an order, or how long it took to process an invoice.

Tips for creating logs

  • Consumers

    There are two consumers for log files: people and machines.

    People consumers—When people are the consumer, their role influences the type of information they are looking for. A developer might need information to debug, analyze performance, or locate errors. An analyst might need audit information or performance information.

    Machine consumers—Machines read log files typically through shell scripts written by system administrators. Design logs suitable for both these log file consumers.

  • Content

    • Include objects—A good logs includes: timestamp, logging level, machine name, name of the task, and the message.

    • Error log statements.—Include the line number and error description for any error from the Automation Anywhere error handling block.

    • Debug statements—Use debugging log statements when passing variable between sub-tasks. Include the variable values as they enter and exit a sub-task. Use isProductionMode variable to turn off debugging statement when the bot is moved to production.

    • Interface calls—If a bot interfaces with other systems, such as Metabots, APIs, REST or SOAP calls, log those calls and, if appropriate, their responses.

  • Formatting

    • Delimiters—Delimit content values. To support easy log file importing and parsing, use tab delimiting to separate the values.

    • Log-to-file—Use the log-to-file feature built into Automation Anywhere.

    • Timestamp—Use the built-in time stamp in the log to file command.

      Note: Do not create your own method and format for time stamping, even for Excel. Only modify from the built-in version, if there is a specific need for different timestamp.
  • Security and shortcuts

    • Passwords—Never log passwords or any personal information!

    • Short cuts—Do not add short-cut characters and scripts, (magic codes), that only a few people can understand.

    • Numbering—Avoid number formatting. Use patterns that can be easily recognized by regular expressions.

  • Performance

    • Excessive logging—Normal logging commands themselves are not costly in terms of performance. However, do not allow excessive logging. For example, multiple iterations inside of a small loop.

    • Frequency—Create new logs every 24 hours. Add code to verify the current date. If the day has changed, create a new log. Compress and archive (dozing) older log files, as needed. This prevents excessively large log files.