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.
Operative Beobachtbarkeit
Beobachtbarkeit ist erforderlich, um umsetzbare Erkenntnisse über die Leistung Ihrer Umgebungen zu gewinnen und Probleme zu erkennen und zu untersuchen. Sie hat auch einen sekundären Zweck, der es Ihnen ermöglicht, wichtige Leistungsindikatoren (KPIs) und Service-Level-Ziele (SLOs) wie die Verfügbarkeit zu definieren und zu messen. Für die meisten Unternehmen KPIs sind die Mean Time to Detect (MTTD) und die Mean Time to Recovery (MTTR) nach einem Vorfall wichtige Operationen.
Bei der Beobachtbarkeit ist der Kontext wichtig, da Daten gesammelt und anschließend die zugehörigen Tags gesammelt werden. Unabhängig davon, auf welche Service-, Anwendungs- oder Anwendungsebene Sie sich konzentrieren, können Sie nach diesem bestimmten Datensatz filtern und analysieren. Mithilfe von Stichwörtern können Sie das Onboarding von CloudWatch Alarmen automatisieren, sodass die richtigen Teams benachrichtigt werden können, wenn bestimmte Messwerte überschritten werden. Beispielsweise könnten ein Tag-Schlüssel example-inc:ops:alarm-tag und der darauf stehende Wert darauf hinweisen, dass der Alarm ausgelöst wurde. CloudWatch Eine Lösung, die dies demonstriert, ist unter Verwenden von Tags zur Erstellung und Verwaltung von CloudWatch Amazon-Alarmen für EC2 Amazon-Instances
Wenn zu viele Alarme konfiguriert sind, kann dies leicht zu einem Alarmsturm führen — wenn eine große Anzahl von Alarmen oder Benachrichtigungen die Bediener schnell überfordert und ihre Gesamteffektivität beeinträchtigt, während die Bediener einzelne Alarme manuell auswählen und priorisieren. Zusätzlicher Kontext für die Alarme kann in Form von Tags bereitgestellt werden, was bedeutet, dass Regeln innerhalb von Amazon definiert werden können, EventBridge um sicherzustellen, dass der Fokus auf das vorgelagerte Problem und nicht auf nachgelagerte Abhängigkeiten gelegt wird.
Die Rolle des Nebenbetriebs DevOps wird oft übersehen, aber in vielen Unternehmen leisten die zentralen Betriebsteams auch außerhalb der normalen Geschäftszeiten immer noch eine wichtige Erstreaktion. (Weitere Einzelheiten zu diesem Modell finden Sie im Whitepaper Operational Excellence.) Im Gegensatz zu dem DevOps Team, das für den Workload verantwortlich ist, verfügen sie in der Regel nicht über die gleiche Tiefe an Wissen, sodass der Kontext, den Tags in Dashboards und Benachrichtigungen bereitstellen, sie zum richtigen Runbook für das Problem weiterleiten oder ein automatisiertes Runbook initiieren kann (weitere Informationen finden Sie im Blogbeitrag Automating Amazon CloudWatch
