Kardinalitäten von Metrics bedarfsgerecht steuern mit Metric Aggregate Pruning

Ihre Metrics überschreiten die Grenzen der Kardinalität? Mit Metric Aggregate Pruning, ab sofort als Teil von New Relic One verfügbar, gehen Sie diesen zentralen Aspekt dimensionaler Metrics bedarfsgerecht an. 

Über Metric Aggregate Pruning können Sie Regeln definieren, anhand derer Sie den Attributen Ihrer verschiedenen Metrics gewissermaßen „den richtigen Schnitt“ verleihen. Denn einige Attribute sind für langfristige Analysen von Trends und anderen Entwicklungen wichtig, sollten daher auch dauerhaft abgefragt werden. Bei anderen wiederum ist eine Abfrage nur über kürzere Zeiträume etwa für Troubleshooting-Zwecke relevant. Indem Sie diese mithilfe des Pruning-Tools ausschneiden lassen, vermeiden Sie Überschreitungen der in New Relic One geltenden Limits für Kardinalitäten, durch die Sie das Potenzial Ihrer Daten nicht mehr in vollem Umfang nutzen können.

Metric Aggregate Pruning ist Teil des Data-Dropping-Regelsatzes der Nerdgraph API für Datenmanagement.  Falls Sie mit Kardinalitäten und den für sie geltenden Limits sowie mit den API-Regeln rund um Data Dropping bereits vertraut sind und direkt loslegen möchten, finden Sie alles Nötige in der zugehörigen Dokumentation sowie im vorliegenden Dokument ab dem Abschnitt Anwendung von Metric Aggregate Pruning.

Womöglich möchten Sie Ihr Wissen rund um Kardinalitäten und dazu, wie Sie eine Überschreitung der für sie geltenden Limits erkennen, noch einmal auffrischen. Hierzu finden Sie im Folgenden einen kurzen Exkurs. Im Anschluss daran gehen wir dann auf drei Strategien zur Lösung der Problematik ein. 

Kardinalität im Kontext von Metrics 

Metrics bilden das Zahlenfundament, das Observability erst möglich macht. Mit ihnen lässt sich einmal eine Momentaufnahme des Zustands eines bestimmten Datenpunkts zu einer bestimmten Zeit quantifizieren (z. B. die CPU-Auslastung auf einem System in Prozent), außerdem aber auch zusammengefasste bzw. aggregierte Einzelgrößen, z. B die Byte-Menge, die innerhalb einer Minute über ein Netzwerk übermittelt wird. Kennzahlen wie diese eignen sich ideal, um Trends oder Änderungsraten im Zeitverlauf abzubilden.

Im Monitoring-Kontext steht die Kardinalität für die Anzahl der eindeutigen Kombinationen von Schlüssel-Wert-Paaren, die für die verschiedenen in einer Metric zusammengefassten Attribute möglich sind.  Ein Beispiel wäre, dass Sie aus jedem Ihrer Systeme die CPU-Auslastung in Prozent anhand einer Metric namens „cpuPercent“ erfassen.  Durch Ergänzung des Attributs hostname können Sie das jeweilige System identifizieren, aus dem sie erfasst wird. Angenommen, Sie erfassen diese für „host1“ und „host2“, entspricht dies zwei Hosts und somit einer niedrigen Kardinalität. Die Metric umfasst mit hostname nur ein einzelnes Attribut, für das mit host1 und host2 nur zwei eindeutige Werte möglich sind. Man spricht hier von einer Kardinalität von 2. Ergänzen Sie selbige Metric „cpuPercent“ nun aber über das Attribut hostname hinaus auch um das Attribut process id, über das sämtliche auf einem System ausgeführten Prozesse erfasst werden, würde sie eine hohe Kardinalität aufweisen. Denn Systeme können Sie bekanntlich Tausende haben, entsprechend sind zwischen ihnen und Prozess-IDs also Millionen an eindeutigen Kombinationen möglich.

Niedrige und hohe Kardinalität sind gleichermaßen wichtig, wobei im Kontext von Observability insbesondere letztere zentral ist. Dies etwa in Bezug darauf, bei welchen Benutzer:innen an einem bestimmten Tag in einem bestimmten Zeitraum der Fehler 504 aufgetreten ist, wie wir in diesem Blog aufzeigen. Hinter einer Fragestellung wie dieser stehen Korrelationen immenser Datenmengen. Umso wichtiger also, dass diese schnellstmöglich abgerufen werden können. 

Daher aggregiert New Relic One aus sämtlichen Metric-Daten, die Sie an die Plattform übermitteln, in verschiedenen Zeitintervallen zusätzlich sogenannte Rollups. Dabei handelt es sich um Datenpunkte, die im Vergleich mit den Rohdaten effizienter gespeichert und zudem schneller abgefragt werden können, insbesondere über längere Zeiträume hinweg. Abhängig von der jeweiligen Abfrage entscheidet New Relic One dabei, ob es für diese auf die Rohdaten oder den ihnen zugehörigen Rollup zurückgreift und gewährleistet so ihre schnellstmögliche Abwicklung.  

Feststellen einer Limit-Überschreitung

New Relic One ist als Plattform so skalierbar wie performant, kann daher jeden Tag Millionen an eindeutigen Metric-Zeitreihen auf einem Benutzerkonto problemlos verarbeiten. Damit die Stabilität und Performance des Systems aber stets für alle Benutzer:innen gewährleistet bleibt, müssen auch wir bestimmte Grenzen ansetzen. 

Sollten die Kardinalitäten bei Ihnen diese Limits doch einmal überschreiten, wird für Ihr Konto ein Event namens NrIntegrationError ausgegeben. Dies können Sie via NRQL-Abfrage sowie in der UI von New Relic One unter dem Bereich für Limits im Data Management Hub feststellen. Ihre Daten werden jedoch auch in diesem Fall weiterhin verarbeitet und gespeichert; lediglich die Erstellung der zugehörigen Rollups erfolgt bis zum Ende des jeweiligen Tages nicht mehr.  Für Abfragen, die sich über ein Zeitfenster von mehr als einer Stunde erstrecken, sind dann keine Rollups mehr verfügbar.  

Die von Ihnen übermittelten Rohdaten werden jedoch weiterhin erfasst. Auf sie zugreifen können Sie, indem Sie die Abfrage auf ein Zeitfenster von einer Stunde oder weniger eingrenzen. Außerdem können Sie in der Abfrage das Keyword RAW angeben und so die nötigen Daten zur Behebung des Problems abrufen. Damit Ihre Metrics die Limits aber gar nicht erst überschreiten, können Sie nun das Pruning-Feature auf sie anwenden.

Anwendung von Metric Aggregate Pruning

Über den Code DROP_ATTRIBUTES_FROM_METRIC_AGGREGATES können Sie ein oder mehrere Attribute definieren, die via Metric Aggregate Pruning aus den Rollups ausgeschlossen werden. 

Dies ist ideal für Metrics mit Attributen wie der Container-ID oder anderen Unique Identifiers, die eine hohe Kardinalität aufweisen. Diese Attribute liefern wichtige Details für die Ursachenanalyse in engen Zeitfenstern, verlieren jedoch im Lauf der Zeit an Wert und besitzen mit Blick auf langfristige Trends keine Relevanz mehr. 

Der nachfolgende Screenshot zeigt am Beispiel des Attributs containerId, wie das Pruining-Tool auf eine fiktive Kennzahl namens some.metric angewendet wird.

Weitere Strategien zur Vorbeugung

Außerdem können Sie einer Überschreitung der Limits auch wie folgt vorbeugen:

• Partitionierung Ihrer Daten: Verteilen Sie sie dazu auf mehrere Unterkonten Ihres New Relic Master-Kontos. 
• Weniger wichtige Metrics oder ihnen zugehörige Attribute dauerhaft verwerfen: Dies können Sie entweder direkt im Client oder über die Data-Dropping-Features der NerdGraph API vornehmen.  Auf diese Weise werden die entsprechenden Metrics und Attribute gar nicht erst gespeichert.