{"id":52722,"date":"2025-08-07T12:54:24","date_gmt":"2025-08-07T20:54:24","guid":{"rendered":"https:\/\/www.sumologic.com\/blog\/warum-prometheus-nicht-ausreicht-um-komplexe-umgebungen-zu-ueberwachen"},"modified":"2026-02-25T04:26:33","modified_gmt":"2026-02-25T12:26:33","slug":"prometheus-monitoring","status":"publish","type":"blog","link":"https:\/\/www.sumologic.com\/de\/blog\/prometheus-monitoring","title":{"rendered":"Warum Prometheus nicht ausreicht, um komplexe Umgebungen zu \u00fcberwachen"},"content":{"rendered":"\n
\n
\n
\n
\n
\"Prometheus-Überwachung<\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

Moderne Systeme unterscheiden sich grundlegend von denen fr\u00fcherer Jahre. Die meisten Unternehmen haben sich von traditionellen Monolithen verabschiedet und containerisierte Anwendungen <\/a>eingef\u00fchrt, die auf hochverteilten Infrastrukturen laufen.\u00a0<\/p>\n\n\n\n

Diese Entwicklung erh\u00f6ht die Resilienz, bringt jedoch ein h\u00f6heres Ma\u00df an Komplexit\u00e4t mit sich, was die Identifikation und Behebung von Problemen erschwert.<\/p>\n\n\n\n

Ein Teil der L\u00f6sung f\u00fcr diese Herausforderung liegt in der Nutzung von Tools und Plattformen, die den Zustand von Diensten und Infrastruktur effektiv \u00fcberwachen k\u00f6nnen. Zu diesem Zweck werden in diesem Beitrag Best Practices f\u00fcr die Prometheus-\u00dcberwachung von Diensten und Infrastrukturen erl\u00e4utert. Dar\u00fcber hinaus werden die Gr\u00fcnde dargelegt, warum Prometheus allein nicht ausreicht, um die komplexen, hochgradig verteilten Systemumgebungen zu \u00fcberwachen, die heute im Einsatz sind.<\/p>\n\n\n\n

Was ist Prometheus?<\/h2>\n\n\n\n

Prometheus ist ein Open-Source-Monitoring- und Alerting-Toolkit<\/a>, das 2012 von SoundCloud f\u00fcr das Monitoring Cloud-nativer Metriken entwickelt wurde.\u00a0<\/p>\n\n\n\n

Im Bereich Monitoring und Observability<\/a> gibt es drei zentrale Datentypen: Logs, Metriken und Traces. Metriken dienen als zeitbasierte Messwerte, die Ihnen helfen, Service Level Objectives<\/a> (SLOs) und Service Level Indicators<\/a> (SLIs) in Form von Zeitreihen zu verfolgen.<\/p>\n\n\n\n

Metriken mit hoher Kardinalit\u00e4t haben viele eindeutige Kombinationen von Bezeichnungen (z. B. user_id, region), was die Speicher- und Abfrageleistung von Prometheus belasten kann. Viele Kunden ben\u00f6tigen jedoch mehr von ihren Observability-Umgebungen, und heutzutage haben die meisten Unternehmen OpenTelemetry \u00fcbernommen, um Collectors zu vereinheitlichen und Daten aus allen drei Datenquellen zu sammeln.<\/a><\/a><\/p>\n\n\n\n

Was kann mit Prometheus \u00fcberwacht werden?<\/h2>\n\n\n\n

Unternehmen nutzen Prometheus, um Metrikdaten zur Performance von Services und Infrastruktur zu sammeln. Je nach Anwendungsfall k\u00f6nnen dies Indikatoren wie CPU-Auslastung, Speicherauslastung, Gesamtanzahl der Requests, Requests pro Sekunde, Request-Z\u00e4hler, Exception-Z\u00e4hler und mehr sein. Wenn diese Metriken korrekt genutzt werden, unterst\u00fctzen sie Unternehmen dabei, Systemprobleme zeitnah zu identifizieren.<\/p>\n\n\n\n

Prometheus-Server-Architektur<\/h2>\n\n\n\n

Im Mittelpunkt der Prometheus-Architektur steht der Prometheus-Server, der die eigentlichen \u00dcberwachungsfunktionen durchf\u00fchrt. Der Prometheus-Server besteht aus drei Hauptkomponenten: einer Zeitreihen-Datenbank, einem Worker f\u00fcr den Datenabruf und einem HTTP-Server.<\/p>\n\n\n\n

Zeitreihendatenbank<\/h3>\n\n\n\n

Diese Komponente ist f\u00fcr die Speicherung der Metriken verantwortlich. Diese Metriken werden als Zeitreihe abgelegt, was bedeutet, dass die Daten als eine Reihe von zeitgestempelten Datenpunkten in der Datenbank gespeichert werden, die derselben Metrik und denselben Label-Dimensionen zugeordnet sind.<\/p>\n\n\n\n

Worker f\u00fcr Datenabruf<\/h3>\n\n\n\n

Diese Komponente tut genau das, was ihr Name andeutet: ruft Metriken von sogenannten “Targets” ab, wie etwa Anwendungen, Services oder Infrastrukturkomponenten. Diese Metriken werden dann in die Zeitreihendatenbank \u00fcbertragen. Die Datenerfassung erfolgt durch das Abrufen von HTTP-Endpunkten, auch als Prometheus-Instanzen bekannt, auf den entsprechenden Targets.<\/p>\n\n\n\n

Der Standard-Endpoint f\u00fcr Metriken lautet \/metrics. Um ein Target zu \u00fcberwachen, wird Prometheus mit einem sogenannten Exporter <\/a>konfiguriert. Ein Exporter ist ein Service, der Metriken vom Target abruft, sie korrekt formatiert und den \/metrics-Endpoint bereitstellt, damit der Worker die Daten zur Speicherung in der Zeitreihendatenbank abholen kann. F\u00fcr Jobs, die nicht gescraped werden k\u00f6nnen, bietet der Prometheus Pushgateway eine M\u00f6glichkeit, Zeitreihen von kurzlebigen Batch-Jobs zu pushen, die Prometheus dann abruft.\u00a0<\/hostaddress><\/p>\n\n\n\n

HTTP-Server\u00a0<\/h3>\n\n\n\n

Der HTTP-Server akzeptiert Abfragen in der Prometheus Query Language (PromQL<\/a>), um Daten aus der Zeitreihendatenbank abzurufen. Der HTTP-Server kann sowohl durch die Prometheus-UI als auch durch andere Visualisierungstools wie Grafana<\/a> verwendet werden, um Entwicklern und IT-Personal eine benutzerfreundliche Schnittstelle zum Abfragen und Visualisieren dieser Metriken bereitzustellen.<\/p>\n\n\n\n

Verwaltung von Prometheus-Alerts<\/h2>\n\n\n\n

Auch der Prometheus Alertmanager ist hier erw\u00e4hnenswert. In der Prometheus-Konfiguration k\u00f6nnen Regeln definiert werden, die Grenzwerte festlegen, bei deren \u00dcberschreitung ein Alarm ausgel\u00f6st wird. Wenn diese Grenze \u00fcberschritten wird, sendet der Prometheus-Server den Alarm an den Alertmanager. Der Alertmanager \u00fcbernimmt dann die Aufgaben der Deduplizierung, Gruppierung und Weiterleitung dieser Alarme an die zust\u00e4ndigen Personen per E-Mail oder \u00fcber andere Integrationen.<\/p>\n\n\n\n

Warum Prometheus allein nicht ausreicht<\/h2>\n\n\n\n

Wie wir wissen, haben moderne Entwicklungsarchitekturen ein viel h\u00f6heres Ma\u00df an Komplexit\u00e4t als noch vor \u00fcber einem Jahrzehnt. Heutige Systeme bestehen aus vielen Servern, die containerisierte Anwendungen und Services betreiben, wie z. B. in einem Kubernetes-Cluster. Diese Services sind lose gekoppelt und rufen sich gegenseitig auf, um Funktionalit\u00e4ten f\u00fcr den Endnutzer bereitzustellen. Architektonisch k\u00f6nnen diese Services auch entkoppelt sein und in mehreren Cloud-Umgebungen laufen. Die komplexe Struktur dieser Systeme kann dazu f\u00fchren, dass die Ursachen von Ausf\u00e4llen schwer zu identifizieren sind.<\/p>\n\n\n\n

Um diese Herausforderung zu bew\u00e4ltigen, ben\u00f6tigen Unternehmen einen detaillierten Einblick in das Systemverhalten. Die Sammlung und Aggregation von Logdaten<\/a> ist dabei von entscheidender Bedeutung. Diese Logdaten k\u00f6nnen mit Leistungsmetriken korreliert werden, so dass Unternehmen die f\u00fcr eine effiziente Ursachenanalyse<\/a> erforderlichen Einblicke und Zusammenh\u00e4nge gewinnen. Prometheus sammelt zwar Metriken, aber keine Logdaten. Daher bietet es nicht den Detailgrad, der f\u00fcr eine effektive Incident Response<\/a> erforderlich ist.<\/p>\n\n\n\n

Dar\u00fcber hinaus steht Prometheus vor Herausforderungen, wenn es stark skaliert wird \u2013 eine Situation, die bei solchen hochgradig verteilten modernen Systemen oft unvermeidlich ist. Prometheus wurde urspr\u00fcnglich nicht f\u00fcr die Abfrage und Aggregation von Metriken aus mehreren Instanzen entwickelt. Eine entsprechende Konfiguration erfordert eine zus\u00e4tzliche Komplexit\u00e4t der Prometheus-Bereitstellung in Ihrem Unternehmen. Dies erschwert die Erlangung eines ganzheitlichen \u00dcberblicks \u00fcber das gesamte System, was ein entscheidender Aspekt f\u00fcr eine effiziente Reaktion auf Vorf\u00e4lle ist.<\/p>\n\n\n\n

Und schlie\u00dflich wurde Prometheus nicht entwickelt, um Metrikdaten \u00fcber lange Zeitr\u00e4ume aufzubewahren. Der Zugriff auf diese Art von historischen Daten kann f\u00fcr Unternehmen, die komplexe Umgebungen verwalten, von unsch\u00e4tzbarem Wert sein. Zum einen k\u00f6nnen Unternehmen diese Metriken analysieren, um Muster zu erkennen, die \u00fcber einige Monate oder sogar ein Jahr hinweg auftreten, um ein Verst\u00e4ndnis f\u00fcr die Systemnutzung w\u00e4hrend eines bestimmten Zeitraums zu erhalten. Solche Erkenntnisse k\u00f6nnen Skalierungsstrategien vorgeben, wenn die Systeme an ihre Grenzen sto\u00dfen.<\/p>\n\n\n\n

Einheitliche Erfassung f\u00fcr Kubernetes-Monitoring\u00a0<\/h2>\n\n\n\n

Prometheus ist zwar ein hervorragendes Tool f\u00fcr die Erfassung von Metriken auf hoher Ebene f\u00fcr SLOs und SLIs, aber Site Reliability Engineers<\/a> und Sicherheitsanalysten m\u00fcssen die Logs genauer untersuchen, um herauszufinden, was genau schief gelaufen sein k\u00f6nnte. Deshalb ist eine einheitliche Telemetrieerfassung f\u00fcr alle Datentypen \u2013 Logs, Metriken und Traces \u2013 so wichtig. Wir m\u00fcssen veraltete Prozesse und Denkweisen hinter uns lassen, um innovativ zu sein und die neuesten Best Practices zu nutzen, um das bestm\u00f6gliche digitale Kundenerlebnis<\/a> zu gew\u00e4hrleisten.<\/p>\n\n\n

\n
\"Was<\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

All diese Herausforderungen lassen sich am besten durch die Nutzung einer einheitlichen Kubernetes-\u00dcberwachung<\/a> mit OpenTelemetry Collector von Sumo Logic <\/a>und die Einrichtung des neuesten Helm Chart<\/a> bew\u00e4ltigen. Zus\u00e4tzlich k\u00f6nnen Sie mit Otel Remote Management von Sumo Logic<\/a> Zeit bei der Einrichtung und Verwaltung Ihrer Collectors Zeit sparen. Sie k\u00f6nnen Prometheus-Daten immer noch neben diesem Collector aggregieren, aber es gibt keinen Grund, ihn als Middleware f\u00fcr Metriken zu verwenden, es sei denn, Ihre Infrastruktur erfordert spezifische Fachkenntnisse. Ein Beispiel daf\u00fcr w\u00e4re die Vertrautheit mit PromQL oder das Erfordernis bestimmter Histogramme, die im Sumo Logic-Monitoring-Umfeld nicht verf\u00fcgbar sind.\u00a0<\/p>\n\n\n\n

Es ist sinnvoll, OpenTelemetry als Standard zu nutzen, um eine kleinere Erfassungsfl\u00e4che zu erreichen und die Zeit f\u00fcr die Instrumentierung im Rahmen der besten Sicherheits- und Monitoringpraktiken zu minimieren.\u00a0<\/p>\n\n\n\n

Neugierig auf mehr? Schauen Sie sich die Best Practices f\u00fcr Kubernetes-Monitoring an<\/a>.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div><\/section>\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":331,"featured_media":50017,"template":"","meta":{"_acf_changed":false,"show_custom_date":false,"custom_date":"","featured":false,"featured_image":0,"learn_more_label":"","image_alt_text":"","learn_more_type":"","show_popup":false,"learn_more_link_file":0,"event_date":false,"event_start_date":"","event_end_date":"","place_holder_image_url":"","post_reading_time":"4","notification_enabled":false,"notification_text":"","notification_logo":"","notification_expiration_time":0,"is_enable_transparent_header":false,"selected_taxonomy_terms":{"blog-category":[256],"blog-tag":[],"translation_priority":[221]},"selected_primary_terms":[],"learn_more_link":[],"featured_page_list":[],"notification_enabled_post_list":[],"_gspb_post_css":"","_relevanssi_hide_post":"","_relevanssi_hide_content":"","_relevanssi_pin_for_all":"","_relevanssi_pin_keywords":"","_relevanssi_unpin_keywords":"","_relevanssi_related_keywords":"","_relevanssi_related_include_ids":"","_relevanssi_related_exclude_ids":"","_relevanssi_related_no_append":"","_relevanssi_related_not_related":"","_relevanssi_related_posts":"52702,62709,62726","_relevanssi_noindex_reason":"","inline_featured_image":false,"footnotes":""},"blog-category":[256],"blog-tag":[],"class_list":["post-52722","blog","type-blog","status-publish","has-post-thumbnail","hentry","blog-category-devops-it-operations"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/blog\/52722","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/users\/331"}],"version-history":[{"count":11,"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/blog\/52722\/revisions"}],"predecessor-version":[{"id":70172,"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/blog\/52722\/revisions\/70172"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/media\/50017"}],"wp:attachment":[{"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/media?parent=52722"}],"wp:term":[{"taxonomy":"blog-category","embeddable":true,"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/blog-category?post=52722"},{"taxonomy":"blog-tag","embeddable":true,"href":"https:\/\/www.sumologic.com\/de\/wp-json\/wp\/v2\/blog-tag?post=52722"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}