AIOps op VPS: self-hosted AI-monitoring open source

Datadog en New Relic rekenen per host, per GB, of beide. Voor een solo-ontwikkelaar of klein team dat één tot vijf VPS-instanties beheert, lopen die kosten snel op met weinig rendement. Bekijk de Datadog-prijspagina en de New Relic-prijspagina voor actuele tarieven.

Het alternatief: je hele monitoring-, loganalyse- en incidentresponsstack draaien op één VPS. Open-source tools zoals SigNoz, Grafana+Loki en Ollama geven je observability, AI-gestuurde anomaliedetectie en geautomatiseerde remediëring. Totale kosten: de prijs van je VPS. Bij Virtua Cloud begint dat bij 24 EUR/maand voor een server met 2 vCPU en 4 GB RAM voor basisobservability, of 48 EUR/maand voor de volledige stack op een server met 4 vCPU en 8 GB RAM.

Dit artikel beschrijft de vijf lagen van een self-hosted AIOps-stack. Het is geen stap-voor-staphandleiding. Elke sectie legt uit wat de laag doet, beveelt tools aan en verwijst naar de aparte verdiepingsgids waar je alles installeert en configureert.

Wat is AIOps en waarom is het relevant voor VPS-beheerders?

AIOps betekent AI en machine learning inzetten om monitoring, loganalyse, anomaliedetectie en incidentrespons te automatiseren. Voor VPS-beheerders vervangt het de handmatige cyclus van dashboards controleren, logs lezen en services herstarten. In plaats van te betalen voor enterprise SaaS-platformen draai je open-source tools op de infrastructuur die je al beheert. Je data blijft op je server. Je kosten blijven vast.

De enterprise-definitie van AIOps richt zich op het correleren van duizenden alerts over honderden microservices. Dat is niet waar deze gids over gaat. Voor VPS-beheerders die één tot vijf servers beheren, betekent AIOps:

Metrics, logs en traces verzamelen op één plek in plaats van SSH-en naar elke server.
Een lokaal LLM draaien om patronen in logs te ontdekken die grep en regex missen.
Reacties automatiseren op veelvoorkomende storingen zoals een volle schijf, een gecrasht proces of een geheugenlek.
AI-feedback op code krijgen voordat het productie bereikt.

De stack heeft vijf lagen. Je hebt ze niet allemaal nodig. Begin met observability, voeg AI-analyse toe wanneer het logvolume handmatige review pijnlijk maakt, en bouw richting self-healing naarmate je vertrouwen groeit.

Hoeveel kost self-hosted monitoring vergeleken met Datadog?

Een self-hosted AIOps-stack op een Virtua Cloud VPS kost tussen 24 en 96 EUR/maand, afhankelijk van hoeveel lagen je uitrolt. Dat zijn de totale kosten: server, opslag, bandbreedte en alle software. Commerciële alternatieven zoals Datadog gebruiken per-host en per-GB prijsmodellen die meeschalen met je infrastructuur. Hun kosten groeien naarmate je hosts toevoegt, meer logs opneemt of APM-tracing activeert.

Functie	Commercieel SaaS (Datadog, New Relic)	Self-Hosted (Virtua Cloud VPS)
Infrastructuurmonitoring	Per-host prijzen, gelaagd per plan	Inbegrepen (Prometheus + Grafana)
Logbeheer	Per-GB ingestie + indexeringskosten per event	Inbegrepen (Loki of OpenObserve)
APM / Traces	Extra per-host kosten	Inbegrepen (SigNoz of Tempo)
AI-loganalyse	Niet beschikbaar of aparte add-on	Inbegrepen (Ollama + lokaal LLM)
Alerting	Inbegrepen	Inbegrepen (Alertmanager)
Dataretentie	Door leverancier bepaalde limieten (dagen tot maanden)	Jij bepaalt het. De schijf is de limiet.
Datalocatie	US/EU (jij kiest regio)	Jouw VPS. Jouw jurisdictie.
Prijsmodel	Per host + per GB, groeit met gebruik	Vaste maandelijkse VPS-kosten

Voor actuele commerciële prijzen, zie Datadog-prijzen en New Relic-prijzen. Self-hosted kosten hangen alleen af van het gekozen VPS-plan.

De self-hosted kolom gaat uit van één vCS-8-plan (4 vCPU, 8 GB RAM, 160 GB SSD) dat de volledige observability-stack draait via Docker Compose. Als je alleen basismetrics en logs nodig hebt, kan een vCS-4 (2 vCPU, 4 GB RAM) van 24 EUR/maand Grafana + Loki + Prometheus aan voor kleine workloads.

Voor teams die ook de AI-analyselaag willen (Ollama met een 3-7B parametermodel), is de 8 GB VPS het minimum. Ollama met Gemma 2 (2B) draait op ongeveer 2 GB RAM, wat genoeg ruimte overlaat voor SigNoz of Grafana ernaast.

Welke open-source observability-tools werken het best op een VPS?

De observability-laag verzamelt metrics, logs en traces van je applicaties en infrastructuur. Drie open-source stacks domineren dit gebied: SigNoz, OpenObserve en Grafana + Loki. Elk maakt andere afwegingen tussen functionaliteit, resourcegebruik en complexiteit.

Tool	Best voor	Logs	Metrics	Traces	Backend	Min RAM	Complexiteit
SigNoz	Volledige APM-vervanging voor Datadog	Ja	Ja	Ja	ClickHouse	4 GB	Gemiddeld
OpenObserve	Lichtgewicht logaggregatie	Ja	Ja	Ja	Ingebouwd (Rust)	~1 GB	Laag
Grafana + Loki + Prometheus	Gevestigd ecosysteem, uitbreidbaarheid	Ja (Loki)	Ja (Prometheus)	Via Tempo	Meerdere	2-4 GB	Hoger

Alle drie ondersteunen OpenTelemetry voor instrumentatie. Dit betekent dat je je applicatie één keer kunt instrumenteren en later van backend kunt wisselen zonder applicatiecode te wijzigen.

Wanneer kies je SigNoz boven OpenObserve?

Kies SigNoz wanneer je volledige applicatieprestatiemonitoring nodig hebt: gedistribueerde traces, servicemaps, error tracking en gecorreleerde logs. SigNoz gebruikt ClickHouse als opslagengine, die goed overweg kan met high-cardinality data maar meer RAM vereist. Een Docker Compose-deployment heeft minstens 4 GB RAM nodig voor SigNoz, met 8 GB aanbevolen voor productie-workloads inclusief ClickHouse.

Kies OpenObserve wanneer je primaire behoefte logaggregatie en zoeken is. OpenObserve wordt geleverd als een enkele binary geschreven in Rust. Het start met minder dan 1 GB RAM in een basis Docker Compose-setup. Het claimt 140x lagere opslagkosten vergeleken met Elasticsearch dankzij kolomgebaseerde compressie. Als je een indie hacker bent die één applicatie draait en snelle logzoekopdrachten wil zonder de overhead van ClickHouse, is OpenObserve het lichtere pad.

Beide tools hebben web-UI's voor queries en dashboards. SigNoz biedt een completere Datadog-achtige ervaring. OpenObserve is slanker en sneller te deployen.

Is Grafana + Loki in 2026 nog de beste optie?

Grafana + Loki blijft de meest flexibele optie. Het is niet de eenvoudigste installatie, maar het wint op ecosysteembreedte. Duizenden communitydashboards bestaan voor elke denkbare service. Prometheus-exporters dekken databases, webservers, hardwaremetrics en aangepaste applicatiemetrics. Loki handelt logaggregatie af met een LogQL-querytaal die PromQL weerspiegelt.

De afweging: meer bewegende delen. Een minimale Grafana-stack betekent Grafana (UI), Prometheus (metrics) en Loki (logs) als afzonderlijke containers draaien. Voeg Promtail of Alloy toe als logverzamelaar. Dat zijn vier containers voordat je je eigen applicatie toevoegt. Op een 4 GB VPS past deze stack maar laat weinig ruimte over.

Kies Grafana + Loki wanneer je het ecosysteem al kent, uitgebreide aanpassingen nodig hebt of tools wilt integreren die alleen Prometheus-metriekexport ondersteunen.

Hoe voeg je AI-gestuurde loganalyse toe aan je monitoringstack?

Draai een lokaal LLM via Ollama om logs te analyseren zonder data naar een externe API te sturen. Ollama serveert modellen zoals Gemma 2 (2B), Llama 3.2 (3B) of Qwen 2.5 (7B) via een lokale HTTP-API. Een script of cronjob voert logfragmenten aan het model en vraagt het om anomalieën te identificeren, foutpatronen samen te vatten of oorzaken voor te stellen. Geen API-kosten. Geen data die je server verlaat.

Hier wijkt self-hosted AIOps af van traditionele monitoring. Grafana en Prometheus vertellen je wat er is gebeurd. Een lokaal LLM helpt je begrijpen waarom.

Wat de AI-analyselaag doet:

Anomaliedetectie: voer de laatste 1.000 logregels aan het model met een prompt als "identificeer ongebruikelijke patronen of fouten in deze logs". Het model markeert entries die afwijken van normale patronen.
Foutsamenvatting: wanneer een incident honderden logregels genereert, vat het LLM ze samen in een leesbare samenvatting met de waarschijnlijke oorzaak.
Patroonherkenning: na verloop van tijd ontstaan terugkerende foutpatronen. Het LLM kan gerelateerde fouten groeperen en terugkerende problemen identificeren die drempelgebaseerde alerts niet zouden triggeren.

Modelgroottes voor VPS:

Model	Parameters	RAM-gebruik	Snelheid (tokens/sec, CPU)	Best voor
Gemma 2 (2B)	2,6 mld	~2 GB	~15-20	Snelle logtriage op VPS met weinig RAM
Llama 3.2 (3B)	3,2 mld	~2,5 GB	~10-15	Gebalanceerde analyse en snelheid
Qwen 2.5 (7B)	7 mld	~5 GB	~5-8	Diepere analyse, vereist 8 GB+ VPS

Op een 4 vCPU VPS zonder GPU krijg je CPU-only inferentie. Een 2-3B model produceert bruikbare loganalyse in 5-15 seconden per query. Dat is snel genoeg voor batchanalyse om de paar minuten, niet voor realtime streaming.

Dit is geen magie. Kleine modellen hallucineren. Ze missen context. Ze markeren soms normale logentries als verdacht. Behandel LLM-loganalyse als een triage-assistent, niet als een orakel. Verifieer de suggesties altijd tegen de daadwerkelijke logs en metrics.

Wat is een zelfherstellende VPS en hoe werkt het?

Een zelfherstellende VPS detecteert en verhelpt automatisch veelvoorkomende storingen zonder menselijke tussenkomst. De basisarchitectuur: Prometheus monitort metrics, Alertmanager vuurt alerts af wanneer drempels worden overschreden, en een webhook-ontvanger voert remediëringscripts uit. Een LLM toevoegen aan deze lus laat je storingen afhandelen die niet bij vooraf gedefinieerde regels passen.

De self-healing pipeline:

Prometheus scrapt metrics elke 15 seconden (CPU, geheugen, schijf, processtatus, HTTP-foutpercentages).
Alertregels definiëren voorwaarden: schijfgebruik boven 90%, een service die 60 seconden niet reageert, geheugengebruik aanhoudend boven 95%.
Alertmanager ontvangt het alert en routeert het naar een webhook-endpoint.
Remediëringshandler ontvangt de webhook. Voor bekende condities (volle schijf, gecrashte service) voert het een vooraf gedefinieerd script uit. Voor onbekende condities roept het het lokale LLM aan via Ollama met de alertcontext en recente logs, en vraagt om een diagnose en remediëringssuggestie.
Uitvoering (optioneel): voor bekende remediëringen met hoog vertrouwen (service herstarten, tijdelijke bestanden opruimen, logs roteren) voert de handler automatisch uit. Voor door het LLM voorgestelde acties stuurt het de suggestie naar je notificatiekanaal voor menselijke goedkeuring.

Veelvoorkomende geautomatiseerde remediëringen:

Schijf vol: /tmp opruimen, oude logs roteren, Docker-images opschonen met docker system prune.
Service gecrasht: systemctl restart <service>, dan verifiëren dat het gezond is. Als het binnen 5 minuten opnieuw crasht, escaleren naar een mens.
Geheugendruk: de grootste geheugenverbruiker identificeren, herstarten als het zijn verwachte baseline overschrijdt.
Certificaatvervaldatum: een Certbot-vernieuwing triggeren wanneer het certificaat minder dan 7 dagen geldig is.

Begin conservatief. Automatiseer alleen remediëringen die je tientallen keren handmatig hebt uitgevoerd en volledig begrijpt. Laat het LLM acties voorstellen voor onbekende situaties, maar houd een mens in de lus voor de uitvoering.

Voor een no-code-benadering van alertrouting en remediëringsworkflows kan n8n de orkestratielaag zijn tussen Alertmanager en je remediëringscripts.

Hoe past AI in je CI/CD-pipeline?

AI-codereview vangt bugs, beveiligingsproblemen en prestatieproblemen op voordat code je server bereikt. GitHub Actions-workflows kunnen pull request-diffs naar Claude of Gemini sturen voor analyse, reviewopmerkingen plaatsen en merges blokkeren wanneer kritieke problemen worden gevonden. Dit draait in je CI/CD-pipeline zonder wijzigingen aan je VPS.

Wat AI-codereview wel vindt en linters niet:

Logicafouten en edge cases die statische analyse niet kan detecteren.
Beveiligingskwetsbaarheden in context (een linter markeert gevaarlijke functies, maar een LLM begrijpt waarom de omringende code ze exploiteerbaar maakt).
Prestatieregressies: "deze query in een lus zal de database N keer aanspreken."
Documentatielacunes: ontbrekende foutafhandeling, onduidelijke variabelenamen, ongedocumenteerde bijeffecten.

Deze laag verschilt van de andere omdat het doorgaans in je CI-platform draait (GitHub Actions, GitLab CI), niet op je VPS. Als je echter alles self-hosted wilt houden, kun je een CI-runner op je VPS draaien en codereviewverzoeken naar je lokale Ollama-instantie routeren. De afweging: langzamere reviews met kleinere modellen versus snellere, nauwkeurigere reviews met cloud-API's.

Wat is LLM-observability en waarom heb je het nodig?

LLM-observability volgt hoe je AI-tools presteren: tokengebruik, latentie, foutpercentages, kosten en outputkwaliteit. Als je een LLM-aangestuurde functie draait (chatbot, code-assistent, loganalysator, contentgenerator), geeft Langfuse je zicht op elke aanroep. Het is de "monitor de monitors"-laag van je AIOps-stack.

Langfuse is een open-source LLM-engineeringplatform. Self-hosted draait het als twee containers (web + worker) met PostgreSQL en optioneel ClickHouse voor analytics. Het biedt:

Tracing: elke LLM-aanroep zien met input, output, latentie en tokenaantal. Inzoomen op multi-stap agent-workflows om te vinden waar tijd en tokens worden besteed.
Evaluatie: outputs scoren met LLM-as-a-judge, menselijke feedback of aangepaste metrics. Kwaliteit volgen over tijd.
Kostentracering: werkelijke uitgaven berekenen per LLM-aanroep, per gebruiker, per functie. Modelprestaties vergelijken bij verschillende prijspunten.
Promptbeheer: prompts versiebeheren en A/B-testen. Terugdraaien wanneer een nieuwe prompt de outputkwaliteit verslechtert.

Als je Ollama draait voor loganalyse (laag 2 van deze stack), traceert Langfuse elke analyseverzoek. Je ziet welke logqueries nuttige resultaten opleveren, welke het model moeite kosten en hoe de latentie verandert bij het wisselen van model.

Langfuse integreert met OpenTelemetry, LangChain, LlamaIndex en de OpenAI SDK (waarmee Ollama compatibel is). Instrumentatie vereist doorgaans maar een paar regels code.

Je hebt deze laag nodig wanneer je LLM-gebruik voorbij experimenteren gaat. Zodra je afhankelijk bent van AI-outputs voor alerting of remediëring, moet je weten wanneer het model onbruikbare resultaten begint te produceren.

Welke VPS-resources heb je nodig voor een volledige AIOps-stack?

De resources hangen af van welke lagen je uitrolt. Hier zijn drie configuraties gekoppeld aan Virtua Cloud VPS-plannen:

Configuratie	Lagen	VPS-plan	CPU	RAM	Schijf	EUR/maand
Starter	Grafana + Prometheus + Loki	vCS-4	2 vCPU	4 GB	80 GB	24
Standard	SigNoz + Ollama (3B model)	vCS-8	4 vCPU	8 GB	160 GB	48
Volledige stack	SigNoz + Ollama (7B) + Langfuse + Alertmanager	vCS-16	8 vCPU	16 GB	320 GB	96

Starter handelt metrics en logaggregatie af voor één tot drie kleine applicaties. Dashboards en alerts zonder AI-analyse.

Standard voegt AI-loganalyse toe. SigNoz neemt ongeveer 4 GB in beslag en Ollama met een 3B model gebruikt ongeveer 2,5 GB. Het resterende RAM gaat naar het besturingssysteem en je gemonitorde applicaties. Dit is het optimale punt voor een solo-ontwikkelaar of klein team.

Volledige stack draait alle lagen die in deze gids worden beschreven. Een 7-miljard parametermodel produceert betere analyse dan een 3B model maar heeft meer RAM nodig. Langfuse voegt ongeveer 1 GB toe. Deze configuratie is voor teams die LLM-aangestuurde functies in productie draaien en volledige observability nodig hebben over zowel hun infrastructuur als hun AI.

Alle configuraties draaien alles via Docker Compose. De bijbehorende artikelen behandelen de exacte docker-compose.yml-bestanden voor elke tool.

Een opmerking over schijfgebruik: observabilitydata groeit snel. SigNoz met ClickHouse comprimeert goed (verwacht 5-10x compressie op logs), maar reken op 1-5 GB aan nieuwe data per dag afhankelijk van de verbositeit van je logs. Stel retentiebeleid in vanaf dag één. Een 160 GB schijf geeft je bij gematigde ingestietempo's ongeveer één tot drie maanden aan data.

Datasoevereiniteit: het AVG-voordeel van self-hosted monitoring

Wanneer je je monitoringstack op een Europese VPS draait, verlaten je observabilitydata nooit de jurisdictie. Metrics, logs en traces bevatten vaak persoonsgegevens: IP-adressen, gebruikers-ID's, verzoekpaden, foutmeldingen met gebruikerscontext. Die data naar een in de VS gevestigd SaaS-platform sturen introduceert AVG-transferrisico, zelfs wanneer de provider een EU-regio aanbiedt.

Met een self-hosted stack op een Virtua Cloud VPS in Frankrijk of Duitsland beheer je:

Waar de data wordt opgeslagen. Op schijf, in je VPS, in een Europees datacenter.
Wie er toegang toe heeft. Geen leveranciersmedewerkers, geen subverwerkers, geen gegevensverwerkingsovereenkomsten met derden om te auditen.
Hoe lang het wordt bewaard. Jij stelt het retentiebeleid in. Geen door de leverancier opgelegde minimums of schema's voor gegevensverwijdering.

Dit is geen juridisch advies. Raadpleeg je functionaris voor gegevensbescherming voor je specifieke situatie. Maar vanuit technisch oogpunt elimineert self-hosted monitoring een hele categorie vragen over gegevensoverdracht.

Waar moet je beginnen?

Je startpunt hangt af van je ervaring en welk probleem je nu aan het oplossen bent.

Als je nieuw bent met servermonitoring (indie hackers, eerste VPS):

Begin met SigNoz. Het geeft je metrics, logs en traces in één tool met een web-UI. Eén Docker Compose-bestand, één tool om te leren.
Als je vertrouwd bent met het lezen van dashboards, voeg dan Ollama toe voor AI-loganalyse.
Automatiseer nog geen remediëring. Begrijp eerst het normale gedrag van je server.

Als je al Prometheus of Grafana draait (DevOps-professionals):

Voeg Loki toe voor logaggregatie als je dat nog niet hebt gedaan.
Integreer Ollama voor AI-gestuurde logtriage naast je bestaande alertregels.
Bouw self-healing workflows met Alertmanager-webhooks.
Voeg Langfuse toe wanneer je begint te vertrouwen op LLM-outputs voor operationele beslissingen.

Als je de volledige stack wilt vanaf dag één (AI-ontwikkelaars):

Rol een vCS-8 of vCS-16 VPS uit op Virtua Cloud.
Stel SigNoz in voor observability.
Draai Ollama met een 7B model voor loganalyse en anomaliedetectie.
Verbind Alertmanager met je remediëringscripts.
Deploy Langfuse om je LLM-laag te monitoren.
Voeg AI-codereview toe aan je CI/CD-pipeline.

Elk bijbehorend artikel in dit themacluster is een op zichzelf staande tutorial. Je kunt ze in elke volgorde volgen. De stack is modulair: elke laag werkt onafhankelijk en voegt op zichzelf waarde toe.

Copyright 2026 Virtua.Cloud. Alle rechten voorbehouden. Deze inhoud is een origineel werk van het Virtua.Cloud-team. Reproductie, herpublicatie of herdistributie zonder schriftelijke toestemming is verboden.