Beobachtbarkeit und Überwachung – Muster
Weitere Informationen zu Well-Architected Operational Excellence → Observability and Monitoring (Beobachtbarkeit und Überwachung)
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Ereignisüberwachung | ✅ Die Ereignisüberwachung wurde für die anfängliche Architektur entwickelt, die Korrelations-IDs erfasst, die Anforderungen über asynchrone Verarbeitungsketten und externe Integrationen verfolgen |
| Plattform | Ereignisüberwachung | ✅ Die Infrastruktur für die Beobachtbarkeit wird aus dem anfänglichen Sprint einbezogen und nicht nachgerüstet, nachdem sich Produktionsvorfälle als unmöglich erwiesen haben |
| Plattform | Integration | ✅ Integrations-Checkpoints werden bewusst platziert, um die Anforderungsverfolgung über Systemgrenzen hinweg zu ermöglichen |
| Plattform | Plattformereignisse | ✅ Plattformereignisnutzlasten sind für die betriebliche Sichtbarkeit mit Transaktionsmarkierungen und Kontext strukturiert |
| Plattform | Benutzerdefinierte Protokollierung | ✅ Das benutzerdefinierte Protokollierungs-Framework erfasst diskrete Ereignisse mit vollständigen Kontextinformationen, einschließlich Benutzeridentität, Zeitstempel, Dauer und Ergebnis |
| Plattform | Kennzahlen | ✅ Kennzahlen aggregieren numerische Messwerte im Laufe der Zeit und zeigen Trends wie API-Verbrauchsraten, Apex CPU-Zeitverteilungen und Erfolgsraten bei Batchaufträgen |
| Plattform | Distributed Tracing | ✅ Verfolgt die Verbindung von synchronen API-Aufrufen mit asynchronen Verarbeitungsketten, Plattformereignissen mit Abonnentenausführungen und Integrationsanforderungen mit externen Systemantworten |
| Plattform | Beobachtbarkeit | ✅ Mit der Beobachtbarkeit können Bediener beliebige Fragen zum Systemverhalten beantworten, ohne für jede Untersuchung neue Instrumente bereitzustellen |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Ereignisüberwachung | ⚠️ Die Lösung wird ohne benutzerdefinierte Protokollierung gestartet, was sechs Monate später eine umfassende Refaktorierung erfordert, wenn sich Produktionsvorfälle als unmöglich erweisen, nur mit Plattformprotokollen zu diagnostizieren |
| Plattform | Ereignisüberwachung | ⚠️ Die Beobachtbarkeit wird in eine bestehende Lösung nachgerüstet, die Instrumentierungsänderungen erfordert, die die meisten Komponenten berühren, und Fehlerrisiken während der operativen Verbesserungsarbeiten |
| Plattform | Integration | ⚠️ Integrationsfehler treten auf, Anforderungspfade können jedoch ohne umfassende Telemetrie nicht über Systemgrenzen hinweg verfolgt werden |
| Plattform | Plattformereignisse | ⚠️ Plattformereignisnutzlasten fehlt der betriebliche Kontext, wodurch die Vorfallsuntersuchung von der Suche nach mehreren Systemen abhängig gemacht wird |
| Plattform | Benutzerdefinierte Protokollierung | ⚠️ Protokolle erfassen unzureichenden Kontext. Untersuchungen erfordern Probleme bei der Wiedergabe, um zusätzliche Informationen zu erfassen |
| Plattform | Beobachtbarkeit | ⚠️ Vordefinierte Dashboards können unerwartete Fragen zum Systemverhalten in der Produktion nicht beantworten |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Ereignisüberwachung | ✅ Die Ereignisüberwachung ist für Produktionsumgebungen aktiviert, die API-Nutzung, Anmeldeaktivität, Apex Ausführung, SOQL-Abfragen, Visualforce Seiten, Lightning Seiten und Berichtausführungen erfassen |
| Plattform | Ereignisüberwachung | ✅ Ereignisprotokolldateien werden stündlich in eine zentralisierte Protokollplattform exportiert, wodurch Verlaufsanalysen über die native Plattformaufbewahrung hinaus möglich sind |
| Plattform | Ereignisüberwachung | ✅ Externe Protokollaggregation ermöglicht Korrelation mit Unternehmenstelemetrie aus anderen Systemen für die durchgängige Transaktionsverfolgung |
| Plattform | Ereignisüberwachung | ✅ Ereignisprotokolldateien werden entsprechend den gesetzlichen Anforderungen für Compliance-Berichte und langfristige Trendanalysen beibehalten |
| Plattform | Proactive Monitoring | ✅ Proactive Monitoring-Schwellenwerte werden bewusst auf der Grundlage des organisationsspezifischen normalen Betriebsbereichs abgestimmt, statt Standardeinstellungen zu akzeptieren |
| Plattform | Proactive Monitoring | ✅ Warnungen vom Typ “Proactive Monitoring” erkennen API-Obergrenzenspitzen, gleichzeitige Apex-Fehler, SOQL-Zeilenbegrenzungsansätze und Zeilensperrkonflikte vor für Benutzer sichtbaren Vorfällen |
| Plattform | Proactive Monitoring | ✅ Abgestimmte Schwellenwerte generieren handlungsrelevante Signale, denen Teams Trust schenken und auf die Schaffung von zyklischen Verbesserungen reagieren |
| Plattform | Skalierungscenter | ✅ Skalierungscenter-Basiswerte werden während der Lösungsstabilisierung festgelegt und nach jeder Hauptversion erneut aufgerufen |
| Plattform | Skalierungscenter | ✅ Das Skalierungscenter zeigt, welche Vorgänge die meisten Ressourcen verbrauchen, welche Transaktionen sich den Zeitüberschreitungsschwellenwerten nähern und wo Optimierungsinvestitionen den größten Einfluss haben |
| Plattform | Skalierungscenter | ✅ Die Transaktionszeit erhöht sich im Vergleich zur Basisuntersuchung der Eingabeaufforderungen und zeigt unbeabsichtigte N+1-Abfragemuster, die in der letzten Bereitstellung eingeführt wurden |
| Plattform | Setup-Aktivierungsprotokoll | ✅ Setup-Aktivierungsprotokoll verfolgt Konfigurationsänderungen, einschließlich Berechtigungsänderungen, Metadatenbereitstellungen und Sicherheitseinstellungsaktualisierungen mit Aufbewahrung bis zu 180 Tagen |
| Plattform | Setup-Aktivierungsprotokoll | ✅ Setup-Aktivierungsprotokoll-Einträge werden zur Aufbewahrung über 180 Tage hinaus exportiert, wenn Compliance- oder Vertragsanforderungen längere historische Zeitfenster erfordern |
| Plattform | Shield | ✅ Feld-Aktivierungsprotokoll wird selektiv für Felder aktiviert, die sensible Daten, regulierte Daten, die einen Änderungsverlauf erfordern, oder wichtige Geschäftsdaten enthalten |
| Plattform | Shield | ✅ Das Feld-Aktivierungsprotokoll bietet eine Aufbewahrung von bis zu 10 Jahren für Felder, in denen das Verständnis historischer Werte Vorgänge und Compliance-Berichte erleichtert |
| Plattform | Integritätsprüfung | ✅ Integritätsprüfungen werden vierteljährlich geplant, wobei die Ergebnisse anhand der Risikopriorität für die Umwelt korrigiert werden |
| Plattform | Integritätsprüfung | ✅ Ergebnisse der Integritätsprüfung werden bewusst überprüft und nicht passiv akzeptiert. Kompensationskontrollen oder unterschiedliche Risikotoleranzen werden dokumentiert |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Ereignisüberwachung | ⚠️ Die Ereignisüberwachung ist aktiviert, Protokolle werden jedoch nie exportiert, wodurch Untersuchungen auf das native Aufbewahrungsfenster beschränkt werden und die Analyse historischer Trends verhindert wird |
| Plattform | Ereignisüberwachung | ⚠️ Ereignisprotokolldateien verbleiben im Plattformspeicher; die externe Aggregation wird nicht implementiert, was die langfristige Kapazitätsplanung verhindert |
| Plattform | Proactive Monitoring | ⚠️ Proactive Monitoring verwendet Standardschwellenwerte, die zu sensibel oder zu lasch sind, was zu lauten Benachrichtigungen führt, die Teams ignorieren sollten |
| Plattform | Proactive Monitoring | ⚠️ Benachrichtigungsrauschen zerstört Trust in das Überwachungssystem; Teams reagieren nicht mehr auf gültige Signale |
| Plattform | Skalierungscenter | ⚠️ Das Skalierungscenter ist aktiviert, wird jedoch nie proaktiv überprüft. Die Leistung verschlechtert sich langsam, bis sich Benutzer nach Monaten der inkrementellen Verschlechterung beschweren |
| Plattform | Skalierungscenter | ⚠️ Leistungskennzahlen ohne Basiskontext; unklar, ob 3-Sekunden-Transaktionszeiten typisch sind, sich verbessern oder verschlechtern |
| Plattform | Setup-Aktivierungsprotokoll | ⚠️ Das Setup-Aktivierungsprotokoll wird nicht exportiert. Aufbewahrungseinschränkungen verhindern Sicherheitsuntersuchungen oder die Validierung von Compliance-Vorschriften nach 180 Tagen |
| Plattform | Shield | ⚠️ Das Feld-Aktivierungsprotokoll ist für alle Felder aktiviert und nicht selektiv. Dadurch entstehen Speicherkosten ohne entsprechenden Compliance-Wert. |
| Plattform | Integritätsprüfung | ⚠️ Die Ergebnisse der Integritätsprüfung werden nie überprüft. Die Sicherheitskonfiguration weicht von den Basisempfehlungen ab, ohne bewusst akzeptiert zu werden. |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Benutzer-Flows | ✅ Wichtige Benutzer-Flows werden anhand der Geschäftsauswirkungen definiert und durchgängig auf Erfolgsraten, Abschlusszeit, Verlassenspunkte und Fehlerraten überwacht |
| Plattform | Benutzer-Flows | ✅ Wichtige Flows umfassen umsatzgenerierende Aktivitäten (Auftragserteilung, Vertragsausführung, Opportunity-Schluss), Aktivitäten mit hohem Volumen (Anmeldung, Suche, Datensatzerstellung) und konformitätsrelevante Aktivitäten (Einwilligungserfassung, Erfüllung der Rechte betroffener Personen) |
| Plattform | Benutzer-Flows | ✅ Flows werden mit Transaktionsmarkierungen instrumentiert, die Start, Abschluss, Verlassen und Fehler bei jedem wichtigen Schritt anzeigen |
| Plattform | Benutzer-Flows | ✅ Flow für die Auftragseinreichung mit Plattformereignissen in jeder Phase (Einkaufswagenvalidierung, Inventarprüfung, Zahlungsabwicklung, Abwicklungsauslöser) mit Erfolgsrate nach Phase |
| Plattform | Benutzer-Flows | ✅ Die Überwachung auf Flussebene zeigt Probleme auf, die bei der Überwachung auf Komponentenebene nicht sichtbar sind, da an jedem Übergangspunkt Fehler auftreten können |
| Plattform | Benutzer-Flows | ✅ Warnungen werden ausgelöst, wenn Flow-Erfolgsraten unter akzeptable Schwellenwerte fallen oder die Dauer Latenzziele überschreitet |
| Plattform | Integration | ✅ Die Integrationsintegritätsüberwachung erkennt externe Systemfehler, Netzwerkprobleme, Authentifizierungsprobleme und Ansätze zur Ratenbegrenzung, bevor sie zu benutzerseitigen Fehlern führt |
| Plattform | Integration | ✅ Warnungen zur Erfolgsratenüberwachung bei Unterschreiten von 99 % für wichtige synchrone Integrationen |
| Plattform | Integration | ✅ Warnungen bei der Fehlerverteilungsüberwachung, wenn neue Fehlertypen angezeigt werden, die in der Basisversion nicht vorhanden waren |
| Plattform | Integration | ✅ Warnungen bei Latenzperzentilüberwachung (p95) bei mehr als 3 Sekunden für synchrone Benutzeranrufe |
| Plattform | Integration | ✅ Warnungen zur Durchsatzüberwachung bei mehr als 80 % der bekannten Ratenobergrenze oder des SLA-Schwellenwerts |
| Plattform | Integration | ✅ Warnungen zur Statusüberwachung des Leistungsschalters, wenn ein Stromkreis geöffnet wird, was auf eine Verschlechterung des externen Systems hinweist |
| Plattform | Integration | ✅ Warnungen zur Wiederholungsratenüberwachung, wenn die Wiederholungsrate 5 % überschreitet, was auf Zuverlässigkeitsprobleme hindeutet |
| Plattform | Integration | ✅ Integrationstelemetrie leitet an zentralisierte Überwachungsplattformen weiter, um Korrelation über Systemgrenzen hinweg zu ermöglichen |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Benutzer-Flows | ⚠️ Komponenten werden unabhängig voneinander überwacht und zeigen einen gesunden Betrieb an, während 12 % der Benutzer kritische Flows ohne Einblick in die Gründe verlassen |
| Plattform | Benutzer-Flows | ⚠️ Komponentenintegritäts-Dashboards werden grün angezeigt, während Benutzer wichtige Workflows nicht abschließen können, bei denen Fehler bei der Überwachungsarchitektur festgestellt werden |
| Plattform | Benutzer-Flows | ⚠️ Benutzer-Journey, die mehrere Apex-Klassen, Flows, Plattformereignisse und externe Integrationen berührt, ist nicht vollständig sichtbar |
| Plattform | Benutzer-Flows | ⚠️ Kritische Geschäfts-Journeys sind nicht instrumentiert; Erfolgsraten und Verwerfenspunkte sind unbekannt |
| Plattform | Integration | ⚠️ Integrationsfehler werden erst nach der Kaskade in benutzerseitige Fehler erkannt und nicht proaktiv. |
| Plattform | Integration | ⚠️ Integrationstelemetrie bleibt in einzelnen Systemen isoliert und verhindert Korrelation und Ursachenanalyse über Grenzen hinweg |
| Plattform | Integration | ⚠️ Überwachen von Warnungen zu nachgelagerten Symptomen nach der Schädigung, statt Ursachen frühzeitig zu erkennen |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | SLIs | ✅ Verfügbarkeits-SLIs messen den Prozentsatz der erfolgreichen Ausführung wichtiger Flows aus Benutzerperspektive (erhält erwartetes Ergebnis, nicht nur 200 Statuscodes) |
| Plattform | SLIs | ✅ Latenz-SLIs messen die Zeit bis zum Abschluss von Vorgängen bei p50 (Median), p90 (90. Perzentil ohne Ausreißer), p95 (95. Perzentil ohne schlimmste Ausreißer) und p99 (99. Perzentil mit Erfahrung im schlimmsten Fall) |
| Plattform | SLIs | ✅ Latenzziele variieren je nach Vorgangskritischität und Benutzererwartung (500 ms Suche fühlt sich sofort an, gleiche Latenz für Eingaben fühlt sich träge an) |
| Plattform | SLIs | ✅ Durchsatz-SLIs messen das Volumen erfolgreicher Vorgänge pro Zeiteinheit und zeigen Kapazitätsauslastung und Wachstumstrends an |
| Plattform | SLIs | ✅ Der Durchsatz in Kombination mit der Latenz zeigt an, ob das System die Leistung bei zunehmender Last beibehält oder bei wachsendem Volumen nachlässt |
| Plattform | SLIs | ✅ Fehlerraten-SLIs unterscheiden zwischen Fehlertypen (Benutzerfehler wie Validierungsfehler und Systemfehler wie Ausnahmen bei Obergrenzen) |
| Plattform | SLOs | ✅ Service Level Objectives (Servicestufenziele) werden festgelegt und definieren akzeptable SLI-Schwellenwerte basierend auf Geschäftsanforderungen, bevor Architekturmuster ausgewählt werden |
| Plattform | SLOs | ✅ Geschäftsanforderung “Vertriebsmitarbeitern müssen Opportunity-Aktualisierungen innerhalb von 5 Sekunden angezeigt werden” steuert SLO “Opportunity-Detailseite wird innerhalb von 3 Sekunden bei p95 abgeschlossen”, was Architekturentscheidungen steuert |
| Plattform | SLOs | ✅ SLOs entstehen aus Geschäftsanforderungen und steuern architektonische Entscheidungen, statt basierend darauf definiert zu werden, was das System derzeit erreicht |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | SLIs | ⚠️ Die Verfügbarkeit wird aus technischer Perspektive (200-Statuscode) und nicht aus Benutzerperspektive (erwartetes Ergebnis) gemessen |
| Plattform | SLIs | ⚠️ Die Latenz wird nur im Median gemessen, ohne die Benutzererfahrung im schlimmsten Fall bei p95- oder p99-Perzentilen zu verstehen |
| Plattform | SLIs | ⚠️ Fehlerraten-SLIs unterscheiden nicht zwischen Benutzerfehlern und Systemfehlern, wodurch verschiedene Probleme maskiert werden, die unterschiedliche Lösungen erfordern |
| Plattform | SLOs | ⚠️ Die Architektur wird zuerst erstellt, dann wird SLO als “was immer wir derzeit erreichen” definiert, was zur Akzeptanz von Seitenladevorgängen von 12 Sekunden führt, da beim Systemdesign nie Benutzeranforderungen berücksichtigt wurden |
| Plattform | SLOs | ⚠️ SLOs sind eher von der Architektur als von Unternehmen gesteuert und legen Ziele fest, die darauf basieren, was das System erreicht und was Benutzer benötigen. |
Muster
| Wohin schauen | Wie gut aussieht |
|---|---|
| Plattform | Warnung | ✅ Schweregradklassifizierung leitet wichtige Vorfälle (Produktion nicht verfügbar, Datenbeschädigungsrisiko, Sicherheitskompromittierung) sofort an Techniker auf der Seite für Bereitschaft weiter |
| Plattform | Warnung | ✅ Vorfälle mit hohem Schweregrad (Leistungseinbußen, Teilausfälle) generieren Benachrichtigungen für eine sofortige Untersuchung innerhalb der Geschäftszeiten |
| Plattform | Warnung | ✅ Warnungen (näher rückende Schwellenwerte, Konfigurationsabweichung) generieren tägliche Auszugsbenachrichtigungen für die proaktive Sanierung |
| Plattform | Warnung | ✅ Der Benachrichtigungskontext umfasst die Anzahl der betroffenen Benutzer, Fehlermeldungen, Stapelverfolgungen, aktuelle Bereitstellungen, zugehörige Benachrichtigungen und Links zu relevanten Dashboards. |
| Plattform | Warnung | ✅ Reichhaltiger Kontext reduziert die mittlere Zeit bis zur Bestätigung, indem sofortige Schweregradbewertung und -untersuchung ohne Erfassung grundlegender Informationen ermöglicht werden |
| Plattform | Warnung | ✅ Benachrichtigungsgruppierung verhindert Warnungsstürme, bei denen Hunderte zugehöriger Warnungen für einzelne zugrunde liegende Probleme ausgelöst werden |
| Plattform | Warnung | ✅ Integrationsfehler löst eine Benachrichtigung aus, die nach Integrationsendpunkt gruppiert 156 fehlgeschlagene Anforderungen in den letzten 5 Minuten mit Latenzdiagramm, Fehlerverteilung und Dashboard-Link anzeigt |
| Plattform | Warnung | ✅ Die Unterdrückung von Benachrichtigungen verhindert, dass bekannte vorübergehende Bedingungen während erwarteter Wartungszeiträume oder automatischer Korrekturzeiträume Warnungen generieren |
| Plattform | Warnung | ✅ Benachrichtigungen werden während der geplanten Wartung, während der ersten Minuten nach der Bereitstellung bei warmen Caches und bei kurzzeitigen vorübergehenden Fehlern mit erfolgreicher Wiederholungslogik unterdrückt |
Antimuster
| Wohin schauen | Wie schlecht sieht |
|---|---|
| Plattform | Warnung | ⚠️ Alle Warnungen werden ohne Schweregradklassifizierung an denselben Kanal weitergeleitet. Wichtige Vorfälle werden nicht von Routinewarnungen unterschieden |
| Plattform | Warnung | ⚠️ Warnungen fehlt der Diagnosekontext. Bereitschaftsingenieure müssen grundlegende Informationen über separate Abfragen erfassen, bevor sie den Schweregrad beurteilen können |
| Plattform | Warnung | ⚠️ Integrationsfehler generiert 156 einzelne Benachrichtigungen in 5 Minuten, die das Telefon des Technikers auf Abruf überfordern, wobei jede Benachrichtigung mit Ausnahme des Zeitstempels identisch ist |
| Plattform | Warnung | ⚠️ Warnstürme verhindern, dass Responder einzelne zugrunde liegende Probleme von Hunderten verwandter Symptome unterscheiden |
| Plattform | Warnung | ⚠️ Warnungen werden während bekannter Wartungszeitfenster und vorübergehender Bedingungen ausgelöst und verursachen Geräusche, die Trust in die Überwachung untergraben |
| Plattform | Warnung | ⚠️ Die Benachrichtigungsmüdigkeit aufgrund von verrauschten falsch positiven Ergebnissen führt dazu, dass Teams Benachrichtigungen ignorieren, was die Effektivität der Antwort reduziert |