AIOps on a VPS: Self-Hosted AI Monitoring Tools

Datadog and New Relic charge per host, per GB, or both. For a solo developer or small team running one to five VPS instances, those costs add up fast with little return. Check Datadog's pricing page and New Relic's pricing page for current rates.

The alternative: run your entire monitoring, log analysis, and incident response stack on a single VPS. Open-source tools like SigNoz, Grafana+Loki, and Ollama give you observability, AI-powered anomaly detection, and automated remediation. Total cost: the price of your VPS. On Virtua Cloud, that starts at 24 EUR/month for a 2 vCPU, 4 GB RAM server that handles basic observability, or 48 EUR/month for the full stack on a 4 vCPU, 8 GB RAM server.

This article maps the five layers of a self-hosted AIOps stack. It is not a step-by-step tutorial. Each section explains what the layer does, recommends tools, and links to the dedicated deep-dive guide where you install and configure everything.

What is AIOps and why does it matter for VPS operators?

AIOps means using AI and machine learning to automate monitoring, log analysis, anomaly detection, and incident response. For VPS operators, it replaces the manual cycle of checking dashboards, reading logs, and restarting services. Instead of paying for enterprise SaaS platforms, you run open-source tools on the same infrastructure you already manage. Your data stays on your server. Your costs stay flat.

The enterprise definition of AIOps focuses on correlating thousands of alerts across hundreds of microservices. That is not what this guide covers. For VPS operators managing one to five servers, AIOps means:

Collecting metrics, logs, and traces in one place instead of SSH-ing into each server.
Running a local LLM to spot patterns in logs that grep and regex miss.
Automating responses to common failures like a full disk, a crashed process, or a memory leak.
Getting AI feedback on code before it reaches production.

The stack has five layers. You do not need all of them. Start with observability, add AI analysis when your log volume makes manual review painful, and build toward self-healing as you gain confidence.

How much does self-hosted monitoring cost compared to Datadog?

A self-hosted AIOps stack on a Virtua Cloud VPS costs between 24 and 96 EUR/month depending on how many layers you deploy. That is the total cost: server, storage, bandwidth, and all the software. Commercial alternatives like Datadog use per-host and per-GB pricing models that scale with your infrastructure. Their costs grow as you add hosts, ingest more logs, or enable APM tracing.

Feature	Commercial SaaS (Datadog, New Relic)	Self-Hosted (Virtua Cloud VPS)
Infrastructure monitoring	Per-host pricing, tiered by plan	Included (Prometheus + Grafana)
Log management	Per-GB ingestion + per-event indexing fees	Included (Loki or OpenObserve)
APM / Traces	Additional per-host fee	Included (SigNoz or Tempo)
AI log analysis	Not available or separate add-on	Included (Ollama + local LLM)
Alerting	Included	Included (Alertmanager)
Data retention	Vendor-defined limits (days to months)	You control it. Disk is the limit.
Data location	US/EU (you choose region)	Your VPS. Your jurisdiction.
Pricing model	Per-host + per-GB, grows with usage	Flat monthly VPS cost

For current commercial pricing, see Datadog's pricing and New Relic's pricing. Self-hosted costs depend only on the VPS plan you choose.

The self-hosted column assumes a single vCS-8 plan (4 vCPU, 8 GB RAM, 160 GB SSD) running the full observability stack via Docker Compose. If you only need basic metrics and logs, a vCS-4 (2 vCPU, 4 GB RAM) at 24 EUR/month handles Grafana + Loki + Prometheus for small workloads.

For teams that also want the AI analysis layer (Ollama with a 3-7B parameter model), the 8 GB VPS is the minimum. Ollama with Gemma 2 (2B) runs in roughly 2 GB of RAM, leaving enough headroom for SigNoz or Grafana alongside it.

Which open-source observability tools work best on a VPS?

The observability layer collects metrics, logs, and traces from your applications and infrastructure. Three open-source stacks dominate this space: SigNoz, OpenObserve, and Grafana + Loki. Each makes different tradeoffs between features, resource usage, and complexity.

Tool	Best for	Logs	Metrics	Traces	Backend	Min RAM	Complexity
SigNoz	Full APM replacement for Datadog	Yes	Yes	Yes	ClickHouse	4 GB	Medium
OpenObserve	Lightweight log aggregation	Yes	Yes	Yes	Built-in (Rust)	~1 GB	Low
Grafana + Loki + Prometheus	Established ecosystem, extensibility	Yes (Loki)	Yes (Prometheus)	Via Tempo	Multiple	2-4 GB	Higher

All three support OpenTelemetry for instrumentation. This means you can instrument your application once and switch backends later without changing application code.

When should you choose SigNoz over OpenObserve?

Choose SigNoz when you need full application performance monitoring: distributed traces, service maps, error tracking, and correlated logs. SigNoz uses ClickHouse as its storage engine, which handles high-cardinality data well but demands more RAM. A Docker Compose deployment needs at least 4 GB of RAM dedicated to SigNoz, with 8 GB recommended for production workloads that include ClickHouse.

Choose OpenObserve when your primary need is log aggregation and search. OpenObserve ships as a single binary written in Rust. It starts with under 1 GB of RAM in a basic Docker Compose setup. It claims 140x lower storage costs compared to Elasticsearch thanks to columnar compression. If you are an indie hacker running a single application and want fast log search without the overhead of ClickHouse, OpenObserve is the lighter path.

Both tools have web UIs for querying and dashboards. SigNoz offers a more complete Datadog-like experience. OpenObserve is leaner and faster to deploy.

Is Grafana + Loki still the best option in 2026?

Grafana + Loki remains the most flexible option. It is not the simplest to set up, but it wins on ecosystem breadth. Thousands of community dashboards exist for every service you can think of. Prometheus exporters cover databases, web servers, hardware metrics, and custom application metrics. Loki handles log aggregation with a LogQL query language that mirrors PromQL.

The tradeoff: more moving parts. A minimal Grafana stack means running Grafana (UI), Prometheus (metrics), and Loki (logs) as separate containers. Add Promtail or Alloy as the log shipper. That is four containers before you add your own application. On a 4 GB VPS, this stack fits but leaves limited headroom.

Pick Grafana + Loki when you already know the ecosystem, need heavy customization, or want to integrate with tools that only support Prometheus metrics export.

How do you add AI-powered log analysis to your monitoring stack?

Run a local LLM through Ollama to analyze logs without sending data to any external API. Ollama serves models like Gemma 2 (2B), Llama 3.2 (3B), or Qwen 2.5 (7B) over a local HTTP API. A script or cron job feeds log snippets to the model and asks it to identify anomalies, summarize error patterns, or suggest root causes. No API costs. No data leaving your server.

This is where self-hosted AIOps diverges from traditional monitoring. Grafana and Prometheus tell you what happened. A local LLM helps you understand why.

What the AI analysis layer does:

Anomaly detection: Feed the last 1,000 log lines to the model with a prompt like "identify any unusual patterns or errors in these logs." The model flags entries that deviate from normal patterns.
Error summarization: When an incident generates hundreds of log lines, the LLM condenses them into a human-readable summary with the likely root cause.
Pattern recognition: Over time, repeated error patterns emerge. The LLM can group related errors and identify recurring issues that might not trigger threshold-based alerts.

Model sizing for VPS:

Model	Parameters	RAM Usage	Speed (tokens/sec, CPU)	Best for
Gemma 2 (2B)	2.6B	~2 GB	~15-20	Quick log triage on low-RAM VPS
Llama 3.2 (3B)	3.2B	~2.5 GB	~10-15	Balanced analysis and speed
Qwen 2.5 (7B)	7B	~5 GB	~5-8	Deeper analysis, needs 8 GB+ VPS

On a 4 vCPU VPS without a GPU, expect CPU-only inference. A 2-3B model produces useful log analysis in 5-15 seconds per query. That is fast enough for batch analysis every few minutes, not for real-time streaming.

This is not magic. Small models hallucinate. They miss context. They sometimes flag normal log entries as suspicious. Treat LLM log analysis as a triage assistant, not an oracle. Always verify its suggestions against the actual logs and metrics.

What is a self-healing VPS and how does it work?

A self-healing VPS automatically detects and remediates common failures without human intervention. The basic architecture: Prometheus monitors metrics, Alertmanager fires alerts when thresholds are breached, and a webhook receiver executes remediation scripts. Adding an LLM to this loop lets you handle failures that do not match predefined rules.

The self-healing pipeline:

Prometheus scrapes metrics every 15 seconds (CPU, memory, disk, process status, HTTP error rates).
Alerting rules define conditions: disk usage above 90%, a service not responding for 60 seconds, memory usage sustained above 95%.
Alertmanager receives the alert and routes it to a webhook endpoint.
Remediation handler receives the webhook. For known conditions (full disk, crashed service), it runs a predefined script. For unknown conditions, it calls the local LLM via Ollama with the alert context and recent logs, asking for a diagnosis and remediation suggestion.
Execution (optional): for high-confidence known remediations (restart a service, clear temp files, rotate logs), the handler executes automatically. For LLM-suggested actions, it sends the suggestion to your notification channel for human approval.

Common automated remediations:

Disk full: Clear /tmp, rotate old logs, prune Docker images with docker system prune.
Service crashed: systemctl restart <service>, then check it is healthy. If it crashes again within 5 minutes, escalate to human.
Memory pressure: Identify the top memory consumer, restart it if it exceeds its expected baseline.
Certificate expiry: Trigger a Certbot renewal when the certificate has fewer than 7 days left.

Start conservative. Automate only remediations you have manually executed dozens of times and fully understand. Let the LLM suggest actions for unfamiliar situations, but keep a human in the loop for execution.

For a no-code approach to alert routing and remediation workflows, n8n can be the orchestration layer between Alertmanager and your remediation scripts.

How does AI fit into your CI/CD pipeline?

AI code review catches bugs, security issues, and performance problems before code reaches your server. GitHub Actions workflows can send pull request diffs to Claude or Gemini for analysis, post review comments, and block merges when critical issues are found. This runs in your CI/CD pipeline with no changes to your VPS.

What AI code review catches that linters miss:

Logic errors and edge cases that static analysis cannot detect.
Security vulnerabilities in context (a linter flags dangerous functions, but an LLM understands why the surrounding code makes them exploitable).
Performance regressions: "this query inside a loop will hit the database N times."
Documentation gaps: missing error handling, unclear variable names, undocumented side effects.

This layer is different from the others because it typically runs in your CI platform (GitHub Actions, GitLab CI), not on your VPS. If you want to keep everything self-hosted, you can run a CI runner on your VPS and route code review requests to your local Ollama instance. The tradeoff: slower reviews with smaller models versus faster, more accurate reviews with cloud APIs.

What is LLM observability and why do you need it?

LLM observability tracks how your AI tools perform: token usage, latency, error rates, costs, and output quality. If you run any LLM-powered feature (chatbot, code assistant, log analyzer, content generator), Langfuse gives you visibility into every call. It is the "monitor the monitors" layer of your AIOps stack.

Langfuse is an open-source LLM engineering platform. Self-hosted, it runs as two containers (web + worker) with PostgreSQL and optionally ClickHouse for analytics. It provides:

Tracing: See every LLM call with input, output, latency, and token count. Drill into multi-step agent workflows to find where time and tokens are spent.
Evaluation: Score outputs with LLM-as-a-judge, human feedback, or custom metrics. Track quality over time.
Cost tracking: Calculate actual spend per LLM call, per user, per feature. Compare model performance at different price points.
Prompt management: Version and A/B test prompts. Roll back when a new prompt degrades output quality.

If you are running Ollama for log analysis (layer 2 of this stack), Langfuse traces every analysis request. You see which log queries produce useful results, which ones the model struggles with, and how latency changes as you swap models.

Langfuse integrates with OpenTelemetry, LangChain, LlamaIndex, and the OpenAI SDK (which Ollama is compatible with). Instrumentation is usually a few lines of code.

You need this layer when your LLM usage moves beyond experimentation. Once you depend on AI outputs for alerting or remediation, you need to know when the model starts producing garbage.

What VPS resources do you need for a full AIOps stack?

The resources depend on which layers you deploy. Here are three configurations mapped to Virtua Cloud VPS plans:

Configuration	Layers	VPS Plan	CPU	RAM	Disk	EUR/month
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
Full stack	SigNoz + Ollama (7B) + Langfuse + Alertmanager	vCS-16	8 vCPU	16 GB	320 GB	96

Starter handles metrics and log aggregation for one to three small applications. Dashboards and alerts without AI analysis.

Standard adds AI log analysis. SigNoz takes roughly 4 GB and Ollama with a 3B model uses about 2.5 GB. The remaining RAM goes to the OS and your applications being monitored. This is the sweet spot for a solo developer or small team.

Full stack runs every layer described in this guide. A 7B parameter model produces better analysis than a 3B model but needs more RAM. Langfuse adds about 1 GB. This configuration is for teams that run LLM-powered features in production and need full observability over both their infrastructure and their AI.

All configurations run everything through Docker Compose. The spoke articles cover exact docker-compose.yml files for each tool.

A note on disk usage: Observability data grows fast. SigNoz with ClickHouse compresses well (expect 5-10x compression on logs), but plan for 1-5 GB of new data per day depending on your log verbosity. Set retention policies from day one. A 160 GB disk gives you roughly one to three months of data at moderate ingestion rates.

When you run your monitoring stack on a European VPS, your observability data never leaves the jurisdiction. Metrics, logs, and traces often contain personal data: IP addresses, user IDs, request paths, error messages with user context. Sending that data to a US-based SaaS platform introduces GDPR transfer risk, even when the provider offers an EU region.

With a self-hosted stack on a Virtua Cloud VPS in France or Germany, you control:

Where the data is stored. On disk, in your VPS, in a European data center.
Who can access it. No vendor employees, no subprocessors, no third-party data agreements to audit.
How long it is retained. You set the retention policy. No vendor-imposed minimums or data deletion schedules.

This is not a legal opinion. Consult your data protection officer for your specific situation. But from a technical standpoint, self-hosted monitoring eliminates an entire category of data transfer questions.

Where should you start?

Your starting point depends on your experience and what problem you are solving right now.

If you are new to server monitoring (indie hackers, first VPS):

Start with SigNoz. It gives you metrics, logs, and traces in one tool with a web UI. One Docker Compose file, one tool to learn.
Once you are comfortable reading dashboards, add Ollama for AI log analysis.
Do not automate remediation yet. Understand your server's normal behavior first.

If you already run Prometheus or Grafana (DevOps practitioners):

Add Loki for log aggregation if you have not already.
Integrate Ollama for AI-assisted log triage alongside your existing alerting rules.
Build self-healing workflows with Alertmanager webhooks.
Add Langfuse when you start relying on LLM outputs for operational decisions.

If you want the full stack from day one (AI developers):

Deploy a vCS-8 or vCS-16 VPS on Virtua Cloud.
Set up SigNoz for observability.
Run Ollama with a 7B model for log analysis and anomaly detection.
Wire Alertmanager to your remediation scripts.
Deploy Langfuse to monitor your LLM layer.
Add AI code review to your CI/CD pipeline.

Each spoke article in this cocoon is a standalone tutorial. You can follow them in any order. The stack is modular: every layer works independently and adds value on its own.