Docker-Container-Protokollanalyse

Containerprotokolle anzeigen

Verwenden Sie zunächst docker run -it --rm -d -p 80:80 nginx:1.15.8-alpine um einen Nginx-Container zu starten. Wenn keine Ausnahme vorliegt, erhalten Sie eine lange Zeichenfolge von Container-IDs wie d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00 . Verwenden Sie dann curl -i http://127.0.0.1, um auf den Dienst zuzugreifen und zu bestätigen, dass der Nginx-Container gestartet und normal ausgeführt wird. Verwenden Sie abschließend docker logs -f d24 , um die Protokollausgabe des Containers anzuzeigen, die wie folgt lautet:

172.17.0.1 - - [24/Mar/2019:03:51:21 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"

Generell sind die ersten 3 Ziffern der Container-ID ausreichend.

Das Obige ist unsere tägliche Methode zum Anzeigen von Containerprotokollen, die sehr einfach und praktisch ist.

Container-Protokolldateispeicher

Die Containerprotokolle werden als JSON-Dateien auf der lokalen Festplatte gespeichert. Sie können die folgende Methode verwenden, um den Dateipfad anzuzeigen: docker inspect d42 | grep Log um Folgendes zu finden:

"LogPath": "/var/lib/docker/containers/d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00/d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00-json.log",

Hinweis 1: Auf dem Mac gibt es kein Verzeichnis /var/lib/docker, da Docker für Mac anders funktioniert. Am besten üben Sie mit einem Linux-System.

Hinweis 2: Wenn der LogPath-Inhalt leer ist, liegt das wahrscheinlich an der Docker-Engine-Version. Sie können die Docker-Version auf docker-ce 18.09.3 aktualisieren.

Überprüfen Sie die Datei d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00-json.log und Sie können Folgendes sehen:

{"log":"172.17.0.1 - - [24/Mar/2019:03:51:21 +0000] \"GET / HTTP/1.1\" 200 612 \"-\" \"curl/7.29.0\" \"-\"\r\n","stream":"stdout","time":"2019-03-24T03:51:21.982476951Z"}

Der Inhalt des Protokollfelds dieser Informationen stimmt mit dem Inhalt überein, der zuvor über den Befehl „Docker-Protokolle“ angezeigt wurde.

Containerprotokolle folgen dem Containerlebenszyklus und werden vernichtet, wenn der Container vernichtet wird. Verwenden Sie Docker Stop 24, um den getesteten Nginx-Dienst herunterzufahren. Da der Parameter --rm beim Starten des Containers verwendet wird, wird er nach dem Herunterfahren automatisch bereinigt und gelöscht. Sie werden also feststellen, dass das Verzeichnis /var/lib/docker/containers/d2408a7931c95a3a83ffeca2fba887763cf925a67890ef3be4d9ff838aa25b00 nicht mehr vorhanden ist und die entsprechenden Protokolldateien ebenfalls gelöscht werden.

Rotationsstrategie für Container-Protokolldateien

Standardmäßig werden Docker-Containerprotokolle in JSON-Dateien geschrieben, was dazu führen kann, dass die Festplatte beim Online-Ausführen voll ist. Sie können die Strategie anpassen und es laufen lassen. Ändern Sie /etc/docker/daemon.json (falls es nicht existiert, erstellen Sie manuell eines) und fügen Sie den folgenden Inhalt hinzu:

{
 "log-opts": {
 "max-size": "1m",
 "max-Datei": "3"
 }
}

Nachdem die Änderung abgeschlossen ist, starten Sie den Docker-Dienst neu:

systemctl daemon-reload
systemctl Neustart docker.service

Um die neue Protokollierungsrichtlinie zu testen, erstellen Sie mit dem folgenden Befehl einen Container:

docker run -d --rm alpine:3.6 sh -c „während wahr; mache echo hallo Welt; usleep 10; fertig“

Dieser Alpine-Container gibt alle 10 Mikrosekunden „Hallo Welt“ aus, behält die Hochfrequenzausgabe bei und erstellt schnell Protokolldateien.

Hinweis: Zeitsteuerung in der Shell

1. sleep: Der Standardwert beträgt Sekunden.
sleep 1s bedeutet Verzögerung um eine Sekunde
sleep 1m bedeutet eine Minute Verzögerung
sleep 1h bedeutet Verzögerung um eine Stunde
sleep 1d bedeutet Verzögerung um einen Tag

2. usleep: Der Standardwert ist in Mikrosekunden.

1s = 1000ms = 1000000 us

Befolgen Sie die Methode zum Anzeigen der Protokolldatei im vorherigen Artikel

# Passwort
/var/lib/docker/containers/aa3307f5b42770319129e126122be123cfd8e0ebe1c412371ad27e62faa007e3
# ls -lah
insgesamt 2,6 Mio.
drwx------ 4 root root 4.0K 24. März 16:22.
drwx------ 3 root root 4.0K 24. März 16:21 ..
-rw-r----- 1 root root 647K 24. März 16:22 aa3307f5b42770319129e126122be123cfd8e0ebe1c412371ad27e62faa007e3-json.log
-rw-r----- 1 root root 977K 24. März 16:22 aa3307f5b42770319129e126122be123cfd8e0ebe1c412371ad27e62faa007e3-json.log.1
-rw-r----- 1 root root 977K 24. März 16:21 aa3307f5b42770319129e126122be123cfd8e0ebe1c412371ad27e62faa007e3-json.log.2

Es lässt sich leicht feststellen, dass die Protokolldateistrategie darin besteht, drei 1-Millionen-Dateien zu verwalten, was mit unseren Einstellungen übereinstimmt.

Denken Sie nach Abschluss des Tests daran, die Testsite mit Docker Stop AA3 zu bereinigen. Die maximale Größe kann auch entsprechend den tatsächlichen Anforderungen angepasst werden.

Nginx-Containerprotokolle

Nachdem wir die Protokollierungsstrategie von Docker-Containern verstanden haben, schauen wir uns an, wie häufig verwendete Container gehandhabt werden. Schauen wir uns zunächst den Nginx-Container an.

Zuerst erstellt docker run -it --rm -d -p 80:80 nginx:1.15.8-alpine einen Nginx-Container, dann ruft docker exec -it b6d sh den Container auf und überprüft /etc/nginx/nginx.conf, um Folgendes anzuzeigen:

Fehlerprotokoll /var/log/nginx/error.log warnen;
Zugriffsprotokoll /var/log/nginx/access.log Haupt;

Das heißt, nginx schreibt Fehlerprotokolle und Zugriffsprotokolle in die entsprechenden Protokolldateien. Sehen Sie sich weiterhin das Verzeichnis /var/log/nginx an:

/var/log/nginx # ls -lah
gesamt 0
drwxr-xr-x 2 root root 39 4. März 07:54 .
drwxr-xr-x 3 root root 18 4. März 07:54 ..
lrwxrwxrwx 1 root root 11 Jan 31 23:32 access.log -> /dev/stdout
lrwxrwxrwx 1 root root 11 Jan 31 23:32 error.log -> /dev/stderr

Und hier kommt das Geheimnis ins Spiel. Die Datei access.log wird über einen Softlink zur Standardausgabe umgeleitet, während das Fehlerprotokoll error.log den Standardfehler umleitet. Auf diese Weise können Sie den Befehl „Docker Log“ verwenden, um das Nginx-Zugriffsprotokoll anzuzeigen.

Zur weiteren Überprüfung prüfen Sie die Dockerfile-Datei von nginx, die Folgendes enthält:

# Anfrage- und Fehlerprotokolle an den Docker-Log-Collector weiterleiten
 && ln -sf /dev/stdout /var/log/nginx/access.log \
 && ln -sf /dev/stderr /var/log/nginx/error.log

Es ist ersichtlich, dass die Ausgabe der Protokolldatei beim Erstellen des Nginx-Image definiert wird.

Verwenden Sie außerdem Docker Stop 524, um die Site zu bereinigen. Dieser Bereinigungsschritt wird in Zukunft nicht mehr eingeführt.

MySQL-Containerprotokoll

Starten Sie einen MySQL-Container

docker run --rm -e MYSQL_ROOT_PASSWORD=123456 mysql:5.7

Es ist nicht schwierig, die Protokollausgabe des MySQL-Containers anzuzeigen. Im Folgenden finden Sie einen Ausschnitt daraus:

Datenbank initialisieren
2019-03-24T08:48:19.102726Z 0 [Warnung] TIMESTAMP mit implizitem DEFAULT-Wert ist veraltet. Bitte verwenden Sie die Serveroption --explicit_defaults_for_timestamp (weitere Einzelheiten finden Sie in der Dokumentation).
2019-03-24T08:48:20.241459Z 0 [Warnung] InnoDB: Neue Logdateien erstellt, LSN=45790
2019-03-24T08:48:20.414933Z 0 [Warnung] InnoDB: Erstellen von Systemtabellen mit Fremdschlüsseleinschränkungen.
2019-03-24T08:48:20.509897Z 0 [Warnung] Es wurde keine vorhandene UUID gefunden, daher gehen wir davon aus, dass dies das erste Mal ist, dass dieser Server gestartet wurde. Eine neue UUID wird generiert: 935a6ee7-4e11-11e9-b135-0242ac110002.
2019-03-24T08:48:20.519148Z 0 [Warnung] Die Gtid-Tabelle ist nicht zur Verwendung bereit. Tabelle „mysql.gtid_executed“ kann nicht geöffnet werden.
2019-03-24T08:48:20.519843Z 1 [Warnung] root@localhost wird mit einem leeren Passwort erstellt! Bitte denken Sie darüber nach, die Option --initialize-insecure auszuschalten.
2019-03-24T08:48:24.066683Z 1 [Warnung] „Benutzer“-Eintrag „root@localhost“ wird im Modus „-skip-name-resolve“ ignoriert.
2019-03-24T08:48:24.066730Z 1 [Warnung] „Benutzer“-Eintrag „mysql.session@localhost“ wird im Modus „--skip-name-resolve“ ignoriert.
2019-03-24T08:48:24.066740Z 1 [Warnung] „Benutzer“-Eintrag „mysql.sys@localhost“ wird im Modus „--skip-name-resolve“ ignoriert.
2019-03-24T08:48:24.066756Z 1 [Warnung] „db“-Eintrag „performance_schema mysql.session@localhost“ wird im Modus „-skip-name-resolve“ ignoriert.
2019-03-24T08:48:24.066761Z 1 [Warnung] „db“-Eintrag „sys mysql.sys@localhost“ wird im Modus „--skip-name-resolve“ ignoriert.
2019-03-24T08:48:24.066772Z 1 [Warnung] „proxies_priv“-Eintrag „@ root@localhost“ wird im Modus „--skip-name-resolve“ ignoriert.
2019-03-24T08:48:24.066814Z 1 [Warnung] „tables_priv“-Eintrag „user mysql.session@localhost“ wird im Modus „-skip-name-resolve“ ignoriert.
2019-03-24T08:48:24.066822Z 1 [Warnung] „tables_priv“-Eintrag „sys_config mysql.sys@localhost“ wird im Modus „--skip-name-resolve“ ignoriert.
Datenbank initialisiert
Initialisieren von Zertifikaten
Generieren eines privaten RSA-Schlüssels

Wenn wir uns die MySQL-Dockerfile-Datei ansehen, können wir sehen, dass sich der Starteintrag des MySQL-Images in entrypoint.sh befindet. Im Skript finden wir:

echo 'Datenbank initialisieren'
"$@" --initialisieren-unsicher
echo 'Datenbank initialisiert'

So sieht die Ausgabe beim Starten des MySQL-Containers aus. entrypoint.sh ist relativ komplex. Seine Hauptfunktion besteht darin, mysqld zu starten und Protokolle auszugeben. Da es nicht im Fokus dieses Artikels steht, wird es nicht im Detail vorgestellt.

Zusammenfassen

1. Standardmäßig gibt der Docker-Container in eine lokale JSON-Datei aus und deren Größe und Menge können gesteuert werden.
2. Anwendungscontainerprotokolle können zuerst Protokolldateien generieren und dann die Anwendungsprotokolldateien per Softverbindung mit der Standardausgabe verbinden, z. B. nginx; oder Protokolle können beim Start direkt in die Standardausgabe gedruckt werden, z. B. mysql.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.