Warum Observability einen Context Graph benötigt

Moderne Observability generiert enorme Mengen an Telemetriedaten, aber Telemetrie allein erklärt nicht, wie die Teile eines Systems zusammenhängen. Wenn ein Vorfall auftritt, ist der schwierigste Teil in der Regel nicht das Finden der Warnung – es ist das Verständnis dessen, was über Services, Infrastruktur und Abhängigkeiten hinweg passiert ist. Der Observability Context Graph in Observe by Snowflake schließt diese Lücke, indem er rohe Telemetriedaten in abfragbare Datasets verwandelt, die Sie miteinander verknüpfen können. Wenn also ein Vorfall auftritt, können Nutzer:innen nachvollziehen, warum etwas kaputtgegangen ist, und nicht nur, was kaputtgegangen ist.

Der Context Graph ist die Architekturschicht in Observe, die Telemetriedaten in einer verbundenen Karte organisiert und es Nutzer:innen ermöglicht, schnell durch ihr gesamtes System zu navigieren, um Erkenntnisse zu gewinnen, anstatt sich manuell durch einzelne Ereignisse zu graben. Er ermöglicht es Nutzer:innen, Verbindungen in ihren Rohdaten visuell zu erkunden, um zu sehen, was in ihrer Umgebung passiert.

Erfahren Sie mehr über Observe by Snowflake und wie es Telemetriedaten in Erkenntnisse verwandelt – und zwar schnell.

Der Observability Context Graph sitzt auf dem Data Lakehouse, dem einzigen Ziel für all Ihre Observability-Daten. Die Art und Weise, wie diese beiden interagieren, ist zentral dafür, wie Observe Teams hilft, schneller zu untersuchen.

Zunächst werden rohe Telemetriedaten von der externen Infrastruktur über eine Integration oder einen Collector an das Telemetry Data Lakehouse weitergeleitet. Observe organisiert und formt diese Daten dann in Datasets, die sich sowohl direkt über Links als auch über gemeinsame Korrelations-Tags verbinden:

• Datasets: Observe formt eingehende Telemetriedaten in Datasets, wie z. B. Kubernetes-Protokolle, Prometheus-Metriken und Trace-Spans. Ressourcen-Datasets identifizieren einzelne Ressourcen – virtuelle oder physische Objekte wie Kubernetes-Pods und -Container, Nutzer:innen, Produkte und Warenkörbe – mithilfe eines Primärschlüssels, der ein Feld oder eine Kombination von Feldern enthalten kann.
• Links verbinden Datasets: Primär- und Fremdschlüssel-Links verbinden Datasets basierend auf der Ressourcenidentität. Beispielsweise kann eine Pod-Ressource mit dem Knoten verknüpft werden, auf dem sie ausgeführt wird. Lineage zeigt eine andere Beziehung zwischen Datasets: welche Datasets verwendet wurden, um ein anderes Dataset zu erstellen. Sie können diese Beziehungen über die Ansichten Links, Lineage und Focus erkunden, die unten kurz behandelt werden.
• Korrelations-Tags verbinden Daten über Datasets hinweg: Korrelations-Tags kennzeichnen Felder, wie z. B. „cluster.name“ oder „service.name“, die dasselbe Konzept über Datasets hinweg darstellen. Wenn Felder ein Korrelations-Tag teilen, kann Observe übereinstimmende Werte verwenden, um verwandte Daten zu finden. Viele Tags werden basierend auf unterstützten Konventionen automatisch angewendet. Diese durchsuchbaren Tags helfen auch dem AI Site Reliability Engineer (AI SRE) von Observe, einen Begriff wie „apiserver“ den richtigen Daten zuzuordnen.

Zusammen bilden diese Verbindungen den Observability Context Graph: Datasets sind seine „Knoten“, und die Links und die Lineage zwischen ihnen sind seine „Kanten“. Korrelations-Tags fügen eine ergänzende Ebene für die Navigation über Datasets hinweg durch gemeinsame Konzepte hinzu. Links, Lineage und Tags machen es möglich, über verbundene Datasets hinweg zu untersuchen, anstatt jedes isoliert zu betrachten.

Der KI-SRE nutzt diese Verbindungen, um relevante Daten zu finden und Teams dabei zu helfen, zu untersuchen, warum etwas kaputtgegangen ist, und nicht nur, was kaputtgegangen ist. Warum ist der Zahlungsdienst um 3 Uhr ausgefallen? Wie hat sich das neueste Deployment auf nachgelagerte Kund:innen ausgewirkt? Müssen wir unsere Knotenanzahl nach der Bereitstellung des neuesten Features erhöhen? Der Observability Context Graph bietet den Kontext, um diese Fragen zu untersuchen, und reduziert die Arbeit, die Teams andernfalls manuell mit der Korrelation von Ereignissen und Ressourcen verbringen würden.

Der Context Graph arbeitet hinter den Kulissen, aber Sie können über die Observe-Benutzeroberfläche auf die Daten zugreifen, auf denen er aufbaut.

Auf der Dataset-Seite können Sie das Schema, die Eigenschaften, die Korrelations-Tags und die Beziehungen eines Datasets überprüfen. Die Ansichten Links und Focus zeigen Dataset-Verbindungen, während die Lineage-Ansicht zeigt, wie Datasets abgeleitet wurden. Observe verfügt auch über eine separate Tag-Verwaltungsseite, auf der Sie alle Korrelations-Tags an einem Ort anzeigen können. Diese Ansichten helfen Nutzer:innen, Dataset-Beziehungen zu überprüfen und Datenursprünge nachzuverfolgen.

Der Context Graph kann über APIs abgefragt werden, die dieselben Verbindungen durchlaufen, die den Graphen bilden (Datasets, Links und Korrelations-Tags). Diese APIs helfen Agenten, Services und Ressourcen zu identifizieren, verwandte Daten zu finden und die Ergebnisse zu nutzen, um eine Untersuchung fortzusetzen.

Der Context Graph ist eine Agentic-Oberfläche; da es sich nicht einfach um eine Benutzeroberfläche handelt, müssen die APIs innerhalb des Graphen agentenfreundlich sein. Sie sind so konzipiert, dass sie schnell genaue, relevante Antworten liefern, ohne unnötige Token zu verwenden.

Während Sie mit den Ansichten Links, Lineage und Focus diese Verbindungen manuell erkunden können, ermöglichen Ihnen die APIs, den Graphen aus dem Code heraus zu durchlaufen, oder Sie lassen den KI-SRE von Observe dies in Ihrem Namen tun. Dies macht den Graphen abfragbar.

Ein Durchlauf folgt dem Graphen auf die gleiche Weise wie eine Untersuchung. Er beginnt mit einem Begriff („payments“, „apiserver“) und verwendet die API „search tag values“, um ihn in die Korrelations-Tag-Werte aufzulösen, die den Service oder die Ressource identifizieren – dieselben Tags, die dieses Konzept über Datasets hinweg verknüpfen. Von dort aus helfen die APIs „list of data sets“ und „list metrics“, die damit verbundenen Datasets und Metriken zu lokalisieren. Da Korrelations-Tags durchsuchbare Metadaten sind, funktioniert dies auch dann, wenn eine Umgebung Tausende davon aufweist.

Der Graph kodiert auch Observability-Expertise direkt, sodass gängige Untersuchungen kein manuelles Wiederzusammensetzen roher Telemetriedaten erfordern. Ein einziger Aufruf der API „list APM services with RED metrics“ kann Service-Rate, Fehler und Dauer zurückgeben, während die API „invocation graph“ Service-Call-Beziehungen abbildet. Da jede Antwort auf das Dataset, die Metrik und das Zeitfenster dahinter verweist, ist der nächste Schritt in der Untersuchung zielgerichtet und keine blinde Suche.

Um die Vorteile des Observability Context Graph zu nutzen, müssen Sie zunächst Infrastrukturdaten in das Telemetry Data Lakehouse übertragen. Wir empfehlen die Verwendung des Observe Agent zum Sammeln Ihrer Daten, aber Sie können auch benutzerdefinierte Integrationen oder einen vorhandenen OpenTelemetry-Collector verwenden.

Erkunden Sie Observe by Snowflake, um zu sehen, wie verbundene Telemetriedaten schnellere Untersuchungen unterstützen.