Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

PromQL-Abfragen für repräsentative Diagramme schreiben

Richtlinien

Wenn SUSE Observability Daten in einem Diagramm anzeigt, muss es fast immer die Auflösung der gespeicherten Daten ändern, um sie in den verfügbaren Platz für das Diagramm einzupassen. Um die repräsentativsten Diagramme zu erhalten, befolgen Sie diese Richtlinien:

Fragen Sie nicht nach der Rohmetrik, sondern aggregieren Sie immer über die Zeit (unter Verwendung der *_over_time oder rate Funktionen).
Verwenden Sie den ${__interval} Parameter als Bereich für Aggregationen über die Zeit, er wird sich automatisch mit der Auflösung des Diagramms anpassen.
Verwenden Sie den ${__rate_interval} Parameter als Bereich für rate Aggregationen, er wird sich ebenfalls automatisch mit der Auflösung des Diagramms anpassen, berücksichtigt jedoch spezifische Verhaltensweisen von rate.

Die Anwendung einer Aggregation bedeutet oft, dass ein Kompromiss eingegangen wird, um bestimmte Muster in den Metriken mehr als andere zu betonen. Zum Beispiel zeigt max_over_time bei großen Zeitfenstern alle Spitzen, aber nicht alle Täler. Während min_over_time das genaue Gegenteil tut und avg_over_time sowohl Spitzen als auch Täler glätten wird. Um dieses Verhalten zu zeigen, hier ist ein Beispiel für eine Metrikbindung unter Verwendung der CPU-Nutzung von Pods. Um es selbst auszuprobieren, kopieren Sie es in eine YAML-Datei und verwenden Sie die Kommandozeilenschnittstelle, um es anzuwenden in Ihrer eigenen SUSE Observability (Sie können es später entfernen).

nodes:
- _type: MetricBinding
  chartType: line
  enabled: true
  tags: {}
  unit: short
  name: CPU Usage (different aggregations and intervals)
  priority: HIGH
  identifier: urn:custom:metric-binding:pod-cpu-usage-a
  queries:
    - expression: sum(max_over_time(container_cpu_usage{cluster_name="${tags.cluster-name}", namespace="${tags.namespace}", pod_name="${name}"}[${__interval}])) by (cluster_name, namespace, pod_name) /1000000000
      alias: max_over_time dynamic interval
    - expression: sum(min_over_time(container_cpu_usage{cluster_name="${tags.cluster-name}", namespace="${tags.namespace}", pod_name="${name}"}[${__interval}])) by (cluster_name, namespace, pod_name) /1000000000
      alias: min_over_time dynamic interval
    - expression: sum(avg_over_time(container_cpu_usage{cluster_name="${tags.cluster-name}", namespace="${tags.namespace}", pod_name="${name}"}[${__interval}])) by (cluster_name, namespace, pod_name) /1000000000
      alias: avg_over_time dynamic interval
    - expression: sum(last_over_time(container_cpu_usage{cluster_name="${tags.cluster-name}", namespace="${tags.namespace}", pod_name="${name}"}[${__interval}])) by (cluster_name, namespace, pod_name) /1000000000
      alias: last_over_time dynamic interval
    - expression: sum(max_over_time(container_cpu_usage{cluster_name="${tags.cluster-name}", namespace="${tags.namespace}", pod_name="${name}"}[1m])) by (cluster_name, namespace, pod_name) /1000000000
      alias: max_over_time 1m interval
    - expression: sum(min_over_time(container_cpu_usage{cluster_name="${tags.cluster-name}", namespace="${tags.namespace}", pod_name="${name}"}[1m])) by (cluster_name, namespace, pod_name) /1000000000
      alias: min_over_time 1m interval
    - expression: sum(avg_over_time(container_cpu_usage{cluster_name="${tags.cluster-name}", namespace="${tags.namespace}", pod_name="${name}"}[1m])) by (cluster_name, namespace, pod_name) /1000000000
      alias: avg_over_time 1m interval
    - expression: sum(last_over_time(container_cpu_usage{cluster_name="${tags.cluster-name}", namespace="${tags.namespace}", pod_name="${name}"}[1m])) by (cluster_name, namespace, pod_name) /1000000000
      alias: last_over_time 1m interval
  scope: (label = "stackpack:kubernetes" and type = "pod")

Nach der Anwendung öffnen Sie die Metrikperspektive für einen Pod in SUSE Observability (vorzugsweise einen Pod mit einigen Spitzen und Tälern in der CPU-Nutzung). Vergrößern Sie das Diagramm mit dem Symbol in der oberen rechten Ecke, um eine bessere Ansicht zu erhalten. Jetzt können Sie auch das Zeitfenster ändern, um zu sehen, welche Auswirkungen die verschiedenen Aggregationen haben (30 Minuten vs. 24 Stunden zum Beispiel).

Wenn die Metrikbindung keine Aggregation angibt, wird SUSE Observability automatisch die last_over_time Aggregation verwenden, um die Anzahl der Datenpunkte für ein Diagramm zu reduzieren. Siehe auch Warum ist das notwendig? für eine Erklärung.

Das Diagramm für diese Metrikbindung für die letzten 30 Minuten

Warum ist das notwendig?

Zunächst einmal, warum sollten Sie eine Aggregation verwenden? Es macht keinen Sinn, mehr Datenpunkte aus dem Metrik-Speicher abzurufen, als im Diagramm Platz finden. Daher bestimmt SUSE Observability automatisch den benötigten Schritt zwischen 2 Datenpunkten, um ein gutes Ergebnis zu erzielen. Für kurze Zeitfenster (zum Beispiel ein Diagramm, das nur 1 Stunde Daten anzeigt) ergibt sich ein kleiner Schritt (etwa 10 Sekunden). Metriken werden oft nur alle 30 Sekunden erfasst, sodass bei 10-Sekunden-Schritten der gleiche Wert für 3 Schritte wiederholt wird, bevor er zum nächsten Wert wechselt. Wenn man auf ein Zeitfenster von 1 Woche herauszoomt, ist ein viel größerer Schritt erforderlich (etwa 1 Stunde, abhängig von der genauen Größe des Diagramms auf dem Bildschirm).

Wenn die Schritte größer werden als die Auflösung der erfassten Datenpunkte, muss eine Entscheidung getroffen werden, wie die Datenpunkte des 1-Stunden-Zeitraums in einen einzelnen Wert zusammengefasst werden. Wenn in der Abfrage bereits eine Aggregation über die Zeit angegeben ist, wird diese verwendet, um dies zu tun. Wenn jedoch keine Aggregation angegeben ist oder wenn das Aggregationsintervall kleiner ist als der Schritt, wird die last_over_time Aggregation verwendet, mit der step Größe als Intervall. Das Ergebnis ist, dass nur der letzte Datenpunkt für jede Stunde verwendet wird, um alle Datenpunkte in dieser Stunde zusammenzufassen.

Zusammenfassend lässt sich sagen, dass bei der Ausführung einer PromQL-Abfrage für einen Zeitraum von 1 Woche mit einem Schritt von 1 Stunde diese Abfrage:

container_cpu_usage /1000000000

automatisch in Folgendes umgewandelt wird:

last_over_time(container_cpu_usage[1h]) /1000000000

Probieren Sie es selbst im SUSE Observability Playground aus.

Max über die Zeit mit automatischem Bereich

Oft ist dieses Verhalten nicht beabsichtigt, und es ist besser, selbst zu entscheiden, welche Art von Aggregation benötigt wird. Mit verschiedenen Aggregationsfunktionen ist es möglich, bestimmtes Verhalten zu betonen (auf Kosten, anderes Verhalten zu verbergen). Ist es wichtiger, Spitzen, Täler, ein glattes Diagramm usw. zu sehen? Verwenden Sie dann den ${__interval} Parameter für den Bereich, da er automatisch durch die step Größe ersetzt wird, die für die Abfrage verwendet wird. Das Ergebnis ist, dass alle Datenpunkte im Schritt verwendet werden.

Der ${interval} Parameter verhindert ein weiteres Problem. Wenn die step Größe und damit der ${interval} Wert auf eine kleinere Größe als die Auflösung der gespeicherten Metrikdaten schrumpfen würde, würde dies zu Lücken im Diagramm führen.

Daher wird ${__interval} niemals kleiner als das 2-fache des standardmäßigen Abfrageintervalls (das standardmäßige Abfrageintervall beträgt 30 Sekunden) des SUSE Observability-Agenten.

Schließlich benötigt die rate() Funktion mindestens 2 Datenpunkte im Intervall, um überhaupt eine Rate zu berechnen. Mit weniger als 2 Datenpunkten wird die Rate keinen Wert haben. Daher ist ${__rate_interval} garantiert immer mindestens das 4-fache des Abfrageintervalls. Dies garantiert, dass es keine unerwarteten Lücken oder andere seltsame Verhaltensweisen in den Raten-Diagrammen gibt, es sei denn, Daten fehlen.

Es gibt einige ausgezeichnete Blogbeiträge im Internet, die dies ausführlicher erklären:

Siehe auch

Einige weitere Ressourcen zum Verständnis von PromQL-Abfragen: