Azure Monitoring für VMs, AKS, App Service und Azure SQL
Erfassen Sie Azure-Monitor-Metriken aus allen Subscriptions ohne Agent, ergänzen Sie Host- und Kubernetes-Daten per Obseria Agent und verfolgen Sie Requests mit OpenTelemetry durchgängig.
Warum Azure mit Obseria überwachen
Eine Sicht über alle Subscriptions
Verbinden Sie Subscriptions über einen Service Principal mit Leserechten und sehen Sie VMs, AKS, App Service, Functions und Datenbanken nebeneinander.
Von der Plattformmetrik zum Code
Korrelieren Sie Azure-Monitor-Metriken mit OpenTelemetry-Traces und Logs, damit ein Anstieg bei Http5xx direkt zur fehlerhaften Abhängigkeit führt.
Kubernetes-Tiefe auf AKS
Betreiben Sie den Obseria Agent als DaemonSet und erhalten Sie Node-, Pod- und Container-Daten, die Plattformmetriken allein nicht liefern.
Azure-Services, die Obseria überwacht
- Azure Virtual Machines und Scale Sets. CPU, verfügbarer Speicher, Disk und Netzwerk pro VM, mit dem Obseria Agent zusätzlich Prozesse und Logs.
- Azure Kubernetes Service (AKS). Zustand von Nodes und Pods aus den AKS-Plattformmetriken, ergänzt um Container-Daten des Obseria Agent.
- Azure App Service. Requests, Antwortzeit, HTTP 4xx/5xx und Instanzzustand für Web-Apps und APIs.
- Azure Functions. Ausführungen, Fehler und Execution Units pro Function App, mit Traces für jeden Aufruf.
- Azure SQL Database. CPU, DTU- oder vCore-Verbrauch, Speicher, Verbindungen und Deadlocks pro Datenbank.
- Azure Monitor und Activity Log. Plattformmetriken jedes Ressourcentyps sowie Ressourcenänderungen und Service-Health-Ereignisse.
Die Azure-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Zustand der virtuellen Maschinen
Zeigt, ob Ihre virtuellen Maschinen genug Rechenleistung und Arbeitsspeicher haben, damit Geschäftsanwendungen reibungslos laufen.
Stabilität der Container-Plattform
Macht sichtbar, ob Ihre Container-Plattform noch Reserven hat und alle Teile Ihrer Anwendungen einsatzbereit sind.
Erlebnis in Web-Apps
Zeigt, wie schnell Ihre Web-Apps antworten, wie oft Nutzer Fehler sehen und wie stark Hintergrundfunktionen ausgelastet sind.
Auslastung der Datenbanken
Zeigt, ob Ihre Datenbanken unter Druck stehen oder sich gegenseitig blockieren, was Bestellungen und Berichte bremsen kann.
Alle 9 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
Microsoft.Compute/virtualMachines Percentage CPU | Percent | Genutzte CPU der VM; erster Indikator für Skalierung oder Rightsizing. |
Microsoft.Compute/virtualMachines Available Memory Bytes | Bytes | Speicher, der Prozessen auf der VM sofort zur Verfügung steht. |
Microsoft.ContainerService/managedClusters node_cpu_usage_percentage | Percent | Aggregierte CPU-Nutzung pro AKS-Node. |
Microsoft.ContainerService/managedClusters kube_pod_status_ready | Count | Anzahl der Pods im Zustand Ready; ein Rückgang zeigt fehlerhafte Workloads. |
Microsoft.Web/sites Http5xx | Count | Serverfehler, die eine App-Service-App zurückgibt. |
Microsoft.Web/sites HttpResponseTime | Seconds | Zeit, die die App zur Beantwortung von Requests benötigt. |
Microsoft.Web/sites FunctionExecutionCount | Count | Ausführungen pro Function App, die Basis für Durchsatz und Fehlerquote. |
Microsoft.Sql/servers/databases cpu_percent | Percent | CPU-Verbrauch der Datenbank im Verhältnis zu ihrem Limit. |
Microsoft.Sql/servers/databases deadlock | Count | In der Datenbank erkannte Deadlocks. |
Azure-Monitoring in wenigen Minuten einrichten
- Schritt 1
Service Principal mit Leserechten anlegen
Registrieren Sie einen Service Principal in Microsoft Entra ID und weisen Sie die Rolle Monitoring Reader sowie Reader für die Ressourcenerkennung auf Subscription- oder Management-Group-Ebene zu.
- Schritt 2
Subscriptions in Obseria verbinden
Tragen Sie Tenant-ID, Client-ID und Secret ein, wählen Sie Subscriptions und Ressourcentypen, und Azure-Monitor-Metriken fließen agentenlos ein.
- Schritt 3
Agent und OpenTelemetry ergänzen
Installieren Sie den Obseria Agent auf VMs oder per Helm auf AKS und konfigurieren Sie OpenTelemetry SDKs mit Ihrem OTLP-Endpunkt für Traces.
# Service Principal mit Leserechten auf Subscription-Ebene
az ad sp create-for-rbac \
--name obseria-reader \
--role "Monitoring Reader" \
--scopes "/subscriptions/${SUBSCRIPTION_ID}"
# Ressourcen- und Tag-Erkennung erlauben (appId aus der Ausgabe oben)
az role assignment create \
--assignee "${OBSERIA_APP_ID}" \
--role "Reader" \
--scope "/subscriptions/${SUBSCRIPTION_ID}"Sofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- Azure-Subscription-Übersicht nach Ressourcengruppe
- Zustand von VMs und Scale Sets mit Rightsizing-Hinweisen
- AKS: Cluster-, Node- und Pod-Zustand
- Alerts für Fehlerraten von App Service und Functions
- Azure-SQL-Performance und Deadlock-Alerts
Azure-Monitoring: Darauf kommt es an
Warum Azure Monitoring eine einheitliche Sicht braucht
Azure Monitoring beginnt meist mit Azure Monitor, das Plattformmetriken für nahezu jeden Ressourcentyp sammelt. Es ist die maßgebliche Quelle für das, was die Azure-Plattform sieht. Eine Produktionsanwendung besteht aber selten aus einer einzigen Ressource. Typisch sind App Service oder AKS, einige Function Apps, Azure SQL, ein Storage Account und ein Service-Bus-Namespace, oft verteilt über mehrere Subscriptions verschiedener Teams.
Wenn etwas ausfällt, müssen Ihre Engineers wissen, welcher Teil zuerst versagt hat und warum. Azure Observability heißt, Plattformmetriken, Application Traces, Logs und Änderungsereignisse an einem Ort zusammenzuführen, verknüpft über Ressourcen-IDs und Tags. So wird der Weg vom Symptom zur Ursache kurz und hängt nicht davon ab, das richtige Blade im Portal zu kennen.
Die Azure-Metriken, auf die es ankommt
Konzentrieren Sie sich auf die Golden Signals pro Schicht und erklären Sie sie mit Ressourcenmetriken:
- Virtuelle Maschinen:
Percentage CPU,Available Memory Bytes, Disk-Operationen und Netzwerkdurchsatz. Details auf Gastebene wie CPU pro Prozess liefert der Obseria Agent. - AKS:
node_cpu_usage_percentage, Working Set des Node-Speichers,kube_pod_status_readyund Node Conditions, dazu Container-Restarts und OOM Kills aus dem Agent. - App Service:
Requests,HttpResponseTime,Http5xxundHttp4xxsowie CPU und Speicher der Instanzen im App Service Plan. - Azure Functions:
FunctionExecutionCountund Execution Units im Consumption Plan, ergänzt um Fehler und Dauer aus Traces. - Azure SQL Database:
cpu_percent,dtu_consumption_percentoder vCore-Nutzung,storage_percent,connection_failedunddeadlock.
Typische Azure-Probleme und wie Sie sie erkennen
Ausgelasteter App Service Plan. Mehrere Apps teilen sich einen Plan. Verbraucht eine App die CPU des Plans, steigen die Antwortzeiten aller Apps. Der Vergleich von HttpResponseTime pro App mit der CPU des Plans zeigt, wer der laute Nachbar ist.
Gedrosselte Datenbanken. Erreicht Azure SQL sein DTU- oder vCore-Limit, stauen sich Abfragen und die Latenz steigt. Dauerhaft hohe Werte bei cpu_percent oder dtu_consumption_percent zusammen mit langsamen Datenbank-Spans in Traces bestätigen eine Drosselung statt eines Anwendungsfehlers.
Cold Starts und Timeouts in Functions. Functions im Consumption Plan, die von null skalieren, verzögern die ersten Requests. Traces zeigen den Cold Start als Teil jedes Aufrufs, sodass Sie entscheiden können, ob sich ein Premium Plan oder vorgewärmte Instanzen lohnen.
Druck auf AKS-Nodes. Verdrängte oder nie bereite Pods deuten oft auf Speicherdruck oder erschöpfte Node Pools hin. Node Conditions, Pod-Readiness und Kubernetes-Events zusammen zeigen, ob Sie den Pool skalieren oder Requests und Limits anpassen sollten.
Konfigurationsänderungen. Viele Incidents folgen auf eine Änderung: einen Slot Swap, einen verkleinerten Plan oder eine geänderte Netzwerkregel. Activity-Log-Ereignisse auf derselben Zeitachse wie die Metriken machen diese Änderungen sichtbar.
Best Practices für Azure Monitoring
- Nutzen Sie einheitliche Tags und Konventionen für Ressourcengruppen, damit sich Dashboards und Alerts nach Team, Service und Umgebung eingrenzen lassen.
- Verbinden Sie jede Subscription, auch außerhalb der Produktion, über einen Service Principal mit Leserechten oder eine Zuweisung auf Management-Group-Ebene.
- Alarmieren Sie auf nutzerrelevante Symptome wie Fehlerrate und Antwortzeit und nutzen Sie Ressourcen-Alerts für die Kapazitätsplanung.
- Instrumentieren Sie .NET-, Java-, Node.js- und Python-Apps mit OpenTelemetry, damit Traces die Grenzen zwischen App Service, Functions und AKS überspannen.
- Erfassen Sie Änderungen und Deployments neben den Metriken, um die Zeit bis zur Ursache zu verkürzen.
So überwacht Obseria Azure
Obseria verbindet sich agentenlos über einen Service Principal mit Leserechten und erfasst Azure-Monitor-Metriken und Ressourcen-Metadaten für VMs, AKS, App Service, Functions, Azure SQL und viele weitere Services, als Teil von 300+ Cloud-Services über AWS, Azure und Google Cloud. Der Obseria Agent ergänzt Daten auf Gast- und Kubernetes-Ebene, OpenTelemetry-Traces und Logs kommen per OTLP an. Obseria TopoGraph erstellt die Abhängigkeitskarte automatisch, und Obseria Intelligence untersucht Incidents darauf aufbauend mit einer nachvollziehbaren Beweiskette. Dashboards, Alerts und SLOs sind enthalten, und Ihre Daten können in der EU-Region bleiben.
Verwandte Integrationen
Passende Funktionen
Cloud Monitoring
Überwachen Sie über 300 Cloud-Services agentenlos und sehen Sie, wie sie Ihre Anwendungen beeinflussen. Eine Plattform für Multi-Cloud-Metriken, Logs, Traces und Topologie.
Mehr erfahrenKubernetes Monitoring
Sehen Sie jeden Cluster, Node, Pod und Workload im Kontext. Obseria verknüpft Metriken, Events, Logs und Traces, damit Sie die Ursache eines fehlerhaften Rollouts in Minuten finden.
Mehr erfahrenServerless Monitoring
Verfolgen Sie jede Invocation über Functions, Queues und APIs hinweg. Obseria zeigt Cold Starts, Fehler, Laufzeit und Kosten Ihrer Serverless-Workloads im Kontext des Gesamtsystems.
Mehr erfahrenMehr erfahren
Was ist Observability?
Was ist Observability? Wie Metriken, Logs, Traces und Profile Ihre Systeme verständlich machen und was Observability vom Monitoring unterscheidet.
Die vier Golden Signals: Latenz, Traffic, Fehler und Sättigung
Die vier Golden Signals erklärt: Latenz, Traffic, Fehler und Sättigung, der Bezug zu RED- und USE-Methode und die Messung mit OpenTelemetry.
Häufige Fragen zum Azure-Monitoring
Obseria liest Plattformmetriken aus Azure Monitor und kombiniert sie mit Traces, Logs und Daten aus anderen Clouds. Viele Teams behalten Azure Monitor als Quelle und nutzen Obseria für serviceübergreifende Analyse, Alerting und Root Cause.
Rollen mit Leserechten genügen: Monitoring Reader für Metriken und Reader für die Ressourcen- und Tag-Erkennung, zugewiesen auf Subscription- oder Management-Group-Ebene.
AKS-Plattformmetriken werden agentenlos erfasst. Für Details zu Nodes, Pods und Containern installieren Sie den Obseria Agent per Helm Chart als DaemonSet oder senden Daten aus einem OpenTelemetry Collector.
Ja. Nutzen Sie das OpenTelemetry SDK Ihrer Sprache und setzen Sie OTEL_SERVICE_NAME und OTEL_EXPORTER_OTLP_ENDPOINT in den App-Einstellungen. Traces verknüpfen dann Funktionsaufrufe und Web-Requests mit nachgelagerten Aufrufen.
Ja. Sie wählen die EU-Region (Frankfurt, Dublin), die UK-Region (London) oder Ihr eigenes Cloud-Konto (BYOC).
Starten Sie heute mit dem Azure-Monitoring
Binden Sie Azure in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.