Spring Boot Observability mit OpenTelemetry
Wie geht es meiner Anwendung eigentlich? Wer hierauf eine präzise Antwort haben möchte, muss die richtigen Daten sammeln. Tut man es nicht, ist man blind unterwegs und kann bei Problemen erst spät reagieren. In diesem Artikel beschreibe ich daher, wie man einfach und standardisiert Observability-Daten seiner Spring-Boot-Anwendung sammelt.
Mit Spring Boot Version 4.1 (Release im Mai 2026, aktuell Preview) ist es angenehm einfach geworden, umfangreiche Observability-Daten abzugreifen.
Der neue Starter spring-boot-starter-opentelemetry bringt dazu alle nötigen Abhängigkeiten und ein Großteil an Konfiguration mit sich.
So werden im Handumdrehen Logs, Traces und Metriken im einheitlichen OpenTelemetry-Format bereitgestellt.
Dabei ist es für den Anfang gar nicht notwendig seinen Code manuell zu instrumentieren, um Daten zu sammeln. Viele Teile des Spring-Ökosystems sind bereits instrumentiert und liefern Out-of-the-Box schon Traces sowie Datenpunkte zu ein- und ausgehenden Requests, Antwortzeiten, Statuscodes und vielem mehr. Weitere Daten lassen sich Bequem über die Observation-API von Micrometer sammeln. Dazu haben wir bereits vor einiger Zeit einen separaten Artikel im JavaMagazin veröffentlicht.
Logs, Traces und Metriken, sogenannte Signale, bilden die drei Säulen für eine gute Observability einer Anwendung. Wenn diese Daten vorliegen und miteinander verknüpfbar sind, findet man bei einem Alert wegen langsamer Antwortzeiten eines Endpunktes schnell den Übeltäter: ein Server, dem der Speicher ausgeht.
Mit OpenTelemetry einheitlich unterwegs
OpenTelemetry bietet dafür eine hervorragende Grundlage. Zum einen gibt es das Format der Signale vor und definiert, wie diese zu übertragen sind. Außerdem sammeln sich im OpenTelemetry-Ökosystem einige interessante Tools, die einem das Leben erleichtern können. Allen voran der OpenTelemetry Collector: eine Anwendung, die Observability-Daten entgegennimmt, anreichert, filtert und weiterschickt.
Der OpenTelemetry Collector kann über Plugins beliebig konfiguriert werden und ist somit vielseitig einsetzbar. Die OpenTelemetry-Daten unsere Spring-Boot-Anwendung können wir so direkt dort abladen. Über die weitere Verarbeitung muss sich die Anwendung keine Gedanken mehr machen. Aber auch weitere Datenquellen sind möglich. Der Collector selbst kann zum Beispiel selbst aktiv werden und Prometheus-Metriken einsammeln oder Log-Dateien auslesen. Im Kubernetes-Umfeld können diese Daten automatisch um Informationen wie Pod- und Namespace-Name ergänzt werden. Insgesamt ein mächtiges Werkzeug, das es ermöglicht anbieterunabhängig OpenTelemetry-Daten zu verarbeiten.
Spring Boot Setup
Aber zurück zu Spring.
Nachdem der spring-boot-starter-opentelemetry Starter im Projekt ist, können wir konfigurieren, an welche Stelle die Signale gesendet werden sollen.
Angenommen, ein OpenTelemetry Collector läuft lokal auf Port 4318, müssen folgende Werte gesetzt werden:
-
Traces:
management.opentelemetry.tracing.export.otlp.endpoint=http://localhost:4318 -
Metriken:
management.otlp.metrics.export.url=http://localhost:4318 -
Logs:
management.otlp.logging.export.otlp.endpoint=http://localhost:4318
In der Praxis wird häufig noch ein Header mit Credentials zur Authentifizierung erwartet.
Dieser kann ebenfalls konfiguriert werden.
Vollständig könnte eine application.yml dann zum Beispiel so aussehen:
management:
# Jeden möglichen Trace aufzeichnen.
# Nur für die Entwicklung oder falls das
# Sampling im Collector erfolgen soll.
tracing:
sampling:
probability: 1
otlp:
logging:
export:
otlp:
endpoint: http://localhost:4318
headers:
Authorization: "<Ausgelassen>"
metrics:
export:
url: http://localhost:4318
headers:
Authorization: "<Ausgelassen>"
opentelemetry:
tracing:
export:
otlp:
endpoint: http://localhost:4318
headers:
Authorization: "<Ausgelassen>"Allein dieses Setup ist ausreichend, um regelmäßig Metriken und Traces an unseren Collector zu senden. Nur für das Thema Logging ist aktuell noch etwas zusätzliche Konfiguration notwendig. Das könnte sich jedoch in zukünftigen Versionen ändern.
Spring Boot kann Logs aktiv im OpenTelemetry-Format senden, zum Beispiel via Logback mit OpenTelemetry Appender. Dafür benötigen wir eine Spring-Komponente, die den Appender registriert und eine Erweiterung der Logback-Konfiguration. Der Appender ergänzt den Console-Appender – Logs landen so auf der Standardausgabe und werden gleichzeitig per OpenTelemetry weitergeschickt.
@Component
class InstallOpenTelemetryAppender implements InitializingBean {
private final OpenTelemetry openTelemetry;
InstallOpenTelemetryAppender(OpenTelemetry openTelemetry) {
this.openTelemetry = openTelemetry;
}
@Override
public void afterPropertiesSet() {
OpenTelemetryAppender.install(this.openTelemetry);
}
}src/main/resources/logback-spring.xml)<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<include
resource="org/springframework/boot/logging/logback/base.xml"/>
<appender name="OTEL"
class="io.opentelemetry.instrumentation.logback.appender.v1_0.OpenTelemetryAppender">
</appender>
<root level="INFO">
<appender-ref ref="CONSOLE"/>
<appender-ref ref="OTEL"/>
</root>
</configuration>Damit haben wir nun einen Einblick in umfangreiche Daten unserer Anwendung. Der eigentliche Mehrwert von OpenTelemetry entfaltet sich, wenn Logs, Traces und Metriken miteinander verknüpft sind. Spring Boot injiziert dafür automatisch die Trace-ID und Span-ID in den Logging-Kontext. Jede Log-Ausgabe innerhalb eines Requests enthält so eine Referenz auf den zugehörigen Trace.
Im Dashboard kann man so direkt von einer auffälligen Metrik zum verursachenden Trace springen. Von dort aus sind die zugehörigen Log-Einträge nur einen Klick entfernt. Diese Korrelation verkürzt die Fehlersuche erheblich.
LGTM-Stack
Zum Speichern der Signale lässt sich in der Entwicklung schnell ein LGTM-Stack hochfahren. Dieser besteht aus Loki für Logs, Grafana als Dashboard, Tempo für Traces und Mimir für Metriken. Gleichzeitig wird auch ein OpenTelemetry Collector mitgebracht, der alle Daten entgegennimmt und an die passenden Anwendungen verteilt.
Ein lokaler LGTM-Stack kann schnell per Docker bereitgestellt werden. Daten können über den Port 4318 hinzugefügt werden. Das Dashboard wird auf Port 3000 bereitgestellt.
$ docker run --name lgtm \
-p 3000:3000 -p 4318:4318 \
--rm -ti grafana/otel-lgtm
Fazit
Observability-Daten zu erheben und zu speichern ist erstmal recht leicht. Geht es aber im produktiven Betrieb um große Datenmengen oder wächst der Anspruch an die Ausfallsicherheit, kommen viele Aspekte hinzu, für die keine pauschale Lösung mehr gibt.
Die Auswahl eines geeigneten Produkts sowie dessen Skalierung erfordern einen Überblick über die verfügbaren Observability-Produkte. Es muss nämlich nicht immer ein Grafana-Stack oder ein Cloud-Produkt sein. Alternativen wie VictoriaMetrics können durchaus einen Blick wert sein, wenn Performance oder Speichereffizienz relevante Themen sind. Andere Produkte versuchen hingegen durch ihren einfachen Aufbau zu bestechen. ClickStack beispielsweise speichert alle drei Signalarten in einer einzelnen ClickHouse Datenbank. Und Queries lassen sich somit direkt in SQL formulieren, was die Handhabung weiter vereinfacht.
Ebenso wichtig ist es, die Anforderungen an das System zu verstehen. Nur so können die richtigen Daten gesammelt und ein passendes Produkt gewählt werden. Diese lassen sich zum Beispiel gut in einem Workshop-Format ermitteln.
Zu den Themen Observability, Monitoring, Spring Boot und Datenbanken bieten wir sowohl Beratung, Entwicklungsunterstützung als auch passende Schulungen an:
Auch für Ihren individuellen Bedarf können wir Workshops und Schulungen anbieten. Sprechen Sie uns gerne an.