Kubernetes überwachen? Container Insights und Managed Prometheus aktivieren

Für Kubernetes brauchst du Messwerte und Kontext. Managed Prometheus erfasst Zeitreihen wie Pod-Zustand und Ressourcenverbrauch. Container Insights bietet Clusteransichten und sammelt Containerlogs und Ereignisse. Die Ausgabe eines Containers hilft zu erklären, was rund um eine Metrikänderung passiert ist.

Verwende law-ctmonitorweu aus Log Analytics konfigurieren. Dieses Lab erstellt einen AKS-Cluster, den du im nächsten Grafana-Trip wiederverwendest. Prüfe die Kostenschätzung: Auch mit kostenloser Control Plane kosten Worker-VMs, Datenträger, Netzwerk und Monitoring-Nutzung Geld. Du brauchst Berechtigungen zum Erstellen von Ressourcen und Zuweisen von Rollen.

Cluster erstellen und Ziele wählen

Erstelle im Azure-Portal einen Azure Monitor workspace namens amw-ctmonitorweu, in rg-cloudtrips-monitor-test-weu, West Europe. Er speichert Prometheus-Metriken. Der vorhandene Log Analytics workspace law-ctmonitorweu speichert Logs. Das sind unterschiedliche Ressourcentypen mit unterschiedlichen Abfragesprachen: PromQL für Prometheus und KQL für Logs.

Erstelle unter Kubernetes service → Kubernetes cluster:

Resource group: rg-cloudtrips-monitor-aks-test-weu
Cluster name: aks-ctmonitorweu
Region: West Europe
Cluster preset: Dev/Test
Pricing tier: Free
Kubernetes version: aktuell unterstützter Standardwert
System node pool: Linux, Standard_D4s_v5 oder verfügbare unterstützte Größe mit 4 vCPUs
Node count: 2, manuelle Skalierung
Authentication/authorization: Microsoft Entra ID with Azure RBAC
Cluster identity: System-assigned managed identity
API server: Public access
Network configuration: Azure CNI Overlay
Outbound type: Load balancer

Verwende für die übrigen Felder die unterstützten Portalstandardwerte. Halte diesen Lab-Cluster getrennt von produktiven Clustern. Öffne auf Monitoring bei Bedarf Advanced settings:

Prometheus metrics: Enabled
Azure Monitor workspace: amw-ctmonitorweu
Container logs and events / Container Insights: Enabled
Log Analytics workspace: law-ctmonitorweu
Logging profile: Standard
Grafana: zunächst nicht auswählen

Bei einem bestehenden Cluster findest du diese Auswahl unter Monitor → Monitor Settings. Speichere und warte auf die erfolgreiche Bereitstellung. Standard-Logging erfasst stdout des Lab-Containers. Bei einer eigenen Konfiguration müssen monitor-demo, stdout und die Tabelle ContainerLogV2 enthalten sein.

Screenshot 1: Cluster-Monitoring-Einstellungen mit beiden aktivierten Erfassungen und ihren Workspaces.

Kleine Workload starten

Weise deinem Benutzer unter aks-ctmonitorweu → Access control (IAM) die Rolle Azure Kubernetes Service RBAC Cluster Admin für diesen dedizierten Lab-Cluster zu. Warte auf die Übernahme der Rolle. Lade monitor-demo.yaml herunter.

Öffne Azure Cloud Shell → Bash und lade die Datei über Upload hoch. Cloud Shell stellt CLI und Kubernetes-Werkzeuge bereit. Führe aus:

az account set --subscription 'CloudTrips TEST'
az aks get-credentials --resource-group rg-cloudtrips-monitor-aks-test-weu --name aks-ctmonitorweu
kubelogin convert-kubeconfig -l azurecli
kubectl config current-context
kubectl apply -f monitor-demo.yaml
kubectl rollout status deployment/monitor-heartbeat -n monitor-demo --timeout=180s
kubectl logs deployment/monitor-heartbeat -n monitor-demo --tail=5

Prüfe vor dem Anwenden, dass der Kontext aks-ctmonitorweu ist. Die Datei erstellt einen Namespace und einen kleinen Container, der alle 30 Sekunden einen Zeitstempel ausgibt. Wird der Zugriff verweigert, prüfe die RBAC-Rolle am Cluster und warte auf ihre Übernahme.

Logs und Metriken prüfen

Öffne Monitor / Insights des Clusters und suche monitor-heartbeat in der Workload- oder Controlleransicht. Öffne nach einigen Minuten law-ctmonitorweu → Logs und führe aus:

ContainerLogV2
| where TimeGenerated > ago(1h)
| where PodNamespace == "monitor-demo"
| project TimeGenerated, PodName, ContainerName, LogMessage
| order by TimeGenerated desc

Screenshot 2: ContainerLogV2-Ergebnisse mit Heartbeat-Meldungen und Pod-Name.

Öffne amw-ctmonitorweu → Prometheus explorer oder die Seite Metrics mit PromQL-Editor und führe aus:

up

Wähle Last 30 minutes. Jede Zeitreihe steht für ein Scrape-Ziel: 1 bedeutet, dass dessen letzter Scrape erfolgreich war; 0 bedeutet einen fehlgeschlagenen Scrape. Damit bestätigst du die Metrikerfassung. Der Heartbeat-Container schreibt Logs und nutzt die integrierten Kubernetes-Metriken des Clusters; für diese Übung braucht er keinen eigenen Prometheus-Endpunkt.

Screenshot 3: Prometheus-Abfrage mit Scrape-Zeitreihen des Clusters.

Bei leerem Ergebnis prüfst du zuerst den Workspace, danach Monitoring-Einstellungen und Aufnahmeverzögerung. Für Logs prüfst du zusätzlich, ob der Pod läuft und stdout erfasst wird. Ein erfolgreicher Prometheus-Scrape und eine gesunde Anwendung sind getrennte Prüfungen.

Abschluss

Lass den Cluster nur laufen, wenn du direkt mit dem Grafana-Trip weitermachst. Andernfalls lösche rg-cloudtrips-monitor-aks-test-weu; AKS entfernt beim Löschen des Clusters auch seine verwalteten Node-Ressourcen. Behalte die gemeinsamen Workspaces für andere Übungen. Bleibt der Cluster bestehen und du möchtest nur das Demo entfernen, führe kubectl delete namespace monitor-demo aus.