{"id":10484,"date":"2026-09-21T12:30:00","date_gmt":"2026-09-21T10:30:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10484"},"modified":"2026-10-26T13:45:35","modified_gmt":"2026-10-26T12:45:35","slug":"warum-prometheus-auf-dem-raspberry-pi-viel-speicher-braucht-zu-viele-messreihen-finden","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/raspberry-pi-de\/warum-prometheus-auf-dem-raspberry-pi-viel-speicher-braucht-zu-viele-messreihen-finden\/","title":{"rendered":"Warum Prometheus auf dem Raspberry Pi viel Speicher braucht: Zu viele Messreihen finden"},"content":{"rendered":"

Die Zahl der Exporter allein reicht zur Auslegung eines Raspberry Pi mit Prometheus nicht aus. Entscheidend sind unter anderem die Anzahl der Zeitreihen, die Abtastrate, Abfragen und Aufbewahrung. Eine Zeitreihe wird durch den Metriknamen und die vollst\u00e4ndige Kombination der Labelwerte identifiziert.<\/p>\n

Die Anzahl unterschiedlicher Kombinationen hei\u00dft Kardinalit\u00e4t. Das Produkt der Wertemengen ist eine Obergrenze, keine automatisch erreichte Anzahl: Nicht jede Kombination muss vorkommen. Ein zus\u00e4tzliches Label mit nur einem festen Wert vervielfacht die Anzahl nicht. Ein Label mit vielen wechselnden Werten kann dagegen erhebliche Kosten verursachen.<\/p>\n

\n\"Beispielhafte\n
Beispielhafte Obergrenze: 3 \u00d7 5 \u00d7 8 \u00d7 40 \u00d7 2.400 = 11.520.000 Kombinationen. Nur tats\u00e4chlich bereitgestellte Kombinationen erzeugen Serien.<\/figcaption>\n<\/figure>\n

Wertemengen und Wechselrate getrennt betrachten<\/h2>\n

Ein Label braucht eine kontrollierbare Wertemenge und einen Zweck. Bei method<\/code> und status<\/code> h\u00e4ngt die tats\u00e4chliche Anzahl von der Anwendung und der Instrumentierung ab. HTTP legt weder genau f\u00fcnf Methoden noch genau zw\u00f6lf Statuswerte fest. Unbekannte Methoden lassen sich beispielsweise auf einen gemeinsamen Ersatzwert abbilden.<\/p>\n

Rohe Pfade wie \/wp-admin<\/code>, \/.env<\/code> oder \/product\/12345<\/code> k\u00f6nnen zus\u00e4tzliche Serien erzeugen, wenn die Instrumentierung jeden Pfad als Label \u00fcbernimmt. Eine erneute Anfrage mit derselben vollst\u00e4ndigen Labelkombination erzeugt keine weitere Serie. Die gespeicherten Daten bleiben au\u00dferdem nicht unbegrenzt erhalten, sondern unterliegen der Aufbewahrung.<\/p>\n
Label<\/th>Typische Herkunft der Werte<\/th>Kontrolle der Kardinalit\u00e4t<\/th><\/tr><\/thead>
job \/ instance<\/td>Ziele und Konfiguration<\/td>Inventar und Zielanzahl<\/td><\/tr>
method \/ status<\/td>Anwendung und Protokoll<\/td>Zul\u00e4ssige Werte und Ersatzwert<\/td><\/tr>
handler \/ route<\/td>Routenvorlagen<\/td>Feste Routenmenge; Ersatzwert<\/td><\/tr>
path (roh)<\/td>Anfragepfade<\/td>An der Quelle normalisieren<\/td><\/tr>
user_id \/ email<\/td>Einzelne Personenkennungen<\/td>Aus aggregierten Metriken weglassen<\/td><\/tr>
container_id \/ pod<\/td>Laufende Instanzen<\/td>Bestand und Wechselrate beobachten<\/td><\/tr><\/tbody><\/table>\n

Churn bezeichnet die Entstehung und das Verschwinden von Serien, etwa durch wechselnde Pod-Kennungen. Verschwinden zehn alte und entstehen zehn neue Serien, bleibt die Gesamtzahl trotz zwanzig \u00c4nderungen gleich. Eine konstante Anzahl gleichzeitig vorhandener Serien kann hohen Churn verdecken. Innerhalb der Aufbewahrungsdauer bleiben alte Serien in den betroffenen Bl\u00f6cken relevant; bei gleichbleibender Wechselrate und begrenzter Aufbewahrung muss die Gesamtmenge jedoch nicht jede Woche weiter wachsen.<\/p>\n

Speicherbedarf ohne starre Faustzahl beurteilen<\/h2>\n

Viele Serien beanspruchen Arbeitsspeicher, CPU, Datentr\u00e4ger und Netzwerk. Aktuelle Seriendaten und Indizes, das Wiederanlaufprotokoll (Write-Ahead Log, WAL) sowie umfangreiche Abfragen tragen zum Bedarf bei. Ein fester Kilobyte-Wert pro Serie ist keine verl\u00e4ssliche Kapazit\u00e4tsgarantie: Labelgr\u00f6\u00dfen, Messwerte, Version und Abfragelast unterscheiden sich. Auch auf dem Pi kann zuerst RAM, CPU oder Speicherplatz knapp werden.<\/p>\n

Speichermangel kann zu einem Abbruch wegen Speichermangels (Out of Memory, OOM) und einer Neustartschleife f\u00fchren. Das ist eine m\u00f6gliche Fehlerfolge, keine Diagnose allein anhand eines ausgefallenen Dashboards. Prozessspeicher, Hostreserve, Neustarts, Protokolle und die zeitliche Entwicklung der Serienzahl geh\u00f6ren gemeinsam gepr\u00fcft.<\/p>\n

Gezielt nach auff\u00e4lligen Serien suchen<\/h2>\n

Die folgenden PromQL-Beispiele grenzen die Untersuchung zun\u00e4chst auf den beispielhaften Job app<\/code> ein. Ein unbeschr\u00e4nkter Scan \u00fcber alle Metriken kann gerade einen bereits belasteten Pi zus\u00e4tzlich beanspruchen. Die zweite Abfrage z\u00e4hlt nur vorhandene, nichtleere path<\/code>-Werte; ohne passende Serien liefert PromQL hier kein Ergebnis statt einer automatisch ausgegebenen null.<\/p>\n

Text<\/span>