Sind Ihre AKS-Protokollierungskosten zu hoch? Hier erfahren Sie, wie Sie sie reduzieren können.

Eines der Herausforderungen, die wir bei unseren Kunden beobachten, ist die hohe Kosten der Analytics-Tabellen in Azure. In einigen Fällen machen die Protokollierungskosten bis zu 20 % ihrer gesamten Cloud-Rechnung aus.

In diesem Blogbeitrag werden wir die Verbesserungen durchgehen, die wir implementiert haben, um die Kosten für die Protokollspeicherung zu optimieren.

Die Menge der Protokolle reduzieren

Beginnen Sie damit, die Namensräume und Anwendungen zu identifizieren, die das höchste Volumen an Protokollen produzieren. Da die Protokollierungskosten in Azure hauptsächlich von ihren Speicherkosten dominiert werden, ist der beste Weg, die Kosten zu senken, weniger zu protokollieren.

Sie können schnell analysieren, welche Anwendung am meisten protokolliert, indem Sie die summarize-Funktion in Azure Log Analytics wie folgt verwenden:

Bei Conveyor verwalten wir die Kubernetes-Infrastruktur für unsere Kunden und haben somit die Kontrolle über den kube-system-Namensraum. Zunächst war dieser Namensraum für +- 50 % aller Protokolle bei unseren Kunden verantwortlich. Es gab zwei Gruppen von Anwendungen, die für die meisten Protokolle verantwortlich waren.

Die erste Kategorie besteht aus unseren Komponenten, die wir im Cluster installieren. Dies können benutzerdefinierte Anwendungen ebenso wie Drittanbieterkomponenten sein, die wir kontrollieren (z. B. cilium-agent, cluster-autoscaler…). Die Protokollierung für diese Komponenten zu reduzieren, ist trivial, da es nur erforderlich ist, eine Umgebungsvariable zu ändern.

Die zweite Kategorie waren Daemonsets, die von Microsoft als Teil des AKS-Clusters installiert wurden (z. B. microsoft-defender, cni,…). Wir fanden diese Komponenten zu bis ins Detail und auch nicht relevant für die Fehlersuche bei diesen Komponenten. Daher haben wir uns entschieden, diese Protokolle nicht an Azure Log Analytics zu senden. Auf diese Weise mussten wir nicht für sie bezahlen, konnten die Protokolle aber dennoch anzeigen, wenn wir uns mit unserem Kubernetes-Cluster verbinden. Das haben wir erst gemacht, nachdem der AKS-Cluster mehr als einen Monat stabil in der Produktion lief.

Das Herausfiltern dieser Komponenten kann mit einem Grep-Filter in Fluentbit wie folgt erfolgen:

[FILTER]Name grepMatch kube.*Exclude $kubernetes['container_name']

Zusätzlich zur Optimierung unserer eigenen Komponenten haben wir auch unsere Kunden zu bewährten Praktiken beim Protokollieren beraten:

• Verwenden Sie ein Protokollierungsframework anstelle einfacher Druckanweisungen

• Ändern Sie das Protokollierungsniveau je nach Ihrer Umgebung

• Protokollieren Sie nur Informationen, die für das Debugging relevant sind

Mit diesen einfachen Änderungen konnten wir die Protokollierungskosten unserer Kunden um 30 % senken.

Die Azure-Protokollaufnahme-API

Wie viel Sie protokollieren, sollte Ihr Ausgangspunkt sein, um die Protokollierungskosten unter Kontrolle zu bringen. Allerdings haben wir beobachtet, dass mit der Zunahme der Arbeit über die Zeit unsere Kunden erneut 20 % ihrer gesamten Cloud-Rechnung für die Protokollierung ausgaben. In diesen Situationen zahlt der Kunde so viel für virtuelle Maschinen wie für seine Protokolle, was mir verrückt erscheint.

Im letzten Jahr hat Azure die Protokollaufnahme-API eingeführt, die die Data Collector API zum Verarbeiten von Protokollen und Metriken ersetzen wird. Die neue API erfordert, dass Sie das Schema für die aufgenommenen Protokolle explizit definieren, was eine bedeutende Verbesserung im Vergleich zur vorherigen dynamischen Schemaerkennung darstellt. In unserer benutzerdefinierten Protokolltabelle haben wir mehrere unnötige Spalten, nur weil eine Handvoll Protokolle zusätzliche Felder enthalten hat.

Ein weiterer Vorteil der neuen API ist, dass sie Basic-Tabellen unterstützt, die ungefähr fünfmal günstiger zu speichern sind im Vergleich zu Analytics-Tabellen. Für die vollständigen Details schauen Sie hier. Der Migrationspfad zur neuen API wird gut in den Dokumentationen beschrieben. Leider gibt es für uns mehrere Ressourcen, die noch nicht in Terraform unterstützt werden:

• Unterstützung beim Definieren eines Schemas bei der Erstellung benutzerdefinierter Tabellen. Der Status wird in diesem Github-Problem verfolgt.

• Erstellen einer DCR (Datenkollektierungsregel) für eine benutzerdefinierte Protokolltabelle.

Wir können diese Probleme umgehen, indem wir die azurerm_resource_group_template_deployment in Terraform verwenden, bis die Probleme behoben sind.

Wie man mit der neuen API arbeitet

Um die neue Protokollaufnahme-API zu nutzen, müssen wir das Fluentbit-Ausgabe-Plugin ersetzen. Das bedeutet den Wechsel vom azure-Ausgabe-Plugin zum azurelogsingestion-Plugin. Leider unterstützt das neue Plugin nur statische Anmeldeinformationen für in Microsoft Entra Id registrierte Anwendungen.

Dies ist problematisch, weil:

• Auf ein statisches client_id und client_secret-Paar statt auf temporäre Anmeldeinformationen zu vertrauen, ist eine schlechte Praktik. Außerdem ist es auch nicht notwendig, da Azure Workload Identity vor 3 Jahren eingeführt wurde.

• Um Anwendungen in Microsoft Entra Id zu registrieren, benötigen Sie Berechtigungen für den Entra Id-Mandanten, die wir (zu Recht) nicht bei unseren Kunden haben.

Wegen dieser Probleme können wir das azurelogsingestion-Ausgabe-Plugin nicht verwenden. Wenn Ihre Situation oder Bedenken anders sind als unsere, können Sie das azurelogsingestion -Ausgabe-Plugin verwenden. Für uns blieben die folgenden Optionen:

• Verwenden Sie Fluentd anstelle von Fluentbit, da sie ein Ausgabe-Plugin haben, das mit Azure Workload Identity funktioniert. Wir haben uns nicht für diesen Ansatz entschieden, da wir vor ein paar Jahren von Fluentd weggegangen sind, da es mehr Ressourcen zum Ausführen benötigt und weniger stabil ist.

• Zur Fluentbit beitragen und die fehlende Funktionalität implementieren. Ich würde dies gerne tun, wenn ich im Schreiben von C erfahren wäre.

• Ein Fluentbit-Ausgabe-Plugin in Golang schreiben. Da unser gesamter Code in Go geschrieben ist, habe ich mich für diese Option entschieden.

Ein benutzerdefiniertes Fluentbit-Ausgabe-Plugin in Go schreiben

Fluentbit unterstützt das Schreiben von Ausgabe-Plugins in Go und gibt sie als C-Shared-Libraries aus. Die Dokumentation erklärt ziemlich gut, wie man sein eigenes Plugin schreibt. Der Hauptknackpunkt ist, dass Ihr Ausgabe-Plugin in einem Paket main sein sollte und auch eine leere Funktion main enthalten sollte.

Das Schreiben des Ausgabe-Plugins ist nicht schwer, die größte Schwierigkeit liegt darin, zu verstehen, wie die Fluentbit-Daten aussehen, die Sie erhalten. Die Datentypen, die Sie erhalten, sind immer vom Typ interface, was anfangs nicht sehr hilfreich ist. Nach einer Weile bemerkte ich, dass einige Eigenschaften als Byte-Arrays und andere als Strings kamen. Der Umgang mit der neuen Azure-Aufnahme-API ist ebenfalls unkompliziert. Insgesamt enthält das Ausgabe-Plugin nur etwa 300 Zeilen Code und ist hier verfügbar.

Das Plugin verwendet Azure Workload Identity, um temporäre Anmeldeinformationen für den Zugriff auf die Protokollaufnahme-API abzurufen. Im Code verwenden wir die DefaultAzureCredential-Kette, die den richtigen Mechanismus zur Abrufung temporärer Anmeldeinformationen auswählt. Damit Fluentbit Protokolle an die neue API senden kann, müssen wir ihm die Rolle Monitoring Metrics Publisher mit dem Geltungsbereich der Datenkollektierungsressource (DCR) zuweisen. Um die Workload-Identität für unseren Container zu konfigurieren, müssen wir die folgenden Umgebungsvariablen angeben:

• AZURE_CLIENT_ID: die Client-ID der Benutzeridentität von Fluentbit

• AZURE_AUTHORITY_HOST: https://login.microsoftonline.com/

• AZURE_TENANT_ID: die ID des Entra Id-Mandanten Ihrer Organisation

Um eine Binärdatei (.so) des Ausgabe-Plugins zu generieren, die die Go-Funktionen als C-ähnliche API bereitstellt, müssen Sie Ihren Go-Code unter Verwendung von buildmode=c-shared kompilieren. Die resultierende Binärdatei ist ziemlich groß, da sie die Go-Laufzeit und abhängige Bibliotheken mitverpackt.

Unser benutzerdefiniertes Ausgabe-Plugin bereitstellen

Bevor wir das Ausgabe-Plugin testen, müssen wir die erforderliche Infrastruktur einrichten. Da Terraform noch nicht alle erforderlichen Ressourcen unterstützt, habe ich ein nicht so einfaches Bash-Skript erstellt, um die Einrichtung zu übernehmen.

Zusätzlich zur Angabe der erforderlichen Umgebungsvariablen, um sich bei Azure zu authentifizieren, sind zwei zusätzliche Konfigurationsdateien erforderlich:

• plugins.conf: Diese Datei gibt den Pfad zur Binärdatei an, die unser Ausgabe-Plugin enthält

• Ausgabebereich in fluent-bit.conf: hier können Sie die zusätzlichen Einstellungen unseres Ausgabe-Plugins konfigurieren:

[OUTPUT]

Installationsanweisungen für unser benutzerdefiniertes Fluentbit-Plugin auf Kubernetes finden Sie auf meinem Github. Das benutzerdefinierte Docker-Image von Fluentbit ist auf Dockerhub verfügbar. Das Plugin ist noch in Arbeit und wir testen es aktiv, daher können wir noch keine endgültigen Kostensenkungszahlen angeben.

Fazit

In diesem Blogbeitrag haben wir Strategien zur Senkung Ihrer Protokollierungskosten in Azure untersucht. Der erste Schritt besteht darin, sicherzustellen, dass Ihre Anwendungen nur das protokollieren, was notwendig ist. Als Ausgangspunkt können Sie analysieren, welche Anwendungen die meisten Protokolle produzieren und prüfen, ob dies optimiert werden kann.

Zweitens haben wir die neue Protokollaufnahme-API von Azure besprochen und wie sie sowohl die Effizienz des Workflows als auch die Kostensenkung verbessern kann. Schließlich haben wir erklärt, wie wir ein benutzerdefiniertes Fluentbit-Ausgabe-Plugin in Golang implementiert haben, um mit der neuen API zu arbeiten.

—

Ich werde in unserem bevorstehenden Live-Webinar am 20. März 2025 wichtige Strategien zur Optimierung von Kubernetes für die Ausführung kurzlebiger Anwendungen behandeln. Registrieren Sie sich hier, wenn Sie teilnehmen möchten.