mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-05 20:53:33 +00:00
c869ea69ac
* Fix 'title out of sequence' errors fixed Dockershim.md * fixed deprecated-features.md * fixed install-and-configure-kubectl.md * fixed rancher-is-no-longer-needed.md * fixed security.md * fixed technical-items.md + spacing, duplicate section, admonitions * fixed telemetry.md * fixed upgrades.md * fixed upgrade-kubernetes-without-upgrading-rancher.md * fixed air-gapped-upgrades.md * fixed dockershim.md * fixed docker-install-commands.md * fixed install-kubernetes.md * fixed infrastructure-private-registry.md * fixed install-rancher-ha * fixed manage-namespaces and tune-etcd-for-large-installs.md * fixed cis-scans/configuration-reference.md * fixed custom-benchmark.md * fixed supportconfig.md * fixed harvester/overview.md * fixed logging-architecture.md * fixed logging-helm-chart-options.md + rm'd unnecessary annotation title * fixed taints-and-tolerances.md * fixed longhorn/overview.md * fixed neuvector/overview.md * fixed monitoring-and-alerting * fixed rancher-cli.md * fixed cluster-configuration.md * fixed monitoring-v2-configuration/examples.md * fixed servicemonitors-and-podmonitors.md * fixed other-troubleshooting-tips/dns.md
33 lines
1.7 KiB
Markdown
33 lines
1.7 KiB
Markdown
---
|
|
title: Logging Architecture
|
|
---
|
|
|
|
<head>
|
|
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/logging/logging-architecture"/>
|
|
</head>
|
|
|
|
This section summarizes the architecture of the Rancher logging application.
|
|
|
|
For more details about how the Logging operator works, see the [official documentation.](https://kube-logging.github.io/docs/#architecture)
|
|
|
|
## How the Logging Operator Works
|
|
|
|
The Logging operator automates the deployment and configuration of a Kubernetes logging pipeline. It deploys and configures a Fluent Bit DaemonSet on every node to collect container and application logs from the node file system.
|
|
|
|
Fluent Bit queries the Kubernetes API and enriches the logs with metadata about the pods, and transfers both the logs and the metadata to Fluentd. Fluentd receives, filters, and transfers logs to multiple `Outputs`.
|
|
|
|
The following custom resources are used to define how logs are filtered and sent to their `Outputs`:
|
|
|
|
- A `Flow` is a namespaced custom resource that uses filters and selectors to route log messages to the appropriate `Outputs`.
|
|
- A `ClusterFlow` is used to route cluster-level log messages.
|
|
- An `Output` is a namespaced resource that defines where the log messages are sent.
|
|
- A `ClusterOutput` defines an `Output` that is available from all `Flows` and `ClusterFlows`.
|
|
|
|
Each `Flow` must reference an `Output`, and each `ClusterFlow` must reference a `ClusterOutput`.
|
|
|
|
The following figure from the [Logging operator documentation](https://kube-logging.github.io/docs/#architecture) shows the new logging architecture:
|
|
|
|
<figcaption>How the Logging Operator Works with Fluentd and Fluent Bit</figcaption>
|
|
|
|

|