{
  "version": 1,
  "type": "tool",
  "canonicalUrl": "https://tools.utildesk.de/tools/prometheus/",
  "markdownUrl": "https://tools.utildesk.de/markdown/tools/prometheus.md",
  "data": {
    "slug": "prometheus",
    "title": "Prometheus",
    "url": "https://tools.utildesk.de/tools/prometheus/",
    "category": "Entwickler-Tools",
    "priceModel": "Open Source",
    "tags": [
      "monitoring",
      "metrics",
      "observability",
      "developer-tools"
    ],
    "description": "Prometheus sammelt Zeitreihenmetriken und löst Alarme für beobachtbare Systeme aus, verlangt aber disziplinierte Labels, SLOs und Runbooks.",
    "officialUrl": "https://prometheus.io/",
    "affiliateUrl": null,
    "inLanguage": "de-DE",
    "tier": "D",
    "editorialStatus": "curated",
    "featureList": [
      "Grafana: Visualisierung und Alerting als Ergänzung zu einer vorhandenen Metrikquelle.",
      "Datadog: gehostete Observability mit breiterem SaaS- und Integrationsumfang.",
      "New Relic: APM und Full-Stack-Beobachtung als verwaltete Plattform.",
      "Elasticsearch: stärker, wenn Suche und Loganalyse den Kern des Problems bilden."
    ],
    "wordCount": 528,
    "contentMarkdown": "# Prometheus\n\nIm Checkout treten kurze Latenzspitzen auf, die in Durchschnittswerten verschwinden. Das Plattformteam erfasst deshalb Rate, Fehler und Dauer pro Dienst, formuliert ein SLO und verbindet den Alarm mit einem konkreten Runbook. Bei der Instrumentierung begrenzt es Labels bewusst, damit Kundennummern oder Request-IDs keine explodierende Kardinalität erzeugen. Prometheus macht das Verhalten messbar; ohne sinnvolle Metriken, Zuständigkeit und Reaktion bleibt auch ein perfekter Alarm nur Lärm.\n\r\nPrometheus ist ein Open-Source-System für Metriken und Monitoring, kein KI-Assistent und kein Workflow-Automatisierer. Es sammelt zeitbasierte Messwerte, speichert sie als Zeitreihen und erlaubt Abfragen sowie Alarme. Typische Signale sind Request-Rate, Fehlerrate, Latenz, Ressourcenverbrauch und Queue-Tiefe.\r\n\r\n## Für wen ist Prometheus geeignet?\r\n\r\nPrometheus passt zu Teams, die Dienste, Container oder Infrastruktur betreiben und aus technischen Signalen handlungsfähige Beobachtbarkeit machen wollen. Es funktioniert besonders gut mit einer Pull-basierten Exporter-Landschaft und ergänzt Visualisierung etwa über [Grafana](/tools/grafana/). Für Log-Suche oder verteilte Traces braucht es zusätzliche Systeme; Metriken allein erklären nicht jeden Vorfall.\r\n\r\n<figure class=\"tool-editorial-figure\">\r\n  <img src=\"/images/tools/prometheus-editorial.webp\" alt=\"Redaktionelle Illustration zum praktischen Einsatz von Prometheus\" loading=\"lazy\" decoding=\"async\" />\r\n</figure>\r\n\r\n## Mit wenigen SLO-Signalen starten\r\n\r\nBeginnen Sie mit der Nutzerperspektive: Verfügbarkeit, Fehlerrate und Latenz eines kritischen Ablaufs. Eine Dashboard-Wand voller CPU-Werte hilft wenig, wenn niemand weiß, ob Kunden betroffen sind. Definieren Sie für jeden Alarm Besitzer, Dringlichkeit, Runbook und eine konkrete Aktion.\r\n\r\n## Labels und Cardinality\r\n\r\nLabels machen Metriken filterbar, können aber Speicher und Abfragekosten explodieren lassen. IDs, E-Mail-Adressen, vollständige URLs oder zufällige Request-Werte gehören nicht als Label in Prometheus. Nutzen Sie wenige begrenzte Dimensionen wie Service, Endpoint-Klasse oder Statusfamilie und prüfen Sie neue Metriken im Review.\r\n\r\n## Abfragen, Recording Rules und Alerting\r\n\r\nPromQL erlaubt flexible Abfragen; häufige oder teure Berechnungen lassen sich als Recording Rules vorbereiten. Alerts sollten Symptome und Dauer abbilden, nicht jede kurzfristige Schwankung. Alertmanager-Routing, Deduplizierung und Inhibition verhindern, dass ein Ausfall zwanzig Seiten erzeugt. Testen Sie Regeln mit absichtlich erzeugten Fehlern.\r\n\r\n## Betrieb und Aufbewahrung\r\n\r\nPlanen Sie Scrape-Intervalle, Aufbewahrungszeit, Speicher, Backups und Hochverfügbarkeit passend zur Last. Prometheus ist nicht als unbegrenztes Langzeitarchiv gedacht; für größere oder längere Aufbewahrung können Remote Storage oder kompatible Systeme nötig sein. Schützen Sie Metrik-Endpunkte, weil sie interne Namen, Kapazitäten oder Fehlerdetails verraten können.\r\n\r\n## Alternativen\n\n- [Grafana](/tools/grafana/): Visualisierung und Alerting als Ergänzung zu einer vorhandenen Metrikquelle.\n- [Datadog](/tools/datadog/): gehostete Observability mit breiterem SaaS- und Integrationsumfang.\n- [New Relic](/tools/new-relic/): APM und Full-Stack-Beobachtung als verwaltete Plattform.\n- [Elasticsearch](/tools/elasticsearch/): stärker, wenn Suche und Loganalyse den Kern des Problems bilden.\n## Redaktionelle Einschätzung\r\n\r\nPrometheus ist ein sehr guter Standard für technische Metriken, sofern das Team Cardinality, Alarmhygiene und Betriebsverantwortung ernst nimmt. Der beste erste Erfolg ist nicht ein schönes Dashboard, sondern ein Alarm, der selten feuert, den richtigen Menschen erreicht und eine klare Diagnose beschleunigt.\r\n\r\n## FAQ\r\n\r\n**Ersetzt Prometheus Log-Management?**\r\n\r\nNein. Metriken zeigen Trends und Symptome effizient; detailreiche Ereignisse und Fehlerursachen liegen meist in Logs oder Traces.\r\n\r\n**Warum sind hoch-kardinale Labels problematisch?**\r\n\r\nJede einzigartige Labelkombination erzeugt eine eigene Zeitreihe. Unbegrenzte IDs oder URLs können Speicher und Abfragen sehr schnell überlasten.\r\n\r\n**Was macht einen guten Alert aus?**\r\n\r\nEr zeigt einen relevanten, anhaltenden Nutzer- oder Systemschaden, hat einen Verantwortlichen und ein kurzes Runbook. Reine Schwankungen sind besser im Dashboard aufgehoben.\n\n**Welche Labels sollte man vermeiden?**\n\nUnbegrenzte Werte wie Request-IDs, Kundennummern oder freie URLs erzeugen hohe Kardinalität. Labels sollten eine bekannte, kontrollierte Menge sinnvoller Dimensionen abbilden."
  }
}