Übersicht

IBM Cloud Private stellt einen ELK-Stack bereit, der als Managementprotokollierungsservice bezeichnet wird, um alle von Docker erfassten Protokolle zu sammeln und zu speichern. Es sind zahlreiche Optionen für die Anpassung des Stacks verfügbar, bevor Sie IBM Cloud Private installieren, zum Beispiel auch eine durchgängige TLS-Verschlüsselung. Sie können zusätzliche ELK-Stacks aus dem Katalog bereitstellen und anpassen oder Lösungen anderer Anbieter bereitstellen, wodurch Sie ein Maximum an Flexibilität zum Verwalten Ihrer Protokolle erhalten.

Der Managementprotokollierungsservice bietet eine breite Auswahl an Optionen, um den Stack Ihren Anforderungen entsprechend zu konfigurieren:

ELK

ELK ist eine Abkürzung der drei Produkte Elasticsearch, Logstash und Kibana, die alle von Elastic Symbol für externen Link entwickelt wurden. Zusammen bilden sie eine Auswahl von Tools, die Daten einschließlich Protokollen streamen, speichern, durchsuchen und überwachen. Eine vierte Elastic-Komponente mit dem Namen Filebeat wird bereitgestellt, um die Protokolle an Elasticsearch zu streamen.

Integration von Docker

Auf jedem Knoten im Cluster muss Docker so konfiguriert sein, dass der Treiber für JSON-Dateien verwendet wird. Docker streamt die stdout- und stderr-Pipes aus jedem Container in eine Datei auf dem Docker-Host. Beispiel: Wenn ein Container die Docker-ID abcd hat, ist für einige Plattformen die Standardposition zum Speichern der Ausgabe des Containers /var/lib/docker/containers/abcd/abcd-json.log. Das IBM Cloud Private-Protokollierungsdiagramm stellt auf jedem Knoten ein Filebeat-DaemonSet bereit, um die JSON-Protokolldateien in den ELK-Stack zu streamen.

Kubernetes fügt zu den einzelnen Containerprotokollen eine eigene Abstraktionsebene hinzu. Im Standardpfad /var/log/containers wird eine symbolische Verbindung (symlink) erstellt, die zurück auf die einzelnen Docker-Protokolldateien verweist. Der Name der Datei der symbolischen Verbindung enthält zusätzliche Kubernetes-Metadaten, die geparst werden können, um vier Felder zu extrahieren:

                   |   1    |   2   |    3    |                               4                                |
/var/log/containers/pod-abcd_default_container-5bc7148c976a27cd9ccf17693ca8bf760f7c454b863767a7e47589f7d546dc72.log
  1. Der Name des Pods, zu dem der Container gehört (gespeichert als kubernetes.pod)
  2. Der Namensbereich, in dem der Pod bereitgestellt wurde (gespeichert als kubernetes.namespace)
  3. Der Name des Containers (gespeichert als kubernetes.container_name)
  4. Die Docker-ID des Containers (gespeichert als kubernetes.container_id)

Protokolle verarbeiten

Logstash

Logstash führt zwei Rollen aus. In erster Linie werden die Daten zwischen Filebeat und Elasticsearch gepuffert. Dieser Puffer bietet Schutz vor Datenverlust und reduziert den Datenverkehr zu Elasticsearch. Die zweite Rolle besteht darin, den Protokollsatz weiter zu parsen, um Metadaten zu extrahieren und um das Durchsuchen der Daten im Datensatz zu erleichtern. Im Folgenden finden Sie die Standardschritte, die der Logstash-Pod ibm-icplogging ausführt:

  1. Parsen der Datumszeitmarke des Protokollsatzes (von Docker an dem Zeitpunkt gespeichert, an dem sie vom Container festgelegt wurde).
  2. Extrahieren des Namens, des Namensbereichs, der Pod-ID und der Container-ID in individuelle Felder.
  3. Wenn der Container einen Protokolleintrag im Format JSON generiert, ist dieser zu parsen und die einzelnen Felder sind in das Stammverzeichnis des Protokollsatzes zu extrahieren.

Der Datensatz wird dann kurz gespeichert, bis Logstash ihn an Elasticsearch sendet.

Elasticsearch

Durch Senden eines Protokollsatzes an Elasticsearch wird dieser zum Dokument. Jedes Dokument wird innerhalb einer benannten Gruppe gespeichert, die als Index bezeichnet wird. Wenn Logstash einen Datensatz an Elasticsearch sendet, wird dieser einem Index mit dem Muster logstash-<YYYY>-<MM>-<dd> zugeordnet. Wenn jeder Datensatz einem Index zugeordnet wird, der nach dem Tag der Übergabe benannt ist, ist das Verfolgen von Protokollaufbewahrungsrichtlinien einfacher.

Elasticsearch selbst wird unabhängig für drei verschiedene Pod-Typen ausgeführt. Viele andere Konfigurationen sind möglich. Dies ist die Konfiguration, die im Helm-Diagramm ibm-icplogging ausgewählt ist.

Kibana

Kibana bietet eine Abfrage- und Visualisierungsschnittstelle zu Elasticsearch, die browserfreundlich ist. Kibana kann optional aus der Bereitstellung ausgeschlossen werden, dies wird jedoch nicht empfohlen, da diese Schnittstelle das Standardtool zum Durchsuchen von Protokollen ist.

Nach der Bereitstellung – Anmerkungen

Protokolle anzeigen und abfragen

Kibana ist das primäre Tool, das für die Schnittstelle zu Protokollen verwendet wird. Es bietet eine Erkennungsansicht, über die Sie Abfragen nach Protokollen ausführen können, die bestimmte Kriterien erfüllen. Es ist möglich, über diese Ansicht Protokolle mithilfe eines oder mehrerer Felder zu sortieren, das bzw. die vom ELK-Stack ibm-icplogging automatisch hinzugefügt werden.

Möglicherweise müssen Sie auf der Basis anderer Kriterien, die nicht vom ELK-Stack erkannt werden können, Protokolle abfragen. Beispielsweise 'Middlewareprodukt', 'Anwendungsname' oder 'Protokollebene'. Ziehen Sie als Ausgabeformat JSON in Betracht, um für Anwendungsprotokolle höchste Genauigkeit zu erzielen. JSON deklariert die Namen der Werte in der Protokolldatei und wartet nicht auf ein ordnungsgemäßes Parsing durch Elasticsearch. Das vom Helm-Diagramm ibm-icplogging bereitgestellte Filebeat-DaemonSet ist vorkonfiguriert, sodass mit JSON formatierte Protokolleinträge geparst werden und Werte so festgelegt werden, dass sie in Elasticsearch als Elemente der obersten Ebene suchbar sind.

Hinweis: Ausnahmebedingungen in Logstash, die auf IBM® Z-Plattformen beobachtet wurden.

Ausnahmebedingungen, die den folgenden Nachrichten ähneln, sind in Logstash sichtbar. Die Ausnahmebedingungen wirken sich nicht auf die Übernahme von Protokollen aus Filebeat in die Kibana-UI aus.

[2019-07-07T12:11:35,834][INFO ][org.logstash.beats.BeatsHandler] [local: 10.1.79.146:5044, remote: 10.1.79.173:48148] Handling exception: error:1e00007d:Cipher functions:OPENSSL_internal:INVALID_NONCE
[2019-07-07T12:11:35,834][WARN ][io.netty.channel.DefaultChannelPipeline] An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.

javax.net.ssl.SSLException: error:1e00007d:Cipher functions:OPENSSL_internal:INVALID_NONCE

at io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:895) ~[netty-all-4.1.30.Final.jar:4.1.30.Final]

at io.netty.handler.ssl.ReferenceCountedOpenSslEngine.shutdownWithError(ReferenceCountedOpenSslEngine.java:882) ~[netty-all-4.1.30.Final.jar:4.1.30.Final]

at io.netty.handler.ssl.ReferenceCountedOpenSslEngine.wrap(ReferenceCountedOpenSslEngine.java:824) ~[netty-all-4.1.30.Final.jar:4.1.30.Final]

Elasticsearch-APIs

Elasticsearch verfügt über einen hohen Grad an Flexibilität sowie über eine gründlich dokumentierte API. Durch die sichere Installation des ELK-Stacks wird der API-Zugriff auf interne Komponenten durch eine gegenseitige Authentifizierung über TLS wie in den vorherigen Abschnitten beschrieben eingeschränkt. Daher ist der externe Zugriff auf Elasticsearch-Daten nur für Benutzer verfügbar, die über Kibana authentifiziert sind. Sie können auch die Anzeige dev tools in der Kibana-Benutzerschnittstelle verwenden, um auf die Elasticsearch-API zuzugreifen. Wenn mehr ELK-Stacks im Standardmodus bereitgestellt werden, ist der Kibana-Zugriff nicht durch die IBM Cloud Private-Authentifizierung oder -Berechtigungsprüfungen geschützt.

Hinweis: Diese APIs dienen nur zum Abfragen und Verarbeiten von Daten, die gegenwärtig im Elasticsearch-Datenspeicher überwacht werden. Sie haben keine Auswirkungen auf Sicherungen.