Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Multi-AZ-Beobachtbarkeit
Um eine Availability Zone während eines Ereignisses evakuieren zu können, das auf eine einzelne Availability Zone beschränkt ist, müssen Sie zunächst feststellen können, dass der Fehler tatsächlich auf eine einzelne Availability Zone beschränkt ist. Dies erfordert einen genauen Überblick darüber, wie sich das System in jeder Availability Zone verhält. Viele AWS Dienste bieten out-of-the-box Kennzahlen, die Ihnen betriebliche Einblicke in Ihre Ressourcen geben. Amazon EC2 bietet beispielsweise zahlreiche Metriken wie CPU Auslastung, Lese- und Schreibvorgänge auf der Festplatte sowie ein- und ausgehender Netzwerkverkehr.
Wenn Sie Workloads erstellen, die diese Services nutzen, benötigen Sie jedoch mehr Transparenz als nur diese Standardmetriken. Sie möchten Einblick in das Kundenerlebnis haben, das Ihr Workload bietet. Darüber hinaus müssen Ihre Kennzahlen auf die Availability Zones abgestimmt sein, in denen sie erstellt werden. Dies ist der Einblick, den Sie benötigen, um unterschiedlich beobachtbare Graufehler zu erkennen. Dieses Maß an Transparenz erfordert Instrumentierung.
Die Instrumentierung erfordert das Schreiben von explizitem Code. Dieser Code sollte beispielsweise aufzeichnen, wie lange Aufgaben dauern, zählen, wie viele Elemente erfolgreich waren oder nicht, Metadaten zu den Anfragen sammeln und so weiter. Außerdem müssen Sie im Voraus Schwellenwerte definieren, um zu definieren, was als normal angesehen wird und was nicht. Sie sollten Ziele und verschiedene Schweregrade für Latenz, Verfügbarkeit und Fehleranzahl in Ihrem Workload skizzieren. Der Artikel [Instrumenting Distributed Systems for Operational Visibility](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) bietet eine Reihe von bewährten Methoden in der Amazon Builders' Library.
Metriken sollten sowohl serverseitig als auch clientseitig generiert werden. Eine bewährte Methode zur Generierung von kundenseitigen Kennzahlen und zum besseren Verständnis des Kundenerlebnisses ist die Verwendung von [Canaries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html), einer Software, die Ihre Arbeitslast regelmäßig überprüft und Kennzahlen aufzeichnet.
Neben der Erstellung dieser Kennzahlen müssen Sie auch deren Kontext verstehen. Eine Möglichkeit, dies zu tun, ist die Verwendung von [Dimensionen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension). Dimensionen geben einer Metrik eine eindeutige Identität und helfen zu erklären, was Ihnen die Metriken sagen. Für Metriken, die zur Identifizierung von Fehlern in Ihrem Workload verwendet werden (z. B. Latenz, Verfügbarkeit oder Fehleranzahl), müssen Sie Dimensionen verwenden, die Ihren [Grenzen zur Fehlerisolierung](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) entsprechen.
Wenn Sie beispielsweise einen Webservice in einer Region über mehrere Availability Zones hinweg mit einem [M odel-view-controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) (MVC) -Webframework ausführen, sollten Sie`Region`,, [https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)`Controller``Action`, und `InstanceId` als Dimensionen für Ihre Dimensionssätze verwenden (wenn Sie Microservices verwenden, könnten Sie den Dienstnamen und die HTTP Methode anstelle der Controller- und Aktionsnamen verwenden). Dies liegt daran, dass Sie davon ausgehen, dass verschiedene Arten von Fehlern durch diese Grenzen isoliert werden. Sie würden nicht erwarten, dass ein Fehler im Code Ihres Webdienstes, der die Möglichkeit beeinträchtigt, Produkte aufzulisten, sich auch auf die Startseite auswirkt. Ebenso würden Sie nicht erwarten, dass ein voller EBS Volume auf einer einzelnen EC2 Instanz andere EC2 Instanzen davon abhält, Ihre Webinhalte bereitzustellen. Mithilfe der Dimension Availability Zone ID können Sie die Auswirkungen auf die Availability Zone überall einheitlich identifizieren. AWS-Konten Sie können die Availability Zone ID in Ihren Workloads auf verschiedene Arten finden. Einige Beispiele finden Sie unter. [Anhang A — Abrufen der Availability Zone-ID](appendix-a-getting-the-availability-zone-id.md)
Dieses Dokument verwendet in den Beispielen hauptsächlich Amazon EC2 als Rechenressource, `InstanceId` könnte aber durch eine Container-ID für die Rechenressourcen [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (AmazonECS) und [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/) (AmazonEKS) als Komponenten Ihrer Dimensionen ersetzt werden.
Ihre Kanaren können auch`Controller`,`Action`, und `Region` als Dimensionen in ihren Metriken verwenden`AZ-ID`, wenn Sie zonale Endpunkte für Ihren Workload haben. Richten Sie in diesem Fall Ihre Canaries so aus, dass sie in der Availability Zone laufen, die sie gerade testen. Dadurch wird sichergestellt, dass, wenn sich ein isoliertes Availability Zone-Ereignis auf die Availability Zone auswirkt, in der Ihr Canary läuft, keine Metriken aufgezeichnet werden, die eine andere Availability Zone, die getestet wird, als ungesund erscheinen lassen. [Ihr Canary kann beispielsweise jeden zonalen Endpunkt anhand seiner zonalen Namen auf einen Dienst hinter einem Network Load Balancer (NLB) oder Application Load Balancer (ALB) testen. DNS](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#dns-name)
![\[Diagramm, das einen Canary zeigt, der auf CloudWatch Synthetics läuft, oder eine AWS Lambda Funktion, die jeden zonalen Endpunkt eines testet NLB\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/advanced-multi-az-resilience-patterns/images/canary-testing-for-zonal-impact.png)
Durch die Erstellung von Metriken mit diesen Dimensionen können Sie [ CloudWatch Amazon-Alarme](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) einrichten, die Sie benachrichtigen, wenn innerhalb dieser Grenzen Änderungen der Verfügbarkeit oder Latenz auftreten. Sie können diese Daten auch schnell mithilfe von [Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) analysieren. Um sowohl Metriken als auch Protokolle effizient zu nutzen, CloudWatch bietet Amazon das [eingebettete Metrikformat](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) (EMF), mit dem Sie benutzerdefinierte Metriken in Protokolldaten einbetten können. CloudWatchextrahiert automatisch die benutzerdefinierten Metriken, sodass Sie sie visualisieren und als Alarm auslösen können. AWS bietet mehrere [Client-Bibliotheken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html) für verschiedene Programmiersprachen, die den Einstieg erleichternEMF. Sie können mit AmazonEC2, Amazon ECS EKS [AWS Lambda](https://aws.amazon.com/lambda/), Amazon und lokalen Umgebungen verwendet werden. Da Metriken in Ihre Protokolle eingebettet sind, können Sie [Amazon CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) auch verwenden, um Zeitreihendiagramme zu erstellen, in denen Daten von Mitwirkenden angezeigt werden. In diesem Szenario könnten wir Daten gruppiert nach Dimensionen wie `AZ-ID``InstanceId`, oder `Controller` sowie nach jedem anderen Feld im Protokoll wie `SuccessLatency` oder anzeigen. `HttpResponseCode`
```
{
"_aws": {
"Timestamp": 1634319245221,
"CloudWatchMetrics": [
{
"Namespace": "workloadname/frontend",
"Metrics": [
{ "Name": "2xx", "Unit": "Count" },
{ "Name": "3xx", "Unit": "Count" },
{ "Name": "4xx", "Unit": "Count" },
{ "Name": "5xx", "Unit": "Count" },
{ "Name": "SuccessLatency", "Unit": "Milliseconds" }
],
"Dimensions": [
[ "Controller", "Action", "Region", "AZ-ID", "InstanceId"],
[ "Controller", "Action", "Region", "AZ-ID"],
[ "Controller", "Action", "Region"]
]
}
],
"LogGroupName": "/loggroupname"
},
"CacheRefresh": false,
"Host": "use1-az2-name.example.com",
"SourceIp": "34.230.82.196",
"TraceId": "|e3628548-42e164ee4d1379bf.",
"Path": "/home",
"OneBox": false,
"Controller": "Home",
"Action": "Index",
"Region": "us-east-1",
"AZ-ID": "use1-az2",
"InstanceId": "i-01ab0b7241214d494",
"LogGroupName": "/loggroupname",
"HttpResponseCode": 200,
"2xx": 1,
"3xx": 0,
"4xx": 0,
"5xx": 0,
"SuccessLatency": 20
}
```
Dieses Protokoll hat drei Gruppen von Dimensionen. Sie werden in der Reihenfolge ihrer Granularität von Instanz zu Availability Zone zu Region weitergeleitet (`Controller`und `Action` sind in diesem Beispiel immer enthalten). Sie unterstützen die Erstellung von Alarmen für Ihren gesamten Workload, die darauf hinweisen, wenn eine bestimmte Controller-Aktion in einer einzelnen Instanz, in einer einzelnen Availability Zone oder innerhalb eines Ganzen AWS-Region Auswirkungen hat. Diese Dimensionen werden für die Anzahl der HTTP Antwortmetriken 2xx, 3xx, 4xx und 5xx sowie für die Latenz erfolgreicher Anforderungsmetriken verwendet (wenn die Anfrage fehlschlägt, wird auch eine Metrik für die Latenz fehlgeschlagener Anfragen aufgezeichnet). Das Protokoll zeichnet auch andere Informationen auf, z. B. den HTTP Pfad, die Quell-IP des Anforderers und ob für diese Anfrage der lokale Cache aktualisiert werden musste. Diese Datenpunkte können dann verwendet werden, um die Verfügbarkeit und Latenz der einzelnen Datenpunkte zu berechnen, die der Workload API bereitstellt.
**Ein Hinweis zur Verwendung von HTTP Antwortcodes für Verfügbarkeitsmetriken**
In der Regel können Sie 2xx- und 3xx-Antworten als erfolgreich und 5xx als Fehlschläge betrachten. 4xx-Antwortcodes liegen irgendwo dazwischen. In der Regel werden sie aufgrund eines Client-Fehlers generiert. Vielleicht liegt ein Parameter außerhalb des zulässigen Bereichs, was zu einer [400-Antwort](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes) führt, oder sie fordern etwas an, das nicht existiert, was zu einer 404-Antwort führt. Sie würden diese Antworten nicht mit der Verfügbarkeit Ihres Workloads verrechnen. Dies könnte jedoch auch das Ergebnis eines Fehlers in der Software sein.
Wenn Sie beispielsweise eine strengere Eingabeüberprüfung eingeführt haben, die eine Anfrage ablehnt, die zuvor erfolgreich gewesen wäre, könnte die Antwort von 400 als Rückgang der Verfügbarkeit gewertet werden. Oder vielleicht drosseln Sie den Kunden und geben eine Antwort von 429 zurück. Die Drosselung eines Kunden schützt zwar Ihren Service, um seine Verfügbarkeit aufrechtzuerhalten, aus Sicht des Kunden ist der Service jedoch nicht verfügbar, um seine Anfrage zu bearbeiten. Sie müssen entscheiden, ob 4xx-Antwortcodes Teil Ihrer Verfügbarkeitsberechnung sind oder nicht.
In diesem Abschnitt wurde zwar die Verwendung CloudWatch als Methode zur Erfassung und Analyse von Metriken beschrieben, dies ist jedoch nicht die einzige Lösung, die Sie verwenden können. Sie können sich dafür entscheiden, Metriken auch an Amazon Managed Service for Prometheus und Amazon Managed Grafana, eine Amazon DynamoDB-Tabelle, zu senden oder eine Überwachungslösung eines Drittanbieters zu verwenden. Entscheidend ist, dass die von Ihrem Workload generierten Metriken einen Kontext zu den Grenzen der Fehlerisolierung Ihres Workloads enthalten müssen.
Mit Workloads, die Metriken erzeugen, deren Dimensionen auf die Grenzen der Fehlerisolierung ausgerichtet sind, können Sie eine Beobachtbarkeit einrichten, die isolierte Ausfälle in der Availability Zone erkennt. In den folgenden Abschnitten werden drei sich ergänzende Ansätze zur Erkennung von Ausfällen beschrieben, die auf die Beeinträchtigung einer einzelnen Availability Zone zurückzuführen sind.
**Topics**
+ [Fehlererkennung mit CloudWatch kombinierten Alarmen](failure-detection-with-cloudwatch-composite-alarms.md)
+ [Fehlererkennung mithilfe der Ausreißererkennung](failure-detection-using-outlier-detection.md)
+ [Fehlererkennung bei zonalen Ressourcen einer einzelnen Instanz](failure-detection-of-single-instance-zonal-resources.md)
+ [Übersicht](summary.md)
# Fehlererkennung mit CloudWatch kombinierten Alarmen
Bei CloudWatch Metriken ist jeder Dimensionssatz eine eindeutige Metrik, und Sie können für jede einzelne einen CloudWatch Alarm erstellen. Sie können dann [ CloudWatch zusammengesetzte Amazon-Alarme](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) erstellen, um diese Metriken zu aggregieren.
Um Auswirkungen genau zu erkennen, werden in den Beispielen in diesem paper zwei verschiedene CloudWatch Alarmstrukturen für jede Dimension verwendet, auf die sie den Alarm einstellen. Jeder Alarm verwendet einen **Zeitraum** von einer Minute, was bedeutet, dass die Metrik einmal pro Minute ausgewertet wird. Beim ersten Ansatz werden drei aufeinanderfolgende Datenpunkte für Sicherheitsverletzungen verwendet, indem die **Bewertungszeiträume** und **Datenpunkte auf „Alarm“ auf drei gesetzt** werden, was einer Gesamtauswirkung von drei Minuten entspricht. Beim zweiten Ansatz wird ein „M aus N“ verwendet, wenn 3 beliebige Datenpunkte innerhalb eines Fünf-Minuten-Zeitfensters verletzt werden, indem die **Bewertungszeiträume auf fünf und die **Datenpunkte** auf Alarm** auf drei gesetzt werden. Auf diese Weise kann sowohl ein konstantes Signal als auch ein Signal erkannt werden, das über einen kurzen Zeitraum schwankt. Die hier angegebenen Zeitdauern und die Anzahl der Datenpunkte sind nur ein Vorschlag. Verwenden Sie Werte, die für Ihre Workloads sinnvoll sind.
## Erkennen Sie Auswirkungen in einer einzelnen Availability Zone
Stellen Sie sich anhand dieses Konstrukts einen Workload vor `Controller``Action`, der`InstanceId`,`AZ-ID`, und `Region` als Dimensionen verwendet. Der Workload besteht aus zwei Controllern, Products und Home, und einer Aktion pro Controller, List und Index. Er ist in drei Availability Zones in der `us-east-1` Region tätig. Sie würden in jeder Availability Zone zwei Alarme für die Verfügbarkeit `Controller` und `Action` eine Kombination davon sowie jeweils zwei Alarme für die Latenz einrichten. Anschließend können Sie optional für jede `Controller` `Action` Kombination einen zusammengesetzten Verfügbarkeitsalarm erstellen. Schließlich erstellen Sie einen zusammengesetzten Alarm, der alle Verfügbarkeitsalarme für die Availability Zone zusammenfasst. Dies wird in der folgenden Abbildung für eine einzelne Availability Zone dargestellt`use1-az1`, wobei der optionale zusammengesetzte Alarm für jede `Controller` `Action` Kombination verwendet wird (ähnliche Alarme wären auch für die Availability Zones `use1-az2` und `use1-az3` Availability Zones vorhanden, werden aber der Einfachheit halber nicht dargestellt).
![\[Das Diagramm zeigt eine zusammengesetzte Alarmstruktur für die Verfügbarkeit in use1-az1\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-availability.png)
Sie würden auch eine ähnliche Alarmstruktur für die Latenz erstellen, wie in der nächsten Abbildung dargestellt.
![\[Ein Diagramm, das eine zusammengesetzte Alarmstruktur für die Latenz in zeigt use1-az1\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-latency.png)
Bei den restlichen Zahlen in diesem Abschnitt werden nur die Alarme `az1-availability` und die `az1-latency` zusammengesetzten Alarme auf der obersten Ebene angezeigt. Diese zusammengesetzten Alarme `az1-availability` und informieren Sie darüber`az1-latency`, ob in einer bestimmten Availability Zone für einen Teil Ihrer Workload entweder die Verfügbarkeit unter oder die Latenz über definierte Schwellenwerte steigt. Möglicherweise sollten Sie auch erwägen, den Durchsatz zu messen, um Auswirkungen zu erkennen, die verhindern, dass Ihre Arbeitslast in einer einzelnen Availability Zone bearbeitet wird. Sie können auch Alarme, die auf den von Ihren Kanaren ausgegebenen Messdaten basieren, in diese zusammengesetzten Alarme integrieren. Auf diese Weise wird durch den Alarm eine Warnung ausgelöst, wenn entweder auf der Server- oder der Clientseite Auswirkungen auf die Verfügbarkeit oder Latenz festgestellt werden.
## Stellen Sie sicher, dass die Auswirkungen nicht regional sind
Ein weiterer Satz zusammengesetzter Alarme kann verwendet werden, um sicherzustellen, dass nur ein isoliertes Availability Zone-Ereignis zur Aktivierung des Alarms führt. Dies wird erreicht, indem sichergestellt wird, dass sich ein zusammengesetzter Availability Zone-Alarm im `ALARM` Status befindet, während sich die zusammengesetzten Alarme für die anderen Availability Zones im `OK` Status befinden. Dies führt zu einem zusammengesetzten Alarm pro Availability Zone, die Sie verwenden. Ein Beispiel ist in der folgenden Abbildung dargestellt (denken Sie daran, dass es Alarme für Latenz und Verfügbarkeit in `use1-az2` und`use1-az3`,`az2-latency`,`az2-availability`, und`az3-latency`, gibt`az3-availability`, die der Einfachheit halber nicht abgebildet sind).
![\[Ein Diagramm, das eine zusammengesetzte Alarmstruktur zur Erkennung von Auswirkungen zeigt, die auf eine einzelne AZ isoliert sind\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-impact.png)
## Stellen Sie sicher, dass die Auswirkungen nicht durch eine einzelne Instanz verursacht werden
Eine einzelne Instanz (oder ein kleiner Prozentsatz Ihrer gesamten Flotte) kann unverhältnismäßige Auswirkungen auf die Verfügbarkeits- und Latenzkennzahlen haben, sodass die gesamte Availability Zone als betroffen erscheinen könnte, obwohl dies in Wirklichkeit nicht der Fall ist. Es ist schneller und genauso effektiv, eine einzelne problematische Instanz zu entfernen, als eine Availability Zone zu evakuieren.
Instances und Container werden in der Regel als kurzlebige Ressourcen behandelt und häufig durch Dienste wie ersetzt. [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) Es ist schwierig, jedes Mal, wenn eine neue Instance erstellt wird, einen neuen CloudWatch Alarm zu erstellen (aber mit den [Lifecycle-Hooks von [Amazon EventBridge](https://docs.aws.amazon.com/autoscaling/ec2/userguide/cloud-watch-events.html) oder Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) ist das sicherlich möglich). Stattdessen können Sie [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) verwenden, um die Anzahl der Mitwirkenden an Verfügbarkeits- und Latenzmetriken zu ermitteln.
Beispielsweise können Sie für eine HTTP Webanwendung eine Regel erstellen, um die wichtigsten Mitwirkenden für HTTP 5xx-Antworten in jeder Availability Zone zu ermitteln. Dadurch wird ermittelt, welche Instances zu einem Rückgang der Verfügbarkeit beitragen (unsere oben definierte Verfügbarkeitsmetrik basiert auf dem Vorhandensein von 5xx-Fehlern). Erstellen Sie anhand des EMF Protokollbeispiels eine Regel mit dem Schlüssel von`InstanceId`. Filtern Sie dann das Protokoll nach dem `HttpResponseCode` Feld. Dieses Beispiel ist eine Regel für die `use1-az1` Availability Zone.
```
{
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "$.InstanceId",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"GreaterThan": 499
},
{
"Match": "$.HttpStatusCode",
"LessThan": 600
},
{
"Match": "$.AZ-ID",
"In": ["use1-az1"]
},
],
"Keys": [
"$.InstanceId"
]
},
"LogFormat": "JSON",
"LogGroupNames": [
"/loggroupname"
],
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
}
}
```
CloudWatch Alarme können ebenfalls auf der Grundlage dieser Regeln erstellt werden. Sie können Alarme auf der Grundlage von Contributor Insights-Regeln mithilfe von [metrischer Mathematik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) und der `INSIGHT_RULE_METRIC` Funktion mit der `UniqueContributors` Metrik erstellen. Sie können auch zusätzliche Contributor Insights-Regeln mit CloudWatch Alarmen für Messwerte wie Latenz oder Fehlerzahlen sowie Alarme für die Verfügbarkeit erstellen. Diese Alarme können zusammen mit den kombinierten Alarmen der isolierten Availability Zone verwendet werden, um sicherzustellen, dass einzelne Instanzen den Alarm nicht auslösen. Die Metrik für die Insights-Regel für `use1-az1` könnte wie folgt aussehen:
```
INSIGHT_RULE_METRIC("5xx-errors-use1-az1", "UniqueContributors")
```
Sie können einen Alarm definieren, wenn diese Metrik einen Schwellenwert überschreitet, in diesem Beispiel zwei. Er wird aktiviert, wenn der einzelne Mitwirkende an 5xx-Antworten diesen Schwellenwert überschreitet, was darauf hindeutet, dass die Auswirkungen auf mehr als zwei Instanzen zurückzuführen sind. Dieser Alarm verwendet den Vergleich „Größer als“ statt „Weniger als“, um sicherzustellen, dass ein Nullwert für einzelne Mitwirkende den Alarm nicht auslöst. Dies zeigt Ihnen, dass die Auswirkung *nicht auf eine einzelne Instanz zurückzuführen* ist. Passen Sie diesen Schwellenwert an Ihre individuelle Arbeitslast an. Als allgemeine Richtlinie gilt, dass dieser Wert mindestens 5% der gesamten Ressourcen in der Availability Zone ausmachen sollte. Mehr als 5% Ihrer Ressourcen, die betroffen sind, weisen bei ausreichender Stichprobengröße eine statistische Signifikanz auf.
## Zusammenführung
Die folgende Abbildung zeigt die vollständige zusammengesetzte Alarmstruktur für eine einzelne Availability Zone:
![\[Ein Diagramm, das eine vollständige zusammengesetzte Alarmstruktur zur Bestimmung der Auswirkungen auf einzelne AZs zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-complete.png)
Der letzte zusammengesetzte Alarm,, wird aktiviert`use1-az1-isolated-impact`, wenn der zusammengesetzte Alarm, der auf die Auswirkungen der isolierten Availability Zone aufgrund von Latenz oder Verfügbarkeit hinweist`use1-az1-aggregate-alarm`, sich im `ALARM` Status befindet und wenn der Alarm, der auf der Contributor Insights-Regel für dieselbe Availability Zone basiert`not-single-instance-use1-az1`, ebenfalls im `ALARM` Status ist (was bedeutet, dass es sich bei der Auswirkung um mehr als eine einzelne Instanz handelt). Sie würden diesen Alarm-Stapel für jede Availability Zone erstellen, die Ihr Workload verwendet.
Sie können diesem letzten Alarm eine [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (AmazonSNS) -Warnung hinzufügen. Alle vorherigen Alarme wurden ohne Aktion konfiguriert. Die Warnung könnte einen Bediener per E-Mail benachrichtigen, um eine manuelle Untersuchung einzuleiten. Es könnte auch eine Automatisierung zur Evakuierung der Availability Zone einleiten. Ein Wort der Vorsicht ist jedoch bei der Gebäudeautomatisierung geboten, um auf diese Warnmeldungen zu reagieren. Nach einer Evakuierung der Availability Zone sollte das Ergebnis sein, dass die erhöhten Fehlerquoten verringert werden und der Alarm wieder in einen Zustand übergeht. `OK` Wenn es in einer anderen Availability Zone zu Auswirkungen kommt, ist es möglich, dass durch die Automatisierung eine zweite oder dritte Availability Zone evakuiert wird, wodurch möglicherweise die gesamte verfügbare Kapazität des Workloads entfernt wird. Die Automatisierung sollte überprüfen, ob bereits eine Evakuierung durchgeführt wurde, bevor Maßnahmen ergriffen werden. Möglicherweise müssen Sie auch Ressourcen in anderen Availability Zones skalieren, bevor eine Evakuierung erfolgreich ist.
Wenn Sie Ihrer MVC Web-App neue Controller oder Aktionen oder einen neuen Microservice oder generell zusätzliche Funktionen hinzufügen, die Sie separat überwachen möchten, müssen Sie in diesem Setup nur einige Alarme ändern. Sie erstellen neue Verfügbarkeits- und Latenzalarme für diese neue Funktionalität und fügen diese dann den entsprechenden zusammengesetzten Verfügbarkeits- und Latenzalarmen hinzu, `az1-latency` wie `az1-availability` in dem Beispiel, das wir hier verwendet haben. Die übrigen zusammengesetzten Alarme bleiben statisch, nachdem sie konfiguriert wurden. Dies macht die Einführung neuer Funktionen mit diesem Ansatz zu einem einfacheren Prozess.
# Fehlererkennung mithilfe der Ausreißererkennung
Eine Lücke zum vorherigen Ansatz könnte entstehen, wenn Sie erhöhte Fehlerraten in mehreren Availability Zones feststellen, die aus einem *unkorrelierten* Grund auftreten. Stellen Sie sich ein Szenario vor, in dem Sie EC2 Instances in drei Availability Zones bereitgestellt haben und Ihr Schwellenwert für den Verfügbarkeitsalarm bei 99% liegt. Dann kommt es zu einer Beeinträchtigung einer einzelnen Availability Zone, wodurch viele Instanzen isoliert werden und die Verfügbarkeit in dieser Zone auf 55% sinkt. Gleichzeitig, aber in einer anderen Availability Zone, verbraucht eine einzelne EC2 Instanz den gesamten Speicherplatz auf ihrem EBS Volume und kann keine Protokolldateien mehr schreiben. Dadurch gibt sie zwar Fehler zurück, besteht aber trotzdem die Integritätsprüfungen des Load Balancers, da diese das Schreiben einer Protokolldatei nicht auslösen. Dies führt dazu, dass die Verfügbarkeit in dieser Availability Zone auf 98% sinkt. In diesem Fall würde Ihr einzelner Availability Zone-Auswirkungsalarm nicht aktiviert werden, da Sie eine Beeinträchtigung der Verfügbarkeit in mehreren Availability Zones feststellen. Sie könnten jedoch trotzdem fast alle Auswirkungen abmildern, indem Sie die beeinträchtigte Availability Zone evakuieren.
Bei einigen Arten von Workloads können in allen Availability Zones konsistent Fehler auftreten, bei denen die vorherige Verfügbarkeitsmetrik möglicherweise nicht hilfreich ist. Nehmen wir AWS Lambda zum Beispiel. AWS ermöglicht es Kunden, ihren eigenen Code für die Ausführung in der Lambda-Funktion zu erstellen. Um den Dienst nutzen zu können, müssen Sie Ihren Code einschließlich Abhängigkeiten in eine ZIP Datei hochladen und den Einstiegspunkt für die Funktion definieren. Aber manchmal verstehen Kunden diesen Teil falsch, weil sie beispielsweise eine kritische Abhängigkeit in der ZIP Datei vergessen oder den Methodennamen in der Lambda-Funktionsdefinition falsch eingeben. Dies führt dazu, dass die Funktion nicht aufgerufen werden kann, was zu einem Fehler führt. AWS Lambda sieht ständig solche Fehler, aber sie deuten nicht darauf hin, dass etwas unbedingt ungesund ist. Eine Beeinträchtigung der Availability Zone kann jedoch auch dazu führen, dass diese Fehler auftreten.
Um ein Signal in dieser Art von Rauschen zu finden, können Sie mithilfe der Ausreißererkennung feststellen, ob die Anzahl der Fehler zwischen den Availability Zones statistisch signifikant schwankt. Wir sehen zwar Fehler in mehreren Availability Zones, aber wenn es wirklich in einer Availability Zone zu einem Ausfall kommen sollte, würden wir davon ausgehen, dass die Fehlerrate in dieser Availability Zone im Vergleich zu den anderen deutlich höher oder möglicherweise deutlich niedriger ist. Aber um wie viel höher oder niedriger?
Eine Möglichkeit, diese Analyse durchzuführen, besteht darin, einen [Chi-Quadrat-Test](https://en.wikipedia.org/wiki/Chi-squared_test) (*x* 2) zu verwenden, um statistisch signifikante Unterschiede in den Fehlerraten zwischen Availability Zones zu erkennen (es gibt [viele verschiedene Algorithmen für](https://dataprocessing.aixcape.org/DataPreprocessing/DataCleaning/OutlierDetection/index.html) die Erkennung von Ausreißern). Schauen wir uns an, wie der Chi-Quadrat-Test funktioniert.
Ein Chi-Quadrat-Test bewertet die Wahrscheinlichkeit, dass eine Verteilung der Ergebnisse wahrscheinlich ist. In diesem Fall interessiert uns die Verteilung der Fehler auf eine bestimmte Gruppe von. AZs Betrachten Sie für dieses Beispiel vier Availability Zones, um die Mathematik zu vereinfachen.
Stellen Sie zunächst die *Nullhypothese* auf, die definiert, was Ihrer Meinung nach das Standardergebnis ist. In diesem Test geht die Nullhypothese davon aus, dass Sie erwarten, dass Fehler gleichmäßig auf jede Availability Zone verteilt werden. Generieren Sie dann die *alternative Hypothese*, dass die Fehler nicht gleichmäßig verteilt sind, was auf eine Beeinträchtigung der Availability Zone hindeutet. Jetzt können Sie diese Hypothesen anhand von Daten aus Ihren Metriken testen. Zu diesem Zweck testen Sie Ihre Metriken in einem Fünf-Minuten-Fenster. Angenommen, Sie erhalten 1000 veröffentlichte Datenpunkte in diesem Fenster, in dem Sie insgesamt 100 Fehler sehen. Sie gehen davon aus, dass bei einer gleichmäßigen Verteilung die Fehler in jeder der vier Availability Zones in 25% der Fälle auftreten würden. Nehmen wir an, die folgende Tabelle zeigt, was Sie erwartet haben, verglichen mit dem, was Sie tatsächlich gesehen haben.
*Tabelle 1: Erwartete und tatsächlich festgestellte Fehler im Vergleich*
| AZ | Expected | Tatsächliche |
| --- | --- | --- |
| use1-az1 | 25 | 20 |
| use1-az2 | 25 | 20 |
| use1-az3 | 25 | 25 |
| use1-az4 | 25 | 35 |
Sie sehen also, dass die Verteilung in Wirklichkeit nicht gleichmäßig ist. Sie könnten jedoch glauben, dass dies auf einen gewissen Grad an Zufälligkeit der von Ihnen untersuchten Datenpunkte zurückzuführen ist. Es besteht eine gewisse Wahrscheinlichkeit, dass ein solcher Verteilungstyp im Stichprobensatz vorkommt, und trotzdem wird davon ausgegangen, dass die Nullhypothese wahr ist. Dies führt zu der folgenden Frage: Wie hoch ist die Wahrscheinlichkeit, ein mindestens so extremes Ergebnis zu erzielen? Wenn diese Wahrscheinlichkeit unter einem definierten Schwellenwert liegt, lehnen Sie die Nullhypothese ab. Um [https://en.wikipedia.org/wiki/Statistical_significance](https://en.wikipedia.org/wiki/Statistical_significance) zu sein, sollte diese Wahrscheinlichkeit 5% oder weniger betragen. 1
1 Craparo, Robert M. (2007). „Signifikanzniveau“. In Salkind, Neil J. Enzyklopädie für Messung und Statistik 3. Thousand Oaks, CA: SAGE Veröffentlichungen. S. 889—891. ISBN1-412-91611-9.
Wie berechnet man die Wahrscheinlichkeit dieses Ergebnisses? Sie verwenden die *x/2-Statistik*, die sehr gut untersuchte Verteilungen liefert und anhand dieser Formel die Wahrscheinlichkeit bestimmt werden kann, dass ein so extremes oder extremeres Ergebnis erzielt wird.
![\[Formeln für Ei, O und X i 2\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas1.png)
In unserem Beispiel ergibt das:
![\[Formeln für E ii, O und X 2 verwenden unser Beispiel, was zu einer Antwort von 6 führt.\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas2.png)
Also, was `6` bedeutet das in Bezug auf unsere Wahrscheinlichkeit? Sie müssen sich eine Chi-Quadrat-Verteilung mit dem entsprechenden Freiheitsgrad ansehen. Die folgende Abbildung zeigt mehrere Chi-Quadrat-Verteilungen für unterschiedliche Freiheitsgrade.
![\[Grafik mit Chi-Quadrat-Verteilungen für verschiedene Freiheitsgrade\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/advanced-multi-az-resilience-patterns/images/chi-squared-distributions.png)
Der Freiheitsgrad wird berechnet, wenn er um eins kleiner ist als die Anzahl der Auswahlmöglichkeiten im Test. In diesem Fall beträgt der Freiheitsgrad drei, da es vier Availability Zones gibt. Dann möchten Sie die Fläche unter der Kurve (das Integral) für *x ≥ 6* im Diagramm *k = 3* ermitteln. Sie können diesen Wert auch anhand einer vorberechneten Tabelle mit häufig verwendeten Werten approximieren.
*Tabelle 2: Kritische Werte im Chi-Quadrat*
| Freiheitsgrade | Wahrscheinlichkeit geringer als der kritische Wert | | **0,75** | **0,90** | **0,95** | **0,99** | **0,999** |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | 1,323 | 2,706 | 3,841 | 6,635 | 10,828 |
| 2 | 2,773 | 4,605 | 5,991 | 9,210 | 13,816 |
| 3 | 4,108 | 6,251 | 7,815 | 11,345 | 16,266 |
| 4 | 5,385 | 7,779 | 9,488 | 13,277 | 18,467 |
Bei drei Freiheitsgraden liegt der Chi-Quadrat-Wert von sechs zwischen den Wahrscheinlichkeitsspalten 0,75 und 0,9. Das bedeutet, dass die Wahrscheinlichkeit, dass diese Verteilung eintritt, bei über 10% liegt, was nicht weniger als der Schwellenwert von 5% ist. Daher akzeptieren Sie die *Nullhypothese und stellen* fest, dass es *keinen* statistisch signifikanten Unterschied bei den Fehlerraten zwischen den Availability Zones gibt.
Die Durchführung eines Chi-Quadrat-Statistiktests wird in der CloudWatch metrischen Mathematik nicht nativ unterstützt. Daher müssen Sie die entsprechenden Fehlermetriken in einer Rechenumgebung wie Lambda sammeln CloudWatch und den Test in einer Rechenumgebung ausführen. Sie können sich dafür entscheiden, diesen Test auf MVC Controller-/Aktionsebene oder individueller Microservice-Ebene oder auf Availability Zone-Ebene durchzuführen. Sie müssen abwägen, ob sich eine Beeinträchtigung der Availability Zone auf jeden Controller/jede Aktion oder jeden Microservice gleichermaßen auswirken würde, oder ob ein DNS Ausfall Auswirkungen auf einen Dienst mit geringem Durchsatz haben könnte und nicht auf einen Dienst mit hohem Durchsatz, der die Auswirkungen in aggregierter Form maskieren könnte. Wählen Sie in beiden Fällen die entsprechenden Dimensionen aus, um die Abfrage zu erstellen. Der Grad der Granularität wirkt sich auch auf die resultierenden CloudWatch Alarme aus, die Sie erstellen.
Erfassen Sie die Metrik zur Fehleranzahl für jede AZ und jeden Controller/jede Aktion in einem bestimmten Zeitfenster. Berechnen Sie zunächst, ob das Ergebnis des Chi-Quadrat-Tests entweder wahr (es gab eine statistisch signifikante Verzerrung) oder falsch (es gab keinen, das heißt, die Nullhypothese gilt). Wenn das Ergebnis falsch ist, veröffentlichen Sie einen Datenpunkt von 0 in Ihrem Metrik-Stream für Chi-Quadrat-Ergebnisse für jede Availability Zone. Wenn das Ergebnis wahr ist, veröffentlichen Sie einen 1-Datenpunkt für die Availability Zone mit den Fehlern, die am weitesten vom erwarteten Wert entfernt sind, und eine 0 für die anderen (Beispielcode, der in einer Lambda-Funktion verwendet werden kann, finden Sie unter). [Anhang B — Beispiel für eine Chi-Quadrat-Berechnung](appendix-b-example-chi-squared-calculation.md) Sie können den gleichen Ansatz wie bei den vorherigen Verfügbarkeitsalarmen verfolgen, indem Sie einen CloudWatch metrischen Alarm 3 in einer Reihe und einen CloudWatch metrischen Alarm 3 von 5 basierend auf den Datenpunkten erstellen, die von der Lambda-Funktion erzeugt werden. Wie in den vorherigen Beispielen kann dieser Ansatz so geändert werden, dass mehr oder weniger Datenpunkte in einem kürzeren oder längeren Fenster verwendet werden.
Fügen Sie diese Alarme dann zu Ihrem bestehenden Availability Zone-Verfügbarkeitsalarm für die Kombination aus Controller und Aktion hinzu, wie in der folgenden Abbildung dargestellt.
![\[Diagramm, das die Integration des Chi-Quadrat-Statistiktests mit zusammengesetzten Alarmen zeigt\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/advanced-multi-az-resilience-patterns/images/statistics-test-with-composite-alarms.png)
Wie bereits erwähnt, müssen Sie, wenn Sie neue Funktionen in Ihren Workload integrieren, nur die entsprechenden CloudWatch metrischen Alarme erstellen, die für diese neue Funktion spezifisch sind, und die nächste Stufe in der zusammengesetzten Alarm-Hierarchie aktualisieren, um diese Alarme einzubeziehen. Der Rest der Alarmstruktur bleibt statisch.
# Fehlererkennung bei zonalen Ressourcen einer einzelnen Instanz
In einigen Fällen verfügen Sie möglicherweise über eine einzelne aktive Instanz einer zonalen Ressource, in den meisten Fällen Systeme, die eine Einzelschreiber-Komponente wie eine relationale Datenbank (wie AmazonRDS) oder einen verteilten Cache (wie [Amazon ElastiCache (OSSRedis](https://aws.amazon.com/elasticache/redis/))) benötigen. Wenn sich eine Beeinträchtigung einer einzelnen Availability Zone auf die Availability Zone auswirkt, in der sich die primäre Ressource befindet, kann dies Auswirkungen auf jede Availability Zone haben, die auf die Ressource zugreift. Dies könnte dazu führen, dass Verfügbarkeitsschwellenwerte in jeder Availability Zone überschritten werden, was bedeutet, dass beim ersten Ansatz die einzelne Availability Zone, von der die Auswirkungen ausgehen, nicht korrekt identifiziert werden würde. Darüber hinaus würden Sie wahrscheinlich in jeder Availability Zone ähnliche Fehlerraten feststellen, was bedeutet, dass das Problem auch bei der Ausreißeranalyse nicht erkannt werden würde. Das bedeutet, dass Sie zusätzliche Beobachtbarkeit implementieren müssen, um dieses Szenario gezielt zu erkennen.
Es ist wahrscheinlich, dass die Ressource, um die Sie sich Sorgen machen, ihre eigenen Messwerte über ihren Zustand erstellt, aber während einer Beeinträchtigung der Availability Zone ist diese Ressource möglicherweise nicht in der Lage, diese Metriken zu liefern. In diesem Szenario sollten Sie Alarme erstellen oder aktualisieren, um zu wissen, wann Sie im *Blindflug* sind. Wenn es wichtige Messwerte gibt, die Sie bereits überwachen und bei denen Sie Alarme auslösen, können Sie den Alarm so konfigurieren, dass die [fehlenden Daten als Sicherheitsverletzung](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data) behandelt werden. Auf diese Weise können Sie feststellen, ob die Ressource keine Daten mehr meldet, und Sie können diese Alarme *in a row* und *m von n einschließen*, die zuvor verwendet wurden.
Es ist auch möglich, dass in einigen Kennzahlen, die den Zustand der Ressource angeben, ein Datenpunkt mit einem Wert von Null veröffentlicht wird, wenn keine Aktivität stattfindet. Wenn die Beeinträchtigung Interaktionen mit der Ressource verhindert, können Sie den Ansatz fehlender Daten für diese Art von Kennzahlen nicht verwenden. Sie möchten wahrscheinlich auch keinen Alarm auslösen, wenn der Wert Null ist, da es legitime Szenarien geben könnte, in denen dieser Wert innerhalb der normalen Schwellenwerte liegt. Der beste Ansatz zur Erkennung dieser Art von Problemen besteht darin, Metriken von den Ressourcen zu erstellen, die diese Abhängigkeit verwenden. In diesem Fall möchten wir mithilfe zusammengesetzter Alarme Auswirkungen in *mehreren* Availability Zones erkennen. Diese Alarme sollten eine Handvoll kritischer Metrikkategorien verwenden, die sich auf die Ressource beziehen. Nachfolgend sind einige Beispiele aufgeführt:
+ **Durchsatz** — Die Rate der eingehenden Arbeitseinheiten. Dies können Transaktionen, Lese- und Schreibvorgänge usw. sein.
+ **Verfügbarkeit** — Messen Sie die Anzahl erfolgreicher und fehlgeschlagener Arbeitseinheiten.
+ **Latenz** — Messen Sie mehrere Perzentile der Latenz für erfolgreiche Arbeit in kritischen Vorgängen.
Auch hier können Sie die Alarme „*In einer Reihe*“ und „*m aus n*“ für jede Metrik in jeder Metrikkategorie, die Sie messen möchten, erstellen. Nach wie vor können diese zu einem zusammengesetzten Alarm kombiniert werden, um festzustellen, ob diese gemeinsam genutzte Ressource die Ursache für Auswirkungen in allen Availability Zones ist. Sie möchten in der Lage sein, mit den kombinierten Alarmen Auswirkungen auf mehr als eine Availability Zone zu identifizieren, aber die Auswirkungen müssen nicht unbedingt *alle* Availability Zones betreffen. Die allgemeine Verbundalarmstruktur für diese Art von Ansatz ist in der folgenden Abbildung dargestellt.
![\[Das Diagramm zeigt ein Beispiel für die Erstellung von Alarmen zur Erkennung von Auswirkungen auf mehrere Availability Zones, die durch eine einzelne Ressource verursacht werden\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/advanced-multi-az-resilience-patterns/images/creating-alarms-to-detect-impact.png)
Sie werden feststellen, dass dieses Diagramm weniger aussagekräftig ist, welche Art von metrischen Alarmen verwendet werden sollte und wie die Hierarchie der zusammengesetzten Alarme aussieht. Das liegt daran, dass es schwierig sein kann, diese Art von Problem zu erkennen, und es ist daher erforderlich, sorgfältig auf die richtigen Signale für die gemeinsam genutzte Ressource zu achten. Diese Signale müssen möglicherweise auch auf spezifische Weise bewertet werden.
Darüber hinaus sollten Sie beachten, dass der `primary-database-impact` Alarm keiner bestimmten Availability Zone zugeordnet ist. Das liegt daran, dass sich die primäre Datenbank-Instance in jeder Availability Zone befinden kann, für deren Verwendung sie konfiguriert ist, und es keine CloudWatch Metrik gibt, die angibt, wo sie sich befindet. Wenn Sie sehen, dass dieser Alarm aktiviert wird, sollten Sie ihn als Signal verwenden, dass möglicherweise ein Problem mit der Ressource vorliegt, und einen Failover zu einer anderen Availability Zone einleiten, falls dieser nicht automatisch durchgeführt wurde. Nachdem Sie die Ressource in eine andere Availability Zone verschoben haben, können Sie abwarten, ob Ihr isolierter Availability Zone-Alarm aktiviert ist, oder Sie können Ihren Availability Zone-Evakuierungsplan präventiv aufrufen.
# Übersicht
In diesem Abschnitt wurden drei Ansätze beschrieben, mit deren Hilfe Beeinträchtigungen in einzelnen Availability Zones identifiziert werden können. Jeder Ansatz sollte zusammen verwendet werden, um einen ganzheitlichen Überblick über den Zustand Ihres Workloads zu erhalten.
Der CloudWatch kombinierte Alarmansatz ermöglicht es Ihnen, Probleme zu finden, bei denen der Verfügbarkeitsunterschied statistisch nicht signifikant ist, z. B. Verfügbarkeiten von 98% (die beeinträchtigte Availability Zone), 100% und 99,99%, die nicht auf eine einzelne, gemeinsam genutzte Ressource zurückzuführen sind.
Die Ausreißererkennung hilft dabei, Beeinträchtigungen einzelner Availability Zones zu erkennen, wenn in mehreren Availability Zones unkorrelierte Fehler auftreten, die alle Ihren Alarmschwellenwert überschreiten.
Und schließlich hilft die Identifizierung der Beeinträchtigung der zonalen Ressource einer einzelnen Instanz dabei, herauszufinden, ob sich eine Beeinträchtigung der Availability Zone auf eine Ressource auswirkt, die von mehreren Availability Zones gemeinsam genutzt wird.
Die Alarme, die sich aus jedem dieser Muster ergeben, können zu einer CloudWatch zusammengesetzten Alarmhierarchie zusammengefasst werden, um zu ermitteln, wann Beeinträchtigungen einzelner Availability Zones auftreten und sich auf die Verfügbarkeit oder Latenz Ihrer Arbeitslast auswirken.