Skip to content

[enterprise-4.8] RHDEVDOCS-2610 #29806

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 24, 2021
Merged

[enterprise-4.8] RHDEVDOCS-2610 #29806

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 5 additions & 12 deletions modules/cluster-logging-about-collector.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,27 +7,20 @@

{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]
====
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.
====