Prometheus 3.15 scrapt über Unix-Sockets und lädt Log-Stufen im Betrieb
Victoria Shinder2 Min. LesezeitPrometheus 3.15.0 ist am 25. September erschienen. Zwei neue Funktionen verändern den Betrieb des Servers. Scrape-Ziele lassen sich jetzt über Unix Domain Sockets erreichen - passend für Exporter, die gar keinen Netzwerkport öffnen sollen. Und die Log-Stufe lässt sich über die Einstellung runtime.log_level festlegen, die beim Neuladen wirksam wird; das Flag --log.level ist damit zugunsten der Konfigurationsdatei veraltet.
Auch der Speicher bekommt Aufmerksamkeit. Mit dem neuen Flag --auto-gomemlimit.refresh-interval erkennt Prometheus die Speichergrenze des Containers oder Systems regelmäßig neu und passt Gos GOMEMLIMIT im laufenden Betrieb an, statt sie nur beim Start zu lesen. Bei der Aufnahme von Daten implementiert das Release das Scrape-Format OpenMetrics 2.0, unterstützt zstd-komprimierte Antworten hinter dem Feature-Flag zstd-scrape und senkt die CPU-Last beim Initialisieren des TSDB-Heads. Die XOR2-Kodierung für Float-Chunks ist jetzt stabil: Das Flag xor2-encoding ist zugunsten von storage.tsdb.chunk_encoding.floats: xor2 veraltet, mit dem Hinweis, vorher zu prüfen, ob andere Software, die die TSDB direkt liest - etwa ein Thanos-Sidecar -, XOR2 unterstützt.
Eine Korrektur verdient genaues Lesen. Eine Range-Abfrage, deren end nicht am step ausgerichtet war, ließ Subqueries darin über den letzten tatsächlichen Schritt hinaus auswerten. Das blähte peakSamples in der Abfragestatistik und gegenüber dem Limit query.max-samples auf und las Daten aus dem Speicher, die im Ergebnis nie auftauchten.
Was das bedeutet
Die Änderung an der Log-Stufe ist klein, aber im Betrieb willkommen. Mehr Ausführlichkeit während eines Vorfalls bedeutete bisher einen Neustart mit anderem Flag, der Zustand im Speicher verliert und das untersuchte Verhalten selbst verändern kann. Als neu ladbare Einstellung wird daraus eine Konfigurationsänderung. Das laufende Neuerkennen der Speichergrenze schließt eine ähnliche Lücke bei Containern, deren Grenzen im Betrieb geändert werden - eine nur beim Start gelesene Grenze ließe die Go-Laufzeit auf den alten Wert eingestellt.
Die Subquery-Korrektur betrifft alle, die mit Dashboards über nicht ausgerichtete Zeiträume an query.max-samples gestoßen sind: Ein Teil dieser Ablehnungen ging auf Daten zurück, die die Abfrage gar nicht brauchte. Und der XOR2-Hinweis ist die Zeile, auf die man vor dem Umstellen der Speichereinstellungen reagieren sollte - ein Format, das der Server versteht, ein Sidecar aber nicht, fällt erst auf, wenn Daten zurückgelesen werden.