← Projecten

Een logcluster van 24 TB dat volloopt: meten, stabiliseren en een koers kiezen

Een Graylog-cluster met data vanaf 2019, 15.000 shards en een journal die volliep. Hoe ik het die dag stabiliseerde, met alleen-lezen metingen voorspelde wanneer de schijf vol zou zijn, en waarom de oplossing niet 'meer Graylog' is.

Het incident

Op een maandagochtend stond de uitvoer van één Graylog-node op nul: de process- en outputbuffers zaten op 100 % en de journal liep vol. 19 miljoen berichten, ruim 40 % van de journal, en vol rond vijf uur 's middags. Als die journal vol is, gaan er logs verloren, en de bewaarplicht is minimaal vijf jaar.

De stabilisatie: de node uit de load balancer, Graylog herstarten (niet Elasticsearch), en meten. Daarna nam Elasticsearch ~3.000 berichten per seconde op tegen ~2.300 instroom, en liep de achterstand in een paar uur weg.

Meten zonder in te loggen

Alles via alleen-lezen bronnen: Prometheus, de _cat- en _nodes/stats-API's van Elasticsearch en de load-balancerstatus van Graylog. Bewust geen _tasks: lopende zoekopdrachten kunnen persoonsgegevens bevatten.

Het beeld:

Data~24 TB, vanaf 2019
Indices / shards~3.900 / ~15.000 (4 primaries, 0 replica's)
Groei~78 GB per dag per node
Vrij3,8 TB per node
Heap98 % na garbage collection op één node, ~14 GiB segmentgeheugen per node

Met die groei is de schijf rond begin december vol. Replicatie terugzetten past niet meer op de schijven; die was ooit bewust uitgezet als oplossing voor een eerder probleem.

Waar komt het volume vandaan?

Een telling van veldwaarden (alleen aantallen, geen inhoud) liet zien dat het grootste deel van het volume uit framework-logging bestaat: databasecommando's, hosting- en routingdiagnostiek, naast de eigenlijke requestlogs. Eén applicatie leverde ~75 % van alle instroom. Er wordt simpelweg te veel gelogd.

Ook zichtbaar: velden met gevoelige namen bestaan in de indexen. De waarden heb ik niet bekeken, maar het hoort wel in de afweging over bewaartermijn en toegang.

De koers

  • Geen nieuwe Graylog. Uitbreiden lost het volumeprobleem niet op en verlengt een platform dat aan zijn eind is.
  • Overstappen naar Loki, op dezelfde manier als bij de acceptatieomgeving: Alloy neemt per poort de ingangen over, en Graylog wordt alleen-lezen voor de historie.
  • Minder loggen bij de bron, met het ontwikkelteam: frameworkniveau omlaag en requestlogs gestructureerd.
  • Korte termijn: alerts op journal-vulling en buffers, een snapshot-repository, en minder shards per index.
  • Een notitie voor security over bewaartermijn, toegang en gevoelige velden, want dat besluit ligt niet bij beheer.

Les

Een cluster dat "het altijd deed", kan jaren aan technische schuld verbergen. Meet eerst, met alleen-lezen bronnen, en maak een voorspelling met een datum erbij. "Rond begin december is de schijf vol" zet meer in beweging dan "het cluster is oud".