Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 9. Configuring your Logging deployment
9.1. Configuring CPU and memory limits for logging components Link kopierenLink in die Zwischenablage kopiert!
You can configure both the CPU and memory limits for each of the logging components as needed.
9.1.1. Configuring CPU and memory limits Link kopierenLink in die Zwischenablage kopiert!
The logging components allow for adjustments to both the CPU and memory limits.
Procedure
Edit the
custom resource (CR) in theClusterLoggingproject:openshift-logging$ oc -n openshift-logging edit ClusterLogging instanceapiVersion: "logging.openshift.io/v1" kind: "ClusterLogging" metadata: name: "instance" namespace: openshift-logging ... spec: managementState: "Managed" logStore: type: "elasticsearch" elasticsearch: nodeCount: 3 resources:1 limits: memory: 16Gi requests: cpu: 200m memory: 16Gi storage: storageClassName: "gp2" size: "200G" redundancyPolicy: "SingleRedundancy" visualization: type: "kibana" kibana: resources:2 limits: memory: 1Gi requests: cpu: 500m memory: 1Gi proxy: resources:3 limits: memory: 100Mi requests: cpu: 100m memory: 100Mi replicas: 2 collection: resources:4 limits: memory: 736Mi requests: cpu: 200m memory: 736Mi type: fluentd- 1
- Specify the CPU and memory limits and requests for the log store as needed. For Elasticsearch, you must adjust both the request value and the limit value.
- 2 3
- Specify the CPU and memory limits and requests for the log visualizer as needed.
- 4
- Specify the CPU and memory limits and requests for the log collector as needed.
9.2. Configuring systemd-journald and Fluentd Link kopierenLink in die Zwischenablage kopiert!
Because Fluentd reads from the journal, and the journal default settings are very low, journal entries can be lost because the journal cannot keep up with the logging rate from system services.
We recommend setting
RateLimitIntervalSec=30s
RateLimitBurst=10000
9.2.1. Configuring systemd-journald for OpenShift Logging Link kopierenLink in die Zwischenablage kopiert!
As you scale up your project, the default logging environment might need some adjustments.
For example, if you are missing logs, you might have to increase the rate limits for journald. You can adjust the number of messages to retain for a specified period of time to ensure that OpenShift Logging does not use excessive resources without dropping logs.
You can also determine if you want the logs compressed, how long to retain logs, how or if the logs are stored, and other settings.
Procedure
Create a Butane config file,
, that includes an40-worker-custom-journald.bufile with the required settings./etc/systemd/journald.confNoteThe Butane version you specify in the config file should match the OpenShift Container Platform version and always ends in
. For example,0. See "Creating machine configs with Butane" for information about Butane.4.14.0variant: openshift version: 4.14.0 metadata: name: 40-worker-custom-journald labels: machineconfiguration.openshift.io/role: "worker" storage: files: - path: /etc/systemd/journald.conf mode: 06441 overwrite: true contents: inline: | Compress=yes2 ForwardToConsole=no3 ForwardToSyslog=no MaxRetentionSec=1month4 RateLimitBurst=100005 RateLimitIntervalSec=30s Storage=persistent6 SyncIntervalSec=1s7 SystemMaxUse=8G8 SystemKeepFree=20%9 SystemMaxFileSize=10M10 - 1
- Set the permissions for the
journald.conffile. It is recommended to set0644permissions. - 2
- Specify whether you want logs compressed before they are written to the file system. Specify
yesto compress the message ornoto not compress. The default isyes. - 3
- Configure whether to forward log messages. Defaults to
nofor each. Specify:-
to forward logs to the system console.
ForwardToConsole -
to forward logs to the kernel log buffer.
ForwardToKMsg -
to forward to a syslog daemon.
ForwardToSyslog -
to forward messages as wall messages to all logged-in users.
ForwardToWall
-
- 4
- Specify the maximum time to store journal entries. Enter a number to specify seconds. Or include a unit: "year", "month", "week", "day", "h" or "m". Enter
0to disable. The default is1month. - 5
- Configure rate limiting. If more logs are received than what is specified in
RateLimitBurstduring the time interval defined byRateLimitIntervalSec, all further messages within the interval are dropped until the interval is over. It is recommended to setRateLimitIntervalSec=30sandRateLimitBurst=10000, which are the defaults. - 6
- Specify how logs are stored. The default is
persistent:-
to store logs in memory in
volatile. These logs are lost after rebooting./run/log/journal/ -
to store logs to disk in
persistent. systemd creates the directory if it does not exist./var/log/journal/ -
to store logs in
autoif the directory exists. If it does not exist, systemd temporarily stores logs in/var/log/journal/./run/systemd/journal -
to not store logs. systemd drops all logs.
none
-
- 7
- Specify the timeout before synchronizing journal files to disk for ERR, WARNING, NOTICE, INFO, and DEBUG logs. systemd immediately syncs after receiving a CRIT, ALERT, or EMERG log. The default is
1s. - 8
- Specify the maximum size the journal can use. The default is
8G. - 9
- Specify how much disk space systemd must leave free. The default is
20%. - 10
- Specify the maximum size for individual journal files stored persistently in
/var/log/journal. The default is10M.NoteIf you are removing the rate limit, you might see increased CPU utilization on the system logging daemons as it processes any messages that would have previously been throttled.
For more information on systemd settings, see https://www.freedesktop.org/software/systemd/man/journald.conf.html. The default settings listed on that page might not apply to OpenShift Container Platform.
Use Butane to generate a
object file,MachineConfig, containing the configuration to be delivered to the nodes:40-worker-custom-journald.yaml$ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yamlApply the machine config. For example:
$ oc apply -f 40-worker-custom-journald.yamlThe controller detects the new
object and generates a newMachineConfigversion.rendered-worker-<hash>Monitor the status of the rollout of the new rendered configuration to each node:
$ oc describe machineconfigpool/workerExample output
Name: worker Namespace: Labels: machineconfiguration.openshift.io/mco-built-in= Annotations: <none> API Version: machineconfiguration.openshift.io/v1 Kind: MachineConfigPool ... Conditions: Message: Reason: All nodes are updating to rendered-worker-913514517bcea7c93bd446f4830bc64e