Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Zur Unterstützung der Erfahrung zum Anzeigen betroffener Ressourcen umfasst Service Health Features für folgende Aufgaben:
- Zeigen Sie Ressourcen an, die aufgrund eines geplanten Wartungsereignisses betroffen sind.
- Bereitstellen von Informationen zu betroffenen Ressourcen für geplante Wartung über das Service Health-Portal.
In diesem Artikel wird beschrieben, was Benutzer*innen mitgeteilt wird und wo sie Informationen zu ihren betroffenen Ressourcen anzeigen können.
Anzeigen betroffener Ressourcen für geplante Wartungsereignisse im Service Health-Portal
Im Azure-Portal werden auf der Registerkarte Betroffene Ressourcen unter Service Health>Geplante Wartung Ressourcen angezeigt, die von einem geplanten Wartungsereignis betroffen sind. Das folgende Beispiel der Registerkarte „Betroffene Ressourcen“ zeigt ein geplantes Wartungsereignis mit betroffenen Ressourcen.
Service Health enthält die folgenden Informationen zu Ressourcen, die von einem geplanten Wartungsereignis betroffen sind:
| Felder | Beschreibung |
|---|---|
| Ressourcenname | Der Name der Ressource, die von dem geplanten Wartungsereignis betroffen ist. |
| Ressourcentyp | Der Vom geplanten Wartungsereignis betroffene Ressourcentyp. |
| Ressourcengruppe | Die Gruppe "Ressource", die die betroffene Ressource enthält. |
| Region | Die Region, die die betroffene Ressource enthält. |
| Abonnement-ID | Die eindeutige ID für das Abonnement, das die betroffene Ressource enthält. |
| Aktion(*) | Ein Link zur Seite „Angewendetes Update“ während des Self-Service-Zeitfensters (nur für neugestartete Updates für Computeressourcen) |
| Fälligkeitsdatum der Self-Service-Wartung(*) | Das Fälligkeitsdatum für das Fenster Self-Service, wenn der Benutzer das Update anwendet (nur für neustartpflichtige Updates auf Rechnerressourcen). |
Hinweis
Felder mit einem Sternchen * sind optionale Felder, die je nach Ressourcentyp verfügbar sind.
Filtern der Ergebnisse
Kunden können die Ergebnisse mithilfe dieser Filter filtern:
- Region: Die Region, in der sich die betroffene Ressource befindet.
- Abonnement-ID: Alle Abonnement-IDs, auf die der Benutzer Zugriff hat.
- Ressourcentyp: Alle Ressourcentypen unter den Benutzerabonnements.
In eine CSV-Datei exportieren
Die Liste der betroffenen Ressourcen kann in eine Excel-Datei exportiert werden, indem Sie auf diese Option klicken.
Die CSV-Datei enthält die Eigenschaften, die den einzelnen Ereignissen zugeordnet sind, und weitere Details pro Ereignisebene. Diese Datei kann als statischer Zeitpunkt für alle aktiven Ereignisse unter der Ansicht Service Health>Geplante Wartung verwendet werden.
Diese Details sind eine Teilmenge weiterer Informationen auf Ereignisebene, die über die Dienststatus-API verfügbar sind, die in Event Grid oder andere Ereignisautomatisierungslösungen integriert werden können.
Diese Tabelle enthält eine kurze Beschreibung der einzelnen Spalteneigenschaften.
| Spalteneigenschaften | Beschreibung |
|---|---|
| Titel | Der Titel des veröffentlichten Ereignisses. |
| TrackingId | Ein eindeutiger Bezeichner für jedes Ereignis in verschiedenen Service Health-Kategorien. |
| Betroffene Dienste | Mindestens ein Dienst, für den das veröffentlichte Wartungsereignis gilt. |
| Startzeit der Auswirkung | Die Startzeit in UTC für das Ereignis. Es könnte kleinere Arbeitsfenster oder Zeiträume innerhalb jedes Ereignisses geben, das über die Updatekommunikation freigegeben wird. |
| Endzeit der Auswirkung | Die Endzeit in UTC für das Ereignis. Es könnte kleinere Arbeitsfenster oder Zeiträume innerhalb jedes Ereignisses geben, das über die Updatekommunikation freigegeben wird. |
| Abonnement(s) | Alle SubscriptionIds, die sich im Bereich des veröffentlichten Ereignisses befinden. |
| Geschätzte Auswirkungsdauer* | Geschätzte Zeit in Sekunden für Auswirkungen auf Ressourcenebene. Ein Ereignisfenster kann für einen breiteren Zeitrahmen (z. B. mehrere Stunden oder manchmal sogar Tage) verwendet werden. Dieses Feld zeigt jedoch die geschätzte Auswirkungsdauer innerhalb des geplanten Fensters an. |
| Auswirkungstyp* | Vordefinierte Auswirkungstypen, die bei der Kategorisierung von Ereignissen hilfreich sind, basierend auf der Art und Weise, wie die Auswirkungen auf Dienst- oder Ressourcenebene während des Ereignisfensters beobachtet werden. Weitere Details zu Kategorien finden Sie im folgenden Abschnitt. |
| Empfehlung* | Schritte oder empfohlene Aktionen für Benutzer basierend auf dem Auswirkungstyp. |
Hinweis
Felder mit einem Sternchen (*) sind neu eingeführte Eigenschaften, die für einige Dienste leer sein können, da sie das neue Layout noch nicht übernommen haben.
Felder "Wartungsauswirkungstyp" und "Dauer"
In unserem ständigen Bestreben, die Benachrichtigungen für Geplante Wartung zuverlässiger und vorhersehbarer für Kunden zu machen, haben wir kürzlich drei neue Eigenschaften hinzugefügt, insbesondere im Hinblick auf den Auswirkungsaspekt für das veröffentlichte Ereignis. Diese Eigenschaften sind derzeit über die CSV-Exportoption oder über den Service Health-API-Aufruf verfügbar.
Hinweis
Wir ermöglichen mehr Dienste, diese Felder als Teil der Ereignisveröffentlichung einzuschließen, aber es gibt eine Teilmenge von Diensten, die sich im Prozess des Onboardings befinden, und diese Felder zeigen möglicherweise keinen Wert für ihre Ereignisse.
Auswirkungen auf gehostete Dienste und Endbenutzer
Die Impact Type-Eigenschaft ist der Schlüssel, um diese häufige Sorge zu beantworten. Das Azure Service Health-Portal enthält ein neues Feld "Auswirkungstyp" für Wartungsereignisse, das schnell die erwarteten Auswirkungen während der geplanten Zeit anzeigt.
Wir verfügen über einen vordefinierten Satz von Kategorien, die unterschiedliche Auswirkungssymptome in Azure Services abdecken oder darstellen. Es besteht die Wahrscheinlichkeit, dass sich geringfügige Überschneidungen ergeben, da jeder Dienst seine eindeutigen Kriterien für die Auswirkung gemäß Produktdesign hat.
Diese Tabelle bietet weitere Einblicke in mögliche Werte für die Impact Type-Eigenschaft. Die Beschreibungsspalten zeigen die Zuordnung mit Branchenstandardbegriffen wie Blackout, Brownout und Grayout.
| Kategorie Auswirkungstyp | Beschreibung | Beispiele |
|---|---|---|
| Dienstverfügbarkeit | #Blackout, #Impactful, #ServicePaused, #TempStorageLoss Die Ressource oder der Dienst befindet sich für eine kurze Dauer im angehaltenen Zustand. Ereignisse unter dieser Kategorie können sich vorübergehend auf die allgemeine Ressourcenverfügbarkeit und/oder Benutzerverbindungen auswirken. |
Netzwerk: Möglicherweise verliert der virtuelle Computer (VM) netzwerkkonnektivität und/oder vorhandene Verbindungen werden möglicherweise beendet. Compute (VMs): Temporäres Anhalten oder Einfrieren von virtuellen Kernen (CPU) wirkt sich auf die Reaktionszeiten und Konnektivität der virtuellen Maschine aus. Der Dienstheilungsprozess während der erzwungenen Aktualisierung oder Verschlechterung der Hostintegrität ist ein weiteres häufiges Szenario. Speicher: Vollständige oder temporäre Pause auf Datenträger-IOs (z. B. Treiberupdates oder Speicher-Agent-Updates). SQL: Temporäre Auswirkungen auf SQL-Datenbanken durch erneute Wartungskonfigurierungen, die sich auf die Antwortzeiten der Abfrage auswirken, und kurzer Verlust der Datenbankverbindung. Länger laufende Abfragen können unterbrochen werden und eventuell neu gestartet werden müssen. |
| Leistungsbeeinträchtigung | #Brownout, #ModerateImpact, #Latency, #IntermittentTimeouts, #Slowness, #VMStatePreserved Die Symptome können je nach Dienstleistung oder Produkt variieren. Bei einigen Anwendungen wie SQL Apps können Latenzzeiten oder langsamere Antwortzeiten für Benutzer oder ausgeführte Abfragen deutlicher sein. Die Ressource ist in der Regel in Betrieb, aber mit heruntergestufter oder eingeschränkter Funktionalität. Dies ist für sensible Workloads besonders ausgeprägt. |
Netzwerk: Sichtbare Beeinträchtigung der Konnektivität, die zu zeitweiligen Timeouts oder Trennungen führt. Langsame Reaktionszeiten beim Zugriff auf Datenträgerlaufwerke (z. B. während der Aktualisierung kann die Funktion „Beschleunigter Netzwerkbetrieb“ angehalten werden). Zeitweiliger Paketverlust. Compute (VMs): Live-Migration-Aktivität. Anwendungen oder Benutzer beobachten möglicherweise eine langsamere Verarbeitung. Ein weiteres Szenario ist die NIC-Zurücksetzung, bei der beeinträchtigte Konnektivität für bis zu 9 Sekunden beobachtet werden kann. Speicher: Möglichkeit von heruntergestuften Datenträger-IOPSs. SQL-: Bei DB-Latenzanforderungen können Verzögerungen oder Fehler bei Lese- oder Schreibvorgängen auftreten. |
| Netzwerkkonnektivität | #Grayout, #ModerateImpact, #ConnectionTimeouts, #RetriesSucceed Moderate Benutzerauswirkungen, wenn sich die Ereignisse auf den Netzwerkstapel beziehen. Die Auswirkungsdauer ist kürzer, da redundante Ebenen pro Architekturdesign integriert sind, wodurch die Gesamtauswirkung minimiert wird. Diese Timeouts können ereignisse im Zusammenhang mit T0-, T1-, NIC- oder NMAgent-Upgrades und/oder regionalen oder zonenbezogenen Netzwerkkabeln und -switches sein. |
Netzwerk: Vorhandene Verbindungen funktionieren weiterhin, aber neue Verbindungen können nicht hergestellt werden (dies kann z. B. bei VFP-Updates geschehen). Ein Teil der ToR (Top of Rack)-Gerätewartung fällt in diese Kategorie. |
| Ressource nicht verfügbar | #Impactful, #Reboot, #Restart, #Redeploy, #Shutdown, #NoConnectivity, #Downtime Ein Ereignis mit einer relativ langen Dauer von Ressourcenausfallzeiten (z. B. für VMs > 30 Sekunden). Der Dienst oder die Ressource ist für Benutzer und/oder Anwendungen möglicherweise nicht verfügbar. Mit neueren Plattformdesigninnovationen wird die Häufigkeit der Ereignisse in dieser Kategorie drastisch reduziert. |
Compute: Reboot oder Neustart des VMs. Daten im temporären Speicher können verlorengehen. Vorgänge wie Neustart, erneute Bereitstellung, Beenden/Starten eines virtuellen Computers sind häufige Beispiele für dieses Szenario. Das Initiieren der kontrollierten Wartung für VMs fällt in diese Kategorie, da sie eine erneute Bereitstellung darstellt. |
| Datenverfügbarkeit | #Grayout, #Failover#ModerateImpact, #ConnectionTimeouts, #QueryTimeouts, #RetriesSucceed Gilt für die SQL-Suite von Apps. Die Auswirkungen auf Benutzer sind minimal und werden nur während des Failovers bemerkt. |
SQL: Wartungsereignisse können je nach der Konstellation der primären und sekundären Replikate zu Beginn des Wartungsereignisses eine einzelne oder mehrere Neukonfiguration(en) oder Failover erzeugen. Die durchschnittliche Auswirkungsdauer beträgt einige Sekunden. Wenn sie bereits verbunden ist, muss Ihre Anwendung erneut eine Verbindung herstellen, und lange ausgeführte Abfragen können unterbrochen werden und möglicherweise neu gestartet werden. |
| Keine Auswirkung erwartet | #NoImpact, #Impactless | Keine spürbaren Auswirkungen. Netzwerk: Beispielsweise verursachen Glasfaserkabelwartungsereignisse in der Regel keine großen Probleme – außer während des kurzen Moments, in dem datenverkehr umgeleitet wird, was dann zu einem geringfügigen, temporären Paketverlust führen kann. Diese Pakete werden jedoch in der Regel erfolgreich wiederholt. |
| Sonstige (Details finden Sie in der Nachricht) | Wenn keine dieser Kategorien direkt zutrifft oder mehr als eine der oben genannten Kategorien zutrifft, würden wir weitere Details in der Nachricht angeben. | Mehr als eine der Auswirkungskategorien trifft zu. |
Auswirkungsdauer
Das Feld „Auswirkungsdauer“ zeigt einen numerischen Wert an, der die Zeit in Sekunden darstellt, die sich das Ereignis auf die aufgelistete Ressource auswirken würde. Je nach Dienstresilienz und Implementierungsentwurf sollte das Feld „Dauer“ in Kombination mit dem Feld „Auswirkungstyp“ dabei helfen, den Gesamtumfang der von den Benutzern zu erwartenden Auswirkungen zu bestimmen.
Ein wichtiger Aspekt, der hervorzuheben ist, ist der Unterschied zwischen der StartTime/EndTime und der Dauer des Ereignisses. Während die Felder auf Ereignisebene, wie z. B. Start-/Endzeiten, das geplante Arbeitsfenster darstellen, stellt das Feld „Auswirkungsdauer“ die tatsächliche Ausfallzeit innerhalb dieses geplanten Arbeitsfensters dar.