Configuring logging for the Search Server

You can configure logging in the Search server Docker container by using Run Engine commands.

Note:

When you work with IBM to debug request processing problems, there might be occasions where low-level tracing components must be enabled to capture details for how the request is processed. These low-level Application server trace components do not know the request intent or the potential data within. Therefore, when enabled, it is possible that these tracing components might potentially include sensitive information, in plain text, in the trace file.

It is recommended that you do not enable these types of tracing components on a production system and attempt to simulate the problem on a quality assurance environment to capture the appropriate information. However, if the tracing components must be enabled on a production system, handle the trace files with caution. Before you send the trace, remove sensitive data that might be in the trace before you allow a third party to use the trace for diagnosis. Further, when the trace is no longer required, remove the files with a military-grade data wiping process. When the problem is found and the tracing component is no longer required, immediately disable the low-level tracing components.

Procedure

  • Enable tracing in your target container by using Run Engine commands. There are different methods of implementation.
    Method Procedure
    Enabling trace in a running container in your local Docker environment. Use this method on your local quality assurance or development environment.
    1. Enter your target container.
      docker exec -it container_name bash
    2. Set your trace specification. For example, the following command adds trace on ServiceLogger. For a list of specifications, see see Trace strings.
      run set-trace-specification com.ibm.commerce.foundation.logging.ServiceLogger=FINEST
    3. By default, the trace is output to STDOUT. If you want to output the trace to a log file, then update /opt/WebSphere/Liberty/usr/servers/default/configDropins/overrides/logging.xml and replace traceFileName=stdout with traceFileName=trace.log. Save the file and restart the container.
    4. Reproduce the issue.
    5. If you did not configure your Docker container to start with a volume mount to preserve logs in the Docker host machine, then run the following commands to make the trace available on the Docker host.
      docker cp container_name:/profile/logs/trace.log /tmp/container_name_trace.log
    Creating a new Docker image to include the trace specification by default during start up. Use this method to create custom Docker images to set the trace specification by default. Then you can distribute the custom Docker image.
    1. Create a Dockerfile for the target Docker image.
    2. In the Dockerfile, define the Run Engine command to set your trace specification. For example,
      run set-trace-specification com.ibm.commerce.foundation.logging.ServiceLogger=FINEST
    3. By default, the trace is output to STDOUT. If you want to output the trace to a log file, then update /opt/WebSphere/Liberty/usr/servers/default/configDropins/overrides/logging.xml and replace traceFileName=stdout with traceFileName=trace.log. Save the file and restart the container.
    4. Create a new Docker image with the Dockerfile.
    Providing the trace specification in an advanced system with orchestration tools and remote configuration center. This method also includes the trace specification by default during start up. Docker images can accept a TRACE_SPEC parameter value when starting the container.
    1. Ensure that you configured your orchestration tool to retrieve configuration parameters from your Configuration center.
    2. In your Configuration center (such as Vault), define the trace specification in the TRACE_SPEC parameter.
    3. Now, when new containers are deployed, the containers will be configured with your trace specifications.
  • Trace strings

    The following table includes the trace strings that are available specifically for the Search server Docker container. In some cases, you might need to enable trace strings in multiple servers to fully troubleshoot a component. For more information, see the MustGather sections in Trace components.

    Component Trace string
    Search build index
    *=info:com.ibm.commerce.foundation.*=all:
    com.ibm.commerce.search.*=all:
    org.apache.solr.*=all:
    com.ibm.commerce.solr.*=all
    Search cache invalidation
    *=info:com.ibm.commerce.foundation.*=all: 
    com.ibm.commerce.search.*=all: 
    org.apache.solr.*=all: 
    com.ibm.commerce.solr.*=all
    Search core creation
    *=info:com.ibm.commerce.foundation.*=all: 
    com.ibm.commerce.search.*=all: 
    org.apache.solr.*=all: 
    com.ibm.commerce.solr.*=all
    Search facets
    *=info:com.ibm.commerce.foundation.*=all:
    com.ibm.commerce.search.*=all: 
    com.ibm.commerce.rest.*=all
    Search health check
    *=info:com.ibm.commerce.foundation.*=all: 
    com.ibm.commerce.search.*=all: 
    org.apache.solr.*=all:
    com.ibm.commerce.solr.*=all
    Search relevancy
    *=info:com.ibm.commerce.foundation.*=all:
    com.ibm.commerce.rest.*=all
    Search replication
    *=info:com.ibm.commerce.foundation.*=all: 
    com.ibm.commerce.search.*=all: 
    org.apache.solr.*=all: 
    com.ibm.commerce.solr.*=all
    Search rules
    com.ibm.commerce.rest.*=all:
    com.ibm.commerce.foundation.*=all
    Search Rules Based Sales Categories
    com.ibm.commerce.rest.*=all:com.ibm.commerce.foundation.*=all
    Search runtime
    *=info:com.ibm.commerce.foundation.*=all: 
    com.ibm.commerce.search.*=all: 
    com.ibm.commerce.rest.*=all
    Search term associations and landing pages
    *=info:com.ibm.commerce.foundation.*=all: 
    com.ibm.commerce.search.*=all: 
    com.ibm.commerce.rest.*=all