Inhalt

Einleitung

Hintergrund

Problem

Analyse

Lösung

Einleitung

Dieses Dokument beschreibt das vollständige Problem des Knotenexporteur-Datenträgers, das im Netzwerk eines Benutzers festgestellt wurde.

Hintergrund

Wenn eine Überprüfung der Common Execution Environment (CEE) von Cluster Manager durchgeführt wird, zeigt das Audit-Ergebnis, dass die Festplatte des Knotenexporteurs voll ist.

Problem

Ein kritischer Schweregrad-Alarm liegt vor, da in den nächsten 24 Stunden eine vollständige Festplattenbedingung prognostiziert wird. Dieser Alarm wurde auf CEE beobachtet:

" Gerät /dev/sda3 des Knotenexporteurs cee03/node-export-4dd4a4dd4a4a4a soll innerhalb der nächsten 24 Stunden voll sein."

Analyse

Die gemeldete Warnmeldung bezieht sich auf die CEE, die Hardwareprobleme für das Rack verfolgt und prognostiziert, dass der vollständige Festplattenzustand in den nächsten 24 Stunden auftreten wird.

cisco@deployer-cm-primary:~$ kubectl get pods -A -o wide | grep node

cee03 node-exporter-4dd4a4dd4a 1/1 Running 1 111d 10.10.1.1 deployer-cm-primary <none> <none>

root@deployer-cm-primary:/# df -h

Filesystem Size Used Avail Use% Mounted on

overlay 568G 171G 368G 32% /

tmpfs 64M 0 64M 0% /dev

tmpfs 189G 0 189G 0% /sys/fs/cgroup

tmpfs 189G 0 189G 0% /host/sys/fs/cgroup

/dev/sda1 9.8G 3.5G 5.9G 37% /host/root

udev 189G 0 189G 0% /host/root/dev

tmpfs 189G 0 189G 0% /host/root/dev/shm

tmpfs 38G 15M 38G 1% /host/root/run

tmpfs 5.0M 0 5.0M 0% /host/root/run/lock

/dev/sda3 71G 67G 435M 100% /host/root/var/log

Wenn ein Audit durchgeführt wird, scheint es, den /dev/sda3-Datenträger zu füllen.

root@deployer-cm-primary:/host/root/var/log# du -h --max-depth=1

76M ./sysstat

16K ./lost+found

4.0K ./containers

4.0K ./landscape

9.3M ./calico

1.1G ./apiserver

808K ./pods

5.6G ./journal

60G ./audit

36K ./apt

67G .

Eine Überprüfung des Audits zeigt, dass die Protokolle gespeichert werden, sodass der Serverzustand des Exporteur-Knoten-Datenträgers wahrscheinlich auftritt.

cisco@deployer-cm-primary:~$ sudo cat /etc/audit/auditd.conf

#

# This file controls the configuration of the audit daemon

#

local_events = yes

write_logs = yes

log_file = /var/log/audit/audit.log

log_group = adm

log_format = RAW

flush = INCREMENTAL_ASYNC

freq = 50

max_log_file = 8

num_logs = 5

priority_boost = 4

disp_qos = lossy

dispatcher = /sbin/audispd

name_format = NONE

##name = mydomain

max_log_file_action = keep_logs

space_left = 75

space_left_action = email

verify_email = yes

action_mail_acct = root

admin_space_left = 50

admin_space_left_action = halt

disk_full_action = SUSPEND

disk_error_action = SUSPEND

use_libwrap = yes

##tcp_listen_port = 60

tcp_listen_queue = 5

tcp_max_per_addr = 1

##tcp_client_ports = 1024-65535

tcp_client_max_idle = 0

enable_krb5 = no

krb5_principal = auditd

##krb5_key_file = /etc/audit/audit.key

distribute_network = no

cisco@deployer-cm-primary:~$

Lösung

Führen Sie den unten aufgeführten Befehlscode sowohl für den Bereitsteller-cm-primary als auch für den Bereitsteller-cm-Sekundär aus, um den vollen Zustand des potenziellen Knotenexporteurs zu beheben.

sudo vim /etc/audit/auditd.conf

Verwenden Sie dann den aufgelisteten Code, um die interne Datei von Keep_logs zu drehen.

max_log_file_action = rotate

Nachdem der Code geändert wurde, starten Sie den Dienst neu.

sudo systemctl restart auditd.service

Überprüfen Sie, ob die kritische Warnmeldung entfernt wird.