Azure Log Analytics – One to collect them all?

Azure Log Analytics – One to collect them all?

Lesezeit: 15 Minuten

Was ist Azure Log Analytics?

Grob gesagt ist Azure Log Analytics eine weitere Möglichkeit zur Speicherung von Event- und Metrik-Daten innerhalb von Microsoft Azure.

alt text

Quelle: https://docs.microsoft.com/en-us/azure/azure-monitor/platform/design-logs-deployment

Die zentrale Komponente von Log Analytics ist der „Log Analytics Workspace“. Dieser dient als Sammelstelle für alle möglichen Arten von Informationen. Wie schon erwähnt, kann ein Workspace unterschiedliche Arten von Informationen enthalten. Hierzu zählen metrische Daten, Syslog-Einträge, Eventlog, IIS-Logs, Custom-Logs, etc….
Da Log Analytics die Möglichkeit bietet, benutzerdefinierte Daten zu speichern, sind die Einsatzzwecke hier vielfältig.

Die gesammelten Daten werden in unterschiedlichen Tabellen mit jeweils speziellen Eigenschaften gespeichert. Diese Art der Datenspeicherung bietet die Möglichkeit verschiedene Rechtekonzepte zu erstellen, um zu steuern, wer auf welche Daten Zugriff hat.

Weitere Informationen für die Erstellung eines Rechtekonzepts liefert Microsoft in seinem Technet: https://docs.microsoft.com/en-us/azure/azure-monitor/platform/design-logs-deployment

Wie kommen die Daten in den Workspace?

Um Daten in einen Workspace zu speichern, muss dieser mit einer Datenquelle verbunden werden. Am einfachsten geschieht dies, indem man aus einem Microsoft Service heraus, z.B. Metriken von virtuellen Maschinen, den Workspace als Ziel angibt.

alt text

In dem o.g. Beispiel wird über die „Azure Diagnostics Extension“ der Log Analytics Agent auf der VM installiert. Dieser Agent sammelt die metrischen Daten, sowie die Einträge aus dem Syslog und sendet diese an den konfigurierten Log Analytics Workspace.

Wer es eilig hat und direkt einen Blick auf die gesammelten Daten werfen möchte, wird enttäuscht werden. Zwischen dem Einspeisen der Daten in den Workspace und ihrer Verfügbarkeit kann es immer wieder Verzögerungen von bis zu 15 Minuten geben. Für die Echtzeitüberwachung von Daten ist Log Analytics somit nicht geeignet.

Wie komme ich an die Daten?

Der Workspace sammelt nun fleißig Daten. Um sich hier einen Überblick zu verschaffen, was genau gesammelt wurde, bietet Microsoft im Azure Portal einen Editor an, um die Daten auszuwerten.

alt text

In dem Editor können Abfragen in der von Microsoft entwickelten Abfragesprache „Kusto“ abgesetzt werden.

Weitere Infos zum Umgang mit Kusto sind hier zu finden: https://docs.microsoft.com/en-us/azure/data-explorer/kusto/concepts/

Durch die Aufteilung in unterschiedliche Tabellen bringt jeder verbundene Service sein eigenes Set an Eigenschaften mit, welche abgefragt und ausgewertet werden können.

alt text

Der Screenshot zeigt einen Workspace, welcher nur Daten von einer VM erhält. Je mehr Services verbunden werden, desto länger wird die Liste.

Als kleines Beispiel. Die folgende Abfrage liefert Informationen über die gesammelten metrischen Daten der letzten 24 Stunden einer VM. Die Ausgabe wird auf 10 Datensätze eingegrenzt

InsightsMetrics | where TimeGenerated > ago(24h) | limit 10

alt text

Wofür kann ich diese Daten nutzen?

Microsoft ist dabei Log Analytics als Datenbasis für weitere Services zu nutzen.

  • Sammlung interner VM Daten
  • Alarmierung über Azure Monitor
  • Updateautomatisierung von virtuellen Maschinen
  • Application Logs

Wenn ein Service die Nutzung eines Log Analytics Workspace voraussetzt und es wurde noch keiner erstellt, so wird im Verlauf der Aktivierung ein Workspace angelegt. Ansonsten muss ein bereits existierender Workspace ausgewählt werden.

Services, welche einen eigenen Bereich für die Daten im Workspace haben, nennt Microsoft Solutions. Solutions haben jeweils eine eigene Unterseite, auf welcher noch zusätzliche Informationen grafisch dargestellt werden.

Nehmen wir zwei Beispiel für die Nutzung:

Update Management von virtuellen Maschinen

Will man das Update Management von virtuellen Maschinen über den bereitgestellten Automatismus von Azure durchführen, so muss im Verlauf der Aktivierung ein Log Analytics Workspace ausgewählt oder erstellt werden.

Danach sendet der Agent auf den VMs die Informationen zu den notwendigen Updates an den Konfigurierten Workspace. Diese Informationen dienen als Basis für die Steuerung der Installation der Updates.

Azure Monitor

Ein weiterer Service, welcher die Daten von Log Analytics nutzt, ist der Azure Monitor. Azure Monitor dient zur Überwachung der Cloud Umgebung und Alarmierung im Problemfall. Über die Nutzung der, von Log Analytics gesammelten, Daten lassen sich genauere Alarmierungsregeln erstellen. So kann auch das Auftreten eines Eintrages im Eventlog als Grundlage für einen Alarm dienen.

Wie weiter oben im Text beschrieben gibt es eine Verzögerung zwischen der Speicherung und der Auswertung der Daten. Das sollte bei der Überprüfung von Werten, aus Log Analytics, über den Azure Monitor unbedingt berücksichtigt werden.

Was kostet der Spaß?

Nun kommen wir zu einem Punkt, welcher sehr häufig nicht beachtet wird. Die Kosten von Log Analytics.

Die Abrechnung von Log Analytics erfolgt nach der Menge der zugeführten Daten in einen Workspace und der Dauer, über welche die Daten vorgehalten werden sollen. Der Standardzeitraum für die Aufbewahrung beträgt 31 Tage und ist inkludiert.

Ein Wichtiger Punkt hierbei ist: Die Kosten entstehen durch das Einfügen der Daten, nicht direkt durch die Aufbewahrung. Sollten, als Beispiel, 10GB an Daten auf einmal in einen Workspace eingeführt und nach kurzer Zeit gelöscht werden, so entstehen die Kosten trotzdem.

Nehmen wir uns doch einmal den Price Calculator von Microsoft. Die Berechnung für Log Analytics versteckt sich unter dem Punkt „Azure Monitor“.

Annahmen:

  • 50 Virtuelle Maschinen
  • 2GB Log pro Maschine pro Monat
  • 31 Tage Aufbewahrung
  • Kein erweiterter Support
  • Kein EA Vertrag mit gesonderten Preisen

alt text

Die Monatlichen Kosten belaufen Sich hierbei auf ca. 240€.

Wenn wir die Parameter etwas ändern und annehmen das wir weniger virtuelle Maschinen haben, diese dafür aber eine bzw. mehrere LOG-intensive Applikationen hosten, sieht es wie folgt aus.

Geänderte Annahmen:

  • 5 Virtuelle Maschinen
  • 15 GB Log pro Maschine pro Monat

alt text

Hier verursachen nun 5 Maschinen allein ca. 2/3 der Kosten des vorherigen Beispiels.

Nicht betrachtet ist hierbei auch noch die Integration von weiteren PaaS Services oder der Nutzung von Application Insights.

Generell gilt bei der Einbindung von Services in Log Analytics immer das Sprichwort: Kleinvieh macht auch Mist.

Auch wenn die Daten eines Service sehr gering erscheinen, so können diese in der breiten Masse auch wieder für einen hohen Kostenfaktor verantwortlich sein.

Welche Alternativen gibt es?

Wie bereits erwähnt fokussiert Microsoft stark die Nutzung von Log Analytics als Basis für eine Vielzahl aktueller und kommender weiterer Dienste. Einen Weg vollkommen an Log Analytics vorbei wird es nicht mehr geben.

Trotzdem müssen nicht alle Daten in Log Analytics gespeichert werden.

Variante 1

Als Alternative für die Log Einträge schauen wir uns die Kombination aus „Azure Event Hubs“, für die Sammlung, und „Azure Blog Storage“, für die Speicherung, der Daten an.

Azure Event Hubs ist ein Service für die Verarbeitung von Realtime Dateneinträgen. Hauptsächlich findet es seinen Einsatz im Bereich der BI. Aber auch für die Sammlung und Speicherung von Log Daten erfüllt es seinen Zweck. Die Kostenberechnung erfolgt an der Anzahl der Verarbeiteten Events und der Menge des Durchflusses an Daten. Azure Blob Storage ist eine Komponente des Azure Storage Accounts für die Speicherung von Daten. Berechnet wird die Menge der gespeicherten Daten.

Wir gehen von folgender Konfiguration für die beiden Produkte aus:

  • Event Hubs
    • Standard Tier
    • Capture aktiviert, damit die Daten direkt in einen Storage Account geschrieben werden
    • 2 Millionen Events
    • 1 Throughput Unit pro Tag
  • Storage Account
    • Standard Tier
    • Blob Storage
    • LRS Verfügbarkeit
    • Access Tier Cold
    • 60 GB erwartetes Volumen
    • 2 Millionen Schreib Operationen
    • Den Rest belassen wir beim Standard

alt text

In dieser Konfiguration liegen wir bei um die 100€. Ein deutlicher Unterschied zu den vorherigen Beispielen.

Wichtig hierbei ist zu beachten, dass ohne eine genaue Kenntnis der Umgebung, in Bezug auf Größe und Anzahl der Erwarteten Logs, eine Kalkulation im Voraus eher schwierig ist.

Die Hauptsächlichen Kostenpunkte hierbei sind die Anzahl der benötigten TUs des Event Hubs sowie die Anzahl der Schreiboperationen im Storage Account.

Die gespeicherten Daten müssen nun noch zur weiteren Verarbeitung von einer weiteren Instanz abgeholt werden.

Variante 2

Die, im Event Hub, gesammelten Daten müssen nicht zwangsweise in einem Storage Account gespeichert werden. Das Event Hub speichert die Daten auch für eine kurze Zeit zwischen. Diese Daten können dann von einer weiteren Instanz abgeholt werden.

Hierfür würde sich die Kombination von Elasticsearch als Speicherziel und ein Dashboard für eine konsolidierte Anzeige der gespeicherten eignen.

Der CLOUDETEER Ops.STACK baut auf diesen Prinzipien auf.

Die Log Daten werden über Event Hub in den Elasticsearch geschrieben und von dort über ein Dashboard zu Ansicht bereitgestellt.

Mehr zum CLOUDETEER Ops.STACK ist hier zu finden: https://www.cloudeteer.de/solutions/

Die Kosten bei dieser Variante variieren je nach der bestehenden Infrastruktur. Als Kostenpunkte wären hier die Plattform, auf welcher der Elasticsearch betrieben wird zu nennen. Kosten für den Storage sind zu vernachlässigen.

Variante 3

Logshipping über fluentd.
Fluentd ist eine modular aufgebauter Logshipper, der Log-Daten sammelt, transferiert und in einem einheitlichen Format an einen beliebigen Datenspeicher ausliefert. Dazu stehen 500+ Plugins zur Verfügung, welche die gängigsten Input/Output Formate unterstützen. Als Projekt der CNCF (Cloud Native Computing Foundation) wird fluentd von vielen Organisationen im Cloud Umfeld genutzt.

Als zentraler Datenspeicher kann hier (wie in Variante 2) z.B. Elasticsearch genutzt werden, was dann die Daten für die Visualisierung über ein Dashboard zur Verfügung stellt.

Kosten entstehen bei dieser Variante primär für die verbrauchten Ressourcen (CPU/RAM/Storage).

Variante 4

Die vielleicht einfachste Methode für die Sammlung von Metrischen Daten ist Nutzung der nativen Azure API-Schnittstellen. Hier lassen sich schon einige Daten abziehen, welche dann entweder weiterverarbeitet oder in einem Ziel System, z.B. Elasticsearch, gespeichert werden können.

Microsoft bietet neben REST auch SDK´ s für diverse Programmiersprachen an. So wird das Sammeln der Daten nochmals vereinfacht.

Der Nachfolgende Aufruf listet die prozentuale Nutzung der CPU einer virtuellen Maschine auf:
https:/management.azure.com/ resource/subscriptions/12345678-ABCD-1111-2222-123456ABCDEF/resourceGroups/RESOURCEGROUP /providers/Microsoft.Compute/virtualMachines/VMNAME/metrics?api-version=2018-01-01&metricnames=Percentage%20CPU

Bleiben wir bei den metrischen Daten von virtuellen Maschinen, so ist der variable Teil die Angabe des gewünschten Counters. Lässt man diese Angabe weg, so werden alle Daten, welche zu dem Bereich „metrics“ gehören angezeigt.

Die Einfachheit der Nutzung der API-Schnittstellen ist hier die größte Stärke. Leider ist der Gehalt der Informationen nicht so groß, wie z.B. bei der Nutzung von Log Analytics oder Event Hub. Eventlogs von virtuellen Maschinen lassen sich auf diese Art nicht Sammeln.

Microsoft schränkt die maximale Anzahl von API-Calls gegen Azure ein, um sicherzustellen, dass keine Engpässe auftreten.

Weitere Informationen zu den Einschränkungen sind hier zu finden: https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/request-limits-and-throttling#:~:text=If%20your%20requests%20come%20from,each%20Azure%20Resource%20Manager%20instance.

Fazit

Microsoft bietet mit Log Analytics eine einfache Möglichkeit, um zentral Daten von verschiedenen Services zu sammeln und diese mit einer einfachen Sprache abzufragen. Wie oft bei solchen Möglichkeiten steckt der Teufel aber im Detail. Bindet man alle verfügbaren Daten an Log Analytics an, so stehen Sie einfach zur Verfügung, aber die möglichen Kosten können schnellstens in die Höhe schießen.

Hier sei jedem angeraten zu prüfen, ob die Notwendigkeit der Datenspeicherung in Log Analytics benötigt wird oder ob eine der aufgezeigten Alternativen die bessere Variante wäre.