主页
产品
OpenShift Container Platform
4.5
Logging
3.2. Configuring the logging collector

3.2. Configuring the logging collector

OpenShift Container Platform uses Fluentd to collect operations and application logs from your cluster and enriches the data with Kubernetes pod and project metadata.

You can configure the CPU and memory limits for the log collector and move the log collector pods to specific nodes. All supported modifications to the log collector can be performed though the spec.collection.log.fluentd stanza in the ClusterLogging custom resource (CR).

3.2.1. About unsupported configurations
复制链接

The supported way of configuring cluster logging is by configuring it using the options described in this documentation. Do not use other configurations, as they are unsupported. Configuration paradigms might change across OpenShift Container Platform releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in this documentation, your changes will disappear because the Elasticsearch Operator and Cluster Logging Operator reconcile any differences. The Operators reverse everything to the defined state by default and by design.

注意

If you must perform configurations not described in the OpenShift Container Platform documentation, you must set your Cluster Logging Operator or Elasticsearch Operator to Unmanaged. An unmanaged cluster logging environment is not supported and does not receive updates until you return cluster logging to Managed.

3.2.2. Viewing logging collector pods
复制链接

You can use the oc get pods --all-namespaces -o wide command to see the nodes where the Fluentd are deployed.

Procedure

Run the following command in the openshift-logging project:

oc get pods --selector component=fluentd -o wide -n openshift-logging

$ oc get pods --selector component=fluentd -o wide -n openshift-logging

Copy to Clipboard

Toggle word wrap

Example output

NAME           READY  STATUS    RESTARTS   AGE     IP            NODE                  NOMINATED NODE   READINESS GATES
fluentd-8d69v  1/1    Running   0          134m    10.130.2.30   master1.example.com   <none>           <none>
fluentd-bd225  1/1    Running   0          134m    10.131.1.11   master2.example.com   <none>           <none>
fluentd-cvrzs  1/1    Running   0          134m    10.130.0.21   master3.example.com   <none>           <none>
fluentd-gpqg2  1/1    Running   0          134m    10.128.2.27   worker1.example.com   <none>           <none>
fluentd-l9j7j  1/1    Running   0          134m    10.129.2.31   worker2.example.com   <none>           <none>

NAME           READY  STATUS    RESTARTS   AGE     IP            NODE                  NOMINATED NODE   READINESS GATES
fluentd-8d69v  1/1    Running   0          134m    10.130.2.30   master1.example.com   <none>           <none>
fluentd-bd225  1/1    Running   0          134m    10.131.1.11   master2.example.com   <none>           <none>
fluentd-cvrzs  1/1    Running   0          134m    10.130.0.21   master3.example.com   <none>           <none>
fluentd-gpqg2  1/1    Running   0          134m    10.128.2.27   worker1.example.com   <none>           <none>
fluentd-l9j7j  1/1    Running   0          134m    10.129.2.31   worker2.example.com   <none>           <none>

Copy to Clipboard

Toggle word wrap

3.2.3. Configure log collector CPU and memory limits
复制链接

The log collector allows for adjustments to both the CPU and memory limits.

Procedure

Edit the ClusterLogging custom resource (CR) in the openshift-logging project:

oc edit ClusterLogging instance

$ oc edit ClusterLogging instance

Copy to Clipboard

Toggle word wrap

$ oc edit ClusterLogging instance

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"

....

spec:
  collection:
    logs:
      fluentd:
        resources:
          limits: 
            memory: 736Mi
          requests:
            cpu: 100m
            memory: 736Mi

$ oc edit ClusterLogging instance

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"

....

spec:
  collection:
    logs:
      fluentd:
        resources:
          limits:


            memory: 736Mi
          requests:
            cpu: 100m
            memory: 736Mi

Copy to Clipboard

Toggle word wrap

1: Specify the CPU and memory limits and requests as needed. The values shown are the default values.

3.2.4. About logging collector alerts
复制链接

The following alerts are generated by the logging collector. You can view these alerts in the OpenShift Container Platform web console, on the Alerts page of the Alerting UI.

Expand

表 3.1. Fluentd Prometheus alerts
Alert	Message	Description	Severity
`FluentdErrorsHigh`	`In the last minute, <value> errors reported by fluentd <instance>.`	Fluentd is reporting a higher number of issues than the specified number, default 10.	Critical
`FluentdNodeDown`	`Prometheus could not scrape fluentd <instance> for more than 10m.`	Fluentd is reporting that Prometheus could not scrape a specific Fluentd instance.	Critical
`FluentdQueueLengthBurst`	`In the last minute, fluentd <instance> buffer queue length increased more than 32. Current value is <value>.`	Fluentd is reporting that it is overwhelmed.	Warning
`FluentdQueueLengthIncreasing`	`In the last 12h, fluentd <instance> buffer queue length constantly increased more than 1. Current value is <value>.`	Fluentd is reporting queue usage issues.	Critical

3.2.5. Removing unused components if you do not use the default Elasticsearch log store
复制链接

As an administrator, in the rare case that you forward logs to a third-party log store and do not use the default Elasticsearch log store, you can remove several unused components from your logging cluster.

In other words, if you do not use the default Elasticsearch log store, you can remove the internal Elasticsearch logStore, Kibana visualization, and log curation components from the ClusterLogging custom resource (CR). Removing these components is optional but saves resources.

Prerequisites

Verify that your log forwarder does not send log data to the default internal Elasticsearch cluster. Inspect the ClusterLogForwarder CR YAML file that you used to configure log forwarding. Verify that it does not have an outputRefs element that specifies default. For example:
```
outputRefs:
- default
```
```
outputRefs:
- default
```
Copy to Clipboard Toggle word wrap

警告

Suppose the ClusterLogForwarder CR forwards log data to the internal Elasticsearch cluster, and you remove the logStore component from the ClusterLogging CR. In that case, the internal Elasticsearch cluster will not be present to store the log data. This absence can cause data loss.

Procedure

Edit the ClusterLogging custom resource (CR) in the openshift-logging project:
```
oc edit ClusterLogging instance
```
```
$ oc edit ClusterLogging instance
```
Copy to Clipboard Toggle word wrap
If they are present, remove the logStore, visualization, curation stanzas from the ClusterLogging CR.

Preserve the collection stanza of the ClusterLogging CR. The result should look similar to the following example:

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  collection:
    logs:
      type: "fluentd"
      fluentd: {}

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  collection:
    logs:
      type: "fluentd"
      fluentd: {}

Copy to Clipboard

Toggle word wrap

Verify that the Fluentd pods are redeployed:
```
oc get pods -n openshift-logging
```
```
$ oc get pods -n openshift-logging
```
Copy to Clipboard Toggle word wrap

Additional resources

Forwarding logs to third party systems

返回顶部

3.2. Configuring the logging collector

3.2.1. About unsupported configurations
复制链接

3.2.2. Viewing logging collector pods
复制链接

3.2.3. Configure log collector CPU and memory limits
复制链接

3.2.4. About logging collector alerts
复制链接

3.2.5. Removing unused components if you do not use the default Elasticsearch log store
复制链接

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

3.2. Configuring the logging collector

3.2.1. About unsupported configurations复制链接链接已复制到粘贴板!

3.2.2. Viewing logging collector pods复制链接链接已复制到粘贴板!

3.2.3. Configure log collector CPU and memory limits复制链接链接已复制到粘贴板!

3.2.4. About logging collector alerts复制链接链接已复制到粘贴板!

3.2.5. Removing unused components if you do not use the default Elasticsearch log store复制链接链接已复制到粘贴板!

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

3.2.1. About unsupported configurations
复制链接

3.2.2. Viewing logging collector pods
复制链接

3.2.3. Configure log collector CPU and memory limits
复制链接

3.2.4. About logging collector alerts
复制链接

3.2.5. Removing unused components if you do not use the default Elasticsearch log store
复制链接