Azure Monitor und Log Analytics für kleine Unternehmen in Berlin

Azure-Workloads ohne Monitoring-Strategie zu betreiben bedeutet operativen Blindflug. Sie wissen nicht, wann die Festplatte einer virtuellen Maschine voll läuft, bis eine Anwendung ausfällt. Sie wissen nicht, dass eine Datenbank seit zwei Stunden bei 95% CPU-Auslastung arbeitet, bis ein Nutzer anruft und sagt, die Anwendung sei langsam. Sie wissen nicht, dass ein fehlgeschlagener Function-App-Trigger drei Tage lang still Nachrichten verwirft, bis die Abstimmung die Datenlei zeigt. Azure Monitor und der integrierte Log Analytics-Arbeitsbereich lösen dies: Eine einheitliche Plattform für Metriken, Protokolle, Alarme und Dashboards, die jede Azure-Ressource, lokale Server und Microsoft 365-Signale in einem einzigen Fenster abdeckt.

Dieser Leitfaden erklärt, wie Azure Monitor und Log Analytics funktionieren, wie nützliche KQL-Abfragen erstellt werden, wie aussagekräftige Alarme konfiguriert werden und wie Berliner Unternehmen ohne dediziertes DevOps-Team eine Monitoring-Basis aufbauen können.

Architektur: Zwei Datenkanäle

Azure Monitor erfasst zwei Datenkategorien:

• Metriken: Numerische Zeitreihendaten, die von Azure-Ressourcen in regelmäßigen Intervallen ausgegeben werden. CPU-Prozentsatz, Festplatten-IOPS, Netzwerkbytes ein/aus, SQL-DTU-Verbrauch, App Service-Antwortzeit. Metriken werden nativ in Azure Monitor Metrics gespeichert und 93 Tage aufbewahrt
• Protokolle: Strukturierte oder semi-strukturierte Ereignisdatensätze. Ressourcendiagnoseprotokolle (Key Vault-Zugriffsereignisse, NSG-Flussprotokolle, Speicherkonto-Audit-Ereignisse), Anwendungsprotokolle aus Application Insights, Windows-Ereignisprotokolle von VMs, Azure-Aktivitätsprotokoll (wer was mit welcher Ressource wann getan hat). Protokolle werden an einen Log Analytics-Arbeitsbereich gesendet – einen zentralisierten Protokollspeicher mit einer SQL-ähnlichen Abfragesprache (KQL)

Der Log Analytics-Arbeitsbereich

Der Log Analytics-Arbeitsbereich ist das Herzstück Ihrer Azure-Observability-Infrastruktur. Jede Diagnoseprotokollquelle, jeder VM-Agent und jeder verbundene Dienst schreibt in einen Arbeitsbereich. Wichtige Merkmale:

• Schema: Jede Protokollquelle schreibt in eine benannte Tabelle. AzureActivity (Azure-Control-Plane-Ereignisse), SigninLogs (Entra ID-Anmeldungen), KeyVaultLogs (Tresorzugriffsereignisse), AzureDiagnostics (Multi-Ressourcen-Diagnoseprotokolle), SecurityEvent (Windows-Sicherheitsereignisprotokoll), Heartbeat (VM-Agent-Lebendigkeit)
• Aufbewahrung: Konfigurierbar von 30 bis 730 Tagen. Die interaktive Aufbewahrung (vollständig abfragbar) ist standardmäßig 30 Tage; die Archivaufbewahrung (niedrigere Kosten, abfragbar aber nicht in Echtzeit-Dashboards) verlängert auf 7 Jahre für Compliance-Zwecke
• Kosten: Die Einspeisung wird pro GB berechnet. Der kostenlose Azure Monitor-Tarif enthält 5 GB/Monat; darüber hinaus beträgt der Pay-as-you-go-Preis ca. 2,30 €/GB. Für die meisten Kleinunternehmen liegen die Monitoring-Kosten bei 5–20 €/Monat
• Microsoft Sentinel-Integration: Sentinel läuft auf einem Log Analytics-Arbeitsbereich und erweitert ihn um SIEM-Erkennungsregeln, Incident-Management und SOAR-Playbooks. Der Arbeitsbereich ist gemeinsam genutzt, sodass für Sentinel eingespeiste Daten auch als rohe Protokolle in Log Analytics abfragbar sind

KQL-Grundlagen

Kusto Query Language (KQL) ist die Abfragesprache für Log Analytics. Sie liest von links nach rechts mit Pipe-Operatoren und ist auch ohne SQL-Erfahrung lesbar. Nützliche Abfragen für Berliner Kleinunternehmen:

Alle fehlgeschlagenen Anmeldeversuche von außerhalb Deutschlands in den letzten 24 Stunden:

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != "0"
| where Location !startswith "DE"
| summarize FailedAttempts = count() by UserPrincipalName, Location, IPAddress
| order by FailedAttempts desc

Key Vault-Geheimniszugriffsereignisse der letzten 7 Tage:

KeyVaultLogs
| where TimeGenerated > ago(7d)
| where OperationName == "SecretGet"
| project TimeGenerated, CallerIPAddress, identity_claim_upn_s, ResultSignature
| order by TimeGenerated desc

Azure-Aktivitätsprotokoll – wer hat heute Ressourcen gelöscht oder verändert:

AzureActivity
| where TimeGenerated > ago(24h)
| where ActivityStatus == "Success"
| where OperationNameValue contains "delete" or OperationNameValue contains "write"
| project TimeGenerated, Caller, OperationNameValue, ResourceGroup, Resource
| order by TimeGenerated desc

Alarmregeln

Azure Monitor-Alarmregeln lösen aus, wenn ein Metrikschwellenwert überschritten wird oder wenn eine KQL-Abfrage Ergebnisse zurückgibt. Wesentliche Alarmregeln für jede Azure-Umgebung:

Alarm	Bedingung	Schweregrad
VM-CPU kritisch	CPU-Prozentsatz > 95% für 10 Minuten	1
VM-Festplattenspeicher niedrig	Verfügbarer Festplattenspeicher < 10%	1
SQL-DTU-Grenze nähert sich	DTU-Verbrauch > 85% für 15 Minuten	2
App Service 5xx-Fehler	Http5xx > 10 in 5 Minuten	1
Key Vault-Drosselung	ServiceApiThrottled > 0	2
Azure-Aktivität: Ressourcenlöschung	KQL-Abfrage: AzureActivity mit Лöschen + Erfolg	2
VM-Agent-Heartbeat verloren	Heartbeat-Abwesenheit für 5 Minuten	1

Workbooks: Operative Dashboards

Azure Monitor-Workbooks sind parametrisierte Dashboards, die aus KQL-Abfragen und Metrikdiagrammen aufgebaut sind. Microsoft stellt integrierte Workbooks für gängige Szenarien bereit: VM-Leistung, Azure AD-Anmeldeanalyse, Speicherkontoübersicht, SQL-Leistung. Benutzerdefinierte Workbooks können mehrere Datenquellen kombinieren – Metriken von einer VM, Protokolle einer Anwendung, Entra-Anmeldedaten – zu einer einzigen operativen Ansicht, die sich automatisch aktualisiert.

Diagnoseeinstellungen: Protokollerfassung aktivieren

Azure-Ressourcen senden standardmäßig keine Protokolle an einen Arbeitsbereich – jede Ressource benötigt eine Diagnoseeinstellung, die festlegt, welche Protokollkategorien wohin gesendet werden. Die wichtigsten Ressourcen für Diagnoseeinstellungen:

• Azure Key Vault: AuditEvent-Protokolle aktivieren (alle Geheimnis-/Schlüssel-/Zertifikatzugriffsereignisse)
• Azure SQL: SQLSecurityAuditEvents und SQLInsights aktivieren
• Azure App Service: AppServiceHTTPLogs und AppServiceConsoleLogs aktivieren
• Netzwerksicherheitsgruppen: NetworkSecurityGroupEvent aktivieren (NSG-Regel-Treffer)
• Entra ID: SigninLogs und AuditLogs über das Diagnoseeinstellungen-Blatt im Entra Admin Center konfigurieren

Kostenmanagement

Protokolleinspeisungskosten können unkontrolliert wachsen, wenn alle Diagnoseprotokollkategorien für alle Ressourcen aktiviert werden. Kostenoptimierungsstrategien: Nur sicherheitsrelevante Protokollkategorien aktivieren, ein tägliches Datenlimit für den Arbeitsbereich setzen, Archivtarif für Protokolle älter als 30 Tage verwenden und ausführliche rauscharme Tabellen mit niedrigem Wert aus der Einspeisung ausschließen.

Einrichtungsschritte für Berliner Kleinunternehmen

1. Azure-Portal → Log Analytics-Arbeitsbereiche → Erstellen → Deutschland West Central für Datenspeicherort auswählen → gleiche Ressourcengruppe wie Ihr primärer Workload wählen
2. Arbeitsbereichsaufbewahrung einstellen: Arbeitsbereich → Nutzung und geschätzte Kosten → Datenaufbewahrung → auf 90 Tage setzen
3. Diagnoseeinstellungen für Key Vault, SQL, App Service und NSGs konfigurieren: Jede Ressource → Diagnoseeinstellungen → Hinzufügen → an den Arbeitsbereich senden
4. VMs verbinden: Azure Monitor → Virtuelle Maschinen → Azure Monitor-Agent aktivieren und Data Collection Rule konfigurieren
5. Entra ID-Protokollexport konfigurieren: Entra Admin Center → Überwachung → Diagnoseeinstellungen → Einstellung hinzufügen → SigninLogs und AuditLogs an den Arbeitsbereich senden
6. Erste Alarmregel erstellen: Arbeitsbereich → Alarme → Erstellen → Protokollsuchalarm → KQL-Abfrage für fehlgeschlagene Authentifizierungen → Aktionsgruppe, die E-Mail an die Sicherheitsleitung sendet
7. Relevante integrierte Workbooks prüfen und bereitstellen: Azure Monitor → Workbooks → öffentliche Vorlagen → VM-Leistungs- und Azure AD-Workbooks bereitstellen

Der für Azure Monitor erstellte Log Analytics-Arbeitsbereich ist derselbe Arbeitsbereich, den Microsoft Sentinel verwendet – die Aktivierung von Sentinel auf dem Arbeitsbereich erweitert ihn um SIEM-Erkennungsregeln und Incident-Management ohne zusätzliche Datenkosten, da bereits für das operative Monitoring eingespeiste Protokolle für die Sicherheitserkennung wiederverwendet werden.