Configuring logging for a Content Delivery software component

This task applies if you run Content Delivery software components in a Java/JSP web application. You already set up logging when you installed your Content Delivery software components. But you can configure logging in more detail by editing the logback.xml, the configuration file for the Logback logging framework used by Content Delivery. You can also set environmental parameters to tweak your log output.

About this task

RWS recommends against changing the format of the log output. Logback inherits its log output format from the default log output pattern in Spring Boot.

For detailed information about the Logback framework and its configuration, refer to http://logback.qos.ch/documentation.html.

Each of the following Content Delivery roles are used in Tridion Docs and they each have logs. It is possible that you would like to configure logs for one or more of these roles.
  • Content Service
  • Content Deployer
  • Search (both the IQ Query service and IQ Index service)
In addition, in your presentation environment, you can use this task to configure logging for the RESTful API role (the CIL) in your Dynamic Documentation Java web app.

Procedure

  1. In the location of the software component for which you want to activate logging, open logback.xml for editing. This file is located in the configuration location of your software component.
  2. Set the following properties:
    <property name="log.history" value="7"/>
    <property name="log.folder" value="./logs"/>
    <property name="log.level" value="ERROR"/>
    <property name="log.encoding" value="UTF-8"/>
    log.history (number of log files)
    The log.history property specifies the number of log files to back up (the default is 7 files).
    log.folder (logging location)
    The log.folder property specifies the location where log files are saved (defaults to ./logs, that is, the logs/ subfolder of the root location of the Role). You can change this location if you want.
    log.level (logging level)
    To change the default logging level, change the value of the log.level property to one of the values describes in the following table. Note that logging levels are incremental and inclusive; each level logs data for the previous levels. For example, DEBUG also logs and events covered by INFO, WARN, and ERROR.
    Logging LevelDescription
    OFFTurn off logging.
    ERROR (default)Log events that cause a specific feature of the application to fail.
    WARNLog events that are potentially harmful.
    INFOLog neutral, informational messages about high-level functionality being executed.
    DEBUGLog fine-grained informational messages about low-level functionality being executed, intended to discover the source of a problem.
    TRACELog highly detailed informational messages about the application's lowest-level activity,
    ALLMaximum logging level that logs everything.
    log.encoding (logging encoding)
    The encoding used when writing log files. For example, UTF-16.
  3. To specify parameters rather than hardcoded values in logback.xml, refer to the "Variable substitution" section on this webpage: http://logback.qos.ch/manual/configuration.html.
  4. If you want to enable Logback to apply your configuration changes without having to restart your web application, use the scan and scanPeriod attributes in the configuration element. Refer to http://logback.qos.ch/manual/configuration.html#autoScan.
  5. Save and close logback.xml.
  6. If you want, you can also set a number of environmental properties to configure exactly what appears in the log output. A default log output line has the following format:
    TIMESTAMP LOGLEVEL [SERVICENAME,CUSTOMERNAME,ENVIRONMENTNAME,CDENVNAME] LOGMESSAGE
    You can set the value of the following items:
    • SERVICENAME is the name of the microservice that produced the log output, taken from the property spring.application.name in the application.properties file of the microservice.
    • CUSTOMERNAME is the value (say MyOrganization) of an environment variable called customer, which you can set in your operating system, in a properties file, or pass as a -D switch to your microservice installation script.
    • ENVIRONMENTNAME is the value (say DockerCompose) of an environment variable called environment, which you can set in your operating system, in a properties file, or pass as a -D switch to your microservice installation script.
    • CDENVNAME is the value (say staging) of an environment variable called cdenvironment, which you can set in your operating system, in a properties file, or pass as a -D switch to your microservice installation script. The Add-Ons Service already requires you to set this environment variable, so you may already have set it up.
  7. Restart your Content Delivery role or web application.