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.
Stufe 2: Beobachtbarkeit implementieren
In dieser Phase beginnen Sie mit dem Prozess, damit sich Ihre Teams schrittweise bis zum North Star vorarbeiten können.
Wählen Sie Ihre Observability-Plattform
Der erste Schritt besteht darin, die richtigen Tools zu finden, um die Signale aufzunehmen, zu visualisieren und zu analysieren und Warnmeldungen zu senden. Bei der Auswahl eines Tools sollten Sie dessen Funktionsumfang, Lizenzmodell, Preis, Qualifikationsanforderungen und Wartung berücksichtigen.
Funktionsumfang
Hier sind einige der Fragen, die Sie berücksichtigen sollten:
-
Konfigurierbarkeit und Anpassung. Welche Funktionen bietet das Tool, um die Ermittlungserfahrung zu vereinfachen und die MTTR zu verkürzen? Bietet das Tool Alarmkorrelation, metrische Mathematik, Flexibilität beim Umgang mit fehlender Telemetrie oder Erkennung von Anomalien?
-
Granularität. Welche Granularität wird bei der Erfassung und Visualisierung von Telemetriesignalen unterstützt?
-
Personas. Unterstützt das Tool die Erlebnisse, die Sie Ihren Entwicklern, Plattformtechnikern und anderen Personas bieten möchten? Funktioniert es sowohl für technische als auch für Geschäftsleute?
-
Widgets. Welche Arten von Widgets unterstützen die Dashboards? Erlaubt das Tool die Erstellung von benutzerdefinierten Widgets?
-
Vorgefertigte Lösungen. Welche vorgefertigten Observability-Lösungen bietet das Tool, um die Amortisationszeit zu verkürzen?
-
Automatisierung und generative KI. Welche Funktionen bietet das Tool, mit denen Sie und Ihr Team den Arbeitsaufwand automatisieren oder reduzieren können? Beispielsweise können automatische Anomalieerkennung, prädiktive Analysen und andere generative KI-Funktionen dazu beitragen, den Stress von Annahmen und Unbekannt-Unbekannten (also Dingen, die Sie weder kennen noch vollständig verstehen) zu reduzieren. Unterstützt das Tool die Verwendung generativer AI/ML Modelle, um die Analyse der Daten im großen Maßstab zu verbessern? Bietet es Ihnen die Möglichkeit zur Automatisierung und Implementierung AIOps?
-
Sicherheit.Welche Arten von Authentifizierungs- und Autorisierungsintegrationen unterstützt das Tool? Entsprechen die Benutzer- und Anmeldemöglichkeiten den Anforderungen Ihres Unternehmens?
-
OpenTelemetry Unterstützung. Unterstützen das Tool und der Agent OpenTelemetry? Die meisten Observability-Plattformen unterstützen die Aufnahme von OpenTelemetry -kompatiblen Signalen, aber nicht alle Agenten bieten Konfigurationsoptionen, um diese Signale an eine Observability-Plattform weiterzuleiten.
-
Integrationen. Welche Integrationen bietet das Tool? Überlege dir, ob du Benachrichtigungen an Slack senden, Teammitglieder kontaktieren oder die Problembehebung automatisieren möchtest.
-
Skalierbarkeit. Wie skalierbar und performant ist das Tool? Die Observability-Lösung muss mit Ihren Anforderungen und der steigenden Nutzung skaliert werden, sodass sie auch dann Diagnosen stellen kann, wenn Ihre Anwendung nicht verfügbar ist.
-
Support. Welches Support-Modell wird angeboten? Ihr Observability-Tool muss auch dann verfügbar sein, wenn Ihre Anwendung ausfällt, damit Sie Ihre MTTR- und Anwendungsverfügbarkeitsziele oder Service Level Agreements () einhalten können. SLAs Open-Source-Lösungen bieten möglicherweise nur begrenzten formellen Support.
Lizenzierungs- und Bereitstellungsmodell
Berücksichtigen Sie das Lizenzmodell (Open Source oder kommerziell) und das Bereitstellungsmodell (selbst gehostet oder cloudbasiert) der Lösung. Open-Source-Optionen haben oft geringere Vorlaufkosten, erfordern jedoch möglicherweise mehr Zeit für Bereitstellung, Einrichtung und Konfiguration, Wartung und Teamqualifizierung, bevor sie einen Mehrwert bieten. Wenn Sie Open-Source-Optionen in Betracht ziehen, benötigen Sie möglicherweise ein engagiertes Team von Observability-Experten. Kommerzielle Software bietet in der Regel eine kürzere Amortisierungszeit bei höheren Vorlaufkosten, und der Bedarf an einem eigenen Observability-Team wächst mit der Zeit, wenn Akzeptanz, Komplexität und Reife zunehmen. Selbst gehostete Lösungen erfordern im Vergleich zu cloudbasierten Lösungen mehr Zeit für Bereitstellung, Einrichtung und Konfiguration, Wartung und Betriebskosten.
Preisdimensionen
Wie wird sich das Preismodell des Tools auf Ihre Gesamtbetriebskosten (TCO) auswirken, wenn Ihre Anwendung neue Benutzer gewinnt, die Architektur größer wird oder neue Funktionen und Anwendungen hinzukommen? Einige typische Lizenzmodelle sind beispielsweise unbefristet oder basieren auf Abonnements, der Anzahl der benannten Benutzer, dem Verbrauch oder dem Volumen. Überlegen Sie, wie Ihre Anwendung und das Observability-Tool im Hinblick auf die Nutzung skalieren werden und wie sich das Lizenzmodell auf die Kosten des Tools auswirken kann.
Fähigkeiten im Team
Abhängig von den aktuellen Fähigkeiten und dem Reifegrad Ihres Teams müssen Sie festlegen, wie viel Weiterbildung erforderlich sein wird. Überlegen Sie, welche Art von Unterstützung der Anbieter für die Schulung Ihres Teams anbietet. Überlegen Sie auch, ob Ihre Organisationsstruktur die Konfiguration und Verwaltung des von Ihnen ausgewählten Tools unterstützt. Wenn Sie sich beispielsweise dafür entscheiden OpenTelemetry, sollten Sie in Betracht ziehen, ein eigenes Team zusammenzustellen, das sich auf Beobachtbarkeit spezialisiert hat.
Betrieb und Wartung
Beurteilen Sie die folgenden Fragen:
-
Welche Bereitstellungsoptionen bietet der Observability Agent oder Collector? Entsprechen diese Optionen den Anforderungen Ihrer Architektur? Wenn Sie beispielsweise eine containerisierte Bereitstellung für das Observability-Tool verwenden, unterstützt es dann ein Daemonset oder Sidecar? Welche zusätzlichen Schritte oder Tools müsste das Betriebsteam ergreifen oder einsetzen, um sicherzustellen, dass die Sicherheit und alle anderen Prozesse eingehalten werden?
-
Welcher Aufwand ist für die Wartung der Lösung erforderlich? Wie einfach oder automatisiert ist der Prozess der Aktualisierung des Agenten oder Collectors? Vollständig verwaltete und cloudbasierte Observability-Schnittstellen haben im Vergleich zu selbst bereitgestellten und gehosteten Anwendungen in der Regel einen geringeren Betriebsaufwand, obwohl die Verwaltung des Agenten oder Collectors gleich bleibt. Berücksichtigen Sie Ihre Teamstruktur und berücksichtigen Sie die Personalkosten, die mit der Wartung der von Ihnen ausgewählten Option verbunden sind.
Instrumentieren Sie Ihre Bewerbung
Die Antworten auf die Fragen im vorherigen Abschnitt geben Ihnen die Informationen, die Sie für die Instrumentierung Ihrer Anwendung benötigen, d. h., um Ihrer Anwendung Code zur Erfassung von Telemetriesignalen hinzuzufügen und Verhaltensweisen zu messen, zu beobachten und zu validieren. Sie können SDKs beispielsweise das OpenTelemetry SDK für die Sprache Ihrer Anwendung verwenden, um Ihre Anwendung automatisch zu instrumentieren. Möglicherweise müssen Sie dennoch manuellen Instrumentierungscode hinzufügen, um etwaige Lücken zu schließen und die end-to-end Sichtbarkeit zu gewährleisten. Gehen Sie bewusst mit der Telemetrie um, die Sie hinzufügen, und stellen Sie sicher, dass Sie sie wieder mit einer oder mehreren SLIs Telemetriedaten verbinden können SLOs , die Sie in der vorherigen Phase eingerichtet haben.
Erfassen Sie Telemetrie
Implementieren Sie Observability-Komponenten
Wenn die Telemetrie fließt und in eine Observability-Plattform aufgenommen wird, erstellen Sie Dashboards, Warnmeldungen, Playbooks und Runbooks.
-
Dashboards: Erstellen Sie Dashboards, die relevante Informationen enthalten, einschließlich einer visuellen Darstellung aktueller und historischer Trends im Zusammenhang mit Ihren priorisierten Ergebnissen. Stellen Sie diese Dashboards den Stakeholdern zur Verfügung, die Sie in Phase 1 definiert haben. Weitere Informationen finden Sie unter Aufbau von Dashboards für betriebliche Transparenz
auf der Website der Amazon Builders' Library. -
Warnmeldungen: Definieren Sie Warnmeldungen, um Ihr Team zu benachrichtigen, wenn die Ergebnisse gefährdet sind oder verletzt werden. Erwägen Sie, Warnmeldungen für Sicherheits- und Leistungsprobleme hinzuzufügen. Optimieren Sie Warnmeldungen, um die Warnungsmüdigkeit und die damit verbundenen Kosten zu reduzieren, indem Sie folgende Maßnahmen ergreifen:
-
Verwenden Sie die Anomalieerkennung, um die Festlegung fester Schwellenwerte zu vermeiden, die häufig angepasst werden müssen, und um das Auftreten von Unbekannt-Unbekannten zu reduzieren.
-
Verwenden Sie intelligente Alert-Kombinationen, die mehrere verwandte Metriken zusammen betrachten, anstatt einzelne Alerts für jede Metrik einzurichten. Anstatt beispielsweise separate Warnmeldungen für CPU, Arbeitsspeicher und Reaktionszeit einzurichten, sollten Sie eine aussagekräftige Warnung erstellen, die nur ausgelöst wird, wenn diese Metriken zusammen auf ein echtes Problem hinweisen. Dieser Ansatz reduziert die Anzahl der Warnmeldungen erheblich und hilft Ihren Teams, sich auf tatsächliche Probleme zu konzentrieren, die sich auf den Service auswirken, anstatt auf einzelne Messspitzen reagieren zu müssen.
-
Generieren Sie Warnmeldungen nur, wenn die Benutzererfahrung oder die Ergebnisse gefährdet sind. Vermeiden Sie es beispielsweise, Benachrichtigungen über eine CPU-Spitze zu erhalten, die durch ein automatisiertes Upgrade verursacht wird, wenn Ihre Anwendung keine aktiven Benutzer hat.
-
-
Playbooks: Ein Playbook bietet der Person, die auf einen Vorfall oder eine Warnung reagiert, ein mentales Modell und einen Kontext und hilft ihr, die Ursache schneller zu identifizieren. Erwägen Sie die Erstellung von Playbooks für hochgradig gekoppelte, komplexe Anwendungen und für Anwendungen, denen es an Instrumentierung mangelt, die sich jedoch direkt auf die Ergebnisse auswirken, die Sie in Phase 1 identifiziert und priorisiert haben.
-
Runbooks: Verwenden Sie Runbooks, um die Schritte zu definieren, die zur Behebung eines Vorfalls oder einer Warnung erforderlich sind.
Validieren Sie das Observability-System
Stellen Sie während Ihres gesamten Softwareentwicklungszyklus (SDLC) sicher, dass die Dashboards die erwarteten Verhaltensweisen und Aktualisierungen während der Systemtests bieten. Implementieren Sie Chaos Engineering und validieren Sie die in Playbooks und Runbooks dokumentierten Schritte, um sicherzustellen, dass sie korrekt sind und ihren Zweck erfüllen. Sie sollten auch die Inhaberschaft der Warnmeldungen und die Eskalationswege überprüfen.