Logging lokaler Ressourcen mit Blue Medora

Diese Lösung ist Teil einer zweiteiligen Reihe, wie Sie Cloud Logging und Cloud Monitoring in lokale Infrastrukturen und Anwendungen einbinden.

  • Logging (diese Lösung): Erfahren Sie, wie Sie mit Logging Logdaten von lokalen Ressourcen erhalten.
  • Monitoring: Lesen Sie, wie Sie mit Monitoring lokale Ressourcen überwachen.

Aus folgenden Gründen sollten Sie Logging und Monitoring zum Protokollieren und Überwachen Ihrer lokalen Ressourcen in Betracht ziehen:

  • Sie benötigen eine temporäre Lösung, während Sie Ihre Infrastruktur zu Google Cloud verschieben, und möchten Ihre lokalen Ressourcen protokollieren und überwachen, bis sie außer Betrieb genommen werden.
  • Möglicherweise haben Sie eine heterogene Computerumgebung mit verschiedenen Cloud- und lokalen Ressourcen.

In beiden Fällen können Sie sowohl mit den Logging und Monitoring APIs als auch mit BindPlane Einblick in Ihre lokalen Ressourcen erhalten. Diese Lösung richtet sich an DevOps-Entwickler, Manager und Führungskräfte, die an einer Logging-Strategie für Ressourcen in Google Cloud und den verbleibenden lokalen Infrastrukturen und Anwendungen interessiert sind.

Logs mit Logging aufnehmen

Sie können Logs mithilfe der API auf zwei unterstützte Arten in Logging aufnehmen:

  • Verwenden Sie das BindPlane-Tool von Blue Medora, um Logs von Ihren lokalen oder anderen Cloud-Quellen aufzunehmen.
  • Verwenden Sie die Cloud Logging API direkt über Ihre Anwendung oder mit einem benutzerdefinierten Agent.

BindPlane zum Aufnehmen von Logging-Logs verwenden

Im folgenden Diagramm ist dargestellt, wie BindPlane Logs aufnimmt und wie diese Logs in Logging aufgenommen werden.

Architektur für die Verwendung von Logging und BindPlane zum Aufnehmen lokaler Logs

BindPlane bietet einen integrierten Dienst zum Aufnehmen von lokalen Logs in Logging. BindPlane verwendet die Logging APIs mithilfe eines Fluentd-Agents, um Logs an Logging zu senden, was dem Vorgang des Logging-Agents ähnelt. Weitere Informationen finden Sie in den Anleitungen zu BindPlane. Diese Option ist am einfachsten zu implementieren, da sie zum Einrichten nur eine Konfiguration und keine Programmentwicklung benötigt.

Vorteile:

  • Sie benötigt Konfiguration, keine Programmentwicklung.
  • Sie ist in den Kosten für die Verwendung von Logging enthalten.
  • Sie gehört zur unterstützten Konfiguration vom Logging-Produkt und -Support.
  • Sie kann auf Logs erweitert werden, die nicht von der Standardkonfiguration bereitgestellt werden.

Nachteile:

  • Sie erfordert die Verwendung eines Drittanbietertools.
  • Möglicherweise muss die Konfiguration des Fluentd-Plug-ins bereitgestellt werden, wenn das Log-Plug-in nicht standardmäßig bereitgestellt wird. Die bereitgestellte Liste der Logs ist unter Quellen verfügbar.

Logging API direkt verwenden

Das folgende Diagramm zeigt, wie Logs von der Instrumentierung erfasst und in Logging aufgenommen werden.

Diagramm: Architektur für die Verwendung der Logging API zur direkten Aufnahme lokaler Logs

Wenn Sie die APIs direkt verwenden, müssen Sie Ihre Anwendungen instrumentieren, Logs direkt an die API zu senden, oder einen benutzerdefinierten Agent entwickeln, der Logs an die API sendet. Das ist die aufwendigste Option, da sie mit Entwicklungsaufwand verbunden ist.

Vorteile:

  • Sie bietet Flexibilität, da Sie die Instrumentierung mit Client-Logging-Bibliotheken implementieren können.

Nachteile:

  • Sie erfordert eine separate Lösung für Infrastrukturlogs, z. B. einen benutzerdefinierten Agent.
  • Sie erfordert Code-Instrumentierung, was höhere Implementierungskosten bedeuten kann.
  • Sie erfordert Batching und andere skalierbare Aufnahmetechniken für eine angemessene Aufnahmeleistung.
  • Support wird nur für die Logging API angeboten, nicht aber für benutzerdefinierten Code.

BindPlane verwenden

Diese Lösung behandelt die Verwendung des Tools BindPlane von Blue Medora zur Aufnahme von Logs in Logging. BindPlane ist in den Kosten von Logging enthalten. Daher ist keine Entwicklung erforderlich und es wird eine produktunterstützte Lösung bereitgestellt.

Agents, Quellen und Ziele

BindPlane bietet die folgenden Funktionen:

  • Agents: Software zum Erfassen von Logs, die normalerweise auf dem Computer installiert wird, auf dem die Logs erstellt werden. Agents senden die Logs auch an die Logging API.
  • Quellen: Konfiguration, die angibt, welche Logs aufgenommen werden sollen (wie Syslogs, Apache und Kubernetes) und wie die Logs analysiert werden. Weitere Informationen finden Sie in der Dokumentation von BindPlane zu Quellen. Nicht unterstützte Logs können über einen generischen Syslog input oder Tail input erfasst werden. Für benutzerdefinierte Logs können Sie einen Custom Input angeben, der einen benutzerdefinierten Fluentd-Konfigurationsblock als Eingabe verwendet.
  • Ziele: Die Drittanbieterdienste, an die BindPlane die Logs weiterleitet. In diesem Fall ist das Ziel die Logging API, um Messwerten in Logging zu schreiben.

Ausführlichere Informationen zu Agents, Quellen und Zielen finden Sie unter Erste Schritte.

Anwendungsbeispiel

BeispielUnternehmen verfügt beispielsweise über Ressourcen, die in Google Cloud, Microsoft Azure und mithilfe von vSphere in lokalen Ressourcen bereitgestellt werden. BeispielUnternehmen hat Ressourcen in jeder dieser Umgebungen und möchte Logs für jede Komponente erfassen, unabhängig davon, wo die Komponente bereitgestellt wird. Indem Logs aus jeder Umgebung mithilfe von BindPlane-Agents an Logging gesendet werden, werden alle Logs an einem einzigen Speicherort für zentralisierte Berichterstellungs-, Monitoring- und operative Zwecke gespeichert.

In diesem Beispiel wird Logging als Ziel für ein Array von Agents, einschließlich der Agents in Google Cloud, Microsoft Azure und vSphere, eingerichtet. Nachdem die Logs generiert wurden, werden sie von BindPlane in Logging aufgenommen.

Logs der lokalen Umgebung an Logging senden

Nachdem Sie BindPlane eingerichtet und mit dem Senden von Logs begonnen haben, werden diese Logs an Logging gesendet. Öffnen Sie die Google Cloud Console, um Logs anzusehen, zu verarbeiten und zu exportieren. Die Logs werden als Ressourcentypen generic_node oder generic_task aufgelistet. Weitere Informationen zu den in den einzelnen Ressourcentypen enthaltenen Labels finden Sie in der Ressourcenliste von Logging.

Cloud Logging unterstützt mithilfe von zwei Ressourcentypen Logs, die nicht von Cloud Logging stammen:

  • Generischer Knoten: Gibt eine Maschine oder eine andere Computing-Ressource an, für die kein anderer Ressourcentyp anwendbar ist. Die Labelwerte müssen den Knoten eindeutig identifizieren.
  • Allgemeine Aufgabe: identifiziert einen Anwendungsprozess, für den keine andere Ressource anwendbar ist, z. B. einen von einem benutzerdefinierten Orchestrierungssystem geplanten Prozess. Die Labelwerte müssen die Aufgabe eindeutig identifizieren.

Logs in Logging aufrufen

In der Cloud Console wird Generischer Knoten als Ressourcentyp in der Liste auf der Seite "Logging" angezeigt.

Screenshot: Liste der Ressourcen in Logging

Die folgenden Logs wurden als Ressourcentyp generic_node erfasst und werden in Logging angezeigt.

Liste der Logs in Logging

Der folgende Logeintrag verwendet ein strukturiertes Logging-Format. Dies bietet ein umfangreicheres Format für die Suche in den Logs, da die Lognutzlast als jsonPayload gespeichert wird. Das strukturierte Logging-Format erleichtert den Zugriff auf Logs, da Sie die Felder in der Nutzlast als Teil der Suche verwenden können. Der Logging-Agent von BindPlane stellt eine Zuordnung vom ursprünglichen Logeintrag zum strukturierten Log in Logging bereit.

Screenshot: Logeintrag im strukturierten Logging-Format

Fazit

Mit den in Logging verfügbaren Logs können Sie die Logging-Funktionen in vollem Umfang nutzen. Logs werden in der Cloud Console angezeigt. Sie können Logs mithilfe von Logexporten exportieren und mit diesen unter Verwendung von logbasierten Messwerten Messwerte und Benachrichtigungen in Monitoring erstellen.

Nächste Schritte