Monitoring und Alerting einrichten

Stell dir vor: Es ist Freitagabend, du sitzt gemütlich beim Heurigen in Rust, und plötzlich schreibt ein Kunde: "Eure App geht nicht." Du hast keine Ahnung, was los ist. Kein Monitoring, keine Logs, keine Alerts. Du fischst im Trüben.

Das muss nicht sein. In diesem Beitrag zeige ich dir, wie du Monitoring und Alerting für dein Startup einrichtest -- so, dass du Probleme erkennst, bevor deine Kunden sie bemerken.

Warum Monitoring von Anfang an?

Viele Gründer denken: "Monitoring mache ich später, wenn das Produkt läuft." Das Problem: Wenn du es brauchst, ist es zu spät, um es aufzusetzen. Monitoring gehört zu den Grundlagen, genau wie Tests und Backups.

Was du ohne Monitoring nicht weisst

• Ist deine App überhaupt erreichbar?
• Wie schnell antworten deine API-Endpoints?
• Ist die Datenbank voll?
• Steigt der Speicherverbrauch langsam an?
• Gibt es Fehler, die Nutzer nicht melden?

Die drei Säulen der Observability

1. Metrics: Zahlen über Zeit (CPU-Auslastung, Response Time, Error Rate)
2. Logs: Textbasierte Aufzeichnungen von Ereignissen
3. Traces: Nachverfolgung einzelner Requests durch dein System

Für den Anfang konzentrieren wir uns auf Metrics und Logs. Tracing kommt später, wenn dein System komplexer wird.

Level 1: Uptime Monitoring -- Starte hier

Das Minimum: Du musst wissen, ob deine App erreichbar ist. Dafür brauchst du ein externes Uptime-Monitoring.

Empfohlene Tools

Einrichten mit UptimeRobot

1. Registriere dich auf uptimerobot.com (kostenlos)
2. Füge einen neuen Monitor hinzu:
   • Typ: HTTP(s)
   • URL: https://deine-app.at
   • Intervall: 5 Minuten
3. Konfiguriere Benachrichtigungen: E-Mail und/oder Slack
4. Optional: Richte eine Status-Seite ein (z.B. status.deine-app.at)

Zeitaufwand: 10 Minuten. Kosten: 0 EUR.

Das ist dein erstes Sicherheitsnetz. Wenn deine App down geht, bekommst du sofort eine Nachricht.

Level 2: Application Monitoring

Uptime allein reicht nicht. Du willst wissen, was innerhalb deiner App passiert. Hier kommen Application Performance Monitoring (APM) Tools ins Spiel.

Error Tracking mit Sentry

Sentry fängt Fehler in deiner Anwendung ab -- bevor Nutzer sie melden.

// Installation
// npm install @sentry/node

const Sentry = require("@sentry/node");

Sentry.init({
    dsn: "https://dein-key@sentry.io/projekt-id",
    environment: process.env.NODE_ENV,
    tracesSampleRate: 0.1, // 10% der Requests tracen
});

// Fehler werden automatisch erfasst
// Du kannst auch manuell Fehler melden:
try {
    riskanterCode();
} catch (error) {
    Sentry.captureException(error);
}

Sentry Free Tier: 5.000 Events pro Monat -- für ein Startup in der Frühphase völlig ausreichend.

Health Check Endpoint

Jede Anwendung sollte einen Health Check Endpoint haben:

app.get('/health', async (req, res) => {
    try {
        // Datenbankverbindung pruefen
        await db.query('SELECT 1');

        // Redis pruefen (wenn vorhanden)
        await redis.ping();

        res.json({
            status: 'healthy',
            timestamp: new Date().toISOString(),
            version: process.env.APP_VERSION || 'unknown',
            uptime: process.uptime(),
        });
    } catch (error) {
        res.status(503).json({
            status: 'unhealthy',
            error: error.message,
        });
    }
});

Diesen Endpoint kannst du von UptimeRobot oder deinem Monitoring-Tool abfragen.

Level 3: Metriken mit Prometheus und Grafana

Wenn du tiefer einsteigen willst, sind Prometheus (Metriken sammeln) und Grafana (Metriken visualisieren) der Goldstandard -- und beide sind Open Source.

Prometheus-Metriken in deiner App

// npm install prom-client
const prometheus = require('prom-client');

// Standard-Metriken aktivieren (CPU, Memory, etc.)
prometheus.collectDefaultMetrics();

// Eigene Metriken definieren
const httpRequestDuration = new prometheus.Histogram({
    name: 'http_request_duration_seconds',
    help: 'Dauer der HTTP Requests in Sekunden',
    labelNames: ['method', 'route', 'status_code'],
    buckets: [0.01, 0.05, 0.1, 0.5, 1, 5],
});

const activeUsers = new prometheus.Gauge({
    name: 'active_users_total',
    help: 'Anzahl der aktiven User',
});

// Middleware fuer Request-Tracking
app.use((req, res, next) => {
    const end = httpRequestDuration.startTimer();
    res.on('finish', () => {
        end({ method: req.method, route: req.path, status_code: res.statusCode });
    });
    next();
});

// Metriken-Endpoint
app.get('/metrics', async (req, res) => {
    res.set('Content-Type', prometheus.register.contentType);
    res.end(await prometheus.register.metrics());
});

Docker Compose mit Prometheus und Grafana

version: '3.8'

services:
  app:
    build: .
    ports:
      - "3000:3000"

  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3001:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=sicheres-passwort
    volumes:
      - grafana_data:/var/lib/grafana
    depends_on:
      - prometheus

volumes:
  prometheus_data:
  grafana_data:

prometheus.yml

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'app'
    static_configs:
      - targets: ['app:3000']
    metrics_path: '/metrics'

Level 4: Log-Management

Logs sind dein bester Freund, wenn etwas schiefgeht. Aber unstrukturierte Logs in der Konsole helfen dir wenig.

Strukturiertes Logging

Logge im JSON-Format -- das macht Logs maschinenlesbar und durchsuchbar:

const pino = require('pino');

const logger = pino({
    level: process.env.LOG_LEVEL || 'info',
    transport: process.env.NODE_ENV === 'development'
        ? { target: 'pino-pretty' }
        : undefined,
});

// Statt: console.log("User 123 hat bestellt")
// Besser:
logger.info({
    event: 'order_created',
    userId: 123,
    orderId: 'ORD-456',
    amount: 75.00,
    currency: 'EUR',
}, 'Neue Bestellung erstellt');

// Bei Fehlern:
logger.error({
    event: 'payment_failed',
    userId: 123,
    orderId: 'ORD-456',
    error: error.message,
    stack: error.stack,
}, 'Zahlung fehlgeschlagen');

Zentrales Log-Management

Wenn du mehrere Container oder Services hast, brauchst du ein zentrales Log-Management:

Kostenlose Optionen:

• Grafana Loki: Leichtgewichtig, integriert sich perfekt mit Grafana
• Better Stack Logs: Free Tier mit 1 GB pro Monat
• Papertrail: Free Tier mit 50 MB pro Monat

Loki mit Docker Compose:

loki:
  image: grafana/loki:latest
  ports:
    - "3100:3100"
  volumes:
    - loki_data:/loki

promtail:
  image: grafana/promtail:latest
  volumes:
    - /var/log:/var/log
    - ./promtail-config.yml:/etc/promtail/config.yml

Alerting -- Die richtigen Benachrichtigungen

Monitoring ohne Alerting ist wie ein Rauchmelder ohne Batterie. Du musst benachrichtigt werden, wenn etwas nicht stimmt.

Die goldenen Regeln für Alerts

1. Nur alerting-würdige Dinge: Jeder Alert sollte eine Aktion erfordern
2. Keine Alert-Müdigkeit: Zu viele Alerts führen dazu, dass du alle ignorierst
3. Klare Eskalation: Wer wird wann benachrichtigt?
4. Kontext im Alert: Der Alert sollte genug Information enthalten, um das Problem zu verstehen

Alert-Kategorien

Welche Alerts du brauchst

Minimum (starte hier):

• App ist nicht erreichbar (HTTP 5xx)
• Datenbank ist nicht erreichbar
• Disk-Space unter 20%
• SSL-Zertifikat läuft in 14 Tagen ab

Später hinzufügen:

• Response Time über 2 Sekunden
• Error Rate über 1%
• CPU über 80% für mehr als 5 Minuten
• Memory über 90%

Alerting mit Grafana

In Grafana kannst du direkt auf deine Metriken Alerts definieren:

1. Öffne ein Dashboard-Panel
2. Klicke auf "Alert" Tab
3. Definiere die Bedingung (z.B. "Error Rate > 1%")
4. Konfiguriere den Benachrichtigungskanal (Slack, E-Mail, PagerDuty)

Das pragmatische Starter-Setup

Du musst nicht alles auf einmal einrichten. Hier ist ein realistischer Fahrplan:

Woche 1: Basics (0 EUR/Monat)

• UptimeRobot für externen Health Check
• Sentry Free Tier für Error Tracking
• Health Check Endpoint in deiner App

Woche 2: Logging (0 EUR/Monat)

• Strukturiertes Logging mit pino oder winston
• Logs zentralisieren (Better Stack Free Tier oder Grafana Loki)

Monat 2: Metriken (0-20 EUR/Monat)

• Prometheus und Grafana aufsetzen (oder Grafana Cloud Free Tier)
• Basis-Dashboards erstellen
• Erste Alerts konfigurieren

Monat 3: Fortgeschritten (20-50 EUR/Monat)

• Custom Business-Metriken (Bestellungen pro Stunde, aktive User)
• SLOs definieren (z.B. 99,9% Uptime)
• Alert-Eskalation einrichten

Grafana Cloud -- Die einfache Alternative

Wenn du dir den Betrieb von Prometheus und Grafana sparen willst, ist Grafana Cloud eine exzellente Option:

• Free Tier: 10.000 Metriken, 50 GB Logs, 50 GB Traces
• Kein Self-Hosting: Grafana Labs betreibt die Infrastruktur
• Alle Features: Dashboards, Alerts, Loki, Prometheus -- alles integriert

Für die meisten Startups reicht der Free Tier völlig aus.

Was du messen solltest -- Business Metriken

Technische Metriken sind wichtig, aber vergiss nicht die Business-Metriken:

// Beispiel: Business-Metriken tracken
const signups = new prometheus.Counter({
    name: 'user_signups_total',
    help: 'Gesamtzahl der Registrierungen',
});

const orders = new prometheus.Counter({
    name: 'orders_total',
    help: 'Gesamtzahl der Bestellungen',
    labelNames: ['status'],
});

const revenue = new prometheus.Counter({
    name: 'revenue_eur_total',
    help: 'Gesamtumsatz in EUR',
});

// Bei Registrierung:
signups.inc();

// Bei Bestellung:
orders.inc({ status: 'completed' });
revenue.inc(bestellung.total);

Ein Dashboard mit diesen Metriken gibt dir Echtzeit-Einblick in dein Business -- kein Warten auf den nächsten Analytics-Report.

Häufige Monitoring-Fehler

Fehler 1: Zu viele Dashboards, zu wenig Alerts

Ein Dashboard, das niemand anschaut, ist nutzlos. Lieber wenige, aber aussagekräftige Dashboards -- und gut konfigurierte Alerts.

Fehler 2: Alert-Müdigkeit

Wenn du 20 Alerts pro Tag bekommst, ignorierst du alle. Jeder Alert muss eine konkrete Aktion erfordern. Wenn nicht, ist es kein Alert, sondern eine Info.

Fehler 3: Kein Runbook

Wenn ein Alert kommt -- was tust du? Dokumentiere für jeden Alert die Schritte zur Problemlösung. Das hilft dir und zukünftigen Teammitgliedern.

Fehler 4: Nur technische Metriken

CPU und Memory sind wichtig, aber die Frage "Können Kunden bestellen?" ist wichtiger. Definiere Business-relevante Health Checks.

Fazit

Monitoring und Alerting sind keine optionalen Extras -- sie sind essentiell für jedes Startup, das ein Live-Produkt betreibt. Die gute Nachricht: Du kannst mit 0 EUR pro Monat starten und trotzdem gut aufgestellt sein.

Starte mit dem Minimum: Uptime Monitoring und Error Tracking. Baue dann Schritt für Schritt aus. Und denk immer daran: Das Ziel ist nicht, die meisten Metriken zu sammeln, sondern die richtigen -- und auf sie zu reagieren.

Deine Kunden beim Heurigen in Rust werden es dir danken.

Startup Burgenland unterstützt dich

Du willst Monitoring für dein Startup einrichten und brauchst Hilfe bei der Auswahl der richtigen Tools? Bei Startup Burgenland stehen dir technische Mentoren zur Seite, die dir helfen, von Anfang an die richtige Observability-Strategie zu fahren.

Jetzt Beratung anfragen

Weiterführende Artikel

• Cloud-Hosting für Startups -- AWS Azure oder Hetzner
• Serverless Architecture für Startups
• Kosten-Optimierung in der Cloud
• Skalierbare Infrastruktur planen
• DevOps Grundlagen für Gründer

Dieser Beitrag ist Teil der Serie "Cloud und Infrastruktur" im Startup Burgenland Blog. In dieser Serie behandeln wir alle technischen Themen rund um Hosting, Deployment und Skalierung -- speziell für österreichische Startups und Gründer.

Über den Autor: Felix Lenhard ist Program Director und Startup Coach bei Startup Burgenland. Zuvor Managing Director beim 360 Innovation Lab, Innovation Manager bei RHI Magnesita und Serial Entrepreneur mit internationalen Exits. Über 15 Jahre Erfahrung in Innovation und Unternehmensaufbau.