«ExtendedPromQL» — Zusammenfassung des Vortrags von Roman Khavronenko

Ich lade Sie ein, sich die Zusammenfassung des Vortrags von Roman Khavronenko "ExtendedPromQL" anzusehen

Kurz zu mir. Mein Name ist Roman. Ich arbeite bei CloudFlare und lebe in London. Gleichzeitig bin ich Maintenance-Engineer bei VictoriaMetrics.
Und ich bin der Autor des ClickHouse-Plugins für Grafana und ClickHouse-proxy – ein kleiner Proxy für ClickHouse.

Wir beginnen mit dem ersten Teil, der «Herausforderungen der Übersetzung» heißt, und darin werde ich erzählen, dass jede Sprache oder sogar einfach eine Kommunikationssprache sehr wichtig ist. Denn so übermitteln Sie Ihre Gedanken an eine andere Person oder ein System, so formulieren Sie Anfragen. Menschen im Internet streiten darüber, welche Sprache besser ist – Java oder eine andere. Für mich ist klar, dass die Wahl auf die Aufgabe abgestimmt sein sollte, denn das alles ist spezifisch.

Lassen Sie uns von vorne beginnen. Was ist PromQL? PromQL ist die Prometheus Query Language. Damit formulieren wir Abfragen in Prometheus, um Zeitreihendaten zu erhalten.

Was sind Zeitreihendaten? Wenn wir es wörtlich nehmen, sind das drei Parameter.

Das sind:

• Worauf wir schauen.
• Wann wir darauf schauen.
• Und welchen Wert es anzeigt.

Wenn wir uns dieses Diagramm ansehen (es stammt von meinem Telefon und zeigt die Statistiken meiner Schritte), können wir schnell auf diese Fragen antworten.

Wir betrachten die Schritte. Wir sehen den Wert und die Zeit, wenn wir darauf schauen. Das heißt, anhand dieses Diagramms können wir leicht sagen, dass ich am Sonntag etwa 15.000 Schritte gemacht habe. Es handelt sich um Zeitreihendaten.

Lassen Sie uns nun versuchen, diese Daten in ein anderes Datenmodell in Form einer Tabelle zu "transformieren". Hier haben wir auch das, was wir betrachten. Ich habe hier einige zusätzliche Daten hinzugefügt, die wir als Metadaten bezeichnen werden, das heißt, es waren nicht nur ich, sondern zwei Personen, sagen wir, Jay und Silent Bob, die gegangen sind. Das ist das, was wir betrachten; was zeigt es und wann zeigt es diesen Wert.

Jetzt wollen wir versuchen, all diese Daten in einer Datenbank zu speichern. Beispielsweise habe ich die Syntax von ClickHouse verwendet. Hier erstellen wir eine Tabelle, die „Steps“ genannt wird, das heißt, das was wir betrachten. Es gibt die Zeit, in der wir darauf schauen; was es zeigt und einige Metadaten, wo wir speichern werden, wer es ist: Jay und Silent Bob.

Und um all dies zu visualisieren, werden wir Grafana verwenden, denn erstens sieht es gut aus.

Wir werden auch dieses Plugin verwenden. Es gibt zwei Gründe dafür. Erstens – weil ich es geschrieben habe. Und ich weiß genau, wie schwierig es ist, Zeitreihendaten aus ClickHouse zu extrahieren, um sie in Grafana anzuzeigen.

Wir werden dies im Graph Panel anzeigen. Dies ist das beliebteste Panel in Grafana, das die Abhängigkeit des Wertes von der Zeit zeigt, daher benötigen wir nur zwei Parameter.

Lassen Sie uns die einfachste Abfrage schreiben – wie man die Schrittstatistik in Grafana anzeigt, wobei diese Daten in ClickHouse gespeichert sind, in der Tabelle, die wir erstellt haben. Wir schreiben also diese einfache Abfrage. Wir wählen aus den Schritten. Wir wählen den Wert und die Zeit dieser Werte, also die gleichen drei Parameter, über die wir gesprochen haben.

Und als Ergebnis erhalten wir dieses Diagramm. Wer weiß, warum es so seltsam aussieht?

Richtig, es muss nach der Zeit sortiert werden.

Am Ende bekommen wir ein besseres, aber immer noch seltsames Diagramm. Wer weiß, warum? Richtig, es gibt zwei Teilnehmer, und wir geben in Grafana zwei Zeitreihen aus, denn wenn man sich das Datenmodell nochmal anschaut, dann ist jede Zeitreihe eine einzigartige Kombination aus Namen und allen Schlüssel-Wert-Paaren der Labels.

Deshalb müssen wir eine bestimmte Person auswählen. Wir wählen Jay.

Und zeichnen es nochmal. Jetzt sieht das Diagramm der Wahrheit schon näher. Es ist jetzt ein normales Diagramm und alles funktioniert gut.

Und wahrscheinlich wissen Sie, wie man dasselbe in Prometheus über PromQL macht. Ungefähr so. Ein wenig einfacher. Und wir werden das Ganze noch aufschlüsseln. Wir haben Steps genommen und filtern nach Jay. Wir geben hier nicht an, dass wir einen Wert benötigen, und wählen keine Zeit aus.

Jetzt versuchen wir, die Geschwindigkeit von Jay oder Silent Bob zu berechnen. In ClickHouse müssen wir runningDifference machen, also den Unterschied zwischen Punktpaaren berechnen und durch die Zeit teilen, um die genaue Geschwindigkeit zu erhalten. Die Abfrage sieht ungefähr so aus.

Und es wird ungefähr solche Werte anzeigen, das heißt, Silent Bob oder Jay machen ungefähr 1,8 Schritte pro Sekunde.

Und in Prometheus wissen Sie auch, wie man das macht. Viel einfacher, als es vorher war.

Um es in Grafana weiterhin einfach zu halten, habe ich eine Art Wrapper hinzugefügt, der PromQL sehr ähnelt. Dieser wird als Rate Macros bezeichnet oder wie auch immer Sie ihn nennen möchten. In Grafana schreiben Sie einfach "rate", aber tief im Inneren verwandelt sich dies in eine umfangreiche Anfrage. Sie müssen sich nicht einmal damit auseinandersetzen; sie existiert im Hintergrund, wodurch Sie viel Zeit sparen, denn das Schreiben solcher großen SQL-Abfragen ist immer aufwendig. Sie könnten leicht einen Fehler machen und dann lange nicht verstehen, was passiert.

Hier ist eine Anfrage, die nicht einmal auf eine Folie passte und ich sie auf zwei Spalten aufteilen musste. Das ist ebenfalls eine Anfrage in ClickHouse, die dasselbe rate berechnet, aber für beide Zeitreihen: sowohl für Silent Bob als auch für Jay, damit wir auf unserem Dashboard zwei Zeitreihen haben. Das ist schon sehr komplex, finde ich.

Und für Prometheus wäre das sum(rate). Für ClickHouse habe ich ein separates Makro erstellt, das RateColumns heißt und wie eine Anfrage in Prometheus aussieht.

Wir haben geschaut und PromQL scheint großartig zu sein, aber es hat natürlich auch seine Einschränkungen.

Das sind:

• Limitierte SELECT.
• Grenz-JOIN.
• Keine Unterstützung für HAVING.

Wenn Sie lange mit ihm gearbeitet haben, wissen Sie, dass es manchmal sehr schwierig ist, etwas in PromQL zu erledigen, während dies in SQL fast alles möglich ist. All die Optionen, die wir gerade besprochen haben, hätten in SQL umgesetzt werden können. Aber wäre es praktisch, damit zu arbeiten? Das bringt mich zu dem Gedanken, dass die stärkste Sprache nicht immer die benutzerfreundlichste sein muss.

Deshalb muss man manchmal die Sprache passend zu den Aufgaben auswählen. Es ist wie der Kampf zwischen Batman und Superman. Klar, dass Superman stärker ist, aber Batman konnte ihn besiegen, weil er praktischer ist und genau wusste, was er tut.

Der nächste Teil ist die Erweiterung von PromQL.

Noch einmal zu VictoriaMetrics. Was ist VictoriaMetrics? Es ist eine Zeitreihendatenbank, sie ist OpenSource, und wir vertreiben sowohl die Single- als auch die Cluster-Versionen. Laut unseren Benchmarks ist sie die schnellste, die derzeit auf dem Markt ist, und auch bei der Kompression ähnlich – echte Nutzer berichten von einer Kompression von etwa 0,4 Byte pro Punkt, während Prometheus bei 1,2-1,4 liegt.

Wir unterstützen nicht nur Prometheus. Wir unterstützen auch InfluxDB, Graphite und OpenTSDB.

Sie können in uns "schreiben", d.h. alte Daten können übertragen werden.

Und wir arbeiten perfekt mit Prometheus und Grafana zusammen, d.h. wir unterstützen die PromQL-Engine. In Grafana können Sie einfach den Prometheus-Endpunkt durch VictoriaMetrics ersetzen, und all Ihre Dashboards funktionieren wie gewohnt.

Aber Sie können auch zusätzliche Funktionen nutzen, die VictoriaMetrics bietet.

Lassen Sie uns schnell die Funktionen durchgehen, die wir hinzugefügt haben.

Omit-Interval-Parameter – Sie können Intervalparameter in Grafana weglassen. Wenn Sie keine seltsamen Grafiken beim Heranzoomen oder Herauszoomen im Panel erhalten möchten, wird empfohlen, die Variable $__intervalzu verwenden. Das ist eine interne Variable von Grafana, die den Datenbereich selbst auswählt. Und VictoriaMetrics kann selbst verstehen, wie dieser Bereich aussehen sollte, sodass Sie Ihre Abfragen nicht aktualisieren müssen. Das wird viel einfacher.

Die zweite Funktion ist das Intervall-Referencing. Sie können dieses Intervall in Ihren Ausdrücken verwenden. Sie können es multiplizieren, dividieren, übergeben und darauf referenzieren.

Als nächstes das Familien-Set der Rollup-Funktionen. Rollup-Funktionen transformieren Ihre Zeitreihen in drei separate Zeitreihen: min, max und avg. Ich finde das sehr praktisch, weil es manchmal helfen kann, Anomalien und Ungenauigkeiten zu erkennen.

Und wenn Sie einfach nur die irate oder rate machen, dann könnten Sie wahrscheinlich einige Fälle übersehen, in denen die Zeitreihe sich nicht so verhält, wie Sie angenommen haben. Mit dieser Funktion ist es viel einfacher zu sehen, dass zum Beispiel max stark von avg abweicht.

Die nächste Variable ist default. Default bedeutet, welchen Wert wir in Grafana darstellen müssen, falls wir momentan keine Zeitreihe haben. Wann passiert das? Angenommen, Sie exportieren eine Metrik zu Fehlern. Und Ihre Anwendung läuft so gut, dass Sie beim Start keine Fehler haben und in den nächsten drei Stunden oder sogar einem Tag keine Fehler auftreten. Sie haben Dashboards, die das Verhältnis von Erfolg zu Fehlern anzeigen. Und die werden Ihnen nichts zeigen, weil Sie keine Fehler-Metrik haben. Im Default können Sie jedoch alles angeben.

Keep_last_Value – speichert den letzten Metrikwert, wenn dieser nicht mehr vorhanden ist. Falls Prometheus bei der nächsten Abfrage diesen innerhalb von 5 Minuten nicht findet, werden wir hier den letzten Wert speichern und Ihre Diagramme werden wieder korrekt sein.

Scrape_interval – zeigt, wie häufig Prometheus Daten zu Ihrer Metrik sammelt, mit welcher Frequenz. Hier könnte man beispielsweise eine Lücke sehen.

Bezeichnungsersatz – eine beliebte Funktion. Wir glauben jedoch, dass sie etwas kompliziert ist, da sie ganze Argumente annimmt. Sie müssen sich nicht nur fünf Argumente merken, sondern auch deren Reihenfolge.

Warum also nicht einfacher gestalten? Das heißt, in kleinere Funktionen mit verständlicher Syntax unterteilen.

Und jetzt das Interessante. Warum glauben wir, dass das erweiterte PromQL ist? Weil wir Common Table Expressions unterstützen. Sie können den QR-Code scannen (https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/ExtendedPromQL), um Links mit Beispielen und einem Playground anzusehen, wo Sie Abfragen direkt in VictoriaMetrics im Browser ausführen können, ohne es installieren zu müssen.

Was bedeutet das? Die Anfrage oben ist eine ziemlich gängige Abfrage. Ich denke, in jedem Dashboard vieler Unternehmen verwenden Sie denselben Filter für alles. Normalerweise ist das der Fall. Aber wenn Sie einen neuen Filter hinzufügen müssen, müssen Sie jedes Panel aktualisieren oder das Dashboard herunterladen, in JSON öffnen und eine Suche und Ersetzung durchführen, was auch Zeit in Anspruch nimmt. Warum das Ergebnis nicht in einer Variable speichern und wiederverwenden? Das erscheint mir viel einfacher und verständlicher.

Zum Beispiel, wenn ich die Filter in Grafana für alle Anfragen aktualisieren muss, während das Dashboard riesig sein kann oder sogar mehrere davon existieren. Wie könnte ich dieses Problem in Grafana lösen?

Ich gehe so vor: Ich erstelle einen commonFilter und definiere darin den Filter, den ich dann in den Anfragen wiederverwende. Wenn Sie es jetzt genauso machen, wird es jedoch nicht funktionieren, da Grafana nicht erlaubt, Variablen innerhalb von Abfragevariablen zu verwenden. Das ist ein wenig merkwürdig.

Deshalb habe ich eine Lösung entwickelt, die dies ermöglicht. Wenn Sie interessiert sind oder eine solche Funktion möchten, unterstützen Sie mich bitte oder geben Sie einen Daumen nach unten, falls Ihnen die Idee nicht gefällt. https://github.com/grafana/grafana/pull/16694

Jetzt sprechen wir über die erweiterte PromQL. Hier definieren wir nicht nur eine Variable, sondern direkt eine ganze Funktion. Wir nennen sie ru (Ressourcenauslastung). Diese Funktion nimmt freie Ressourcen, Ressourcenbeschränkungen und Filter entgegen. Der Syntax ist eigentlich ganz einfach. Es ist sehr leicht, diese Funktion zu nutzen und den Anteil des freien Speichers zu berechnen, den wir haben. Das heißt, wie viel Speicherplatz uns zur Verfügung steht, welche Begrenzung besteht und wie wir filtern. Es wäre viel praktischer, wenn Sie alles so schreiben könnten, dass Sie dieselben Filter wiederverwenden, denn das würde in eine sehr große Abfrage münden.

Und hier ist ein Beispiel für eine solche große Abfrage. Sie stammt vom offiziellen Dashboard des NodeExporters für Grafana. Aber ich habe Schwierigkeiten, zu verstehen, was hier passiert. Klar, ich kann es erahnen, wenn ich genau hinschaue, aber die Anzahl der Klammern kann die Motivation, den Inhalt zu verstehen, sofort mindern. Warum also nicht alles einfacher und verständlicher machen?

Zum Beispiel so, indem man bedeutende Dinge oder Teile in Variablen auslagert. Und dann seine grundlegenden Berechnungen durchführt. Das ähnelt bereits mehr der Programmierung, das ist es, was ich in Zukunft in Grafana sehen möchte.

Hier ist ein weiteres Beispiel, wie wir das noch einfacher machen könnten, wenn wir bereits diese Funktion in ru hätten, die es direkt in VictoriaMetrics gibt. Sie würden dann einfach den zwischengespeicherten Wert übergeben, den Sie im CTE deklariert haben.

Ich habe bereits darüber gesprochen, wie wichtig es ist, die richtige Programmiersprache zu verwenden. Wahrscheinlich gibt es in jeder Firma in Grafana etwas Eigenes. Und wahrscheinlich geben Sie Ihren Entwicklern Zugang zu Grafana, und die Entwickler machen etwas Eigenes. Und sie tun das irgendwie unterschiedlich. Es wäre wünschenswert, das irgendwie einheitlich zu gestalten, d.h. auf einen gemeinsamen Standard zu bringen.

Angenommen, Sie haben nicht nur Systemingenieure, vielleicht haben Sie sogar Experten, DevOps oder SRE. Vielleicht haben Sie Experten, die wissen, was Monitoring ist, die wissen, was Grafana ist, d.h. sie arbeiten seit Jahren damit und wissen genau, wie man es richtig macht. Und sie haben das schon 100 Mal geschrieben und allen erklärt, aber irgendwie hört niemand zu.

Was wäre, wenn sie dieses Wissen direkt in Grafana einbringen könnten, damit andere Nutzer die Funktionen wiederverwenden können? Und wenn man den Prozentsatz des freien Speichers berechnen müsste, könnte man einfach die Funktion anwenden. Was wäre, wenn die Entwickler der Exporter, zusammen mit ihrem Produkt, auch eine Sammlung von Funktionen zur Verfügung stellen würden, wie man mit ihren Metriken umgeht, da sie genau wissen, was das für Metriken sind und wie man sie korrekt berechnet?

Das existiert tatsächlich nicht. Das habe ich selbst gemacht. Das ist die Unterstützung von Bibliotheken in Grafana. Angenommen, die Jungs, die NodeExporter entwickelt haben, hätten das gemacht, was ich beschrieben habe. Und hätten zudem eine Sammlung von Funktionen bereitgestellt.

Das sieht ungefähr so aus. Sie binden diese Bibliothek in Grafana ein, gehen zur Bearbeitung und hier steht ganz einfach in JSON, wie man mit dieser Metrik arbeitet. Das heißt, eine Art Sammlung von Funktionen, deren Beschreibung und in was sie umgesetzt werden.

Ich denke, das könnte nützlich sein, denn dann würden Sie in Grafana einfach so etwas schreiben. Und Grafana "sagt" Ihnen, dass es eine solche Funktion aus dieser Bibliothek gibt – lassen Sie uns diese verwenden. Ich denke, das wäre wirklich toll.

Ein wenig über VictoriaMetrics. Wir machen viele interessante Dinge. Lesen Sie unsere Artikel über Kompression, über unsere Wettbewerbe mit anderen Zeitreihen-Datenanwendungen, unsere Erläuterungen zur Arbeit mit PromQL, da es in diesem Bereich noch viele Anfänger gibt, sowie über vertikale Skalierbarkeit und den Wettbewerb mit Thanos.

Fragen:

Ich möchte meine Frage mit einer einfachen Lebensgeschichte beginnen. Als ich zum ersten Mal mit Grafana arbeitete, formulierte ich eine sehr überzeugende Abfrage von fünf Zeilen. Das Ergebnis war ein wirklich beeindruckendes Diagramm. Dieses Diagramm war fast bereit für die Produktion. Bei genauerem Hinsehen stellte sich jedoch heraus, dass dieses Diagramm absoluten Unsinn zeigt, der nichts mit der Realität zu tun hat, obwohl die Zahlen im erwarteten Bereich lagen. Und meine Frage lautet: Wir haben Bibliotheken, wir haben Funktionen, wie schreiben wir Tests für Grafana? Sie haben eine komplexe Abfrage verfasst, von der eine Geschäftsentscheidung abhängt – ob man einen echten Container von Servern bestellen soll oder nicht. Und wie wissen wir, dass die Funktion, die das Diagramm zeichnet, der Wahrheit entspricht? Vielen Dank.

Vielen Dank für die Frage. Es gibt zwei Aspekte. Erstens habe ich den Eindruck, basierend auf meinen Erfahrungen, dass die meisten Nutzer beim Blick auf ihre Grafiken oft nicht verstehen, was ihnen diese zeigen. Irgendwie sind die Leute sehr gut darin, für jede Anomalie, die in den Grafiken auftritt, eine Erklärung zu finden, selbst wenn es sich um einen Fehler in der Funktion handelt. Zweitens, ich denke, dass die Verwendung solcher Funktionen viel besser zur Lösung Ihres Problems passen würde, anstatt dass jeder Ihrer Entwickler seine eigenen Kapazitätsplanungen vornimmt und dabei mit einer gewissen Fehlerquote scheitert.

Wie kann man das überprüfen?

Wie kann man das überprüfen? Wahrscheinlich gar nicht.

In Form eines Tests in Grafana.

Was hat Grafana damit zu tun? Grafana leitet diese Anfrage direkt an die Datenquelle weiter.

Indem man ein wenig zu den Parametern hinzufügt.

Nein, in Grafana wird nichts hinzugefügt. Es können GET-Parameter vorhanden sein, wie z.B. step. Dieser Parameter wird zwar nicht explizit angegeben, kann aber überschrieben werden. Man kann ihn überschreiben oder auch nicht, aber er wird automatisch hinzugefügt. Hier können Sie keine Tests schreiben. Ich denke, man sollte in diesem Kontext nicht auf Grafana als die einzige Wahrheit vertrauen.

Vielen Dank für den Bericht! Vielen Dank für die Kompression! Sie haben das Mapping von Variablen im Diagramm erwähnt, dass man in Grafana eine Variable nicht in einer anderen Variable verwenden kann. Verstehen Sie, worüber ich spreche?

Ja.

Das war anfangs ein Kopfzerbrechen, als ich einen Alert in Grafana erstellen wollte. Dort muss man für jeden Host separat einen Alert einrichten. Funktioniert diese Lösung, die Sie gemacht haben, für Alerts in Grafana?

Wenn Grafana nicht irgendwie anders auf Variablen zugreift, dann ja, wird es funktionieren. Aber mein Rat ist, Alerts in Grafana überhaupt nicht zu verwenden, es ist besser, den Alertmanager zu nutzen.

Ja, ich benutze ihn, aber in Grafana schien es einfacher in der Einrichtung. Vielen Dank für den Rat!

Quelle: habr.com