From e7c6b1f0751dfcf5363d20c1d94270d24c4c6ec1 Mon Sep 17 00:00:00 2001 From: rolfedh Date: Wed, 17 Feb 2021 18:42:31 -0500 Subject: [PATCH] RHDEVDOCS-2610 Add location for the audit log file --- modules/cluster-logging-about-collector.adoc | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-) diff --git a/modules/cluster-logging-about-collector.adoc b/modules/cluster-logging-about-collector.adoc index 6f6bcb834bc3..d63b6c225dbd 100644 --- a/modules/cluster-logging-about-collector.adoc +++ b/modules/cluster-logging-about-collector.adoc @@ -7,22 +7,16 @@ {product-title} uses Fluentd to collect container and node logs. -By default, the log collector uses the following sources: +By default, the log collector uses the following sources: * journald for all system logs * `/var/log/containers/*.log` for all container logs -The logging collector is deployed as a daemon set that deploys pods to each {product-title} node. -System and infrastructure logs are generated by journald log messages from the operating system, -the container runtime, and {product-title}. Application logs are generated by the CRI-O container -engine. Fluentd collects the logs from these sources and forwards them internally or externally -as you configure in {product-title}. +If you configure the log collector to collect audit logs, it gets them from `/var/log/audit/audit.log`. -The container runtimes provide minimal information to identify the source of log messages: project, pod name, -and container id. This is not sufficient to uniquely identify the source of the logs. If a pod with a given name -and project is deleted before the log collector begins processing its logs, information from the API server, such as labels and annotations, -might not be available. There might not be a way to distinguish the log messages from a similarly named pod and project or trace the logs to their source. -This limitation means log collection and normalization is considered *best effort*. +The logging collector is a daemon set that deploys pods to each {product-title} node. System and infrastructure logs are generated by journald log messages from the operating system, the container runtime, and {product-title}. Application logs are generated by the CRI-O container engine. Fluentd collects the logs from these sources and forwards them internally or externally as you configure in {product-title}. + +The container runtimes provide minimal information to identify the source of log messages: project, pod name, and container ID. This information is not sufficient to uniquely identify the source of the logs. If a pod with a given name and project is deleted before the log collector begins processing its logs, information from the API server, such as labels and annotations, might not be available. There might not be a way to distinguish the log messages from a similarly named pod and project or trace the logs to their source. This limitation means that log collection and normalization are considered *best effort*. [IMPORTANT] ==== @@ -30,4 +24,3 @@ The available container runtimes provide minimal information to identify the source of log messages and do not guarantee unique individual log messages or that these messages can be traced to their source. ==== -