mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 21:46:22 +01:00
52 lines
2.3 KiB
Plaintext
52 lines
2.3 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * observability/logging/log_collection_forwarding/log-forwarding.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="about-log-collection_{context}"]
|
|
= Log collection
|
|
|
|
The log collector is a daemon set that deploys pods to each {product-title} node to collect container and node logs.
|
|
|
|
By default, the log collector uses the following sources:
|
|
|
|
* System and infrastructure logs generated by journald log messages from the operating system, the container runtime, and {product-title}.
|
|
* `/var/log/containers/*.log` for all container logs.
|
|
|
|
If you configure the log collector to collect audit logs, it collects them from `/var/log/audit/audit.log`.
|
|
|
|
The log collector collects the logs from these sources and forwards them internally or externally depending on your {logging} configuration.
|
|
|
|
[id="about-log-collectors-types_{context}"]
|
|
== Log collector types
|
|
|
|
link:https://vector.dev/docs/about/what-is-vector/[Vector] is a log collector offered as an alternative to Fluentd for the {logging}.
|
|
|
|
You can configure which logging collector type your cluster uses by modifying the `ClusterLogging` custom resource (CR) `collection` spec:
|
|
|
|
.Example ClusterLogging CR that configures Vector as the collector
|
|
[source,yaml]
|
|
----
|
|
apiVersion: logging.openshift.io/v1
|
|
kind: ClusterLogging
|
|
metadata:
|
|
name: instance
|
|
namespace: openshift-logging
|
|
spec:
|
|
collection:
|
|
logs:
|
|
type: vector
|
|
vector: {}
|
|
# ...
|
|
----
|
|
|
|
[id="about-log-collectors-limitations_{context}"]
|
|
== Log collection limitations
|
|
|
|
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.
|
|
====
|