Die Zukunft von Prometheus und das Projektökosystem (2020)

Ca. übers. : Dies ist eine Übersetzung eines Artikels, der auf einem kürzlich gehaltenen Vortrag von Richard Hartmann basiert, einem prominenten Mitglied des Prometheus-Entwicklungsteams, Community Director bei Grafana Labs, Gründer des OpenMetrics-Projekts und Vorsitzender der SIG Observability Group bei CNCF. Der Autor fasst das letzte Jahr im Leben des Open Source-Projekts (und der Community) Prometheus zusammen und spricht über die Hauptschwierigkeiten und die nächsten Perspektiven.







Während der PromCon Online 2020 hielt ich einen Vortrag mit dem Titel "Die Zukunft von Prometheus und seinem Ökosystem". Und ich möchte Ihnen die wichtigsten Punkte mitteilen.



Zusammenfassung



Seit der letzten Konferenz PromCon - 2019 hat sich Prometheus stark verändert.





2.14



Version 2.14 verfügt über eine neue React-Oberfläche. Obwohl es in Bezug auf die Funktionalität immer noch hinter dem alten zurückbleibt, arbeiten wir daran und verbessern es weiter.



2.15



Version 2.15 stand unter dem Banner der Metadaten-API. Der Prometheus Exposure Format ist seit langem spezielle Ausdrücke unterstützt HELP, TYPEusw., aber Prometheus selbst verwendet , um einfach diese Daten zu verwerfen. Jetzt, da sie erhalten bleiben, können Sie über die API einen externen Zugriff auf sie öffnen. Zum Beispiel nutzt Grafana diese Gelegenheit bereits und bietet Benutzern zusätzliche Informationen zu den Zeitreihen, mit denen sie arbeiten:







2.16



Version 2.16 konzentriert sich auf verschiedene Verbesserungen und Stabilität. Seit 2016 fragen Benutzer beispielsweise nach der Möglichkeit, die Ortszeit in der Benutzeroberfläche auszuwählen, sowie nach der Implementierung des Abfrageprotokolls. Es war schön, diese Probleme zu schließen.



2.17



Apropos verweilende Feature-Anfragen: Version 2.17 brachte schließlich das lang erwartete "I" in ACID für die Datenbank : Isolation .



2.18



In 2.18 wurden die Ablaufverfolgung und die Unterstützung für Instanzen im Belichtungsformat verbessert. Instanzen sind die ersten vom Benutzer wahrnehmbaren Auswirkungen der Implementierung von OpenMetrics in Prometheus. Durch die Kombination mit Grafana können Sie eine bequeme Granularität erzielen, die es Ihnen ermöglicht, von:







... nach:







2.19



In 2.19 haben wir den Speicherverbrauch um bis zu 50% reduziert! Obwohl Prometheus bereits sehr effektiv ist, gibt es ein erhebliches Optimierungspotential - es ist sowohl aufregend als auch entmutigend.



Diese Grafik ist ein gutes Beispiel dafür:







2.20



Version 2.20 bietet das längste Änderungsprotokoll seit Version 2.6 (!). Das wichtigste ist wahrscheinlich die native Service Discovery-Unterstützung für Docker Swarm und DigitalOcean.



Es gibt jedoch eine wichtigere Änderung, die über die Implementierung von zwei unabhängigen Mechanismen zur Erkennung von Diensten hinausgeht: Wir nehmen Prometheus auseinander und werfen einen neuen Blick auf viele alte Lösungen und etablierte Ansätze. Die Welt hat sich verändert (vielleicht haben wir auch daran mitgewirkt) - dies muss sowohl im Projekt selbst als auch in anderen berücksichtigt werden.



node_exporter



Zusammenfassend möchte ich darauf hinweisen, dass node_exporter die Version 1.0 erreicht hat und jetzt EXPERIMENTELLE TLS-Unterstützung enthält. Die Cloud Native Computing Foundation hat die Prüfung von node_exporter durch Cure53 gesponsert (sie deckte sowohl den Exporteur im Allgemeinen als auch unsere TLS-Implementierung im Besonderen ab). Und es hat sich doppelt gelohnt: Wir haben nicht nur TLS überprüft, bevor wir es in andere Exporteure kopiert haben, sondern auch node_exporter als Versuchskaninchen verwendet, von dem andere Muster kopiert werden.



Zukunft



Manchmal habe ich das Gefühl, dass wir uns als Projekt auf unseren Lorbeeren ausruhen. Vor einiger Zeit habe ich in Grafana eine Brainstorming-Sitzung unter dem Motto "Prometheus fehlen Funktionen" durchgeführt und Red Hat dazu ermutigt, dasselbe zu tun. Unterwegs haben wir ein Dokument über ALLES erstellt, das dem gesamten Prometheus-Team zur Verfügung steht. Es dient als Rahmen für die Behandlung spezifischer Themen, die während der Dev-Summits in Diskussionspunkte unterteilt sind (sobald diese Punkte fertig sind).



Entwicklergipfel



Letztes Jahr hatten wir zwei Entwicklungsgipfel: einen nach der KubeCon EU, den zweiten nach der PromCon. Es war geplant, dasselbe im Jahr 2020 zu tun, aber COVID verhinderte dies. In diesem Jahr gab es keine Gipfeltreffen, aber ich glaube, wir haben einen Ausweg gefunden: kürzere, häufigere und virtuellere Treffen. Wir verbringen Blöcke von 4 Stunden, anstatt 1-2 Tage auf einmal zu sammeln. Der erste derartige Entwicklungsgipfel fand am 10. Juli statt, und der nächste wird wahrscheinlich am 7. August stattfinden. Wir werden sie so lange durchführen, bis wir uns mit allen gesammelten Fragen befasst haben (obwohl ihre Anzahl ständig zunimmt, wenn immer mehr Elemente aus dem obigen Dokument hinzugefügt werden).



Im Moment möchte ich zwei Dinge tun:



  1. , . , , . , . — , , .
  2. , , . , , .




Metadaten beginnen, Prometheus einen echten Wert zu verleihen (siehe 2.15 oben). Wir müssen mehr Optionen für die Arbeit mit Metadaten implementieren (z. B. über Remote-Lese- / Schreibzugriff verteilen). Der folgende Konsens behandelt keine interessanten Fragen wie "Was ist, wenn sich die Metadaten geändert haben / verschwunden sind?" oder "Was ist, wenn sie zu einem Angriffsvektor werden?"



KONSENS: Wir wollen Metadaten besser pflegen. Die Arbeiten werden in einem speziellen Dokument durchgeführt .



KONSENS: PR 6815 wird als experimentelle Problemumgehung verwendet . Höchstwahrscheinlich wird es in Version 3.x anders sein.


Workflow ändert sich und s / master / main /



Das Thema des Aufnehmens von Müll, der sich in Arbeitsprozessen angesammelt hat, bedarf keiner besonderen Erklärung, aber es sollten einige Worte zur Beseitigung von Redewendungen (Einheit der Terminologie) gesagt werden. Wir meinen es ernst mit der Bereinigung der Terminologie: Dies ist nicht das Wichtigste, aber etwas, das wir jetzt tun können. Während wir auf das entsprechende Toolkit von GitHub warten. Sobald es erscheint, werden wir versuchen, einen bezahlten Praktikanten über die Community Bridge für diese Arbeit zu gewinnen.



Ich bin in Gesprächen mit der Linux Foundation und CNCF, um dies möglicherweise in allen Projekten umzusetzen. Eine großartige Gelegenheit für alle, die sich für dieses Thema interessieren: die Gelegenheit, viele Projekte zu erkunden, mit verschiedenen Tools zu arbeiten und viele Menschen kennenzulernen. Kontaktieren Sie mich auf Twitter ( @TwitchiH ) oder per Mail ( richih auf grafana.com) wenn Sie interessiert sind.



KONSENS: Setzen Sie in allen Prometheus / Repositories "Statusprüfungen vor dem Zusammenführen erforderlich" ... Keine direkten Pushs im Hauptzweig zulassen? Keine Kraftstöße im Hauptzweig zulassen?



KONSENS: Deaktivieren Sie den Kraftdruck auf alle Hauptzweige.



KONSENS: Das Standardverhalten ermöglicht das Drücken des Hauptzweigs. Es sollte jedoch für einige "wichtige" Repos deaktiviert werden, z. B. Prometheus / Prometheus (nach Ermessen des Betreuers).


Füllen mit Daten (Verfüllen)



Dies ist eine der ältesten Feature-Anfragen und ein gutes Beispiel für die Annäherung an den Konsens. Im Prometheus-Team kursieren zu diesem Thema viele unterschiedliche Meinungen, und es ist schwierig, einen gemeinsamen Nenner zu finden. Aus diesem Grund habe ich einen begrenzten und sehr spezifischen Konsensvorschlag mit drei Kriterien verfasst: "Wir möchten das Auffüllen über das Netzwerk zumindest in Blöcken unterstützen , die sich nicht mit dem Kopfblock überschneiden ."



Nach langwierigen Diskussionen und Versuchen, einen Konsens zu erzielen, wurde klar, dass dies nicht einfach sein würde. Daher habe ich den Vorschlag wie folgt umformuliert: „Wir möchten das Auffüllen über das Netzwerk zumindest durch Streams unterstützen , die sich nicht mit dem Headblock überschneiden".



Nur indem wir alle dazu zwangen, ihre eigene Meinung zu diesem Thema zu äußern, konnten wir zur endgültigen Version gelangen: "Wir möchten das Auffüllen über das Netzwerk in Blöcken unterstützen , die sich nicht mit dem Kopfblock überschneiden, sofern es ordnungsgemäß implementiert ist ." Jedes Wort hier wurde ausgewählt, um das genaue Ausmaß und die Grenzen des Konsenses widerzuspiegeln.



: Prometheus OpenMetrics, CSV- .



: backfilling , .



: backfilling , .



: backfilling , .




Eine weitere Aufgabe, die mit der Ordnung verbunden ist. Hier möchte ich Go kritisieren: Es wurde in einer Welt entwickelt, in der Single Mono die Norm ist. Google speichert den gesamten (oder den größten Teil) seines gemeinsamen Codes in einem einzigen Repository. Dieser Ansatz hat viele Vorteile, lässt sich jedoch nicht gut auf die realen Bedingungen übertragen. Go bewegt sich langsam aber sicher von diesem Erbe weg.



Lustige Tatsache: Ich habe den Konsensvorschlag fast zu Beginn der Diskussion geschrieben. Es war klar, dass wir es zumindest versuchen würden. Es war klar, dass Ben Kochie sich freiwillig dazu melden würde. Und es war klar, dass node_exporter das "Opfer" sein würde. In der Regel bemühen wir uns, den Workflow zu verbessern, und Ben meldet sich immer freiwillig, und node_exporter ist der Prüfstand, von dem wir die Ergebnisse dann an andere Exporteure kopieren. Und ja, es war wichtig, dass die Diskussion eine Weile dauerte und dass die Leute selbst dazu kamen, anstatt sie mit einer Tatsache zu konfrontieren.



CONSENSUS: Löschen Sie es in node_exporter und prüfen Sie, ob wir mit dem Ergebnis zufrieden sind.


Mailinglisten und IRC



Google ist in China gesperrt, aber unsere Mailinglisten funktionieren darauf. Wir haben uns entschlossen, das Abonnieren per E-Mail zu ermöglichen. Ich habe überprüft: prometheus-users+subscribe@googlegroups.com funktioniert. Sie können auch die Archive lesen ( https://www.mail-archive.com/prometheus-users@googlegroups.com/maillist.html ), wenn Sie dies wünschen.



Außerdem haben wir sichergestellt, dass jeder IRC über die Matrix verwenden kann, da für einige xkcd 1782 sehr relevant ist.



:



, Google ; - .



docs/community , Google.



IRC, Matrix; , .




Lassen Sie mich wiederholen, was ich auf dem Gipfel gesagt habe: „Das allererste, was mir an Prometheus im Jahr 2015 nicht gefallen hat, war die Dokumentation. 2020 hasse ich sie einfach. Es ist schwierig zu bedienen und fast nutzlos, nur für diejenigen geeignet, die bereits wissen, was sie tun, oder zumindest eine gute Vorstellung von den Konzepten haben. " Kurz gesagt, wir werden in diese Richtung arbeiten:



:



:



* (user manual) .

* (reference) , PromQL /.

* (guides), .



Diana Payton , .. .



.


Wenn Sie interessiert sind, suchen wir derzeit einen technischen Redakteur für Grafana Cloud, der an der offiziellen Upstream-Dokumentation für Prometheus arbeitet. Letztendlich nehmen wir unser Engagement für die Gemeinschaft ernst.



Wie üblich werden die Notizen vom Dev-Summit veröffentlicht. Sie können auch die Ergebnisse des Gipfeltreffens 2020-1 und die Gipfeltreffen der vergangenen Jahre lesen .



PS vom Übersetzer



Lesen Sie auch in unserem Blog:






All Articles