Fehlgeschlagene Bereitstellungen untersuchen? Fehler, Activity Log und Änderungen prüfen

Eine Meldung über eine fehlgeschlagene Bereitstellung umschließt oft einen genaueren inneren Fehler. Deployment history zeigt den Template-Versuch, Activity Log protokolliert Verwaltungsoperationen und deren Aufrufer, und Change Analysis zeigt verfügbare Vorher-/Nachher-Änderungen von Ressourceneigenschaften. Gemeinsam verbinden sie Fehler, Ursache und umliegende Änderungen.

Dieses eigenständige Lab verwendet eine nicht zugeordnete Netzwerksicherheitsgruppe (NSG) und Azure Cloud Shell. Du brauchst dafür keine VM und keinen Log-Analytics-Workspace. Verwende ein Konto, das Ressourcen in deinem Lab-Abonnement erstellen darf.

Eine Ressource vorbereiten

Erstelle im Azure-Portal eine Network security group:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-monitor-deploy-test-weu
Name: nsg-ctdeployweu
Region: West Europe
Tag: labVersion = v1

Ordne sie keinem Subnetz und keiner Netzwerkschnittstelle zu. Prüfe nach der Erstellung Name und Tag. Lade inspect-monitor-nsg.json herunter, öffne Cloud Shell → Bash und lade die Datei über Upload hoch.

Das Template erstellt keine Ressourcen. Sein Output liest eine bestehende NSG anhand ihres Namens. Der Standardname ist absichtlich falsch, damit wir eine fehlgeschlagene Referenz untersuchen können.

az account set --subscription 'CloudTrips TEST'
az deployment group create \
  --resource-group rg-cloudtrips-monitor-deploy-test-weu \
  --name inspect-nsg-failed \
  --mode Incremental \
  --template-file inspect-monitor-nsg.json

Den konkreten Fehler lesen

Erwartet wird ein fehlgeschlagenes Deployment mit Verweis auf nsg-ctdeploy-missing. Öffne Resource group → Deployments → inspect-nsg-failed → Error details. Klappe den Fehler auf, bis du ID und Meldung zur fehlenden Ressource siehst. Der aussagekräftige Code lautet typischerweise ResourceNotFound, teilweise innerhalb eines Fehlers bei der Output-Auswertung.

Eine Output-Auswertung kann fehlschlagen, ohne dass eine fehlgeschlagene Ressourcenerstellung in der Operationsliste steht. Prüfe deshalb auch den Gesamtfehler und Inputs. Vergleiche den übergebenen nsgName mit der tatsächlich vorhandenen Ressource.

Screenshot 1: Fehlerdetails des Deployments mit Name oder Ressourcen-ID der fehlenden NSG.

Öffne Activity log der Ressourcengruppe, wähle Last hour und untersuche die fehlgeschlagene Deployment-Schreiboperation. Prüfe Status, Aufrufer, Zeitstempel und Correlation-ID. JSON-/Ereignisdetails zeigen den Operationskontext. Gleiche lokale Portalzeiten beim Vergleichen mit UTC ab.

Screenshot 2: Activity-Log-Ereignis des fehlgeschlagenen Deployments mit Status, Aufrufer und Correlation-ID.

Korrigieren und überprüfen

Führe in Cloud Shell ein zweites Deployment mit dem tatsächlichen Ressourcennamen aus:

az deployment group create \
  --resource-group rg-cloudtrips-monitor-deploy-test-weu \
  --name inspect-nsg-fixed \
  --mode Incremental \
  --template-file inspect-monitor-nsg.json \
  --parameters nsgName=nsg-ctdeployweu \
  --query properties.provisioningState --output tsv

Erwartet wird Succeeded. Öffne Deployments → inspect-nsg-fixed → Outputs und untersuche inspectedNsg. Die beiden Namen erhalten den fehlgeschlagenen und den korrigierten Versuch für den Vergleich. Prüfe vor einem echten Wiederholungsversuch den ursprünglichen Fehler: Fehlende Ressourcen, unzureichende Quoten, verweigerte Berechtigungen und fehlende regionale Kapazität verlangen unterschiedliche Lösungen.

Eine aktuelle Änderung untersuchen

Öffne nsg-ctdeployweu → Tags, ändere labVersion von v1 auf v2 und speichere. Notiere die Zeit. Suche im Azure-Portal nach Change Analysis, filtere auf die Lab-Ressourcengruppe und den aktuellen Zeitraum und öffne das NSG-Update, sobald es erscheint. Suche in den geänderten Eigenschaften die alten und neuen Tag-Werte.

Ist die Änderung noch nicht sichtbar, warte einige Minuten. Alternativ verwende Azure Resource Graph Explorer mit deinem Abonnement als Scope:

resourcechanges
| extend ChangeTime=todatetime(properties.changeAttributes.timestamp),
         Target=tostring(properties.targetResourceId),
         ChangeType=tostring(properties.changeType)
| where ChangeTime > ago(1d)
| where Target endswith "/networkSecurityGroups/nsg-ctdeployweu"
| project ChangeTime, ChangeType, Target,
          ChangedBy=properties.changeAttributes.changedBy,
          Changes=properties.changes
| order by ChangeTime desc

Klappe Changes des Updates auf und untersuche tags.labVersion. Führe diese Abfrage im Resource Graph Explorer aus; resourcechanges gehört zu Resource Graph.

Screenshot 3: Change Analysis oder Resource-Graph-Ergebnis mit dem Wechsel von labVersion v1 zu v2.

Die Resource-Graph-Änderungshistorie ist 14 Tage verfügbar; Activity Log wird standardmäßig 90 Tage aufbewahrt. Change Analysis erfasst unterstützte Ressourceneigenschaften der Verwaltungsebene. Der verfügbare Datensatz bestimmt, welche alten und neuen Werte du prüfen kannst. Ein fehlgeschlagener Versuch kann im Activity Log stehen, ohne eine Eigenschaft geändert zu haben.

Abschluss

Lösche rg-cloudtrips-monitor-deploy-test-weu, sobald du alle drei Ansichten untersucht hast. Damit entfernst du die dedizierte NSG und die Deployment-Historie dieser Ressourcengruppe. Behalte Monitoring-Workspaces aus anderen Trips nur, solange du sie noch brauchst.