Ollama Produktions-Monitoring: Logging, Prometheus und AlertManager in der Praxis

Drei Uhr siebzehn nachts. Rote Slack-Meldung: Ollama API timeout - service unavailable. Das Kundenservice-System war zwei Wochen online, mehrere hundert Aufrufe täglich. Beim Deployment nur Basis-Logging – kein Monitoring, keine Alerts. GPU-Speicher voll? Prozess abgestürzt? Netzwerkproblem? Keine Ahnung. Erst um sechs Uhr morgens war der Dienst wieder stabil.

Fehlendes Monitoring gehört zu den Hauptursachen.

Dieser Artikel zeigt den kompletten Weg von der Log-Konfiguration über Prometheus + Grafana bis zu AlertManager-Regeln – alles mit direkt kopierbaren Konfigurationsdateien. Mit diesem Setup steht in etwa 30 Minuten ein produktionsreifes Monitoring.

Kern-Herausforderungen beim Produktions-Monitoring

Ollama unterscheidet sich von klassischen Web-Services. Es ist ein echter Ressourcenfresser. Jedes geladene Modell belegt allein 4 bis 16 GB Speicher (laut Markaicode-Messungen). Der Cold Start – Laden von der Festplatte in den Speicher – dauert 10 bis 30 Sekunden. Fällt der Service aus und startet neu, warten Nutzer bis zu einer halben Minute auf Antworten.

Typische Fallstricke aus der Praxis:

Speicherlecks und GPU-Erschöpfung. Nach längerem Betrieb gibt Ollama manchmal VRAM nicht frei. Auf einer Maschine mit 24 GB VRAM blieben nach zwei Tagen nur noch 2 GB übrig – neue Requests wurden abgelehnt. Ohne Monitoring merkte ich das erst bei Nutzerbeschwerden.

Request-Queue-Stau. Inferenz ist langsam – ein Request kann 5–20 Sekunden dauern. Kommen Dutzende gleichzeitig, wächst die Warteschlange, bis Timeouts drohen. Ob die Queue staut, lässt sich ohne Metriken nur raten.

Modell-Lade-Latenz. Beim Wechsel zwischen Modellen bleibt die Ladezeit oft eine Blackbox. Nutzer wundern sich über langsame Antworten – und Sie wissen nicht warum.

Klares Monitoring-Ziel: Service-Verfügbarkeit (läuft der Prozess?), Performance (wie schnell antwortet er?), Ressourcennutzung (wie viel GPU-Speicher bleibt?), Fehlerrate (wie viele Requests scheitern?). Mit diesen vier Dimensionen haben Sie Kontrolle.

Für die Tool-Auswahl habe ich mehrere Kombinationen getestet. Kleine Teams kommen mit Prometheus + Grafana aus; für LLM-Prompt- und Antwort-Tracking eignet sich Langfuse; Enterprise-Umgebungen können SigNoz mit OpenTelemetry in Betracht ziehen – vereint Logs, Metriken und Traces. Im Folgenden konzentriere ich mich auf Prometheus, weil es die universellste Basis ist.

Logging-Konfiguration und systemd-Service-Optimierung

Ollama starten ist einfach – stabil laufen lassen beginnt mit korrektem Logging. Ich habe erlebt, dass bei Problemen entweder nichts protokolliert wurde oder Logdateien auf Dutzende GB anwuchsen und die Festplatte füllten.

systemd-Service-Konfiguration

Bei Installation über das offizielle Skript existiert bereits ein systemd-Service. Die Standardkonfiguration reicht für Produktion meist nicht:

# /etc/systemd/system/ollama.service

[Unit]
Description=Ollama Service
After=network.target

[Service]
Type=simple
User=ollama
Group=ollama

# Arbeitsverzeichnis
WorkingDirectory=/usr/share/ollama

# Umgebungsvariablen
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_MODELS=/data/ollama/models"
Environment="OLLAMA_DEBUG=1"
Environment="OLLAMA_LOG_FORMAT=json"

# Ressourcenlimits (an Hardware anpassen)
LimitNOFILE=65535
LimitNPROC=4096
MemoryMax=32G

# Auto-Restart-Strategie
Restart=always
RestartSec=10

# Startbefehl
ExecStart=/usr/local/bin/ollama serve

# Standard- und Fehlerausgabe
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Wichtige Punkte aus der Praxis:

Restart=always und RestartSec=10: Bei abnormalen Abstürzen startet der Prozess neu – 10 Sekunden Pause geben dem System Luft. Ohne dieses Intervall kann bei Speichererschöpfung ein Restart-Loop entstehen und die Logs explodieren.

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

MemoryMax=32G: Begrenzt den maximalen Speicher für Ollama. Auf geteilten Servern unverzichtbar. Ohne Limit hat Ollama einmal 64 GB belegt – SSH war nicht mehr erreichbar.

OLLAMA_DEBUG=1 und OLLAMA_LOG_FORMAT=json: Debug-Modus in Produktion erleichtert die Fehlersuche. JSON-Logs lassen sich mit Tools parsen.

Nach Änderungen nicht vergessen:

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo systemctl enable ollama  # Autostart

Logging bei Docker-Deployment

Mit Docker geht Log-Management leichter schief. Docker schreibt standardmäßig nach /var/lib/docker/containers/ – ohne Limits wachsen Logs unbegrenzt.

Meine docker-compose-Konfiguration:

# docker-compose.yml
version: '3.8'

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: always
    ports:
      - "11434:11434"
    volumes:
      - ./ollama_data:/root/.ollama
    environment:
      - OLLAMA_HOST=0.0.0.0:11434
      - OLLAMA_DEBUG=1
    deploy:
      resources:
        limits:
          memory: 32G
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "5"

max-size: "100m" begrenzt einzelne Logdateien auf 100 MB, max-file: "5" behält fünf Dateien – maximal 500 MB, ausreichend ohne Festplattenstress.

Log-Level-Übersicht

Unterstützte Ollama-Umgebungsvariablen:

Ich lasse DEBUG meist aktiv – der Speicherplatz ist günstiger als stundenlange Fehlersuche.

journalctl in der Praxis

Nach der Konfiguration Logs mit journalctl abfragen:

# Live-Logs
sudo journalctl -u ollama -f

# Letzte 100 Zeilen
sudo journalctl -u ollama -n 100

# Logs von heute
sudo journalctl -u ollama --since today

# Nach Schlüsselwort suchen
sudo journalctl -u ollama | grep -i "error"

# Logs exportieren
sudo journalctl -u ollama --since "2026-04-12 00:00:00" > ollama-debug.log

Tipp bei JSON-Logs: Mit jq filtern:

sudo journalctl -u ollama -o json | jq 'select(.level=="error")'

So sehen Sie nur Fehler – ohne durch INFO-Meldungen zu scrollen.

Prometheus + Grafana Monitoring

Logs dienen der Nachanalyse – Monitoring ist das Frühwarnsystem. Prometheus + Grafana nutze ich seit über zwei Jahren: etwas Aufwand bei der Einrichtung, dafür stabil, mit großer Community.

ollama-exporter deployen

Ollama liefert keine Prometheus-Metriken direkt – ein Exporter ist nötig. Ich nutze frcooper/ollama-exporter – wenige Stars (36), aber funktional.

Deployment als Binary oder Docker – Docker ist einfacher:

# ollama-exporter in docker-compose.yml
services:
  ollama-exporter:
    image: frazco/ollama-exporter:latest
    container_name: ollama-exporter
    restart: always
    ports:
      - "9101:9101"
    environment:
      - OLLAMA_HOST=ollama:11434  # zeigt auf Ollama-Container
    depends_on:
      - ollama

Prometheus-Konfiguration:

# prometheus.yml
global:
  scrape_interval: 30s  # Markaicode empfiehlt 30 Sekunden
  evaluation_interval: 30s

scrape_configs:
  - job_name: 'ollama-exporter'
    static_configs:
      - targets: ['ollama-exporter:9101']
        labels:
          instance: 'ollama-prod'

  # GPU-Monitoring (NVIDIA)
  - job_name: 'nvidia-gpu'
    static_configs:
      - targets: ['localhost:9835']

Prometheus in docker-compose:

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    restart: always
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'

volumes:
  prometheus_data:

Wichtige Monitoring-Metriken

Der ollama-exporter liefert unter anderem:

System-Metriken (mit node-exporter):

• CPU-Auslastung: node_cpu_seconds_total
• Speicher: node_memory_MemAvailable_bytes
• Netzwerk: node_network_receive_bytes_total

GPU-Monitoring

Die GPU ist das Herz eines LLM-Services – Monitoring muss sitzen. Ich nutze nvidia_gpu_prometheus_exporter:

# NVIDIA GPU Exporter installieren
docker run -d \
  --name nvidia-exporter \
  --restart always \
  -p 9835:9835 \
  --gpus all \
  nvidia/gpu-prometheus-exporter:latest

Wichtige Metriken:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

• nvidia_gpu_utilization: GPU-Auslastung
• nvidia_gpu_memory_used_bytes: VRAM-Nutzung
• nvidia_gpu_memory_free_bytes: freier VRAM
• nvidia_gpu_temperature: GPU-Temperatur

Bei mehreren GPUs tragen Metriken das Label gpu_id – in Grafana pro Karte getrennt darstellbar.

Grafana-Dashboard

Importierbares Dashboard-JSON – in Grafana unter Import Dashboard laden:

{
  "dashboard": {
    "title": "Ollama Production Monitor",
    "panels": [
      {
        "title": "Request Rate",
        "type": "graph",
        "targets": [
          {
            "expr": "rate(ollama_requests_total[5m])",
            "legendFormat": "Requests/sec"
          }
        ],
        "gridPos": {"x": 0, "y": 0, "w": 12, "h": 6}
      },
      {
        "title": "Error Rate",
        "type": "gauge",
        "targets": [
          {
            "expr": "rate(ollama_requests_failed[5m]) / rate(ollama_requests_total[5m]) * 100",
            "legendFormat": "Error %"
          }
        ],
        "gridPos": {"x": 12, "y": 0, "w": 6, "h": 6}
      },
      {
        "title": "GPU Memory Usage",
        "type": "graph",
        "targets": [
          {
            "expr": "nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes * 100",
            "legendFormat": "GPU {{gpu_id}}"
          }
        ],
        "gridPos": {"x": 0, "y": 6, "w": 12, "h": 6}
      },
      {
        "title": "Response Latency P95",
        "type": "stat",
        "targets": [
          {
            "expr": "histogram_quantile(0.95, rate(ollama_request_duration_seconds_bucket[5m]))",
            "legendFormat": "P95 Latency"
          }
        ],
        "gridPos": {"x": 12, "y": 6, "w": 6, "h": 6}
      }
    ]
  },
  "overwrite": true
}

Typisches Layout:

• Oben links: Request-Rate mit Peak-Zeiten
• Oben rechts: Fehlerrate-Gauge, ab 5 % rot
• Unten links: Multi-GPU-Speichernutzung
• Unten rechts: P95-Latenz

Zusätzlich empfehle ich ein Tokens/s-Panel zum Modellvergleich.

Grafana-Datenquelle

Nach Grafana-Start Prometheus manuell anbinden:

1. Grafana anmelden (Standard admin/admin)
2. Configuration -> Data Sources -> Add data source
3. Prometheus wählen, URL http://prometheus:9090
4. Save & Test

Bei gemeinsamem docker-compose reicht der Containername für die Netzwerkverbindung.

Alert-Regeln und AlertManager

Monitoring zeigt Probleme – Alerts sagen Ihnen, dass Sie jetzt handeln müssen. Ein Fehler: alles als Critical markieren – das Handy vibriert dutzende Male täglich, man gewöhnt sich ab, und echte Incidents werden übersehen.

Dreistufige Alert-Strategie

Grundsatz: Critical-Alerts müssen selten sein und sofort Aufmerksamkeit erzeugen.

Prometheus-Alert-Regeln

In prometheus.yml Regeldatei einbinden:

rule_files:
  - 'ollama_alerts.yml'

Separate ollama_alerts.yml:

# ollama_alerts.yml
groups:
  - name: ollama_critical
    rules:
      # Service-Ausfall
      - alert: OllamaServiceDown
        expr: up{job="ollama-exporter"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Ollama-Service ausgefallen"
          description: "Ollama-Exporter nicht erreichbar – Service möglicherweise gestoppt"

      # GPU-Speicher (>95 %)
      - alert: GPUMemoryCritical
        expr: nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes > 0.95
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "GPU-Speicher fast erschöpft"
          description: "GPU {{ gpu_id }} Speicherauslastung über 95 %, aktuell {{ $value | humanizePercentage }}"

      # Hohe Fehlerrate
      - alert: HighErrorRate
        expr: rate(ollama_requests_failed[5m]) / rate(ollama_requests_total[5m]) > 0.20
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "Request-Fehlerrate zu hoch"
          description: "Fehlerrate der letzten 5 Minuten über 20 % – Logs prüfen"

  - name: ollama_warning
    rules:
      # Antwortzeit
      - alert: SlowResponseTime
        expr: histogram_quantile(0.95, rate(ollama_request_duration_seconds_bucket[5m])) > 60
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "P95-Antwortzeit zu langsam"
          description: "95 % der Requests brauchen über 60 Sekunden"

      # GPU-Speicher-Warnung
      - alert: GPUMemoryWarning
        expr: nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes > 0.80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "GPU-Speicherauslastung erhöht"
          description: "GPU {{ gpu_id }} Speicherauslastung über 80 %"

      # Fehlerrate-Warnung
      - alert: ErrorRateWarning
        expr: rate(ollama_requests_failed[5m]) / rate(ollama_requests_total[5m]) > 0.05
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Request-Fehlerrate steigt"
          description: "Fehlerrate der letzten 5 Minuten über 5 %"

Hinweise:

• for: Xm: Alert erst nach X Minuten anhaltendem Zustand – weniger Fehlalarme
• GPU-Schwelle 95 %: darüber folgen in der Praxis meist sofort Probleme
• Fehlerrate mit rate(): Trends zählen, nicht absolute Zahlen

AlertManager-Konfiguration

AlertManager verteilt Alerts. alertmanager.yml:

global:
  resolve_timeout: 5m

# Routing
route:
  group_by: ['severity', 'alertname']
  group_wait: 30s      # 30 Sekunden warten, gleiche Gruppe sammeln
  group_interval: 5m   # Intervall gleicher Gruppe
  repeat_interval: 3h  # Wiederholung ungelöster Alerts
  routes:
    - match:
        severity: critical
      receiver: 'critical-alerts'
      continue: false
    - match:
        severity: warning
      receiver: 'warning-alerts'
      continue: false
    - match:
        severity: info
      receiver: 'info-alerts'

# Empfänger
receivers:
  - name: 'critical-alerts'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
        channel: '#ollama-critical'
        send_resolved: true
        title: '{{ .Status | toUpper }}: {{ .CommonAnnotations.summary }}'
        text: '{{ .CommonAnnotations.description }}'

  - name: 'warning-alerts'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
        channel: '#ollama-monitor'
        send_resolved: true

  - name: 'info-alerts'
    email_configs:
      - to: '[email protected]'
        send_resolved: true

Slack-Webhook einrichten

1. Slack-App oder Incoming Webhooks anlegen
2. Webhook-URL in api_url eintragen
3. Getrennte Channels: Critical in eigenem Kanal, Warning im Monitor-Kanal

Optional Push über PagerDuty oder OpsGenie – AlertManager unterstützt beides. Kostenlos geht auch ein Telegram-Bot.

Silence und Inhibition

Für Wartungsfenster Alerts temporär stummschalten – in der AlertManager-UI:

# AlertManager UI
http://your-server:9093

# Silences -> New Silence
# Dauer und Match-Labels setzen

Oder per API:

curl -X POST http://localhost:9093/api/v1/silences \
  -d '{
    "matchers": [{"name": "alertname", "value": "OllamaServiceDown", "isRegex": false}],
    "startsAt": "2026-04-12T10:00:00Z",
    "endsAt": "2026-04-12T12:00:00Z",
    "createdBy": "admin",
    "comment": "Scheduled maintenance"
  }'

LLM-spezifische Monitoring-Tools

Prometheus + Grafana deckt Infrastruktur ab – LLMs brauchen zusätzlich Prompt-Tracking, Token-Kosten und Antwortqualität. Dafür sind klassische Monitoring-Tools weniger geeignet.

Langfuse: LLM-Tracing und Prompt-Management

Langfuse ist MIT-lizenziert, self-hostable und LLM-fokussiert:

• Jeden Dialog trace’n: Prompt, Antwort, Token, Dauer
• Prompt-Versionierung: Vorher/Nachher-Vergleich nach Änderungen
• Qualitätsbewertung: Nutzerfeedback, manuelle Labels, Qualitätstrends

Integration ist unkompliziert – Langfuse bietet Ollama-Anbindung:

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

# Python-Integrationsbeispiel
from langfuse import Langfuse
import requests

langfuse = Langfuse(
    public_key="pk-xxx",
    secret_key="sk-xxx",
    host="https://cloud.langfuse.com"  # oder Self-Hosted
)

# Jeden Aufruf protokollieren
trace = langfuse.trace(
    name="ollama-chat",
    input={"prompt": user_prompt},
    metadata={"model": "llama3.1"}
)

response = requests.post(
    "http://localhost:11434/api/generate",
    json={"model": "llama3.1", "prompt": user_prompt}
)

trace.update(
    output=response.json()["response"],
    metadata={"tokens": response.json().get("eval_count", 0)}
)

Self-Hosted per Docker:

services:
  langfuse-server:
    image: langfuse/langfuse:latest
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/langfuse
      - NEXTAUTH_SECRET=your-secret

Mit LangChain gibt es einen offiziellen Callback Handler.

SigNoz: OpenTelemetry Unified Monitoring

SigNoz bündelt Logs, Metriken und Traces auf OpenTelemetry-Basis – kein getrenntes Prometheus, Jaeger und ELK.

Für LLM-Apps nützlich: ein Request von API-Eingang über Modell-Inferenz bis DB-Query als Trace sichtbar.

Ressourcenbedarf höher – mindestens 4 GB RAM. Docker Compose:

git clone https://github.com/SigNoz/signoz.git
cd signoz/deploy/docker
docker compose up -d

Tool-Empfehlung nach Szenario

Aktuell nutze ich Prometheus + Grafana + Langfuse: Infrastruktur und Anwendungsschicht getrennt, klare Verantwortlichkeiten.

Fazit

Kurz gesagt: Warten Sie nicht auf den ersten Incident, um Monitoring einzurichten.

Die Lektion um drei Uhr nachts führte zu diesem Setup. Mein Ollama-Dienst läuft seit über einem Jahr – mehrere GPU-Speicher-Warnungen, alle auf Warning-Niveau behoben, kein nächtlicher Weckruf mehr.

Der Aufwand ist überschaubar. Alle Konfigurationsdateien zum direkten Einsatz:

• systemd-Service
• Docker Compose (Ollama + Exporter + Prometheus + Grafana)
• Prometheus-Alert-Regeln
• AlertManager-Vorlage
• Grafana-Dashboard-JSON

Das GitHub-Repo steht am Artikelende. Erfahrene Nutzer sind in 20 Minuten fertig, Einsteiger in etwa einer halben Stunde.

Empfohlene Schritte:

1. Zuerst Basis-Prometheus + Grafana für Metriken
2. 3–5 Tage Normalbetrieb beobachten, Baseline verstehen
3. Alert-Schwellen anpassen
4. Bei Bedarf Langfuse für Prompt-Tracking ergänzen

Monitoring zahlt sich dauerhaft aus. Hoffentlich brauchen Sie nicht meine Erfahrung um drei Uhr morgens, um das zu lernen.

Konfigurations-Repository: github.com/yourname/ollama-monitoring-config (Beispiellink – bei Deployment ersetzen)

Serienartikel:

• Ollama lokales Deployment – Komplettanleitung — Teil 1 der Serie
• Ollama Performance-Optimierung in der Praxis — Nächster Teil