Update Logging operator links (#443)

* Update Logging operator doc links

* Update links to Logging operator project page

* Update name of the Banzai Cloud Logging operator to Logging operator

* Fix broken link

* Update docs/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md

Co-authored-by: Marty Hernandez Avedon <martyavedon@gmail.com>

* Update versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md

Co-authored-by: Marty Hernandez Avedon <martyavedon@gmail.com>

* Update versioned_docs/version-2.6/integrations-in-rancher/logging/custom-resource-configuration/flows-and-clusterflows.md

Co-authored-by: Marty Hernandez Avedon <martyavedon@gmail.com>

* Update versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/custom-resource-configuration/flows-and-clusterflows.md

Co-authored-by: Marty Hernandez Avedon <martyavedon@gmail.com>

* Update docs/integrations-in-rancher/logging/custom-resource-configuration/flows-and-clusterflows.md

Co-authored-by: Marty Hernandez Avedon <martyavedon@gmail.com>

* Update versioned_docs/version-2.6/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md

Co-authored-by: Marty Hernandez Avedon <martyavedon@gmail.com>

* Update versioned_docs/version-2.6/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md

Co-authored-by: Marty Hernandez Avedon <martyavedon@gmail.com>

* Update versioned_docs/version-2.6/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md

Co-authored-by: Marty Hernandez Avedon <martyavedon@gmail.com>

* Adds a linebreak between an id tag and a title

* inconsistent casing fixed

---------

Co-authored-by: Marty Hernandez Avedon <martyavedon@gmail.com>
This commit is contained in:
Robert Fekete
2023-02-28 10:48:10 -08:00
committed by GitHub
co-authored by Marty Hernandez Avedon
parent bbd475ef40
commit 92df620622
28 changed files with 96 additions and 94 deletions
@@ -2,7 +2,7 @@
title: Flows and ClusterFlows
---
See the [Banzai Cloud Logging operator documentation](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/flow/) for the full details on how to configure `Flows` and `ClusterFlows`.
See the [Logging operator documentation](https://kube-logging.github.io/docs/configuration/flow/) for the full details on how to configure `Flows` and `ClusterFlows`.
See [Rancher Integration with Logging Services: Troubleshooting](../../../../pages-for-subheaders/logging.md#The-Logging-Buffer-Overloads-Pods) for how to resolve memory problems with the logging buffer.
@@ -33,7 +33,7 @@ A `Flow` defines which logs to collect and filter and which output to send the l
The `Flow` is a namespaced resource, which means logs will only be collected from the namespace that the `Flow` is deployed in.
For more details about the `Flow` custom resource, see [FlowSpec.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/flow_types/)
For more details about the `Flow` custom resource, see [FlowSpec.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/flow_types/)
<a id="matches-2-5-8"></a>
@@ -46,7 +46,7 @@ You can specify match statements to select or exclude logs according to Kubernet
Matches can be configured by filling out the `Flow` or `ClusterFlow` forms in the Rancher UI.
For detailed examples on using the match statement, see the [official documentation on log routing.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/log-routing/)
For detailed examples on using the match statement, see the [official documentation on log routing.](https://kube-logging.github.io/docs/configuration/log-routing/)
<a id="filters-2-5-8"></a>
@@ -54,7 +54,7 @@ For detailed examples on using the match statement, see the [official documentat
You can define one or more filters within a `Flow`. Filters can perform various actions on the logs, for example, add additional data, transform the logs, or parse values from the records. The filters in the `Flow` are applied in the order in the definition.
For a list of filters supported by the Banzai Cloud Logging operator, see [this page.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/filters/)
For a list of filters supported by the Logging operator, see [the official documentation on Fluentd filters](https://kube-logging.github.io/docs/configuration/plugins/filters/).
Filters need to be configured in YAML.
@@ -93,7 +93,7 @@ A `Flow` defines which logs to collect and filter and which `Output` to send the
`Flows` need to be defined in YAML.
For more details about the `Flow` custom resource, see [FlowSpec.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/flow_types/)
For more details about the `Flow` custom resource, see [FlowSpec.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/flow_types/)
<a id="matches-2-5-0"></a>
@@ -104,7 +104,7 @@ Match statements are used to select which containers to pull logs from.
You can specify match statements to select or exclude logs according to Kubernetes labels, container and host names. Match statements are evaluated in the order they are defined and processed only until the first matching select or exclude rule applies.
For detailed examples on using the match statement, see the [official documentation on log routing.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/log-routing/)
For detailed examples on using the match statement, see the [official documentation on log routing.](https://kube-logging.github.io/docs/configuration/log-routing/)
<a id="filters-2-5-0"></a>
@@ -112,7 +112,7 @@ For detailed examples on using the match statement, see the [official documentat
You can define one or more filters within a `Flow`. Filters can perform various actions on the logs, for example, add additional data, transform the logs, or parse values from the records. The filters in the `Flow` are applied in the order in the definition.
For a list of filters supported by the Banzai Cloud Logging operator, see [this page.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/filters/)
For a list of filters supported by the Logging operator, see [this page.](https://kube-logging.github.io/docs/configuration/plugins/filters/)
<a id="outputs-2-5-0"></a>
@@ -2,7 +2,7 @@
title: Outputs and ClusterOutputs
---
See the [Banzai Cloud Logging operator documentation](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/flow/) for the full details on how to configure `Flows` and `ClusterFlows`.
See the [Logging operator documentation](https://kube-logging.github.io/docs/configuration/flow/) for the full details on how to configure `Flows` and `ClusterFlows`.
See [Rancher Integration with Logging Services: Troubleshooting](../../../../pages-for-subheaders/logging.md#The-Logging-Buffer-Overloads-Pods) for how to resolve memory problems with the logging buffer.
@@ -20,6 +20,7 @@ The `Outputs` and `ClusterOutputs` can now be configured by filling out forms in
<a id="outputs-2-5-8"></a>
## Outputs
The `Output` resource defines where your `Flows` can send the log messages. `Outputs` are the final stage for a logging `Flow`.
@@ -28,7 +29,7 @@ The `Output` is a namespaced resource, which means only a `Flow` within the same
You can use secrets in these definitions, but they must also be in the same namespace.
For the details of `Output` custom resource, see [OutputSpec.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/output_types/).
For the details of `Output` custom resource, see [OutputSpec.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/output_types/).
The Rancher UI provides forms for configuring the following `Output` types:
@@ -52,7 +53,7 @@ The Rancher UI provides forms for configuring the following `Output` types:
The Rancher UI provides forms for configuring the `Output` type, target, and access credentials if applicable.
For example configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/).
For example configuration for each logging plugin supported by the logging operator, see the [Logging operator documentation](https://kube-logging.github.io/docs/configuration/plugins/outputs/).
<a id="clusteroutputs-2-5-8"></a>
@@ -60,7 +61,7 @@ For example configuration for each logging plugin supported by the logging opera
`ClusterOutput` defines an `Output` without namespace restrictions. It is only effective when deployed in the same namespace as the logging operator.
For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/clusteroutput_types/)
For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/clusteroutput_types/)
</TabItem>
<TabItem value="Rancher before v2.5.8">
@@ -70,6 +71,7 @@ For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](htt
<a id="outputs-2-5-0"></a>
## Outputs
The `Output` resource defines where your `Flows` can send the log messages. `Outputs` are the final stage for a logging `Flow`.
@@ -78,9 +80,9 @@ The `Output` is a namespaced resource, which means only a `Flow` within the same
You can use secrets in these definitions, but they must also be in the same namespace.
`Outputs` are configured in YAML. For the details of `Output` custom resource, see [OutputSpec.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/output_types/)
`Outputs` are configured in YAML. For the details of `Output` custom resource, see [OutputSpec.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/output_types/)
For examples of configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/)
For examples of configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://kube-logging.github.io/docs/configuration/plugins/outputs/)
<a id="clusteroutputs-2-5-0"></a>
@@ -90,9 +92,9 @@ For examples of configuration for each logging plugin supported by the logging o
The Rancher UI provides forms for configuring the `ClusterOutput` type, target, and access credentials if applicable.
`ClusterOutputs` are configured in YAML. For the details of `ClusterOutput` custom resource, see [ClusterOutput.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/clusteroutput_types/)
`ClusterOutputs` are configured in YAML. For the details of `ClusterOutput` custom resource, see [ClusterOutput.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/clusteroutput_types/)
For example configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/)
For example configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://kube-logging.github.io/docs/configuration/plugins/outputs/)
</TabItem>
</Tabs>
@@ -4,20 +4,20 @@ title: Architecture
This section summarizes the architecture of the Rancher logging application.
For more details about how the Banzai Cloud Logging operator works, see the [official documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/#architecture)
For more details about how the Logging operator works, see the [official documentation.](https://kube-logging.github.io/docs/#architecture)
### Changes in Rancher v2.5
The following changes were introduced to logging in Rancher v2.5:
- The [Banzai Cloud Logging operator](https://banzaicloud.com/docs/one-eye/logging-operator/) now powers Rancher's logging solution in place of the former, in-house solution.
- The [Logging operator](https://kube-logging.github.io/docs/) now powers Rancher's logging solution in place of the former, in-house solution.
- [Fluent Bit](https://fluentbit.io/) is now used to aggregate the logs, and [Fluentd](https://www.fluentd.org/) is used for filtering the messages and routing them to the `Outputs`. Previously, only Fluentd was used.
- Logging can be configured with a Kubernetes manifest, because logging now uses a Kubernetes operator with Custom Resource Definitions.
- We now support filtering logs.
- We now support writing logs to multiple `Outputs`.
- We now always collect Control Plane and etcd logs.
### How the Banzai Cloud Logging Operator Works
### 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.
@@ -32,8 +32,8 @@ The following custom resources are used to define how logs are filtered and sent
Each `Flow` must reference an `Output`, and each `ClusterFlow` must reference a `ClusterOutput`.
The following figure from the [Banzai documentation](https://banzaicloud.com/docs/one-eye/logging-operator/#architecture) shows the new logging architecture:
The following figure from the [Logging operator documentation](https://kube-logging.github.io/docs/#architecture) shows the new logging architecture:
<figcaption>How the Banzai Cloud Logging Operator Works with Fluentd and Fluent Bit</figcaption>
<figcaption>How the Logging Operator Works with Fluentd and Fluent Bit</figcaption>
![How the Banzai Cloud Logging Operator Works with Fluentd](/img/banzai-cloud-logging-operator.png)
![How the Logging Operator Works with Fluentd](/img/banzai-cloud-logging-operator.png)
@@ -2,7 +2,7 @@
title: Migrating to Rancher v2.5 Logging
---
Starting in v2.5, the logging feature available within Rancher has been completely overhauled. The [logging operator](https://github.com/banzaicloud/logging-operator) from Banzai Cloud has been adopted; Rancher configures this tooling for use when deploying logging.
Starting in v2.5, the logging feature available within Rancher has been completely overhauled. The [Logging operator](https://github.com/kube-logging/logging-operator) has been adopted; Rancher configures this tooling for use when deploying logging.
Among the many features and changes in the new logging functionality is the removal of project-specific logging configurations. Instead, one now configures logging at the namespace level. Cluster-level logging remains available, but configuration options differ.
@@ -3,7 +3,7 @@ title: Rancher Integration with Logging Services
description: Rancher integrates with popular logging services. Learn the requirements and benefits of integrating with logging services, and enable logging on your cluster.
---
The [Banzai Cloud Logging operator](https://banzaicloud.com/docs/one-eye/logging-operator/) now powers Rancher's logging solution in place of the former, in-house solution.
The [Logging operator](https://kube-logging.github.io/docs/) now powers Rancher's logging solution in place of the former, in-house solution.
For an overview of the changes in v2.5, see [this section.](../explanations/integrations-in-rancher/logging/logging-architecture.md#changes-in-rancher-v25) For information about migrating from Logging V1, see [this page.](../explanations/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md)
@@ -104,7 +104,7 @@ By default, Rancher collects logs for control plane components and node componen
Depending on your configuration, the default buffer size may be too large and cause pod failures. One way to reduce the load is to lower the logger's flush interval. This prevents logs from overfilling the buffer. You can also add more flush threads to handle moments when many logs are attempting to fill the buffer at once.
For a more complete description of how to configure the logging buffer to suit your organization's needs, see the official BanzaiCloud documentation on [buffers](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/buffer/) and on [Fluentd configuration](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/fluentd/).
For a more complete description of how to configure the logging buffer to suit your organization's needs, see the official Logging operator documentation on [buffers](https://kube-logging.github.io/docs/configuration/plugins/outputs/buffer/) and on [Fluentd configuration](https://kube-logging.github.io/docs/logging-infrastructure/fluentd/).
### The `cattle-logging` Namespace Being Recreated
@@ -15,7 +15,7 @@ Before Rancher v2.5, logging in Rancher has historically been a pretty static in
Logging in 2.5 has been completely overhauled to provide a more flexible experience for log aggregation. With the new logging feature, administrators and users alike can deploy logging that meets fine-grained collection criteria while offering a wider array of destinations and configuration options.
"Under the hood", Rancher logging uses the Banzai Cloud logging operator. We provide manageability of this operator (and its resources), and tie that experience in with managing your Rancher clusters.
"Under the hood", Rancher logging uses the [Logging operator](https://github.com/kube-logging/logging-operator). We provide manageability of this operator (and its resources), and tie that experience in with managing your Rancher clusters.
## Cluster-level Logging
@@ -47,7 +47,7 @@ Rancher logging will read all log entries in `/var/log/containers`, ensuring tha
Log collection only retrieves `stdout`/`stderr` logs from pods in Kubernetes. But what if we want to collect logs from other files that are generated by applications? Here, a log streaming sidecar (or two) may come in handy.
The goal of setting up a streaming sidecar is to take log files that are written to disk, and have their contents streamed to `stdout`. This way, the Banzai Logging Operator can pick up those logs and send them to your desired output.
The goal of setting up a streaming sidecar is to take log files that are written to disk, and have their contents streamed to `stdout`. This way, the Logging Operator can pick up those logs and send them to your desired output.
To set this up, edit your workload resource (e.g. Deployment) and add the following sidecar definition:
@@ -2,7 +2,7 @@
title: Flows and ClusterFlows
---
See the [Banzai Cloud Logging operator documentation](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/flow/) for the full details on how to configure `Flows` and `ClusterFlows`.
See the [Logging operator documentation](https://kube-logging.github.io/docs/configuration/flow/) for the full details on how to configure `Flows` and `ClusterFlows`.
See [Rancher Integration with Logging Services: Troubleshooting](../../../pages-for-subheaders/logging.md#The-Logging-Buffer-Overloads-Pods) for how to resolve memory problems with the logging buffer.
@@ -14,7 +14,7 @@ The `Flow` is a namespaced resource, which means logs will only be collected fro
`Flows` can be configured by filling out forms in the Rancher UI.
For more details about the `Flow` custom resource, see [FlowSpec.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/flow_types/)
For more details about the `Flow` custom resource, see [FlowSpec.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/flow_types/)
### Matches
@@ -24,13 +24,13 @@ You can specify match statements to select or exclude logs according to Kubernet
Matches can be configured by filling out the `Flow` or `ClusterFlow` forms in the Rancher UI.
For detailed examples on using the match statement, see the [official documentation on log routing.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/log-routing/)
For detailed examples on using the match statement, see the [official documentation on log routing.](https://kube-logging.github.io/docs/configuration/log-routing/)
### Filters
You can define one or more filters within a `Flow`. Filters can perform various actions on the logs, for example, add additional data, transform the logs, or parse values from the records. The filters in the `Flow` are applied in the order in the definition.
For a list of filters supported by the Banzai Cloud Logging operator, see [this page.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/filters/)
For a list of filters supported by the Logging operator, see [the official documentation on Fluentd filters](https://kube-logging.github.io/docs/configuration/plugins/filters/).
Filters need to be configured in YAML.
@@ -2,7 +2,7 @@
title: Outputs and ClusterOutputs
---
See the [Banzai Cloud Logging operator documentation](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/flow/) for the full details on how to configure `Flows` and `ClusterFlows`.
See the [Logging operator documentation](https://kube-logging.github.io/docs/configuration/flow/) for the full details on how to configure `Flows` and `ClusterFlows`.
See [Rancher Integration with Logging Services: Troubleshooting](../../../pages-for-subheaders/logging.md#The-Logging-Buffer-Overloads-Pods) for how to resolve memory problems with the logging buffer.
@@ -16,7 +16,7 @@ You can use secrets in these definitions, but they must also be in the same name
`Outputs` can be configured by filling out forms in the Rancher UI.
For the details of `Output` custom resource, see [OutputSpec.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/output_types/).
For the details of `Output` custom resource, see [OutputSpec](https://kube-logging.github.io/docs/configuration/crds/v1beta1/output_types/).
The Rancher UI provides forms for configuring the following `Output` types:
@@ -40,7 +40,7 @@ The Rancher UI provides forms for configuring the following `Output` types:
The Rancher UI provides forms for configuring the `Output` type, target, and access credentials if applicable.
For example configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/).
For example configuration for each logging plugin supported by the logging operator, see the [Logging operator documentation](https://kube-logging.github.io/docs/configuration/plugins/outputs/).
## ClusterOutputs
@@ -48,7 +48,7 @@ For example configuration for each logging plugin supported by the logging opera
`ClusterOutputs` can be configured by filling out forms in the Rancher UI.
For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/clusteroutput_types/)
For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://kube-logging.github.io/docs/configuration/crds/v1beta1/clusteroutput_types/)
## YAML Examples
@@ -4,9 +4,9 @@ title: Architecture
This section summarizes the architecture of the Rancher logging application.
For more details about how the Banzai Cloud Logging operator works, see the [official documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/#architecture)
For more details about how the Logging operator works, see the [official documentation.](https://kube-logging.github.io/docs/#architecture)
### How the Banzai Cloud Logging Operator Works
### 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.
@@ -21,8 +21,8 @@ The following custom resources are used to define how logs are filtered and sent
Each `Flow` must reference an `Output`, and each `ClusterFlow` must reference a `ClusterOutput`.
The following figure from the [Banzai documentation](https://banzaicloud.com/docs/one-eye/logging-operator/#architecture) shows the new logging architecture:
The following figure from the [Logging operator documentation](https://kube-logging.github.io/docs/#architecture) shows the new logging architecture:
<figcaption>How the Banzai Cloud Logging Operator Works with Fluentd and Fluent Bit</figcaption>
<figcaption>How the Logging Operator Works with Fluentd and Fluent Bit</figcaption>
![How the Banzai Cloud Logging Operator Works with Fluentd](/img/banzai-cloud-logging-operator.png)
![How the Logging Operator Works with Fluentd](/img/banzai-cloud-logging-operator.png)
@@ -1,7 +1,7 @@
---
title: Migrating to Rancher v2.5 Logging
---
Starting in v2.5, the logging feature available within Rancher has been completely overhauled. The [logging operator](https://github.com/banzaicloud/logging-operator) from Banzai Cloud has been adopted; Rancher configures this tooling for use when deploying logging.
Starting in v2.5, the logging feature available within Rancher has been completely overhauled. The [Logging operator](https://github.com/kube-logging/logging-operator) has been adopted; Rancher configures this tooling for use when deploying logging.
Among the many features and changes in the new logging functionality is the removal of project-specific logging configurations. Instead, one now configures logging at the namespace level. Cluster-level logging remains available, but configuration options differ.
@@ -3,7 +3,7 @@ title: Rancher Integration with Logging Services
description: Rancher integrates with popular logging services. Learn the requirements and benefits of integrating with logging services, and enable logging on your cluster.
---
The [Banzai Cloud Logging operator](https://banzaicloud.com/docs/one-eye/logging-operator/) now powers Rancher's logging solution in place of the former, in-house solution.
The [Logging operator](https://kube-logging.github.io/docs/) now powers Rancher's logging solution in place of the former, in-house solution.
For an overview of the changes in v2.5, see [this section.](../integrations-in-rancher/logging/logging-architecture.md#changes-in-rancher-v2-5) For information about migrating from Logging V1, see [this page.](../integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md)
@@ -117,7 +117,7 @@ By default, Rancher collects logs for control plane components and node componen
Depending on your configuration, the default buffer size may be too large and cause pod failures. One way to reduce the load is to lower the logger's flush interval. This prevents logs from overfilling the buffer. You can also add more flush threads to handle moments when many logs are attempting to fill the buffer at once.
For a more complete description of how to configure the logging buffer to suit your organization's needs, see the official BanzaiCloud documentation on [buffers](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/buffer/) and on [Fluentd configuration](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/fluentd/).
For a more complete description of how to configure the logging buffer to suit your organization's needs, see the official Logging operator documentation on [buffers](https://kube-logging.github.io/docs/configuration/plugins/outputs/buffer/) and on [Fluentd configuration](https://kube-logging.github.io/docs/logging-infrastructure/fluentd/).
### The `cattle-logging` Namespace Being Recreated
@@ -12,7 +12,7 @@ Before Rancher v2.5, logging in Rancher has historically been a pretty static in
Rancher provides a flexible experience for log aggregation. With the logging feature, administrators and users alike can deploy logging that meets fine-grained collection criteria while offering a wider array of destinations and configuration options.
"Under the hood", Rancher logging uses the Banzai Cloud logging operator. We provide manageability of this operator (and its resources), and tie that experience in with managing your Rancher clusters.
"Under the hood", Rancher logging uses the [Logging operator](https://github.com/kube-logging/logging-operator). We provide manageability of this operator (and its resources), and tie that experience in with managing your Rancher clusters.
## Cluster-level Logging
@@ -44,7 +44,7 @@ Rancher logging will read all log entries in `/var/log/containers`, ensuring tha
Log collection only retrieves `stdout`/`stderr` logs from pods in Kubernetes. But what if we want to collect logs from other files that are generated by applications? Here, a log streaming sidecar (or two) may come in handy.
The goal of setting up a streaming sidecar is to take log files that are written to disk, and have their contents streamed to `stdout`. This way, the Banzai Logging Operator can pick up those logs and send them to your desired output.
The goal of setting up a streaming sidecar is to take log files that are written to disk, and have their contents streamed to `stdout`. This way, the Logging Operator can pick up those logs and send them to your desired output.
To set this up, edit your workload resource (e.g. Deployment) and add the following sidecar definition: