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.
Feedback