Skip to main contentCúram on Kubernetes

XML Server Tracing

Introduction

This topic describes how to configure XML server tracing when deployed to Kubernetes.

For more information about XML server tracing, see Debug configuration in the Cúram XML Infrastructure Guide.

Cúram PDF documentation is available to download from Cúram Support Docs.

However, to use it in a Kubernetes environment, the following steps will need to be performed:

  1. Create a new ConfigMap to override the trace setting in the default xmlserverconfig.xml.template file
  2. Optionally (for the xmlserver deployment only), a ConfigMap can be created to override its default log4j properties file.

The Kubernetes commands presented in this topic are generic and assume a helm release name of releasename. To enter the commands below as-is, <name_space> will need to be substituted with the OpenShift project name or AKS namespace for the deployment:

  • For Openshift:
    • Create an alias for the oc command:
      • Bash: alias k='oc'
      • Windows PowerShell: Set-Alias -Name k -Value oc
    • Set the default namespace:
      • k project <name_space>
  • For AKS:
    • Create an alias for the kubectl command:
      • Bash: alias k='kubectl'
      • Windows PowerShell: Set-Alias -Name k -Value kubectl
    • Set the default namespace:
      • k config set-context --current --namespace=<name_space>

Specifying the XML Server Trace Setting

To enable XML server tracing the out-of-the-box setting needs to be modified as follows:

  • Copy the xmlserver pod’s xmlserverconfig.xml.template file to the local file system using the Kubernetes copy command, e.g. k cp <xmlserver-pod-name>:xmlserverconfig.xml.template xmlserverconfig.xml.template -c xmlserver
  • Edit the local xmlserverconfig.xml.template file to change the TRACE_TRAFFIC value as follows: <TRACE_TRAFFIC>true</TRACE_TRAFFIC>
  • Delete the existing releasename-xmlserverconfig-template-cm ConfigMap. For example: k delete configmap releasename-xmlserverconfig-template-cm
  • Create a new releasename-xmlserverconfig-template-cm ConfigMap using the edited copy of xmlserverconfig.xml.template, e.g. k create releasename-xmlserverconfig-template-cm --from-file=xmlserverconfig.xml.template The existing releasename-xmlserverconfig-template-cm ConfigMap in the releasename-xmlserver deployment will be replaced with the newly edited file.
  • The xmlserver pod(s) must be restarted for the new setting to be used. The pod(s) can be restarted using the Kubernetes delete pod command. For example: k delete pod <xmlserver-pod-name> This will terminate the running pod and start a new pod that reflects the new ConfigMap.

Modifying the Log4j Properties

The out-of-the-box log4j2.properties file will write the XML server trace output to stdout, which is routed to the pod’s tmp/xmlserver.log file. Optionally, a custom log4j properties file can be provided. For instance, it can be useful to modify the output layout to indicate the time-of-day and the worker thread processing the XML server job. For example, this log4j pattern:

appender.A1.layout.pattern=[%p] %d{ABSOLUTE_MICROS} [%t] [%c{1}] %m%n

will produce output in this format:

[xmlserver] [INFO] 14:01:46,165000 [ThreadPoolWorker-1] [XMLConnectionHandler] - Awaiting job configuration.

as compared to the out-of-the-box format:

[xmlserver] [INFO] [XMLConnectionHandler] Awaiting job configuration.

For more information on specifying log4j patterns see the Layouts section of the log4j documentation.

To modify the log4j2.properties file:

  • Copy the xmlserver pod’s log4j2.properties file to the local file system using the Kubernetes copy command. For example: k cp <xmlserver-pod-name>:/opt/ibm/Curam/xmlserver/log4j2.properties log4j2.properties -c xmlserver
  • Edit the local file to specify the desired log4j configuration settings.
  • Create a ConfigMap using the edited copy of log4j2.properties; for example: k create configmap xmlserver-log4j-props-cm --from-file=log4j2.properties
  • Edit the xmlserver deployment to specify the new ConfigMap: k edit deployment releasename-xmlserver
    • In the subsequent edit session add the entries for the new ConfigMap, matching the name used when creating it; for example:
...
        volumeMounts:
        ...
        - mountPath: /opt/ibm/Curam/xmlserver/log4j2.properties
          name: xmlserver-log4j-props-cm
          subPath: log4j2.properties
...
      volumes:
      ...
  • The xmlserver pod(s) must be restarted for it to reflect the new trace setting. The pod can be restarted by using the Kubernetes delete pod command, e.g. k delete pod <xmlserver-pod-name>

This will terminate the running pod and start a new pod that reflects the new ConfigMap that contains the log4j properties.

Previous
Troubleshooting: Troubleshooting problems
Next
Troubleshooting: MustGather