Logs

Corda workers write their logs to standard out/standard error from where they are collected by Kubernetes A powerful tool for managing containerized applications at scale, making it easier for teams to deploy and manage their applications with high reliability and efficiency. . You can retrieve the logs for a single pod using kubectl:

kubectl logs <POD_NAME>

If the pod has restarted due to an error, you can retrieve the logs from the previous instance:

kubectl logs --previous <POD_NAME>

You can use a selector to retrieve logs from all of the Corda pods, each line prefixed with the name of the pod:

kubectl logs --selector=app.kubernetes.io/name=corda --prefix

Most observability platforms are capable of receiving logs from containers running on Kubernetes.

Log Format

By default, the logs are JSON formatted using the JsonLayout template for Log4J’s JsonTemplateLayout. If you are working without the benefit of an observability platform to parse the JSON logs, you can to install Corda with a text log format instead. Use the following overrides when installing the Corda Helm A package manager for Kubernetes, which is an open-source container orchestration platform. chart:

logging:
  format: "text"

Log Level

The default log level is info. To get additional diagnostic information, you may modify this via the Helm chart overrides. For example:

logging:
  level: "debug"

You can also modify the log level for just a single type of worker JVM processes that run in a cluster and perform a specific task. The processes required to form a cluster depend on the deployment topology. Workers increase or scale back their capacity depending on the number of available tasks. . For example:

workers:
  db:
    logging:
      level: "trace"

The supported values for the log level are all, trace, debug, info, warn, error, fatal, and off. Pods restart automatically to apply the new log level.