Zuverlässigkeitsempfehlungen

Der Azure Advisor hilft Ihnen, die ununterbrochene Verfügbarkeit Ihrer unternehmenskritischen Anwendungen zu gewährleisten und zu verbessern. Sie können Empfehlungen zur Zuverlässigkeit auf der Registerkarte Zuverlässigkeit im Advisor-Dashboard anzeigen.

  1. Melden Sie sich am Azure-Portal an.

  2. Suchen Sie auf einer beliebigen Seite nach dem Eintrag Advisor, und wählen Sie ihn aus.

  3. Wählen Sie im Advisor-Dashboard die Registerkarte Zuverlässigkeit aus.

FarmBeats

Upgrade auf die aktuelle FarmBeats-API-Version

Wir haben Aufrufe einer FarmBeats-API-Version identifiziert, die als veraltet eingestuft werden soll. Es wird empfohlen, zur neuesten FarmBeats-API-Version zu wechseln, um unterbrechungsfreien Zugriff auf FarmBeats, die neuesten Features und Leistungsverbesserungen sicherzustellen.

Weitere Informationen finden Sie unter Azure FarmBeats: FarmBeatsApiVersion (Upgrade auf die aktuelle FarmBeats-API-Version).

API Management

Fehler bei Rotation von Hostnamenzertifikaten

Vom API Management-Dienst konnte das Hostnamenzertifikat aus Key Vault nicht aktualisiert werden. Stellen Sie sicher, dass das Zertifikat in Key Vault vorhanden ist und dass für die Identität des API Management-Diensts der Lesezugriff für Geheimnisse gewährt wurde. Andernfalls kann der API Management-Dienst keine Zertifikatupdates aus Key Vault abrufen. Dies kann dazu führen, dass für den Dienst veraltete Zertifikate verwendet werden und der API-Laufzeitdatenverkehr blockiert wird.

Weitere Informationen finden Sie unter API Management: HostnameCertRotationFail (Fehler bei Rotation von Hostnamenzertifikaten).

SSL-/TLS-Neuverhandlung blockiert

Versuch zur SSL-/TLS-Neuverhandlung blockiert. Eine Neuverhandlung erfolgt, wenn ein Clientzertifikat über eine bereits hergestellte Verbindung angefordert wird. Ist sie blockiert, wird „NULL“ beim Lesen von „context.Request.Certificate“ in Richtlinienausdrücken zurückgegeben. Aktivieren Sie zur Unterstützung von Szenarien zur Clientzertifikatauthentifizierung die Option „Clientzertifikat aushandeln“ für aufgelistete Hostnamen. Bei browserbasierten Clients kann die Aktivierung dieser Option dazu führen, dass dem Client eine Zertifikataufforderung angezeigt wird.

Weitere Informationen finden Sie unter API Management: TlsRenegotiationBlocked (SSL-/TLS-Neuverhandlung blockiert).

App

Erhöhen der minimalen Replikatanzahl für Ihre Container-App

Wir haben festgestellt, dass die minimale Replikatanzahl für Ihre Container-App möglicherweise niedriger als optimal ist. Erwägen Sie, die minimale Replikatanzahl zu erhöhen, um eine bessere Verfügbarkeit zu erzielen.

Weitere Informationen finden Sie unter Ressource: ContainerAppMinimalReplicaCountTooLow (Erhöhen der minimalen Replikatanzahl für Ihre Container-App).

Cache for Redis

Die Verfügbarkeit kann durch eine hohe Speicherfragmentierung beeinträchtigt werden. Erhöhen Sie die fragmentierungsbezogene Speicherreservierung, um mögliche Auswirkungen zu vermeiden.

Fragmentierung und hohe Arbeitsspeicherauslastung können bei Failover- oder Verwaltungsvorgängen zu Verfügbarkeitsproblemen führen. Durch Erhöhen der Speicherreservierung für die Fragmentierung lassen sich Cachefehler bei hoher Arbeitsspeicherauslastung verringern. Der Arbeitsspeicher für die Fragmentierung kann auf dem Blatt mit den erweiterten Einstellungen mithilfe der Einstellung „maxfragmentationmemory-reserved“ erhöht werden.

Weitere Informationen finden Sie unter Redis Cache-Server: RedisCacheMemoryFragmentation (Die Verfügbarkeit kann durch eine hohe Speicherfragmentierung beeinträchtigt werden. Erhöhen Sie die fragmentierungsbezogene Speicherreservierung, um mögliche Auswirkungen zu vermeiden.).

CDN

Umstellen der Geheimnisversion auf „Neueste“ für das Azure Front Door-Kundenzertifikat

Wir empfehlen, die Geheimnisversion des Azure Front Door-Kundenzertifikats auf „Neueste“ festzulegen, damit Azure Front Door auf die neueste Geheimnisversion in Azure Key Vault verweist, sodass das Geheimnis automatisch rotiert werden kann.

Weitere Informationen finden Sie unter Front Door-Profil: SwitchVersionBYOC (Umstellen der Geheimnisversion für das Azure Front Door-Kundenzertifikat auf „Neueste“).

Compute

Aktivieren von Sicherungen auf virtuellen Computern

Aktivieren von Sicherungen für Ihre virtuellen Computer und Schützen Ihrer Daten

Weitere Informationen finden Sie unter VM (klassisch): EnableBackup (Aktivieren von Sicherungen auf VMs).

Die an Ihre Premium-fähige VM angefügten Standard-Datenträger auf Premium-Datenträger aktualisieren

Wir haben ermittelt, dass Sie für Ihre Premium-fähigen virtuellen Computer Standard-Datenträger verwenden. Wir empfehlen Ihnen, ein Upgrade der Standard-Datenträger auf Premium-Datenträger zu erwägen. Wir garantieren für jeden virtuellen Einzelinstanzcomputer, bei dem Storage Premium für alle Betriebssystem-Datenträger und regulären Datenträger verwendet wird, eine Konnektivität von mindestens 99,9 %. Berücksichtigen Sie bei Ihrer Upgrade-Entscheidung die folgenden Faktoren. Erstens: Für ein Upgrade ist ein Neustart der VM erforderlich. Dieser Vorgang dauert drei bis fünf Minuten. Zweitens: Wenn es sich bei den VMs in der Liste um unternehmenskritische VMs für die Produktion handelt, sollten Sie die verbesserte Verfügbarkeit gegen die Kosten für Premium-Datenträger abwägen.

Weitere Informationen finden Sie unter VM: MigrateStandardStorageAccountToPremium (Die an Ihre Premium-fähige VM angefügten Standard-Datenträger auf Premium-Datenträger aktualisieren).

Aktivieren der Replikation von virtuellen Computern zum Schützen Ihrer Anwendungen vor regionalen Ausfällen

Virtuelle Computer, für die die Replikation in eine andere Region nicht aktiviert ist, sind gegenüber regionalen Ausfällen nicht resilient. Durch eine Replikation der Computer werden negative Auswirkungen auf das Geschäft während des Ausfalls einer Azure-Region drastisch reduziert. Wir empfehlen Ihnen dringend, die Replikation aller unternehmenskritischen virtuellen Computer aus der unten angegebenen Liste zu aktivieren, damit Sie Ihre Computer bei einem Ausfall in der Azure-Remoteregion schnell wieder bereitstellen können. Weitere Informationen finden Sie unter VM: ASRUnprotectedVMs (Aktivieren der Replikation von VMs zum Schützen Ihrer Anwendungen vor regionalen Ausfällen).

Upgrade einer VM von nicht verwalteten Premium-Datenträgern auf verwaltete Datenträger ohne zusätzliche Kosten

Wir haben ermittelt, dass für Ihre VM nicht verwaltete Premium-Datenträger genutzt werden, die ohne zusätzliche Kosten zu verwalteten Datenträgern migriert werden können. Azure Managed Disks bietet eine höhere Resilienz, eine vereinfachte Dienstverwaltung, ein höheres Skalierungsziel und eine größere Auswahl von Datenträgertypen. Sie können dieses Upgrade in weniger als fünf Minuten über das Portal durchführen.

Weitere Informationen finden Sie unter VM: UpgradeVMToManagedDisksWithoutAdditionalCost (Upgrade einer VM von nicht verwalteten Premium-Datenträgern auf verwaltete Datenträger ohne zusätzliche Kosten).

Aktualisieren Ihres Protokolls für ausgehende Konnektivität auf Diensttags für Azure Site Recovery

Die Verwendung der auf IP-Adressen basierenden Filterung wurde als potenziell gefährliche Methode zum Steuern der ausgehenden Konnektivität für Firewalls identifiziert. Als Alternative wird die Verwendung von Diensttags zur Steuerung der Konnektivität empfohlen. Wir empfehlen Ihnen dringend, Diensttags zu verwenden, um die Konnektivität mit Azure Site Recovery-Diensten für die Computer zu ermöglichen.

Weitere Informationen finden Sie unter VM: ASRUpdateOutboundConnectivityProtocolToServiceTags (Aktualisieren Ihres Protokolls für ausgehende Konnektivität auf Diensttags für Azure Site Recovery).

Verwenden von Managed Disks zur Erhöhung der Datenzuverlässigkeit

Virtuelle Computer in einer Verfügbarkeitsgruppe mit Datenträgern, die entweder Speicherkonten oder Speicherskalierungseinheiten gemeinsam nutzen, sind nicht resilient gegen Ausfälle einzelner Speicherskalierungseinheiten während eines Ausfalls. Stellen Sie mit einer Migration zu Azure Managed Disks sicher, dass die Datenträger verschiedener virtueller Computer in der Verfügbarkeitsgruppe ausreichend isoliert sind, um einen Single Point of Failure zu vermeiden.

Weitere Informationen finden Sie unter Verfügbarkeitsgruppe: ManagedDisksAvSet (Verwenden von Managed Disks zur Erhöhung der Datenzuverlässigkeit).

Für den virtuellen Check Point-Computer geht ggf. die Netzwerkkonnektivität verloren.

Wir haben ermittelt, dass für Ihren virtuellen Computer ggf. eine Version des Check Point-Images ausgeführt wird, für die das bekannte Problem besteht, dass bei einem Wartungsvorgang für die Plattform die Netzwerkkonnektivität verloren geht. Wir empfehlen Ihnen, ein Upgrade auf eine neuere Version des Images durchzuführen, um dieses Problem zu beheben. Wenden Sie sich an Check Point, um weitere Informationen zum Upgrade Ihres Images zu erhalten.

Weitere Informationen finden Sie unter VM: CheckPointPlatformServicingKnownIssueA (Für die Check Point-VM geht ggf. die Netzwerkkonnektivität verloren.).

Kein Zugriff auf obligatorische URLs für Ihre Azure Virtual Desktop-Umgebung vorhanden

Damit ein Sitzungshost die Bereitstellung und Registrierung für Azure Virtual Desktop richtig durchführen kann, müssen Sie der Zulassungsliste eine Gruppe mit URLs hinzufügen, falls Ihr virtueller Computer in einer eingeschränkten Umgebung ausgeführt wird. Nach dem Klicken auf den Link „Weitere Informationen“ wird die Liste mit den URLs angezeigt, für die Sie die Blockierung mindestens aufheben müssen, damit die Bereitstellung erfolgreich ist und der Sitzungshost funktioniert. Für bestimmte URLs, die in der Zulassungsliste fehlen, können Sie auch im Protokoll mit den Anwendungsereignissen nach Ereignis 3702 suchen.

Weitere Informationen finden Sie unter VM: SessionHostNeedsAssistanceForUrlCheck (Kein Zugriff auf obligatorische URLs für Ihre Azure Virtual Desktop-Umgebung vorhanden).

PostgreSQL

Verbessern der PostgreSQL-Verfügbarkeit durch das Entfernen von inaktiven logischen Replikationsslots

Unsere internen Telemetriedaten zeigen, dass Ihr PostgreSQL-Server ggf. über inaktive logische Replikationsslots verfügt. ERFORDERT SOFORTIGE BEARBEITUNG. Dies kann aufgrund der WAL-Dateiaufbewahrung und Ansammlung von Momentaufnahmedateien zu einer Verschlechterung der Serverleistung und zu Nichtverfügbarkeit führen. Zur Verbesserung der Leistung und Verfügbarkeit empfehlen wir Ihnen DRINGEND Folgendes: Löschen Sie entweder SOFORT die inaktiven Replikationsslots, oder beginnen Sie mit der Nutzung der Änderungen dieser Slots, damit die Protokollfolgenummer (Log Sequence Number, LSN) der Slots erhöht wird und in der Nähe der aktuellen LSN des Servers liegt.

Weitere Informationen finden Sie unter PostgreSQL-Server: OrcasPostgreSqlLogicalReplicationSlots (Verbessern der PostgreSQL-Verfügbarkeit durch das Entfernen von inaktiven logischen Replikationsslots).

Verbessern der PostgreSQL-Verfügbarkeit durch das Entfernen von inaktiven logischen Replikationsslots

Unsere internen Telemetriedaten zeigen, dass Ihr flexibler PostgreSQL-Server ggf. über inaktive logische Replikationsslots verfügt. IN DIESEM ZUAMMENHANG SIND SOFORTIGE MASSNAHMEN ERFORDERLICH. Dies kann aufgrund der WAL-Dateiaufbewahrung und Ansammlung von Momentaufnahmedateien zu einer Verschlechterung der Serverleistung und zu Nichtverfügbarkeit führen. Zur Verbesserung der Leistung und Verfügbarkeit empfehlen wir Ihnen DRINGEND Folgendes: Löschen Sie entweder SOFORT die inaktiven Replikationsslots, oder beginnen Sie mit der Nutzung der Änderungen dieser Slots, damit die Protokollfolgenummer (Log Sequence Number, LSN) der Slots erhöht wird und in der Nähe der aktuellen LSN des Servers liegt.

Weitere Informationen finden Sie unter Flexibler Azure Database for PostgreSQL-Server: OrcasPostgreSqlFlexibleServerLogicalReplicationSlots (Verbessern der PostgreSQL-Verfügbarkeit durch das Entfernen von inaktiven logischen Replikationsslots).

IoT Hub

Upgrade des Geräteclient-SDK auf eine unterstützte Version für IoT Hub

Einige oder alle Ihre Geräte verwenden ein veraltetes SDK, und es wird empfohlen, ein Upgrade auf eine unterstützte Version des SDK durchzuführen. Siehe die Details in der Empfehlung.

Weitere Informationen finden Sie unter IoT-Hub: UpgradeDeviceClientSdk (Upgrade des Geräteclient-SDK auf eine unterstützte Version für IoT Hub).

Azure Cosmos DB

Konfigurieren eines konsistenten Indizierungsmodus für Ihren Azure Cosmos DB-Container

Wir haben festgestellt, dass Ihr Azure Cosmos DB-Container mit dem verzögerten Indizierungsmodus konfiguriert ist. Dadurch wird die Aktualität der Abfrageergebnisse möglicherweise beeinträchtigt. Es wird empfohlen, zum konsistenten Modus zu wechseln.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBLazyIndexing (Konfigurieren eines konsistenten Indizierungsmodus für Ihren Azure Cosmos DB-Container).

Aktualisieren Ihres alten Azure Cosmos DB SDK auf die neueste Version

Ihr Azure Cosmos DB-Konto verwendet eine ältere Version des SDK. Es wird empfohlen, ein Upgrade auf die neueste Version durchzuführen, um aktuelle Fixes, Leistungsverbesserungen und neue Funktionen zu erhalten.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBUpgradeOldSDK (Aktualisieren Ihres alten Azure Cosmos DB SDK auf die neueste Version).

Aktualisieren Ihres veralteten Azure Cosmos DB SDK auf die neueste Version

Für Ihr Azure Cosmos DB-Konto wird eine veraltete Version des SDK verwendet. Es wird empfohlen, ein Upgrade auf die neueste Version durchzuführen, um aktuelle Fixes, Leistungsverbesserungen und neue Funktionen zu erhalten.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBUpgradeOutdatedSDK (Aktualisieren Ihres veralteten Azure Cosmos DB SDK auf die neueste Version).

Konfigurieren Ihres Azure Cosmos DB-Containers mit einem Partitionsschlüssel

Ihre nicht partitionierten Azure Cosmos DB-Sammlungen haben das bereitgestellte Speicherkontingent nahezu erschöpft. Migrieren Sie diese Sammlungen zu neuen Sammlungen mit einer Partitionsschlüsseldefinition, um das automatische Aufskalieren durch den Dienst zu ermöglichen.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBFixedCollections (Konfigurieren Ihres Azure Cosmos DB-Containers mit einem Partitionsschlüssel).

Aktualisieren Ihres Azure Cosmos DB for MongoDB-Kontos auf die Version 4.0, um Abfrage-/Speicherkosten zu sparen und neue Features zu nutzen

Ihr Azure Cosmos DB for MongoDB-Konto kann auf die Version 4.0 aktualisiert werden. Durch ein Upgrade auf v4.0 können Sie Ihre Speicherkosten um bis zu 55 Prozent und Ihre Abfragekosten um bis zu 45 Prozent senken, indem Sie ein neues Speicherformat nutzen. In v4.0 sind darüber hinaus zahlreiche zusätzliche Features wie Transaktionen mit mehreren Dokumenten enthalten.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBMongoSelfServeUpgrade (Aktualisieren Ihres Azure Cosmos DB for MongoDB-Kontos auf die Version 4.0, um Abfrage-/Speicherkosten zu sparen und neue Features zu nutzen).

Hinzufügen einer zweiten Region zu Ihren Produktionsworkloads in Azure Cosmos DB

Wir haben festgestellt, dass die folgenden Azure Cosmos DB-Konten ihren Namen und Konfigurationen nach möglicherweise für Produktionsworkloads verwendet werden. Diese Konten werden zurzeit in einer einzelnen Azure-Region ausgeführt. Sie können ihre Verfügbarkeit erhöhen, indem Sie sie so konfigurieren, dass sie mindestens zwei Azure-Regionen umfassen.

Hinweis

Für zusätzliche Regionen entstehen zusätzliche Kosten.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBSingleRegionProdAccounts (Hinzufügen einer zweiten Region zu Ihren Produktionsworkloads in Azure Cosmos DB).

Aktivieren der serverseitigen Wiederholung für das Azure Cosmos DB for MongoDB-Konto

Wir haben festgestellt, dass Ihr Konto den Fehler TooManyRequests mit dem Code 16500 auslöst. Wenn Sie die serverseitige Wiederholung aktivieren, können Sie dieses Problem beheben.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBMongoServerSideRetries (Aktivieren der serverseitigen Wiederholung für das Azure Cosmos DB for MongoDB-Konto).

Migrieren Ihres Azure Cosmos DB for MongoDB-Kontos zu Version 4.0, um Abfrage-/Speicherkosten zu sparen und neue Features zu nutzen

Migrieren Sie Ihr Datenbankkonto zu einem neuen Datenbankkonto, um von den Vorteilen von Azure Cosmos DB for MongoDB v4.0 zu profitieren. Durch ein Upgrade auf v4.0 können Sie Ihre Speicherkosten um bis zu 55 Prozent und Ihre Abfragekosten um bis zu 45 Prozent senken, indem Sie ein neues Speicherformat nutzen. In v4.0 sind darüber hinaus zahlreiche zusätzliche Features wie Transaktionen mit mehreren Dokumenten enthalten. Bei einem Upgrade müssen Sie auch die Daten in Ihrem vorhandenen Konto zu einem neuen Konto migrieren, das mit Version 4.0 erstellt wurde. Azure Data Factory oder Studio 3T können Sie bei der Migration Ihrer Daten unterstützen.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBMongoMigrationUpgrade (Migrieren Ihres Azure Cosmos DB for MongoDB-Kontos zu Version 4.0, um Abfrage-/Speicherkosten zu sparen und neue Features zu nutzen).

Von Ihrem Azure Cosmos DB-Konto kann nicht auf die verknüpfte Azure Key Vault-Instanz zugegriffen werden, in der Ihr Verschlüsselungsschlüssel gehostet wird.

Anscheinend verhindert die Konfiguration Ihres Schlüsseltresors, dass von Ihrem Azure Cosmos DB-Konto eine Verbindung mit dem Schlüsseltresor hergestellt wird, um den Zugriff auf Ihre verwalteten Verschlüsselungsschlüssel zu ermöglichen. Wenn Sie vor Kurzem eine Schlüsselrotation vorgenommen haben, sollten Sie sicherstellen, dass der vorherige Schlüssel bzw. die Schlüsselversion aktiviert bleibt und so lange verfügbar ist, bis Azure Cosmos DB die Rotation abgeschlossen hat. Der vorherige Schlüssel oder die vorherige Schlüsselversion kann nach 24 Stunden oder dann deaktiviert werden, wenn in den Azure Key Vault-Überwachungsprotokollen keine Aktivitäten mehr von Azure Cosmos DB für diesen Schlüssel oder diese Schlüsselversion angezeigt werden.

Weitere Informationen finden Sie unter Cosmos DB-Konto: CosmosDBKeyVaultWrap (Von Ihrem Cosmos DB-Konto kann nicht auf die verknüpfte Azure Key Vault-Instanz zugegriffen werden, in der Ihr Verschlüsselungsschlüssel gehostet wird.).

Vermeiden eines Ratenlimits bei Metadatenvorgängen

Wir haben eine hohe Anzahl von Metadatenvorgängen in Ihrem Konto festgestellt. Ihre Daten in Azure Cosmos DB, einschließlich der Metadaten zu Ihren Datenbanken und Sammlungen, werden auf verschiedene Partitionen verteilt. Für Metadatenvorgänge gilt ein Limit in Bezug auf vom System reservierte Anforderungseinheiten (Request Units, RUs). Vermeiden Sie ein Ratenlimit für Metadatenvorgänge, indem Sie statische Azure Cosmos DB-Clientinstanzen in Ihrem Code verwenden und die Namen von Datenbanken und Sammlungen zwischenspeichern.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBHighMetadataOperations (Vermeiden eines Ratenlimits bei Metadatenvorgängen).

Verwenden Sie den neuen 3.6+-Endpunkt, um eine Verbindung mit dem aktualisierten Azure Cosmos DB for MongoDB-Konto herzustellen.

Wir haben festgestellt, dass einige Ihrer Anwendungen über den Legacyendpunkt 3.2 [accountname].documents.azure.com eine Verbindung mit dem aktualisierten Azure Cosmos DB for MongoDB-Konto herstellen. Verwenden Sie den neuen Endpunkt [accountname].mongo.cosmos.azure.com (oder dessen Entsprechung in Sovereign Clouds, Clouds für Behörden oder eingeschränkten Clouds).

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBMongoNudge36AwayFrom32 (Verwenden Sie den neuen 3.6+-Endpunkt, um eine Verbindung mit dem aktualisierten Azure Cosmos DB for MongoDB-Konto herzustellen).

Führen Sie ein Upgrade auf Version 2.6.14 des Async Java SDK v2 durch, um ein kritisches Problem zu vermeiden, oder auf Java SDK v4, da Async Java SDK v2 als veraltet eingestuft wird.

Version 2.6.13 des Azure Cosmos DB Async Java SDK v2 und früher enthält einen kritischen Fehler, der zu Problemen führt, wenn eine globale logische Sequenznummer (LSN) erreicht wird, die den Wert für die maximal zulässige ganze Zahl überschreitet. Im Dienst ist dies für Sie sichtbar, nachdem während der Lebensdauer eines Azure Cosmos DB-Containers eine große Menge von Transaktionen aufgetreten ist. Hinweis: Dies ist ein kritischer Hotfix für das Async Java SDK v2. Wir empfehlen Ihnen aber dringend, trotzdem die Migration zum Java SDK v4 durchzuführen.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBMaxGlobalLSNReachedV2 (Führen Sie ein Upgrade auf Version 2.6.14 des Async Java SDK v2 durch, um ein kritisches Problem zu vermeiden, oder auf Java SDK v4, da Async Java SDK v2 als veraltet eingestuft wird).

Version 4.15 des Azure Cosmos DB Java SDK v4 und früher enthält einen kritischen Fehler, der zu Problemen führt, wenn eine globale logische Sequenznummer (LSN) erreicht wird, die den Wert für die maximal zulässige ganze Zahl überschreitet. Im Dienst ist dies für Sie sichtbar, nachdem während der Lebensdauer eines Azure Cosmos DB-Containers eine große Menge von Transaktionen aufgetreten ist.

Weitere Informationen finden Sie unter Azure Cosmos DB-Konto – CosmosDBMaxGlobalLSNReachedV4 (Upgraden auf die aktuelle empfohlene Version des Java SDK v4 zur Vermeidung eines kritischen Problems).

Azure Fluid Relay

Aktualisieren Ihrer Azure Fluid Relay-Clientbibliothek

Sie haben vor Kurzem den Azure Fluid Relay-Dienst mit einer alten Clientbibliothek aufgerufen. Ihre Azure Fluid Relay-Clientbibliothek sollte jetzt auf die neueste Version aktualisiert werden, um sicherzustellen, dass Ihre Anwendung funktionsfähig bleibt. Durch das Upgrade erhalten Sie die neuesten Funktionen sowie mehr Leistung und Stabilität. Weitere Informationen zu der zu verwendenden aktuellen Version und zum Upgrade finden Sie im entsprechenden Artikel.

Weitere Informationen finden Sie unter FluidRelay-Server: UpgradeClientLibrary (Aktualisieren Ihrer Azure Fluid Relay-Clientbibliothek).

HDInsight

Einstellung der Unterstützung von Kafka 1.1 für Kafka-Cluster in HDInsight 4.0

Ab dem 1. Juli 2020 können Kunden in HDInsight 4.0 keine neuen Kafka-Cluster mit Kafka 1.1 mehr erstellen. Vorhandene Cluster werden unverändert ohne Unterstützung durch Microsoft ausgeführt. Es empfiehlt sich, in HDInsight 4.0 bis zum 30. Juni 2020 auf Kafka 2.1 umzustellen, um potenzielle System-/Supportunterbrechungen zu vermeiden.

Weitere Informationen finden Sie unter HDInsight-Cluster: KafkaVersionRetirement (Einstellung der Unterstützung von Kafka 1.1 für Kafka-Cluster in HDInsight 4.0).

Einstellung der Unterstützung älterer Spark-Versionen in HDInsight Spark-Clustern

Ab dem 1. Juli 2020 können Kunden keine neuen Spark-Cluster mit Spark 2.1 und 2.2 in HDInsight 3.6 oder mit Spark 2.3 in HDInsight 4.0 mehr erstellen. Vorhandene Cluster werden unverändert ohne Unterstützung durch Microsoft ausgeführt.

Weitere Informationen finden Sie unter HDInsight-Cluster: SparkVersionRetirement (Einstellung der Unterstützung älterer Spark-Versionen in HDInsight Spark-Clustern).

Ermöglichen der Anwendung kritischer Updates auf Ihre HDInsight-Cluster

Vom HDInsight-Dienst wird ein wichtiges zertifikatbezogenes Update auf Ihren Cluster angewendet. Mindestens eine Richtlinie Ihres Abonnements verhindert aber, dass vom HDInsight-Dienst Netzwerkressourcen (Lastenausgleich, Netzwerkschnittstelle und öffentliche IP-Adresse) erstellt oder geändert werden, die Ihren Clustern zugeordnet sind, und dass dieses Update angewendet wird. Ergreifen Sie vor dem 13. Januar 2021 (05:00 PM UTC) entsprechende Maßnahmen, damit der HDInsight-Dienst Netzwerkressourcen (Lastenausgleich, Netzwerkschnittstelle und öffentliche IP-Adresse) erstellen oder ändern kann, die Ihren Clustern zugeordnet sind. Das HDInsight-Team führt die Updates zwischen dem 13. Januar 2021 (05:00 PM UTC) und dem 16. Januar 2021 (05:00 PM UTC) durch. Wenn dieses Update nicht angewendet wird, kann dies dazu führen, dass Ihre Cluster fehlerhaft und nicht mehr verwendbar sind.

Weitere Informationen finden Sie unter HDInsight-Cluster: GCSCertRotation (Ermöglichen der Anwendung kritischer Updates auf Ihre HDInsight-Cluster).

Löschen und Neuerstellen Ihrer HDInsight-Cluster zum Anwenden von kritischen Updates

Der HDInsight-Dienst hat versucht, ein kritisches Zertifikatupdate auf Ihre gesamten ausgeführten Cluster anzuwenden. Aufgrund von benutzerdefinierten Änderungen an der Konfiguration war das Anwenden der Zertifikatupdates für einige Ihrer Cluster aber nicht möglich.

Weitere Informationen finden Sie unter HDInsight-Cluster: GCSCertRotationRound2 (Löschen und Neuerstellen Ihrer HDInsight-Cluster zum Anwenden von kritischen Updates).

Löschen und Neuerstellen Ihrer HDInsight-Cluster zum Anwenden von kritischen Updates

Der HDInsight-Dienst hat versucht, ein kritisches Zertifikatupdate auf Ihre gesamten ausgeführten Cluster anzuwenden. Aufgrund von benutzerdefinierten Änderungen an der Konfiguration war das Anwenden der Zertifikatupdates für einige Ihrer Cluster aber nicht möglich. Löschen und erstellen Sie Ihren Cluster vor dem 25. Januar  2021 neu, um zu verhindern, dass der Cluster fehlerhaft und unbrauchbar wird.

Weitere Informationen finden Sie unter HDInsight-Cluster: GCSCertRotationR3DropRecreate (Löschen und Neuerstellen Ihrer HDInsight-Cluster zum Anwenden von kritischen Updates).

Anwenden von kritischen Updates auf Ihre HDInsight-Cluster

Der HDInsight-Dienst hat versucht, ein kritisches Zertifikatupdate auf Ihre gesamten ausgeführten Cluster anzuwenden. Mindestens eine Richtlinie Ihres Abonnements verhindert aber, dass vom HDInsight-Dienst Netzwerkressourcen (Lastenausgleich, Netzwerkschnittstelle und öffentliche IP-Adresse) erstellt oder geändert werden, die Ihren Clustern zugeordnet sind, und dass dieses Update angewendet wird. Entfernen oder aktualisieren Sie Ihre Richtlinienzuweisung vor dem 21. Januar 2021 (05:00 PM UTC), damit der HDInsight-Dienst Netzwerkressourcen (Lastenausgleich, Netzwerkschnittstelle und öffentliche IP-Adresse) erstellen oder ändern kann, die Ihren Clustern zugeordnet sind. Das HDInsight-Team führt die Updates zwischen dem 21. Januar 2021 (05:00 PM UTC) und dem 23. Januar 2021 (05:00 PM UTC) durch. Zum Überprüfen des Richtlinienupdates können Sie versuchen, Netzwerkressourcen (Lastenausgleich, Netzwerkschnittstelle und öffentliche IP-Adresse) in derselben Ressourcengruppe und demselben Subnetz anzuordnen, in der bzw. dem sich auch Ihr Cluster befindet. Wenn dieses Update nicht angewendet wird, kann dies dazu führen, dass Ihre Cluster fehlerhaft und nicht mehr verwendbar sind. Sie können auch vor dem 25. Januar 2021 das Löschen und Neuerstellen Ihres Clusters durchführen, um zu verhindern, dass der Cluster Fehler aufweist und nicht mehr verwendbar ist. Vom HDInsight-Dienst wird eine weitere Benachrichtigung gesendet, falls das Update nicht auf Ihre Cluster angewendet werden konnte.

Weitere Informationen finden Sie unter HDInsight-Cluster: GCSCertRotationR3PlanPatch (Anwenden von kritischen Updates auf Ihre HDInsight-Cluster).

Aktion erforderlich: Migrieren Sie Ihren HDInsight-Cluster vom Typ A8 - A11 vor dem 1. März 2021

Sie erhalten diesen Hinweis, weil Sie über einen oder mehrere aktive HDInsight-Cluster vom Typ A8, A9, A10 oder A11 verfügen. Die virtuellen Computer (VMs) vom Typ A8 - A11 werden am 1. März 2021 eingestellt. Nach diesem Datum wird die Zuordnung für alle Cluster mit den Typen A8 - A11 aufgehoben. Migrieren Sie Ihre betroffenen Cluster vor diesem Datum zu einer anderen von HDInsight unterstützten VM (https://azure.microsoft.com/pricing/details/hdinsight/). Weitere Details finden Sie unter „Weitere Informationen“, oder wenden Sie sich unter askhdinsight@microsoft.com an uns.

Weitere Informationen finden Sie unter HDInsight-Cluster: VMDeprecation (Aktion erforderlich: Migrieren Sie Ihren HDInsight-Cluster des Typs A8–A11 vor dem 1. März 2021).

Hybrid-Compute

Upgrade auf die aktuelle Version des Azure Connected Machine-Agents

Der Azure Connected Machine-Agent wird in Bezug auf Fehlerbehebungen, Stabilitätsverbesserungen und neue Funktionen regelmäßig aktualisiert. Aktualisieren Sie Ihren Agent auf die aktuelle Version, um für Azure Arc die höchste Benutzerfreundlichkeit zu erzielen.

Weitere Informationen finden Sie unter Computer – Azure Arc: ArcServerAgentVersion (Upgrade auf die aktuelle Version des Azure Connected Machine-Agents).

Kubernetes

Es werden Budgets für die Unterbrechung von Pods empfohlen. Verbessern der Hochverfügbarkeit von Diensten

Weitere Informationen finden Sie unter Kubernetes Service: PodDisruptionBudgetsRecommended (Budgets für die Unterbrechung von Pods empfohlen).

Upgraden auf die neueste Agent-Version von Kubernetes mit Azure Arc-Unterstützung

Führen Sie ein Upgrade auf die neueste Agent-Version durch, um Kubernetes mit Azure Arc-Unterstützung optimal nutzen zu können und von verbesserter Stabilität und neuen Funktionalität zu profitieren.

Weitere Informationen finden Sie unter Kubernetes – Azure Arc: Upgrade auf die K8s-Agent-Version mit Azure Arc-Unterstützung (Upgraden auf die neueste Agent-Version von Kubernetes mit Azure Arc-Unterstützung).

Media Services

Erhöhen Sie Media Services-Kontingente oder -Grenzwerte, um die Dienstkontinuität sicherzustellen.

Die Kontingentgrenzen Ihres Medienkontos werden in Kürze erreicht. Überprüfen Sie die aktuelle Nutzung von Medienobjekten, Richtlinien für Inhaltsschlüssel und Stream-Richtlinien für das Medienkonto. Zur Vermeidung von Dienstunterbrechungen empfiehlt es sich, für die Entitäten, bei denen die Kontingentgrenze früher erreicht wird, eine Erhöhung der Kontingentgrenzen anzufordern. Zur Anforderung einer Erhöhung der Kontingentgrenzen können Sie ein Ticket mit den relevanten Angaben erstellen. Erstellen Sie keine zusätzlichen Azure Media-Konten, um höhere Grenzwerte zu erhalten.

Weitere Informationen finden Sie unter Media Services: AccountQuotaLimit (Erhöhen Sie Media Services-Kontingente oder -Grenzwerte, um die Dienstkontinuität sicherzustellen.).

Netzwerk

Durchführen eines Upgrades Ihrer SKU oder Hinzufügen weiterer Instanzen, um Fehlertoleranz sicherzustellen

Mit der Bereitstellung von mindestens zwei mittelgroßen oder großen Instanzen wird die Geschäftskontinuität bei Ausfällen sichergestellt, zu denen es aufgrund von geplanten oder ungeplanten Wartungsmaßnahmen kommt.

Weitere Informationen finden Sie unter Anwendungsgateway: AppGateway (Durchführen eines Upgrades Ihrer SKU oder Hinzufügen weiterer Instanzen, um Fehlertoleranz sicherzustellen).

Umstellen von Basic-Gateways auf Gateway-SKUs für die Produktion

Die Basic-SKU des VPN-Gateways ist für Entwicklungs- oder Testszenarien konzipiert. Wechseln Sie zu einer SKU für die Produktion, wenn Sie das VPN-Gateway zu Produktionszwecken verwenden. SKUs für die Produktion bieten eine höhere Anzahl von Tunneln, BGP-Unterstützung, Aktiv-Aktiv, kundenspezifische IPsec-/IKE-Richtlinien sowie höhere Stabilität und Verfügbarkeit.

Weitere Informationen finden Sie unter Gateway des virtuellen Netzwerks: BasicVPNGateway (Umstellen von Basic-Gateways auf Gateway-SKUs für die Produktion).

Hinzufügen von mindestens einem weiteren Endpunkt zum Profil, vorzugsweise in einer anderen Azure-Region

Profile sollten mehr als einen Endpunkt umfassen, um bei einem Ausfall eines Endpunkts Verfügbarkeit zu gewährleisten. Außerdem wird empfohlen, Endpunkte in verschiedenen Regionen zu platzieren.

Weitere Informationen finden Sie unter Traffic Manager-Profil: GeneralProfile (Hinzufügen von mindestens einem weiteren Endpunkt zum Profil, vorzugsweise in einer anderen Azure-Region).

Hinzufügen eines für „Alle (Welt)“ konfigurierten Endpunkts

Für das geografische Routing wird Datenverkehr basierend auf definierten Regionen an Endpunkte geleitet. Wenn eine Region ausfällt, ist kein vordefiniertes Failover verfügbar. Durch das Konfigurieren eines Endpunkts mit der regionalen Gruppierung „Alle (Welt)“ für geografische Profile werden „schwarze Löcher“ im Datenverkehr vermieden, und es wird Dienstverfügbarkeit Kunden gewährleistet.

Weitere Informationen finden Sie unter Traffic Manager-Profil: GeographicProfile (Hinzufügen eines für „Alle (Welt)“ konfigurierten Endpunkts).

Hinzufügen eines Endpunkts zu einer anderen Azure-Region oder Verschieben eines Endpunkts in eine andere Azure-Region

Alle diesem Näherungsprofil zugeordneten Endpunkte befinden sich in derselben Region. Für Benutzer aus anderen Regionen führt dies möglicherweise zu einer hohen Latenz bei der Verbindungsherstellung. Das Hinzufügen oder Verschieben eines Endpunkts in eine andere Region verbessert die Gesamtleistung für das Näherungsrouting und bietet höhere Verfügbarkeit, falls alle Endpunkte in einer Region ausfallen.

Weitere Informationen finden Sie unter Traffic Manager-Profil: ProximityProfile (Hinzufügen eines Endpunkts zu einer anderen Azure-Region oder Verschieben eines Endpunkts in eine andere Azure-Region).

Implementieren mehrerer ExpressRoute-Leitungen in Ihrem virtuellen Netzwerk zur Erzielung von standortübergreifender Resilienz

Wir haben ermittelt, dass Ihrem ExpressRoute-Gateway nur eine ExpressRoute-Leitung zugeordnet ist. Verbinden Sie mindestens eine weitere Leitung mit Ihrem Gateway, um die Redundanz und Resilienz des Peeringstandorts sicherzustellen.

Weitere Informationen finden Sie unter Gateway des virtuellen Netzwerks: ExpressRouteGatewayRedundancy (Implementieren mehrerer ExpressRoute-Leitungen in Ihrem virtuellen Netzwerk zur Erzielung von standortübergreifender Resilienz).

Implementieren des ExpressRoute-Monitors im Netzwerkleistungsmonitor zur End-to-End-Überwachung Ihrer ExpressRoute-Leitung

Wir haben ermittelt, dass Ihre ExpressRoute-Leitung vom ExpressRoute-Monitor im Netzwerkleistungsmonitor derzeit nicht überwacht wird. Der ExpressRoute-Monitor verfügt über Funktionen für die End-to-End-Überwachung, z. B.: Verlust, Latenz und Leistung von lokal zu Azure und von Azure zu lokal

Weitere Informationen finden Sie unter Gateway des virtuellen Netzwerks: ExpressRouteGatewayE2EMonitoring (Implementieren des ExpressRoute-Monitors im Netzwerkleistungsmonitor zur End-to-End-Überwachung Ihrer ExpressRoute-Leitung).

Vermeiden der Außerkraftsetzung des Hostnamens zur Sicherstellung der Websiteintegrität

Versuchen Sie, bei der Application Gateway-Konfiguration die Außerkraftsetzung des Hostnamens zu vermeiden. Die Verwendung einer anderen Domäne auf dem Application Gateway-Front-End als die, die für den Zugriff auf das Back-End genutzt wird, kann ggf. zur Beschädigung von Cookies oder Umleitungs-URLs führen. Beachten Sie hierbei Folgendes: Dies gilt unter Umständen nicht in allen Fällen, und bestimmte Kategorien von Back-Ends (z. B. REST-APIs) sind hierfür normalerweise weniger anfällig. Vergewissern Sie sich, dass das Back-End dies verarbeiten kann, oder aktualisieren Sie die Application Gateway-Konfiguration, damit der Hostname für das Back-End nicht überschrieben werden muss. Fügen Sie bei Verwendung von App Service einen benutzerdefinierten Domänennamen an die Web-App an, und vermeiden Sie die Nutzung des Hostnamens *.azurewebsites.net für das Back-End.

Weitere Informationen finden Sie unter Anwendungsgateway: AppGatewayHostOverride (Vermeiden der Außerkraftsetzung des Hostnamens zur Sicherstellung der Websiteintegrität).

Verwenden von ExpressRoute Global Reach, um Ihren Entwurf für die Notfallwiederherstellung zu verbessern

Sie scheinen ExpressRoute-Leitungen an mindestens zwei verschiedenen Standorten gepeert zu haben. Verbinden sie diese mithilfe von ExpressRoute Global Reach miteinander, um den Datenverkehrsfluss zwischen Ihrem lokalen Netzwerk und Azure-Umgebungen weiter zu ermöglichen, wenn eine Leitung die Konnektivität verliert. Sie können Global Reach-Verbindungen zwischen Leitungen an verschiedenen Peeringstandorten innerhalb derselben Stadt oder über Stadtgrenzen hinweg herstellen.

Weitere Informationen finden Sie unter ExpressRoute-Leitung: UseGlobalReachForDR (Verwenden von ExpressRoute Global Reach, um Ihren Entwurf für die Notfallwiederherstellung zu verbessern).

Azure WAF-Regelsatz CRS 3.1/3.2 wurde mit der Sicherheitsrisikoregel für log4j2 aktualisiert

Als Reaktion auf das Log4j2-Sicherheitsrisiko (CVE-2021-44228) wurde der Regelsatz CRS 3.1/3.2 von Azure Web Application Firewall (WAF) auf Ihrer Application Gateway aktualisiert, um zusätzlichen Schutz vor diesem Sicherheitsrisiko zu bieten. Die Regeln sind unter Regel 944240 verfügbar, und für die Aktivierung ist keine Aktion erforderlich.

Weitere Informationen finden Sie unter Anwendungsgateway: AppGwLog4JCVEPatchNotification (Azure WAF-Regelsatz CRS 3.1/3.2 wurde mit der Sicherheitsrisikoregel für log4j2 aktualisiert).

Zusätzlicher Schutz zur Entschärfung des Log4j2-Sicherheitsrisikos (CVE-2021-44228)

Zum Abmildern der Auswirkungen des Log4j2-Sicherheitsrisikos empfehlen wir die folgenden Schritte:

  1. Aktualisieren Sie Log4j2 auf Ihren Back-End-Servern auf Version 2.15.0. Wenn ein Upgrade nicht möglich ist, folgen Sie dem unten angegebenen Anleitungslink zur Systemeigenschaft.
  2. Nutzen Sie WAF Core-Regelsätze (CRS), indem Sie ein Upgrade auf die WAF-SKU durchführen.

Weitere Informationen finden Sie unter Anwendungsgateway: AppGwLog4JCVEGenericNotification (Zusätzlicher Schutz zur Entschärfung des Log4j2-Sicherheitsrisikos (CVE-2021-44228)).

Verwenden eines NAT-Gateways für ausgehende Konnektivität

Verhindern Sie das Risiko von Konnektivitätsausfällen aufgrund der Erschöpfung von SNAT-Ports, indem Sie ein NAT-Gateway für den ausgehenden Datenverkehr Ihrer virtuellen Netzwerke verwenden. NAT-Gateway wird dynamisch skaliert und bietet sichere Verbindungen für den Internet-Datenverkehr.

Weitere Informationen finden Sie unter Virtuelles Netzwerk: natGateway (Verwenden des NAT-Gateways für ausgehende Konnektivität).

Aktivieren von Aktiv/Aktiv-Gateways für Redundanz

In der Aktiv-Aktiv-Konfiguration richten beide Instanzen des VPN-Gateways S2S-VPN-Tunnel zu Ihrem lokalen VPN-Gerät ein. Wenn eine geplante Wartung oder ein ungeplantes Ereignis für eine Gatewayinstanz eintritt, wird der Datenverkehr automatisch auf den anderen aktiven IPsec-Tunnel umgeschaltet.

Weitere Informationen finden Sie unter Gateway des virtuellen Netzwerks: VNetGatewayActiveActive (Aktivieren von Aktiv/Aktiv-Gateways für Redundanz).

Recovery Services

Aktivieren des vorläufigen Löschens für Ihre Recovery Services-Tresore

Mit der Funktion „Vorläufiges Löschen“ können Sie Ihre Sicherungsdaten nach dem Löschen noch eine Zeit lang im Recovery Services-Tresor aufbewahren, sodass Sie die Möglichkeit haben, sie abzurufen, bevor sie endgültig gelöscht werden.

Weitere Informationen finden Sie unter Recovery Services-Tresor: AB-SoftDeleteRsv (Aktivieren des vorläufigen Löschens für Ihre Recovery Services-Tresore).

Aktivieren der regionsübergreifenden Wiederherstellung für Ihren Recovery Services-Tresor

Aktivieren der regionsübergreifenden Wiederherstellung für Ihre georedundanten Tresore

Weitere Informationen finden Sie unter Recovery Services-Tresor: Enable CRR (Aktivieren der regionsübergreifenden Wiederherstellung für Ihren Recovery Services-Tresor).

Das Speicherkontingent von 2 GB wird in Kürze überschritten. Erstellen Sie einen Standard-Suchdienst.

Das Speicherkontingent von 2 GB wird in Kürze überschritten. Erstellen Sie einen Standard-Suchdienst. Indizierungsvorgänge funktionieren nach dem Überschreiten des Speicherkontingents nicht mehr.

Weitere Informationen finden Sie unter Suchdienst: BasicServiceStorageQuota90percent (Das Speicherkontingent von 2 GB wird in Kürze überschritten. Erstellen Sie einen Standard-Suchdienst.).

Das Speicherkontingent von 50 MB wird in Kürze überschritten. Erstellen Sie einen Basic- oder Standard-Suchdienst.

Das Speicherkontingent von 50 MB wird in Kürze überschritten. Erstellen Sie einen Basic- oder Standard-Suchdienst. Indizierungsvorgänge funktionieren nach dem Überschreiten des Speicherkontingents nicht mehr.

Weitere Informationen finden Sie unter Suchdienst: FreeServiceStorageQuota90percent (Das Speicherkontingent von 50 MB wird in Kürze überschritten. Erstellen Sie einen Basic- oder Standard-Suchdienst.).

Ihr verfügbares Speicherkontingent ist nahezu erschöpft. Fügen Sie weitere Partitionen hinzu, wenn Sie mehr Speicher benötigen.

Ihr verfügbares Speicherkontingent ist nahezu erschöpft. Fügen Sie weitere Partitionen hinzu, wenn Sie mehr Speicher benötigen. Nach Überschreitung des Speicherkontingents können weiterhin Abfragen durchgeführt werden. Indizierungsvorgänge sind jedoch nicht mehr möglich.

Weitere Informationen finden Sie unter Suchdienst: StandardServiceStorageQuota90percent (Ihr verfügbares Speicherkontingent ist nahezu erschöpft. Fügen Sie weitere Partitionen hinzu, wenn Sie mehr Speicher benötigen.).

Storage

Aktivieren der Funktion „Vorläufiges Löschen“, um Ihre Blobdaten zu schützen

Nach dem Aktivieren von „Vorläufiges Löschen“ werden gelöschte Daten in den Status „Vorläufig gelöscht“ versetzt und nicht endgültig gelöscht. Wenn Daten überschrieben werden, wird eine vorläufig gelöschte Momentaufnahme generiert, um den Zustand der überschriebenen Daten zu speichern. Sie können den Zeitraum konfigurieren, in dem vorläufig gelöschte Daten noch wiederhergestellt werden können, bevor sie dauerhaft ablaufen.

Weitere Informationen finden Sie unter Speicherkonto: StorageSoftDelete (Aktivieren der Funktion „Vorläufiges Löschen“, um Ihre Blobdaten zu schützen).

Verwenden von verwalteten Datenträgern für Speicherkonten, für die die Kapazitätsgrenze erreicht wird

Wir haben ermittelt, dass Sie nicht verwaltete Datenträger vom Typ „SSD Premium“ in Speicherkonten nutzen, für die in Kürze die Kapazitätsgrenze für Storage Premium erreicht wird. Damit bei Erreichung der Grenze Fehler vermieden werden, empfehlen wir Ihnen die Migration zu verwalteten Datenträgern, für die kein Grenzwert für die Kontokapazität besteht. Sie können diese Migration in weniger als fünf Minuten über das Portal durchführen.

Weitere Informationen finden Sie unter Speicherkonto: StoragePremiumBlobQuotaLimit (Verwenden von verwalteten Datenträgern für Speicherkonten, für die die Kapazitätsgrenze erreicht wird).

Web

Erwägen einer horizontalen Skalierung Ihres App Service-Plans zur Vermeidung einer Erschöpfung der CPU-Kapazität

Für Ihre App wurde in den letzten Tagen eine CPU-Auslastung von >90 % erreicht. Eine hohe CPU-Auslastung kann zu Laufzeitproblemen mit Ihren Apps führen. Eine Lösung besteht darin, Ihre App horizontal hochzuskalieren.

Weitere Informationen finden Sie unter App Service: AppServiceCPUExhaustion (Erwägen einer horizontalen Skalierung Ihres App Service-Plans zur Vermeidung einer Erschöpfung der CPU-Kapazität).

Korrigieren der Sicherungsdatenbank-Einstellungen Ihrer App Service-Ressource

Bei den Sicherungen Ihrer App treten aufgrund einer ungültigen Datenbankkonfiguration ständig Fehler auf. Ausführlichere Informationen finden Sie im Sicherungsverlauf.

Weitere Informationen finden Sie unter App Service: AppServiceFixBackupDatabaseSettings (Korrigieren der Sicherungsdatenbank-Einstellungen Ihrer App Service-Ressource).

Erwägen des zentralen Hochskalierens Ihrer App Service Plan-SKU zur Vermeidung einer Erschöpfung der Arbeitsspeicherkapazität

Der App Service-Plan, der Ihre App enthält, hat einen Wert von >85 % des Arbeitsspeichers erreicht. Ein hoher Arbeitsspeicherverbrauch kann zu Laufzeitproblemen mit Ihren Apps führen. Untersuchen Sie, welche App im App Service-Plan eine Erschöpfung des Arbeitsspeichers bewirkt, und führen Sie bei Bedarf das zentrale Hochskalieren auf einen höheren Plan mit mehr Arbeitsspeicherressourcen durch.

Weitere Informationen finden Sie unter App Service: AppServiceMemoryExhaustion (Erwägen des zentralen Hochskalierens Ihrer App Service Plan-SKU zur Vermeidung einer Erschöpfung der Arbeitsspeicherkapazität).

Zentrales Hochskalieren Ihrer App Service-Ressource zum Entfernen des Kontingentlimits

Ihre App ist Teil eines gemeinsam genutzten App Service-Plans und hat ihr Kontingent mehrere Male erreicht. Sobald ein Kontingent erreicht wurde, kann Ihre Web-App keine eingehenden Anforderungen mehr akzeptieren. Führen Sie zum Entfernen des Kontingentlimits ein Upgrade auf einen Standard-Plan durch.

Weitere Informationen finden Sie unter App Service: AppServiceRemoveQuota (Hochskalieren Ihrer App Service-Ressource zum Entfernen des Kontingentlimits).

Verwenden von Bereitstellungsslots für Ihre App Service-Ressource

Sie haben Ihre Anwendung in der letzten Woche mehrmals bereitgestellt. Mit Bereitstellungsslots können Sie Änderungen verwalten und die Bereitstellungsauswirkungen auf Ihre Web-App für die Produktion verringern.

Weitere Informationen finden Sie unter App Service: AppServiceUseDeploymentSlots (Verwenden von Bereitstellungsslots für Ihre App Service-Ressource).

Korrigieren der Sicherungsspeicher-Einstellungen Ihrer App Service-Ressource

Bei den Sicherungen Ihrer App treten aufgrund von ungültigen Speichereinstellungen ständig Fehler auf. Ausführlichere Informationen finden Sie im Sicherungsverlauf.

Weitere Informationen finden Sie unter App Service: AppServiceFixBackupStorageSettings (Korrigieren der Sicherungsspeicher-Einstellungen Ihrer App Service-Ressource).

Umstellen Ihrer App Service-Ressource auf „Standard“ oder höher und Verwenden von Bereitstellungsslots

Sie haben Ihre Anwendung in der letzten Woche mehrmals bereitgestellt. Mit Bereitstellungsslots können Sie Änderungen verwalten und die Bereitstellungsauswirkungen auf Ihre Web-App für die Produktion verringern.

Weitere Informationen finden Sie unter App Service: AppServiceStandardOrHigher (Umstellen Ihrer App Service-Ressource auf „Standard“ oder höher und Verwenden von Bereitstellungsslots).

Erwägen Sie ein Hochskalieren Ihres App Service-Plans, um die Benutzerfreundlichkeit und Verfügbarkeit zu optimieren.

Erwägen Sie ein Hochskalieren Ihres App Service-Plans auf mindestens zwei Instanzen, um Kaltstartverzögerungen und Dienstunterbrechungen während routinemäßiger Wartung zu vermeiden.

Weitere Informationen finden Sie unter App Service-Plan: AppServiceNumberOfInstances (Erwägen Sie ein Hochskalieren Ihres App Service-Plans, um die Benutzerfreundlichkeit und Verfügbarkeit zu optimieren.).

Erwägen Sie ein Upgrade des Hostingplans für Static Web Apps in diesem Abonnement auf die Standard-SKU.

Die von allen Static Web Apps mit Free-SKU in diesem Abonnement verwendete kombinierte Bandbreite überschreitet das monatliche Limit von 100 GB. Erwägen Sie ein Upgrade dieser Apps auf die Standard-SKU, um eine Drosselung zu vermeiden.

Weitere Informationen finden Sie unter Statische Web-App: StaticWebAppsUpgradeToStandardSKU (Erwägen Sie ein Upgrade des Hostingplans für statische Web-Apps in diesem Abonnement auf die Standard-SKU.).

Anwendungscode sollte korrigiert werden, wenn der Workerprozess aufgrund einer nicht behandelten Ausnahme abgestürzt ist.

Wir haben festgestellt, dass der folgende Thread zu einer nicht behandelten Ausnahme für Ihre App geführt hat, und der Anwendungscode sollte korrigiert werden, um Auswirkungen auf die Anwendungsverfügbarkeit zu verhindern. Es kommt zu einem Absturz, wenn eine Ausnahme in Ihrem Code nicht behandelt wird und den Prozess beendet.

Weitere Informationen finden Sie unter App Service: AppServiceProactiveCrashMonitoring (Anwendungscode sollte korrigiert werden, wenn der Workerprozess aufgrund einer nicht behandelten Ausnahme abgestürzt ist.).

Nächste Schritte

Erfahren Sie mehr über Zuverlässigkeit: Microsoft Azure Well-Architected Framework.