Entity-Synthese

Was ist eine Entity und warum sollte man Daten als Entity synthetisieren?

Ein Entity ist alles, was a) Daten an New Relic meldet oder verwandte Daten enthält, auf die man Zugriff hat, und b) Telemetrie, die mit einer eindeutigen Entity-ID versehen ist. Der Fokus auf Entities ist wichtig, da New Relic nicht nur praktischen Observability-Kontext über geschäftszentrierte Objekte bereitstellen, sondern diese auch in logischen Systemen organisieren soll. Mit mehr Einsicht auf der Entity-Ebene sowie besserem Monitoring und Troubleshooting werden moderne, komplexe Systeme einfacher zu handhaben.

Wenn Telemetrie in die New Relic Datenpipeline strömt, wird versucht, einen Datenquellentyp zu klassifizieren und die eingehende Telemetrie mit eindeutigen IDs (GUIDs genannt) zu versehen, was wiederum eine einfachere Klassifizierung der erfassten Daten ermöglicht. New Relic verfügt über einen Standardsatz von Entity-Typen, anhand derer Daten in sogenannte Entities kategorisiert werden, zum Beispiel APM, Infrastruktur, Browser und Mobile. 

Aber was passiert, wenn Telemetrie außerhalb der Standard-Agents gesendet wird, z. B. bei Verwendung von Flex, Ingest APIs oder über OpenTelemetry? Hier kommt die Entity-Synthese ins Spiel.

Die Entity-Synthese ist ein konfigurationsbasierter Prozess, der dynamisch Entity-GUIDs auf Grundlage eindeutiger Kriterien generiert, die in der eingehenden Telemetrie enthalten sind. Die Zuordnung von Telemetriedaten zu einer Entity hat mehrere Vorteile:

• Schneller Zugriff auf Telemetrie über kuratierte Experiences, einschließlich Entity Explorer, Workloads, Service-Level und alle anderen Entity-spezifischen Plattform-Features.
• Eine Standardansicht, mit der Signale von mehreren Instanzen derselben Entity verglichen werden können.
• Ein Standardsatz von Übersichtsmetriken/goldenen Signalen, die wichtige Leistungsindikatoren (KPIs) eines bestimmten Entity-Typs darstellen.
• Entities können zur einfachen Filterung und Gruppierung mit mehreren Schlüsselwertpaaren getaggt werden.
• Alert-Statusdefinitionen bieten einen intuitiven Einblick in die Health von Entities basierend auf konfigurierten Alert-Bedingungen.

Beispiel für Telemetrie (Rohform)     

Der nachstehende Screenshot zeigt Custom-Event-Rohdaten mit dem eventType event, der aus dem Abrufen, Parsen und Einfügen von Daten über die Event-API abgeleitet wird.

Diese Daten sind noch nicht mit Entity-GUIDs versehen, gelten also als unsynthetisiert und sind noch nicht einem Entity-Typ zugeordnet. Das obige eindeutige nodeUid-Attribut kann jedoch als primäre ID für die Erzeugung einer GUID verwendet werden. Weitere Informationen dazu finden Sie weiter unten in diesem Blogpost.

Dieselben Daten können leicht in einem Custom-Dashboard visualisiert werden. Unten sehen Sie das gleiche Custom-Event als Kreisdiagramm dargestellt, mit dem Schlüsselattribut „state“, das ein nützliches goldenes Signal in diesen Telemetriedaten für Visualisierung oder Alerts sein kann.

Wir empfehlen Ihnen, die Daten möglichst immer mit nützlichem Kontext zu versehen. Durch die Erstellung einer Entity können Sie diese Art von Daten einem bestimmten Entity-Typ zuordnen und letztendlich klassifizieren, so dass sie schneller erkannt und anderen Entities oder Telemetriedaten innerhalb von New Relic zugewiesen werden können.

Um Ihnen beim Festlegen von Entity-Definitionen zu helfen, hat New Relic ein öffentliches Repository für die Definition von benutzerdefinierten Entity-Typen eingerichtet, in dem viele der von New Relic erstellten Definitionen für gängige Tools wie APM oder Infrastruktur zu finden sind:

https://github.com/newrelic/entity-definitions

Die folgenden Schritte helfen Ihnen beim Umwandeln aller Telemetrie-Rohdaten (d. h. Daten, die in New Relic erfasst, aber nicht klassifiziert oder mit einer Entity-GUID versehen sind) in Entities.

Synthese der Telemetrie, Schritt für Schritt

Schritt 1: Öffentliches Repository klonen und branchen

Klonen oder forken Sie dieses Repository: https://github.com/newrelic/entity-definitions/entity-types und erstellen Sie dann einen Branch. In diesem Repository gibt es bereits Hunderte anderer Entity-Definitionen. Wir empfehlen Ihnen, sich diese bestehenden Definitionen zur Referenz anzusehen, bevor Sie zum ersten Mal eine eigene Entity-Definition erstellen. Die Dokumentation bietet auch ausführliche Informationen zu den vier erforderlichen Dateien, die zur Definition einer Entity erforderlich sind: definition.yml, dashboard.json, golden_metrics.yml und summary_metrics.yml.

Schritt 2: Syntheseregeln definieren (definition.yml)

Am Beispiel des Entity-Typs ext-solarwinds_server zeigt der folgende Screenshot die Datei definition.yml (links) und die daraus resultierende Darstellung im New Relic Entity Explorer (rechts).

Die Datei definition.yml definiert den Entity-Typ zusammen mit Regeln, die festlegen, wie eindeutige Entities generiert werden sollen. Daten, die in New Relic eingehen, werden anhand dieser Regeln überprüft, und wenn die eingehende Telemetrie damit übereinstimmt, wird sie automatisch zugeordnet und für jeden Satz übereinstimmender Daten wird eine eindeutige GUID erstellt. Im obigen Beispiel ist die eindeutige ID(npm.nodeName) die einzige ID, anhand derer eine eindeutige Entity-GUID generiert wird. Darüber hinaus definiert der Bedingungsabschnitt zwei Filterbedingungen, die den grundlegenden eventType angeben, in dem sich die Telemetrie befindet (partielle String-Übereinstimmung mit solarwinds_), sowie ein spezifisches Attribut, das zur weiteren Filterung der Telemetrie verwendet wird (npm.Category). Mit anderen Worten: Das folgende NRQL-Äquivalent zeigt, wie GUIDs anhand der angegebenen Kriterien generiert werden:

SELECT uniques(npm.nodeId) FROM solarwinds_* where npm.Category = 2

Beachten Sie auch die Kategorie „Other entities“, in die wir diesen Entity-Typ eingeordnet haben. Jeder Entity-Typ, der nicht von der New Relic Plattform stammt, erscheint in dieser Kategorie.

Ansonsten sind noch folgende Konfigurationen in der Definitionsdatei erwähnenswert:

• tags: Dabei handelt es sich um Schlüsselwertpaare in der Telemetrie, die jeder eindeutigen Entity als Tag zugewiesen werden können.
• entityExpirationTime: Die Zeitspanne, nach der die Entity aus der UI verschwindet, wenn in dem festgelegten Zeitrahmen keine Daten erscheinen.
• alertable: Legt fest, ob den erzeugten Entities Alerts hinzugefügt werden können und somit eine Statusänderung möglich ist.

lifecycle: Wie lange sollte die New Relic-Plattform die Entity vorhalten, wenn diese aufhört, Daten zu melden? Der Standardwert beträgt acht Tage und kann für jeden Entity-Typ angepasst werden.

Schritt 3: Metriken zu goldenen Signalen definieren (golden_metrics.yml)

Mit dieser Datei lässt sich definieren, welche Metriken in der Übersicht angezeigt werden – für jede eindeutige Entity (bei Mausklick darauf) und für die Abfragen, die sie definieren. Dies sind in der Regel die wichtigsten Indikatoren für eine bestimmte Entity zur Beobachtung der allgemeinen Health und Performance.

Beispiel für golden_metrics.yml

Schritt 4: Übersichtsmetriken definieren (summary_metrics.yml) 

In unserem Beispiel mit dem gleichen Entity-Typ wie zuvor definiert die Datei summary_metrics.yml, welche Hauptmetriken in der Listenansicht des Entity Explorer erscheinen sollen. Ähnlich wie bei den Metriken zu goldenen Signalen handelt es sich hierbei um wichtige KPIs, die für die Anzeige in einer Übersicht am sinnvollsten sind und typischerweise 1:1 mit den Metriken zu goldenen Signalen definiert werden. Jegliche Telemetrie in einem Dataset kann als Übersichtsmetrik konfiguriert werden.

Beispiel für summary_metrics.yml

Beispiel für Übersichtsdarstellung

Diese Ansicht ist ideal, um die Instanzen Ihres Entity-Typs schnell miteinander zu vergleichen. Die Ansicht bietet auch den Alert-Status, der eine schnelle Identifizierung problematischer Knoten ermöglicht. Wie in der Einleitung erwähnt, wird der Alert-Status für diese Entity an verschiedenen Stellen der UI visualisiert, sobald die New Relic Plattform Daten als einen Entity-Typ erkennt und mindestens ein Alert für diese Entity erstellt wurde (siehe Beispiel oben).

Schritt 5: Übersichts-Dashboard definieren (dashboard.json)

Zum Schluss wird ein Drilldown-Dashboard definiert, das alle wichtigen Metriken anzeigt, die für die Verfolgung von Performance und Gesamt-Health eines bestimmten Entity-Typs nützlich sind. In der Regel empfiehlt es sich, diese Dashboards im Voraus zu erstellen (unter Dashboards), sie in ein JSON-Format zu exportieren und daraus dann hartcodierte Konto-IDs und andere kontospezifische Daten zu entfernen. Das Entity-Definitions-Repository enthält ein Bereinigungstool, mit dem dies leicht möglich ist. Das folgende Beispiel dient als Referenz.

Beispiel für dashboard.json

Beispiel für Entity-Dashboard-Ansicht

Das json-Schema für die Datei dashboard.json ist genau dasselbe wie das Standardschema für das New Relic Dashboard. Hier wird ein Standard-Dashboard mit kritischen Signalen für eine bestimmte Entity definiert. Diese Ansicht zeigt auch den Alert-Status der Entity, den Aktivitätsstrom (Alert-Aktivität) und alle damit verbundenen Entities (z. B. vor- und nachgelagerte Dienste).

Schritt 6: Branch einchecken und Pull-Request erstellen

Sobald alle vier Dateien validiert/vervollständigt sind, können Sie den Branch festschreiben, pushen und einen Pull-Request erstellen, damit er mit dem Haupt-Branch zusammengeführt werden kann (oder einen PR für Ihren Fork senden). Die typische Bearbeitungszeit für die Überprüfung und Zusammenführung beträgt ein bis zwei Wochen.

Fazit

Sie können alle Daten, die in New Relic erfasst werden, in Entities umwandeln – auch wenn sie nicht klassifiziert oder mit einer Entity-GUID versehen sind. Die Synthese von Telemetrie-Rohdaten hat viele Vorteile, unter anderem:

• Das Framework für die Erstellung von Custom-Entities ist sehr benutzerfreundlich, da es auf Konfigurationen basiert.
• Alle Telemetriedaten, einschließlich Events oder Metriken, die an New Relic gesendet werden, können in Entities synthetisiert werden, um eine bessere kuratierte Nutzung zu ermöglichen.
• Synthetisierte Daten (Entities) sorgen für ein besseres Gesamterlebnis bei der Anzeige und Alert-Ausgabe wichtiger Telemetriedaten.
• Mehrere verknüpfte Entities lassen sich bündeln und ihre Zustände zeitlich korrelieren. 

Ein besserer Einblick auf Entity-Ebene erleichtert Ihnen das Monitoring und Troubleshooting Ihres Systems.