Logging considerations
By default, logging is enabled in your cluster. You need to collect and forward the
standard output stdout
logs from the containers to help you troubleshoot issues and improve
their health and performance.
Logs and log persistence must be considered before you install Decision Intelligence Client Managed Software.
Logs and log persistence
All containerized applications write to the standard output and standard error streams, which can
be viewed on a pod level by using kubectl logs on the command line. For example, to view them in the Red Hat® OpenShift® Container Platform (OCP) web console, click .
All Decision Intelligence pods produce logs.
However, if a container crashes, a pod is evicted, or a node dies, you probably still want to access the application logs. Therefore, logs need a separate storage location and a lifecycle that is independent of nodes, pods, or containers. For example, OpenShift Container Platform can provide a logging solution that is based on the EFK stack: Elasticsearch, Fluentd, and Kibana. Fluentd collects all the node and container logs and stores them in dedicated project indexes. Kibana is the centralized user interface where you can create visualizations and dashboards with the aggregated data.
You can customize the logs that are written to stdout by referring to the
configuration parameters for the capability. For more information, see Configuration
parameters.
MustGather
For more information about collecting data to diagnose issues in Decision Intelligence, see MustGather
.