Bessere Observability mit Metadaten

Metadaten sind in der Informationstechnologie allgegenwärtig. Die erste Beschreibung von „Metadaten“ für Computersysteme wird David Griffel und Stuart McIntosh vom MIT im Jahr 1967 zugeschrieben. Ursprünglich bestand der Hauptzweck von Metadaten darin, den physischen Standort der Daten von Lochkarten und Bändern in einem Regal und später im Zuge der Weiterentwicklung der digitalen Technologie auf Festplattenlaufwerken und in Ordnern zu ermitteln. In einer nahezu grenzenlosen Telemetriedatenbank ist der physische Standort der Daten für Benutzer:innen tendenziell weniger wichtig, wobei wir Dinge wie Konto-IDs und benannte Umgebungen (z. B. QA, DEV, Prod) als logische Proxys für die physische Organisation betrachten können.

Im Kern sind Telemetriedaten eigentlich nur eine Reihe von Zahlen.  Einige repräsentieren eine Anzahl, andere Größen und manchmal eine qualitative Zeichenfolge, die eine Bedingung wie OK, PASS, FAIL angibt.  Einige Werte sind höher als vor einer Stunde, andere niedriger.  Das liegt in der Natur der Zeitreihendaten, aus denen New Relic hauptsächlich besteht.  Ohne die Fähigkeit, Telemetriedaten durch Vergleich und Gegenüberstellung gleicher oder ungleicher Gruppen zu analysieren, sind wir quasi nicht in der Lage, fundierte, datengestützte Entscheidungen zu treffen.  Auf der obersten Ebene gruppieren alle Standard-Agents von New Relic die Telemetrie zumindest unter einem gemeinsamen Anwendungsnamen und einer gemeinsamen Anwendungs-ID.  Das ist notwendig, reicht aber für die moderne Observability nicht aus.  In diesem Blog wird erklärt, wie nützlich Metadaten sein können, wie Metadaten in New Relic verwaltet werden und wie ein einfacher Standard für Entity-Metadaten aussehen kann.

Warum wir Metadaten brauchen

Ganz allgemein helfen Ihnen Metadaten bei Folgendem:

• Suche nach Entities und Telemetrie, wenn Sie zwar die relevanten Merkmale kennen, aber möglicherweise nicht alle zugehörigen Entities oder Datensätze (oder wenn diese zu zahlreich sind, um sie als eine große Einheit zu analysieren).
• Visualisierung von Entities und Telemetrie anhand relevanter Merkmale.  Dies ist hilfreich, um die relative Größe der Gruppen zu erkennen und Anomalien darzustellen, wenn Gruppengrößen nicht plausibel sind.
• Routing zu und Antwort auf Workflows, die auf dem Tag dazugehöriger Entities basieren.
• Planung von Aktivitäten und Bewertung der Compliance verschiedener Entities (beispielsweise um sicherzustellen, dass alle Server eines Teams auf die neueste Linux-Version aktualisiert wurden).
• Reporting strategischer Geschäfts- und Unternehmens-KPIs, um herauszufinden, welche Geschäftsbereiche gut laufen und welche verbessert werden müssen.

Ein realistischer Observability-Anwendungsfall für die Verwendung von Tags ist beispielsweise eine Situation, in der wir feststellen, dass eine Anwendung plötzlich eine große Anzahl von Fehlern auslöst.  Möglicherweise haben wir bereits einen Incident-Workflow eingerichtet, und mit dem richtigen Tagging-Schema wissen wir, …

• ... welchem Team diese Entity gehört (wenden Sie sich bei Bedarf an dieses Team)
• … wer für das Code-Repository verantwortlich ist (laden Sie die Verantwortlichen in eine Incident-Einsatzzentrale ein)
• … welche Betriebsregion betroffen ist (Triage nach Geschäftsauswirkungen, regionalen SLA-/Compliance-Vorgaben)
• … welche Geschäftseinheit betroffen ist (Triage nach Geschäftsauswirkungen, Incident-Kosten pro Stunde)

Ansatz 1: Tagging zur Organisation von Entities

Tags aus den folgenden Quellen werden in einigen Fällen automatisch auf Entities angewendet:

• Konto-Metadaten
• New Relic Agent-Kontext
• OpenTelemetry-Agent-Kontext
• Infra-Agent-Kontext

Es gibt verschiedene Möglichkeiten, Tags in New Relic anzuzeigen und mit ihnen zu interagieren. Der einfachste Weg besteht darin, in einer unserer kuratierten Ansichten wie APM auf das Tag-Symbol zu klicken. Dieses Symbol zeigt Ihnen auch die Anzahl der zugehörigen Tags an.

Sie sehen dann alle Tags und können sogar manuell weitere hinzufügen.

Für eine ganzheitlichere Ansicht können Sie den Entity Explorer verwenden, um Entities zu filtern und zu gruppieren (einschließlich Standardkriterien wie „Entity Type“).

Für Standard-Entity-Typen wie APM können Sie Tags in die NRQL-Abfragen (New Relic Query Language) aufnehmen. Dadurch verwischen die Grenzen zwischen einfacher Datenorganisation und Analyse. Die folgende Abfrage kann uns beispielsweise die Anzahl der Transaktionsfehler anzeigen, die bestimmten Teams zugeordnet sind. Den Tags, die in NRQL verfügbar sind, ist „Tags“ vorangestellt:

FROM TransactionError select count(*) facet tags.Team

Das Ergebnis wird wie jede andere Attributfacette angezeigt.

Es ist klar, dass einer der größten Vorteile von Tags darin besteht, Daten verwertbarer zu machen.   Wie oben gezeigt, kann das „Routing“ von Incidents effektiver umgesetzt werden, wenn wir z. B Kenntnisse darüber haben, wem der Code gehört oder wie wir mit Problemen umgehen sollen.

Die meisten Teams neigen dazu, mit dem Tagging nach Angabe des Teamnamen und der Umgebung aufzuhören. Es gibt jedoch keinen Grund, warum wir nicht mehr Kontext hinzufügen können, beispielsweise ein Tag für „help-channel“.

Zusätzlich zur Visualisierung können diese Tags als Teil des New Relic Incident-Workflows in die Incident-Payloads einbezogen werden. Weitere Informationen zu den vielfältigen Einsatzmöglichkeiten von Tags finden Sie in unserer Dokumentation.

Ansatz 2: Custom-Attribute für dynamische Einblicke

Es gibt Zeiten, in denen Tags aufgrund ihres Entity-Fokus nicht die granulare Differenzierung bieten können, die wir bei Telemetriedatensätzen benötigen. Wenn wir in der Lage sein müssen, eine einzelne Telemetrieeinheit dynamisch zu kategorisieren, sollten wir Custom-Attribute in Betracht ziehen. Custom-Attribute werden häufig verwendet, um bestimmte Faktoren des Benutzererlebnisses oder allgemeiner den „Zustand“ einer Anwendung bzw. eines Systems zu einem bestimmten Zeitpunkt für eine bestimmte Anfrage zu erfassen. Beispiele für dynamische Zustandsinformationen sind:

• Benutzerkontext
  • Benutzer-ID
  • Benutzerstandort
  • Andere Informationen zur Benutzergruppe (Basic oder Pro)
• Anfragekontext
  • Verwendetes Produkt oder Unterprodukt
  • Produkttyp 
    • Versicherungskategorie (Motorrad, Kfz, Wohnmobil)
    • Streamingvideo-Kategorie (Sci-Fi, Comedy usw.)
    • Detaillierte Informationen zu Benutzergeräten (Android-Version usw.)

Aber auch wenn Custom-Attribute scheinbar die perfekte Lösung für unsere Metadatenprobleme sein können, sollten wir uns einiger Nachteile bewusst sein, darunter:

• Sie werden nicht zentral gemanagt, sondern auf Code-Ebene.
• Oft sammeln sich viele veraltete Attribute an.
• Für jedes hinzugefügte Attribut fallen zusätzliche Telemetrie-Erfassungskosten an.
• Attribute mit sehr hoher Kardinalität können zu Performance-Problemen führen.
• Kontoeinschränkungen (z. B. das Erstellen einer eindeutigen ID für jede einzelne Anfrage einer App ist nicht machbar).

New Relic APM-, Browser- und mobile Agents verfügen alle über integrierte Funktionen zum Einfügen von Custom-Attributen. Weitere Details finden Sie in unserer Dokumentation.

Ansatz 3: Lookup-Tabellen für Ad-hoc-Einblicke

Es wird niemals möglich sein, alle nützlichen Metadaten zum Zeitpunkt der Instrumentierung zu erfassen. Viele Metadaten sind kurzlebig (da projektbezogen), und manchmal lohnt es sich nicht, Metadatenstandards für Dutzende von Tags oder Attributen durchzusetzen, wenn diese hauptsächlich für Ad-hoc-Analysen verwendet werden. New Relic hat hierfür eine Lösung. Sie können eine CSV-Datei als Lookup-Tabelle in New Relic hochladen. Diese CSV-Datei kann dann wie jeder andere Telemetrie-Namespace (z. B. Log, Transaktion, SystemSample) verwendet werden. Mithilfe der NRQL-Join-Syntax können Sie alles in der CSV-Datei mit allen vorhandenen Telemetriedaten in Beziehung setzen – vorausgesetzt, Sie haben einen gemeinsamen Schlüssel. Solange Sie also ein oder zwei Metadatenelemente auf sehr hoher Ebene durchsetzen, können Sie Ad-hoc-Lookups nach Bedarf verknüpfen. Ein Beispiel aus der Praxis ist ein Unternehmen, das ein unternehmensweites APP_ID-Tag verwendet. Dieses Tag wird für alles verwendet, von APM über Infrastruktur bis hin zu AWS-Streaming-Metriken. In diesem Zusammenhang ist APP_ID ein logischeres Konzept, das sich auf alle zugehörigen Anwendungen und Infrastrukturen bezieht, die einen logischen Geschäftsdienst wie „Inventarverwaltung“ bilden. Dies kann besonders für das Tracking von Projekten nützlich sein.

Angenommen, das Unternehmen verfügt über eine CSV-Datei zum „migration_status“, die den Cloudmigrationsstatus einiger Apps verfolgt.

Wir können den Inhalt beliebiger Lookup-Tabellen mithilfe der folgenden NRQL-Abfrage aufrufen:

FROM lookup(migration_status) SELECT *

Wenn wir als absolutes Minimum das Tag APP_ID durchgesetzt haben, können wir detaillierte Berichte über migrierte Hosts erstellen, die mit dem Team zusammenhängen, dem sie gehören.

FROM SystemSample JOIN (FROM lookup(migration_status) SELECT count(*) where MIGRATED = 'Yes' FACET APP_ID, TEAM limit max) ON APP_ID SELECT uniqueCount(hostname) as 'Hosts Migrated By Team' where APP_ID is NOT NULL facet TEAM  since 1 week ago

Ein einfaches Beispiel für einen Metadaten-Standard

Dieser simple fünfteilige Tagging-„Standard“ ist eine Zusammenfassung verschiedener Ansätze, die für Observability in einer Reihe von Unternehmen verwendet werden. Einzelne Unternehmen mögen dies ändern und stark erweitern, aber mit dieser relativ kleinen Sammlung von Tags können Sie in Ihrem Unternehmen bereits den Nutzen von Metadaten beweisen.