Zelfgehost logbeheer op één VPS: de beste aanpak

Wat zelfgehost logbeheer op één VPS werkelijk kost

Zelfgehost logbeheer op één VPS (virtual private server) komt neer op één vraag: heeft u een zoekcluster nodig, of volstaan logrotatie en een grep? De meeste handleidingen van leveranciers beantwoorden die vraag door te beginnen bij drie nodes en 12 GB RAM voordat er ook maar één logregel is verzonden. Op één server is dat antwoord onbruikbaar, dus de onderstaande vergelijking kijkt naar wat elke optie van een kleine machine vereist voordat deze ook maar iets opslaat.

Als u één of twee servers beheert en u wilt weten wat er afgelopen dinsdag is gebeurd, dan doen systemd-journald en logrotate dat werk al en kunt u na de volgende sectie stoppen. Als meerdere machines hun logs op één plek moeten afleveren met zoekmogelijkheden over meerdere weken, dan past Grafana Loki op een kleine machine, omdat deze labels indexeert en niet de tekst van de regels zelf. Elasticsearch en OpenSearch bieden echte full-text search, maar u betaalt hiervoor in geheugengebruik, omdat de JVM (Java virtual machine) heap een ondergrens heeft waar u niet onder kunt gaan.

Begin bij journald, want de meeste mensen stoppen hier

systemd-journald draait al op elke huidige Ubuntu- of Debian-server. Het legt de standaarduitvoer van elke service-unit, de kernelberichten en alles wat naar syslog wordt gestuurd vast. Vier commando's dekken de meeste incidenten.

journalctl -u nginx.service --since "2026-08-14 09:00" --until "2026-08-14 10:00"
journalctl -p err -b
journalctl -f -u ssh.service
journalctl --disk-usage

Het laatste commando toont een regel zoals Archived and active journals take up 1.1G in the file system.. Dat is het getal dat bepaalt of u nog iets anders nodig heeft. Als het enkele honderden megabytes aangeeft en u kunt vinden wat u nodig heeft met -u en --since, dan bent u klaar.

Of het journal een herstart overleeft, hangt af van Storage= en of /var/log/journal bestaat. Bij de gebruikelijke instelling Storage=auto schrijft journald naar /var/log/journal wanneer die map aanwezig is, en naar /run/log/journal wanneer dat niet zo is. /run wordt in het geheugen bijgehouden, dus op een systeem zonder die map wordt elk logbestand bij een herstart gewist; precies het moment waarop u ze wilt inzien. Ubuntu-images bevatten de map standaard. Minimale en container-gebaseerde images vaak niet.

ls -d /var/log/journal
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
journalctl --disk-usage

Na de herstart zou journalctl --disk-usage een grootte onder /var/log/journal moeten rapporteren in plaats van /run. De standaardwaarden zijn al begrensd, wat de belangrijkste reden is dat journald een serieuze oplossing is en geen noodoplossing. De man-pagina van journald.conf stelt SystemMaxUse= in op 10% van de bestandssysteemgrootte en SystemKeepFree= op 15%, waarbij elke berekende standaardwaarde wordt begrensd op 4G. SystemMaxFileSize= is standaard een achtste van SystemMaxUse=, met een maximum van 128M, dus u behoudt normaal gesproken zeven geroteerde bestanden. MaxRetentionSec= staat standaard op 0, wat verwijdering op basis van leeftijd uitschakelt. Lees die laatste standaardwaarde nog eens: standaard wordt het journal alleen beperkt door grootte, nooit door leeftijd.

[Journal]
Storage=persistent
SystemMaxUse=2G
MaxRetentionSec=30day

Schrijf dat naar /etc/systemd/journald.conf.d/99-size.conf, herstart journald en controleer vervolgens of journalctl --disk-usage richting uw nieuwe limiet is gegaan. Om nu ruimte vrij te maken in plaats van te wachten op de volgende rotatie, voert u sudo journalctl --vacuum-size=500M of sudo journalctl --vacuum-time=14d uit. Beide tonen elk bestand dat ze verwijderen; een stille uitvoering betekent dus dat er niets te verwijderen viel.

Alles buiten het journal, zoals /var/log/nginx/access.log, is de taak van logrotate, dat dagelijks via een systemd-timer wordt uitgevoerd. Eén fout is belangrijk om te kennen omdat het lijkt op een bug in df. Na een rotatie is het oude bestand uit de mappenlijst verdwenen terwijl de daemon het nog steeds open heeft staan; daarom rapporteert df -h dat de schijf vol is, terwijl du -sh /var/log veel minder aangeeft. De ruimte komt pas vrij wanneer het proces zijn logbestand opnieuw opent, waarvoor de postrotate reload-regel in de configuratie dient. sudo lsof -nP +L1 toont verwijderde bestanden die nog steeds open worden gehouden en noemt het proces dat elk bestand vasthoudt. Test een regel zonder iets aan te passen met sudo logrotate -d /etc/logrotate.d/nginx.

Logs van meerdere servers naar één collector sturen

Zodra u meer dan één server beheert, wordt het gelijktijdig beheren van meerdere Linux-servers eenvoudiger wanneer hun logs op één centrale plek binnenkomen. rsyslog is op de meeste distributies al geïnstalleerd, dus de meest efficiënte centrale collector is één bestand op elke verzendende server.

*.* action(type="omfwd" target="logs.example.com" port="514" protocol="tcp")

Sla dit op als /etc/rsyslog.d/50-forward.conf, controleer het met sudo rsyslogd -N1, wat de configuratie valideert en afsluit zonder processen te starten, en herstart vervolgens rsyslog. Schakel op de collector de TCP-input in.

module(load="imtcp")
input(type="imtcp" port="514")

Twee waarschuwingen, beide van technische aard. Standaard syslog bevat geen encryptie en geen authenticatie; alles wat poort 514 kan bereiken, kan logregels injecteren die er exact zo uitzien als die van u. Koppel de service aan een privénetwerk of een VPN en beveilig de poort met een firewall. Ten tweede bevindt de standaard actiewachtrij zich in het geheugen; wanneer de collector onbereikbaar is, raakt de wachtrij vol en gaan berichten verloren zonder dat er een kopie wordt bewaard. rsyslog documenteert een schijf-ondersteunde wachtrij voor dit scenario in de handleiding voor betrouwbare doorsturing.

Waarom de ELK stack niet geschikt is voor een kleine VPS

ELK staat voor Elasticsearch voor opslag en zoekopdrachten, Logstash voor de opname-pipeline en Kibana voor de interface. De ondergrens wordt bepaald door de JVM heap, die wordt toegewezen voordat er ook maar één logbestand binnenkomt.

De documentatie van Elastic adviseert om de heap op maximaal 50% van het totale beschikbare geheugen per Elasticsearch-node in te stellen. Dit komt doordat het proces ook off-heap buffers gebruikt en afhankelijk is van de file cache van het besturingssysteem om indexbestanden snel te kunnen lezen. Een heap van 2 GB vereist dus een machine met 4 GB RAM, nog voordat Kibana is meegerekend en voordat de applicaties waarvoor de server oorspronkelijk is aangeschaft zijn opgestart. Elastic stelt bovendien dat Elasticsearch de heap automatisch schaalt op basis van de rollen van de node en het totale geheugen. Dit betekent dat een kleine server een kleine heap krijgt en vervolgens constant bezig is met garbage collection.

Logstash is het onderdeel dat een klein budget direct overschrijdt. De eigen JVM-instellingenpagina van Elastic adviseert een heap van minimaal 4 GB en maximaal 8 GB voor een standaard opnameproces. Dat is de volledige capaciteit van een 4 GB VPS, enkel voor één proces in het midden van de pipeline.

[
  {
    "label": "Loki plus Alloy (no JVM)",
    "documented_heap_mb": 0
  },
  {
    "label": "OpenSearch demo compose",
    "documented_heap_mb": 512
  },
  {
    "label": "OpenSearch production example",
    "documented_heap_mb": 2048
  },
  {
    "label": "Logstash recommended minimum",
    "documented_heap_mb": 4096
  }
]

Dit zijn de waarden die elk project in de eigen documentatie publiceert. Het zijn geen metingen van een testomgeving; uw werklast zal deze waarden beïnvloeden. Het voorbeeld-compose-bestand van OpenSearch stelt 512 MB per node in voor een demo en 2048 MB in het productievoorbeeld, terwijl de aanbevolen ondergrens voor Logstash 4096 MB is. De heap-kolom toont 0 voor Loki en Alloy, omdat dit Go-programma's zijn die geen JVM heap hoeven te reserveren. Dat is het fundamentele verschil in één getal: een JVM-component claimt zijn reservering, ongeacht of er logs binnenkomen of niet.

Als u de Elastic stack toch op één kleine server wilt draaien, laat Logstash dan weg en verstuur logs direct naar Elasticsearch met een lichtgewicht collector. Logstash is ontworpen voor het parsen en transformeren van grote volumes; op één server kunt u dat werk aan de bron uitvoeren of achterwege laten.

Zowel Elasticsearch als OpenSearch vereisen dat vm.max_map_count wordt verhoogd naar 262144, omdat ze indexbestanden naar het geheugen mappen (memory mapping) en de standaardlimiet van Linux hiervoor te laag is. Een container die enkele seconden na het opstarten op een nieuwe server afsluit, heeft meestal uitsluitend dit probleem.

OpenSearch of Elasticsearch: welke kunt u implementeren?

De korte licentiegeschiedenis is van belang, omdat deze bepaalt wat u mag draaien. In januari 2021 stapte Elastic voor Elasticsearch en Kibana af van de Apache 2.0-licentie en koos voor een duaal model met de SSPL (Server Side Public License) en de Elastic License 2.0. AWS heeft de laatste Apache 2.0-code geforkt als OpenSearch, dat onder de Apache 2.0-licentie blijft vallen. In september 2024 voegde Elastic de AGPLv3 (GNU Affero General Public License version 3) toe als extra optie voor de vrije broncode. Voor een individu dat zelf host op één VPS, staan al deze licenties uw activiteiten toe. De licenties worden pas beperkend wanneer u de software als beheerde dienst aan anderen aanbiedt.

Het praktische verschil op een kleine server is kleiner dan de geschiedenis doet vermoeden, omdat beide onder de motorkap dezelfde engine gebruiken. De namen verschillen: index lifecycle heet ISM (Index State Management) in OpenSearch en ILM (Index Lifecycle Management) in Elasticsearch. Sinds augustus 2026 weigert OpenSearch 2.12 en later te starten zonder dat er bij de eerste uitvoering een beheerderswachtwoord is ingesteld.

sudo sysctl -w vm.max_map_count=262144
printf 'vm.max_map_count = 262144\n' | sudo tee /etc/sysctl.d/99-opensearch.conf
docker run -d -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" \
  -e "OPENSEARCH_INITIAL_ADMIN_PASSWORD=<custom-admin-password>" \
  opensearchproject/opensearch:latest

De sysctl -w-regel past de instelling direct toe en het bestand in /etc/sysctl.d/ is het deel dat een herstart overleeft. Controleer of de container is opgestart met curl -k -u admin:<password> https://localhost:9200. Deze reageert via https met een democertificaat, dus -k slaat de verificatie over; een gezond antwoord is een klein JSON-blok met de naam van het cluster en de versie. De installatiepagina van OpenSearch adviseert gebruikers van Docker Desktop bovendien om de host ten minste 4 GB geheugen toe te wijzen, wat een goede indicatie is van wat het proces verwacht.

Hoe Loki compact blijft: labels in plaats van een volledige tekstindex

Loki houdt één index bij op basis van labels en slaat de logregels op als gecomprimeerde chunks. Een query selecteert eerst streams en filtert daarna op tekst. {unit="ssh.service"} |= "Failed password" kiest de stream op basis van het label en scant vervolgens die chunks op de betreffende string. De inhoud van een regel wordt niet geïndexeerd, waardoor de opname (ingestion) goedkoop blijft en er geen inverted index in het geheugen hoeft te worden bijgehouden. De kosten verschuiven naar het moment van de query, en dat is een goede afruil wanneer u doorgaans weet naar welke service u kijkt.

De documentatie van Grafana plaatst de monolithische modus, waarbij heel Loki in één proces draait met -target=all, bij kleine lees- en schrijfvolumes tot ongeveer 20GB per dag. Eén VPS valt ruim binnen die limiet.

De valkuil is label-cardinaliteit. Elke unieke combinatie van labelwaarden vormt één stream, en het aantal streams bepaalt het geheugengebruik en de indexgrootte van Loki. Een label dat een client-IP-adres of een request-identifier bevat, creëert een stream per waarde. Een drukke webserver kan daardoor tienduizenden streams per dag produceren, waardoor het proces groeit totdat de kernel het stopt. Beperk labels tot waarden die u op papier zou kunnen tellen: unit, host, job, level. Plaats variabele details in de regel zelf, waar een filterexpressie deze tijdens de query kan vinden.

Loki en Alloy installeren op één VPS

Twee processen voeren het werk uit. Loki slaat gegevens op en beantwoordt queries. Grafana Alloy leest logs en verstuurt deze. Promtail was voorheen de shipper, maar bereikte het einde van zijn levensduur op 2 maart 2026. Nieuwe installaties gebruiken daarom Alloy en het officiële Docker-voorbeeld van Loki bevat nu een Alloy-configuratie.

wget https://raw.githubusercontent.com/grafana/loki/v3.7.0/cmd/loki/loki-local-config.yaml -O loki-config.yaml

Lees dat bestand voordat u het gebruikt. Het stelt path_prefix: /tmp/loki in met chunks onder /tmp/loki/chunks, wat correct is voor een demo maar onjuist voor een server: niets onder de /tmp van de container blijft behouden wanneer de container opnieuw wordt aangemaakt, waardoor uw geschiedenis verdwijnt bij de volgende image-update. Wijs dit toe aan een pad dat u mount.

common:
  instance_addr: 127.0.0.1
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

docker volume create loki-data
docker run --name loki -d \
  -v $(pwd):/mnt/config -v loki-data:/loki \
  -p 127.0.0.1:3100:3100 \
  grafana/loki:3.7.0 -config.file=/mnt/config/loki-config.yaml
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3100/ready

Dat laatste commando hoort 200 te tonen, omdat /ready een HTTP 200-statuscode teruggeeft zodra Loki klaar is om verkeer te accepteren. Iets anders betekent dat het proces nog opstart of dat de configuratie is afgewezen, en docker logs loki geeft aan waarom. Twee details in het run-commando zijn bewust gekozen. De poort wordt alleen op 127.0.0.1 gepubliceerd, omdat de voorbeeldconfiguratie auth_enabled: false bevat en Loki zelf geen gebruikersauthenticatie biedt. Iedereen die poort 3100 kan bereiken, kan dus elke log lezen en valse logs schrijven. Houd dit op loopback, of plaats het achter een VPN of een authenticerende reverse proxy. Het named volume is van belang omdat de image draait als de gebruiker loki met UID 10001; een bind-mounted host-directory die eigendom is van root is daardoor niet beschrijfbaar voor de container.

sudo apt-get update && sudo apt-get install -y gpg wget
sudo mkdir -p /etc/apt/keyrings/
sudo wget -O /etc/apt/keyrings/grafana.asc https://apt.grafana.com/gpg-full.key
echo "deb [signed-by=/etc/apt/keyrings/grafana.asc] https://apt.grafana.com stable main" \
  | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt-get update
sudo apt-get install -y alloy

Alloy leest /etc/alloy/config.alloy. Deze configuratie leest het system journal en één set bestanden, en pusht beide naar de lokale Loki.

loki.write "local" {
  endpoint {
    url = "http://127.0.0.1:3100/loki/api/v1/push"
  }
}

loki.relabel "journal" {
  forward_to = []
  rule {
    source_labels = ["__journal__systemd_unit"]
    target_label  = "unit"
  }
}

loki.source.journal "read" {
  forward_to    = [loki.write.local.receiver]
  relabel_rules = loki.relabel.journal.rules
  labels        = {job = "systemd-journal", host = "app-01"}
}

local.file_match "nginx" {
  path_targets = [{"__path__" = "/var/log/nginx/*.log", "job" = "nginx", "host" = "app-01"}]
}

loki.source.file "nginx" {
  targets    = local.file_match.nginx.targets
  forward_to = [loki.write.local.receiver]
}

De relabel-regel kopieert het journal-veld __journal__systemd_unit naar een label genaamd unit, wat ervoor zorgt dat {unit="ssh.service"} later werkt. Zonder die regel staat de unit-naam in de entry in plaats van in een label, waardoor u er niet op kunt filteren en elke query alles moet scannen.

sudo systemctl reload alloy
systemctl show -p User alloy
sudo journalctl -n 5
sudo -u alloy journalctl -n 5

Dit is het punt waar de meeste installaties vastlopen. Alloy draait onder zijn eigen service-account, niet als root, en voor het lezen van het system journal is lidmaatschap van de groep systemd-journal vereist, terwijl bestanden onder /var/log/nginx op Debian en Ubuntu toebehoren aan groep adm. Vervang het account dat systemctl show in het laatste commando toonde. Als het resultaat veel minder entries bevat dan de root-uitvoering, kan dat account het system journal niet lezen en blijft Loki leeg, ongeacht hoe correct uw configuratie is. Voeg de groepen toe en herstart met sudo usermod -aG systemd-journal,adm alloy gevolgd door sudo systemctl restart alloy.

curl -G -s "http://127.0.0.1:3100/loki/api/v1/query_range" \
  --data-urlencode 'query={job="systemd-journal"}' \
  --data-urlencode 'limit=5' | jq '.data.result | length'

Een getal hoger dan 0 betekent dat er streams bestaan met dat label die entries bevatten. Een 0 betekent dat er nog niets onder dat label is binnengekomen. Eén standaardinstelling verklaart een veelvoorkomend vals alarm: loki.source.journal stelt max_age in op 7h, waardoor een nieuwe start de laatste zeven uur van het journal inleest en niets ouder dan dat. Voor een grafische interface draait u Grafana op dezelfde machine en wijst u een Loki-datasource toe aan http://127.0.0.1:3100.. Container-logs vereisen een andere bron: Alloy detecteert actieve Docker-containers en volgt deze, wat ook het "getting started"-voorbeeld van Loki doet. Op een single-node k3s-cluster op een VPS verplaatst die taak zich naar de pod-logdirectory waar de kubelet naar schrijft.

Retentie: bepaal de dag waarop uw logs worden verwijderd

Bijna niemand kiest een retentieperiode totdat de schijf vol is, waarna men dit om 3 uur 's nachts moet doen terwijl de service offline is. Bepaal dit vanaf de eerste dag op basis van twee vragen: hoe ver kijkt u daadwerkelijk terug, en wat moet u nog beschikbaar hebben tijdens een incidentevaluatie volgende maand? Voor een enkele server beantwoorden 14 tot 30 dagen beide vragen.

Loki verwijdert niets totdat u de compactor inschakelt. Retentie staat standaard uit, wat voor verrassingen zorgt bij mensen wiens volume volliep terwijl retention_period niets stond te doen in de configuratie.

limits_config:
  retention_period: 744h

compactor:
  working_directory: /loki/retention
  compaction_interval: 10m
  retention_enabled: true
  retention_delete_delay: 2h
  retention_delete_worker_count: 150
  delete_request_store: filesystem

744h staat gelijk aan 31 dagen. Vier gedocumenteerde regels bepalen dat blok:

• Retentie wordt toegepast door de compactor, en de documentatie van Grafana adviseert om de compactor als een enkelvoudige instantie uit te voeren. Op een enkele VPS gebeurt dit vanzelf.
• De minimale retentieperiode is 24h, en retentie werkt alleen wanneer de indexperiode 24h is. Het voorbeeld schema_config gebruikt al period: 24h, dus wijzig dit niet.
• delete_request_store is vereist zodra retention_enabled op true staat. Het benoemt de opslag die verwijderingsverzoeken bevat, dus op een single-node met bestandssysteemopslag komt dit overeen met de object_store: filesystem die al in het schema staat.
• Chunks worden eerst gemarkeerd en verwijderd na retention_delete_delay, wat hier 2h is, waardoor vrije ruimte later terugkeert dan het beleid suggereert. Beoordeel de instelling niet aan de hand van df vijf minuten na een herlaadactie.

OpenSearch verwijdert hele indexen in plaats van individuele regels, wat de reden is dat log-indexen per dag worden aangemaakt. Een ISM-beleid doorloopt de statussen van een index en verwijdert deze zodra deze oud genoeg is, en een ism_template koppelt het beleid aan nieuwe indexen zodat u dit nooit hoeft te onthouden.

{
  "policy": {
    "description": "delete log indexes after 14 days",
    "default_state": "hot",
    "states": [
      {
        "name": "hot",
        "actions": [],
        "transitions": [
          { "state_name": "delete", "conditions": { "min_index_age": "14d" } }
        ]
      },
      {
        "name": "delete",
        "actions": [ { "delete": {} } ],
        "transitions": []
      }
    ],
    "ism_template": { "index_patterns": ["logs-*"], "priority": 100 }
  }
}

Welk systeem u ook gebruikt, een retentiegetal is slechts zo goed als de controle op vrije schijfruimte erachter. Verwijderen na 14 dagen helpt u niet als 10 dagen aan logs het volume al vullen, dus combineer het beleid met schijfgezondheidsmonitoring op een VPS en een waarschuwing bij 80% verbruik.

Hoeveel schijfruimte per GB aan logs

Het eerlijke antwoord hangt af van uw regels en velden; meet dit daarom op uw eigen data in plaats van te vertrouwen op gepubliceerde ratio's. De mechanismen verschillen voldoende om de richting te kunnen voorspellen. OpenSearch en Elasticsearch schrijven een inverted index over elk geïndexeerd veld naast het opgeslagen document, waardoor wat op de schijf belandt groter is dan de ruwe tekst, en elke replica dit vermenigvuldigt. Zet op een enkele node het aantal replica's op 0, omdat een replica-shard op dezelfde node niet kan overleven als die node uitvalt: het op 1 laten staan verdubbelt het schijfgebruik en houdt de clusterstatus voor altijd op yellow. Loki schrijft gecomprimeerde chunks plus een kleine label-index, waardoor de voetafdruk het gecomprimeerde formaat van de regels volgt.

sudo du -sh /var/lib/docker/volumes/loki-data/_data
curl -k -u admin:<password> "https://localhost:9200/_cat/indices?v&h=index,docs.count,store.size"

Voer de voor u relevante actie uit op twee opeenvolgende dagen. Het verschil is uw dagelijkse groei. Vermenigvuldig dit met uw retentiedagen, voeg ongeveer 30% marge toe voor compactie en merges, en vergelijk dit vervolgens met het volume. Als het niet past, verlaag dan de retentie voordat u schijfruimte bijkoopt, want een groter volume verschuift hetzelfde probleem slechts met enkele weken.

Wat begeeft het eerst op een kleine server

Geheugen is het eerste dat opraakt. De kernel OOM (out of memory) killer kiest een groot proces, en op een server die logs verwerkt is de JVM doorgaans het grootste proces. journalctl -k | grep -i "killed process" toont de beëindiging met de procesnaam tussen haakjes. Het slachtoffer is niet altijd de log-stack: sshd of uw database kan ook worden gekozen, waardoor een log-experiment de applicatie waar u juist logs van wilde hebben, onderuit haalt. Geef containers expliciete limieten zodat de uitval plaatsvindt waar u dat wilt; dit is waar geheugenlimieten in Docker Compose voor dienen.

Schijfruimte is het tweede punt van falen, en zoekmachines falen hierbij op een specifieke en herkenbare manier. Elasticsearch en OpenSearch monitoren schijfgebruik op verschillende niveaus. De 'low watermark' ligt op 85% en de 'high watermark' op 90%. Bij de 'flood stage' van 95% ontvangt elke index met een shard op die node de blokkade index.blocks.read_only_allow_delete, waarna schrijfacties falen met blocked by: [FORBIDDEN/12/index read-only / allow delete (api)]. De blokkade wordt opgeheven zodra het gebruik weer onder de 'high watermark' zakt. Maak eerst ruimte vrij en verwijder de blokkade pas handmatig als deze blijft aanhouden.

curl -k -u admin:<password> -X PUT "https://localhost:9200/_all/_settings" \
  -H 'Content-Type: application/json' \
  -d '{"index.blocks.read_only_allow_delete": null}'

Loki faalt stiller. Het kent geen 'read-only'-modus om op terug te vallen, dus een volle schijf resulteert in mislukte 'pushes' bij de verzender en gaten in zoekresultaten. Het cardinaliteitsprobleem uit zich eerder als een langzame stijging in geheugengebruik dan als een foutmelding. Controleer de grootte van de 'chunks'-directory volgens een schema, niet pas na een incident.

Het laatste probleem is het invoeren van de verkeerde gegevens. Een logsysteem is geen metriekensysteem: CPU-belasting die elke 10 seconden wordt gesampled en als tekst wordt opgeslagen, is duur om te bewaren en onhandig om in grafieken weer te geven. Die taak hoort thuis bij iets als een Zabbix monitoring server op Ubuntu 24.04. Applicatie-exceptions vereisen groepering, ontdubbeling en een weergave van de stack trace; dit is de taak van een zelf-gehoste error tracker. Weten of de site überhaupt bereikbaar is, is weer een aparte taak, die wordt beantwoord door een uptime en statuspagina zoals Uptime Kuma. Gebruik het logsysteem voor tekstregels die door een persoon gelezen zullen worden.

FAQ

Heb ik Elasticsearch nodig om mijn serverlogs te doorzoeken?

Niet voor één of twee servers. journalctl filtert al op unit, prioriteit, boot en tijdsbereik, en geroteerde bestanden reageren op grep en zgrep. Een zoekcluster is pas zinvol als u veel machines heeft, als u in één keer over alle machines heen op vrije tekst wilt zoeken, of als meerdere personen een gedeelde interface nodig hebben. Daaronder doet journald met een groottebeperking en een bewaartermijn hetzelfde werk zonder extra RAM-verbruik.

Hoeveel RAM heb ik nodig voor zelfgehost logbeheer?

Gebruik de gepubliceerde cijfers van elk project in plaats van een vuistregel. Loki en Alloy zijn Go-programma's zonder vooraf te reserveren heap, en Grafana documenteert monolithische Loki tot ongeveer 20 GB per dag. De voorbeeld-compose van OpenSearch stelt 512 MB heap in voor een demo en 2 GB in het productievoorbeeld, en Elastic stelt dat de heap op of onder 50% van het totale geheugen moet blijven; een 2 GB heap vereist dus een machine van 4 GB, nog voor de komst van Kibana. De documentatie van Logstash beveelt minimaal 4 GB heap aan. Dit zijn gedocumenteerde instellingen, geen benchmarks; meet daarom uw eigen belasting voordat u een plan opstelt.

Wat is het werkelijke verschil tussen Loki en OpenSearch voor logs?

Het indexmodel. Loki indexeert alleen labels en bewaart de loginhoud als gecomprimeerde brokken die tijdens het uitvoeren van een query worden gescand; schrijfacties zijn daardoor goedkoop, maar queries kosten meer bij een breed bereik. OpenSearch indexeert de inhoud van de velden, waardoor willekeurige full-text zoekopdrachten snel zijn, maar zowel geheugen als schijfruimte worden gebruikt voor de index. Kies Loki als u weet welke service en welk tijdsvenster u wilt onderzoeken. Kies OpenSearch als u tekst moet doorzoeken die u vooraf niet kunt voorspellen.

Hoe lang moet ik logs op een VPS bewaren?

Kies zelf een termijn voordat de schijfruimte dat voor u doet. Stel dit op slechts één plek per systeem in: MaxRetentionSec= en SystemMaxUse= voor journald, retention_period met de compactor ingeschakeld voor Loki, en een ISM-beleid met min_index_age voor OpenSearch. Voor de meeste opstellingen met één server is 14 tot 30 dagen voldoende voor debugging en incidentanalyse. Alles wat u langer moet bewaren, hoort in een kopie buiten de server thuis, want een log die alleen op de defecte server staat, is geen archief.

Is Promtail nog steeds de manier om logs naar Loki te sturen?

Nee. Promtail bereikte het einde van zijn levensduur op 2 maart 2026 en Grafana Alloy vervangt het. Het Docker-installatievoorbeeld van Loki verstuurt nu een Alloy-configuratie, en Grafana biedt een converter die een bestaande Promtail-configuratie omzet naar Alloy-syntaxis. Een bestaande Promtail-installatie blijft werken, maar ontvangt geen fixes meer; beschouw migratie daarom als regulier onderhoud in plaats van een upgrade die u voor onbepaalde tijd kunt uitstellen.