SigNoz v0.142.0 mit Docker Compose selbst hosten: Traces, Metriken und Logs in einem System

Wer verteilte Anwendungen betreibt, kennt das Problem: Die Infrastruktur-Überwachung meldet grün, alle Container laufen, die CPU-Last ist unauffällig, und trotzdem beschwert sich der Fachbereich über eine Anwendung, die zu langsam antwortet. Klassische Monitoring-Werkzeuge beantworten die Frage, ob ein Server läuft. Sie beantworten nicht die Frage, warum ein einzelner Aufruf im Bestellprozess 4 Sekunden gebraucht hat und in welchem der beteiligten Dienste die Zeit verloren ging.

Genau diese Lücke schließt SigNoz. Das Projekt ist eine selbst hostbare Observability-Plattform, die Traces, Metriken und Logs in einer einzigen Oberfläche und in einem einzigen Datenspeicher zusammenführt. SigNoz ist dabei durchgängig auf OpenTelemetry aufgebaut, den herstellerneutralen Standard der Cloud Native Computing Foundation für Telemetriedaten. Für Unternehmen, die heute über die Kosten kommerzieller APM-Dienste nachdenken, ist SigNoz eine der wenigen Alternativen, die den kompletten Funktionsumfang im eigenen Rechenzentrum abbilden kann. Diese Anleitung zeigt die Installation mit Docker Compose, den kompletten Praxistest inklusive echter Telemetrie-Daten, und sie benennt ehrlich, wo die Grenzen liegen.

Was SigNoz macht und welches Problem es löst

SigNoz ist eine sogenannte Full-Stack-Observability-Plattform. Der Begriff Observability geht über Monitoring hinaus: Monitoring beantwortet vorher definierte Fragen ("Ist die Festplatte voll?"), Observability soll auch Fragen beantworten, die man vorher nicht gestellt hat ("Warum war dieser eine Aufruf von diesem einen Kunden langsam?"). Dafür braucht es drei Datenarten, die in der Fachliteratur als die drei Säulen bezeichnet werden.

• Traces: Der vollständige Weg einer einzelnen Anfrage durch alle beteiligten Dienste, aufgeteilt in einzelne Abschnitte, die Spans heißen. Ein Trace zeigt, dass ein Aufruf 800 Millisekunden gebraucht hat und davon 700 Millisekunden in einer Datenbankabfrage lagen.
• Metriken: Zahlenreihen über die Zeit, also Anfragen pro Sekunde, Fehlerquote, Antwortzeiten im 95. Perzentil, Speicherverbrauch.
• Logs: Die eigentlichen Textmeldungen der Anwendung, idealerweise mit derselben Trace-ID versehen, sodass man von einem langsamen Trace direkt in die zugehörigen Logzeilen springen kann.

Der entscheidende Unterschied zu einer Sammlung einzelner Werkzeuge liegt in der Verknüpfung. Wer Prometheus für Metriken, Loki für Logs und Jaeger für Traces betreibt, hat drei getrennte Systeme mit drei Datenmodellen und drei Abfragesprachen. SigNoz speichert alle drei Datenarten in derselben ClickHouse-Datenbank und verknüpft sie über gemeinsame Attribute. Vom Fehler-Trace zur passenden Logzeile ist es ein Klick statt eines manuellen Zeitstempel-Abgleichs über drei Oberflächen.

Der zweite wichtige Punkt ist OpenTelemetry. SigNoz erfindet kein eigenes Agenten-Format, sondern nimmt Daten über das OTLP-Protokoll entgegen, den Standard, den inzwischen praktisch alle großen Anbieter unterstützen. Die Anwendung wird also nicht an SigNoz gebunden, sondern an einen offenen Standard. Wer SigNoz später ersetzen will, tauscht das Ziel im Collector aus und muss die Instrumentierung des Codes nicht anfassen. Dieser Punkt ist bei der Bewertung von Herstellerabhängigkeit wichtiger als jede Lizenzfrage.

Nutzen und Grenzen, ehrlich betrachtet

SigNoz spielt seine Stärken dort aus, wo eigener Anwendungscode betrieben wird, der instrumentiert werden kann. Eine Microservice-Landschaft, eine selbst entwickelte Webanwendung, eine API mit mehreren Backend-Diensten: Hier liefert SigNoz Antworten, die eine reine Infrastruktur-Überwachung nicht geben kann. Auch die Analyse von Fehlerquoten pro Endpunkt und die Erkennung von langsamen Datenbankabfragen gehören zu den Kernfunktionen.

Ebenso klar sind die Fälle, in denen SigNoz das falsche Werkzeug ist. Wer schlicht wissen will, ob eine Handvoll Server erreichbar ist und ob die Festplatten volllaufen, baut mit SigNoz eine deutlich zu große Maschine. Dafür genügen leichtgewichtigere Ansätze, die mit einem Bruchteil der Ressourcen auskommen. SigNoz ist auch kein Ersatz für eine Verfügbarkeitsüberwachung von außen: Wenn der ganze Server ausfällt, fällt die selbst gehostete Observability-Plattform mit aus und kann niemanden mehr alarmieren. Eine externe Uptime-Überwachung bleibt zusätzlich nötig.

Ein weiterer Punkt betrifft den Betriebsaufwand. Der Stack besteht aus fünf dauerhaft laufenden Diensten, darunter eine ClickHouse-Datenbank samt ClickHouse Keeper für die Koordination. ClickHouse ist eine spaltenorientierte analytische Datenbank, die für dieses Einsatzgebiet hervorragend passt, aber eigene Betriebskenntnisse verlangt, sobald Datenmengen wachsen oder etwas schiefgeht. Wer weder Zeit noch Interesse für Datenbankbetrieb hat, sollte das vor der Entscheidung ehrlich einkalkulieren.

Zur Lizenz: Die Datei LICENSE im Repository weist den Hauptteil des Codes als MIT Expat aus. Ausgenommen sind ausdrücklich die Verzeichnisse ee/ und cmd/enterprise/, die einer separaten Enterprise-Lizenz unterliegen. Das im Test verwendete Standard-Image meldet über die API "ee":"Y", enthält also den Enterprise-Code-Pfad, läuft aber ohne hinterlegten Lizenzschlüssel als Community-Variante. Einzelne Funktionen sind damit an kostenpflichtige Stufen gebunden. Wer auf bestimmte Funktionen angewiesen ist, sollte vor dem Produktiveinsatz die Preisseite des Anbieters prüfen, statt sich auf die Angabe MIT im Repository allein zu verlassen.

Voraussetzungen und Ressourcen

Die offizielle Dokumentation nennt als Mindestanforderung eine Linux- oder macOS-Maschine mit Docker Engine ab Version 20.10 und dem Docker-Compose-v2-Plugin sowie mindestens 4 GB Arbeitsspeicher, die Docker zur Verfügung stehen. Unter Windows empfiehlt das Projekt ausdrücklich WSL 2 mit nativer Docker Engine innerhalb der WSL-Distribution, nicht Docker Desktop, weil ClickHouse Keeper unter der Virtualisierungsschicht von Docker Desktop unter Windows mit Speicherzugriffsfehlern und Exit-Code 139 in eine Neustartschleife geraten kann.

Als Standardports belegt SigNoz 8080 für die Oberfläche, 4317 und 4318 für die OTLP-Aufnahme sowie optional 8000 für den MCP-Server. In dieser Anleitung werden abweichende, nur lokal gebundene Ports verwendet, weil der Testaufbau nicht von außen erreichbar sein soll.

Der Praxistest für diese Anleitung lief auf folgender Umgebung, die bewusst schwächer ist als eine typische Produktivmaschine:

Merkmal	Wert im Test	Bewertung
CPU	Intel Celeron J4125, 2 zugewiesene Kerne	deutlich unter einer Produktivempfehlung
CPU-Befehlssätze	SSE4.2 vorhanden, AVX und AVX2 NICHT vorhanden	ClickHouse lief trotzdem stabil
Arbeitsspeicher gesamt	8,2 GB, davon rund 5,8 GB verfügbar	ausreichend für den Testbetrieb
Speicherplatz	58 GB Root-Dateisystem, 23 GB frei nach dem Test	Images belegen rund 4 GB
Docker	Version 29.1.3	erfüllt die Mindestanforderung
Betriebssystem	Ubuntu Linux, Kernel 7.0.0	unterstützte Plattform

Die Beobachtung zu AVX verdient eine Anmerkung, weil sie häufig für Verwirrung sorgt: ClickHouse-Builds benötigten in älteren Versionen zwingend SSE4.2, und für einige Datenbank-Images ist AVX Pflicht. Das im SigNoz-Stack verwendete ClickHouse 25.12.5 startete auf der oben genannten CPU ohne AVX sauber und meldete sich als healthy. Das ist ein tatsächlich beobachtetes Ergebnis auf genau dieser Hardware und keine allgemeine Zusicherung für jede zukünftige ClickHouse-Version.

Der tatsächliche Ressourcenverbrauch im Leerlauf, gemessen mit docker stats unmittelbar nach dem Start und vor nennenswerter Datenaufnahme, lag deutlich unter den Erwartungen:

Container	Speicherverbrauch im Leerlauf	CPU-Last
signoz-telemetrystore-clickhouse-0-0	391,3 MiB	18,59 Prozent
signoz-metastore-postgres-0	57,3 MiB	0,00 Prozent
signoz-telemetrykeeper-clickhousekeeper-0	50,9 MiB	1,03 Prozent
signoz-ingester-1	46,3 MiB	0,21 Prozent
signoz-signoz-0	44,1 MiB	0,09 Prozent

Diese Werte gelten ausdrücklich für einen Stack ohne nennenswerte Last. Unter echter Telemetrie-Aufnahme steigt vor allem der Bedarf von ClickHouse erheblich, weshalb die Empfehlung von mindestens 4 GB für Docker realistisch bleibt.

Projekt- und Versionsstand mit Beleg

Alle folgenden Angaben wurden am 17. September 2026 direkt über die GitHub-API abgefragt, nicht aus Dokumentationstexten übernommen.

Kennzahl	Wert am 17.09.2026
Repository	SigNoz/signoz
Sterne auf GitHub	32.115
Forks	2.497
Offene Vorgänge	1.574
Letzter Push	16.09.2026
Aktuellstes Release	v0.142.0 vom 16.09.2026
Lizenz	MIT Expat, ausgenommen ee/ und cmd/enterprise/
Archiviert	nein
Foundry-CLI im Test	foundryctl v0.2.17, Commit 273dec4

Die Zahlen sind mit folgendem Befehl reproduzierbar:

# Projektstand direkt aus der GitHub-API abfragen
curl -s https://api.github.com/repos/SigNoz/signoz

# Nur das aktuellste Release anzeigen
curl -s https://api.github.com/repos/SigNoz/signoz/releases/latest

Die Versionsnummer unterhalb von 1.0 sollte nicht als Hinweis auf ein unfertiges Produkt missverstanden werden. Das Projekt veröffentlicht in sehr kurzen Abständen; die Release-Notes zu v0.142.0 listen unter anderem neue Berechtigungsmodelle für Dashboards, überarbeitete Diagramm-Legenden und neue Benachrichtigungskanal-APIs auf.

Wichtig: Docker Compose läuft jetzt über Foundry

An dieser Stelle muss eine Änderung deutlich benannt werden, weil ältere Anleitungen im Netz an ihr scheitern. Das Installationsskript install.sh und die im Repository unter deploy/ mitgelieferten Docker-Compose-Dateien sind laut offizieller Dokumentation seit SigNoz v0.130.0 abgekündigt und werden weder gepflegt noch ausgeliefert. Wer heute versucht, das Verzeichnis deploy/docker/ aus dem Repository zu klonen, findet es nicht mehr. Ein Abruf des Verzeichnisinhalts über die GitHub-API liefert für diesen Pfad eine Antwort mit Status 404, und das noch vorhandene deploy/install.sh gibt beim Aufruf nur noch einen Abkündigungshinweis aus und beendet sich mit Exit-Code 0, ohne irgendetwas zu installieren.

Der unterstützte Weg heißt jetzt Foundry. Das ist ein eigenes Kommandozeilenwerkzeug namens foundryctl, das den Observability-Stack aus einer deklarativen Konfigurationsdatei erzeugt. Wichtig für das Verständnis: Foundry ersetzt Docker Compose nicht, sondern erzeugt die Compose-Dateien. Am Ende läuft weiterhin ein ganz normaler Docker-Compose-Stack, den man mit den gewohnten Befehlen bedienen kann. Foundry übernimmt lediglich das Rendern der Dateien aus einer Vorlage.

Der Ablauf besteht aus drei Stufen, die alle einzeln aufrufbar sind:

• foundryctl gauge prüft die Umgebung, also ob Docker vorhanden und benutzbar ist.
• foundryctl forge erzeugt die Compose-Dateien im Verzeichnis pours/ und schreibt eine Datei casting.yaml.lock, die den erzeugten Stand festhält.
• foundryctl cast führt beide vorherigen Schritte aus und startet den Stack anschließend.

Für eine nachvollziehbare Installation ist der getrennte Weg über gauge und forge klar vorzuziehen. Man sieht dann, welche Compose-Datei tatsächlich entsteht, kann sie lesen und startet den Stack selbst. Genau so wurde in dieser Anleitung vorgegangen.

Installation und erster Start

Zunächst wird das Werkzeug installiert. Die offizielle Anweisung leitet ein Skript direkt in eine Shell. Das ist bequem, aber sicherheitstechnisch die schlechtere Variante, weil man ungeprüften Code ausführt. Besser: das Skript herunterladen, ansehen, dann ausführen. Im Test wurde dieser Weg gewählt und das Zielverzeichnis bewusst auf das Projektverzeichnis gelegt, damit nichts systemweit installiert wird.

# Arbeitsverzeichnis anlegen und betreten
mkdir -p /opt/signoz
cd /opt/signoz

# Installationsskript herunterladen, NICHT direkt ausfuehren
curl -fsSL https://signoz.io/foundry.sh -o foundry.sh

# Skript vor der Ausfuehrung ansehen
less foundry.sh

# Erst danach ausfuehren, Zielverzeichnis explizit setzen
FOUNDRY_INSTALL_DIR=/opt/signoz/bin FOUNDRY_ASSUME_YES=true bash foundry.sh

# Werkzeug fuer die aktuelle Shell verfuegbar machen
export PATH=/opt/signoz/bin:$PATH
foundryctl version

Im Test meldete das Skript [INFO] Installed foundryctl v0.2.17. Der anschließende Versionsaufruf bestätigte Version v0.2.17, Commit 273dec4, gebaut mit Go 1.25.3.

Als Nächstes wird die Konfigurationsdatei angelegt. Sie heißt nach der Foundry-Terminologie casting file. In der Minimalform beschreibt sie lediglich, dass ein SigNoz mit Docker Compose gewünscht ist:

apiVersion: v1alpha1
kind: Installation
metadata:
  name: signoz
spec:
  deployment:
    flavor: compose
    mode: docker

Mit dieser Minimalvariante belegt der Stack die Standardports und bindet sie an alle Netzwerkschnittstellen. Für einen Testaufbau ist das unerwünscht. Anpassungen an der erzeugten Compose-Datei dürfen nicht direkt in pours/ vorgenommen werden, weil forge diese Dateien bei jedem Lauf überschreibt. Der vorgesehene Mechanismus heißt patches und arbeitet mit JSON-Patch-Operationen nach RFC 6902. Die im Test verwendete vollständige Datei bindet die Ports ausschließlich an die lokale Adresse und verschiebt sie in einen hohen Bereich:

apiVersion: v1alpha1
kind: Installation
metadata:
  name: signoz
spec:
  deployment:
    flavor: compose
    mode: docker
  patches:
    - target: "deployment/compose.yaml"
      operations:
        - op: replace
          path: /services/signoz-signoz-0/ports
          value:
            - "127.0.0.1:18443:8080"
        - op: replace
          path: /services/ingester/ports
          value:
            - "127.0.0.1:14317:4317"
            - "127.0.0.1:14318:4318"

Die Bindung an 127.0.0.1 ist hier kein Detail, sondern die entscheidende Absicherung: Ohne sie wäre die Oberfläche ohne jede Anmeldung aus dem Netz erreichbar, solange noch kein Administrator angelegt ist. Wie die Freigabe nach außen sauber gelöst wird, steht weiter unten im Abschnitt zum Reverse Proxy.

Jetzt folgen Prüfung, Erzeugung und Start:

# Umgebung pruefen
foundryctl gauge -f casting.yaml

# Compose-Dateien erzeugen
foundryctl forge -f casting.yaml

# Erzeugte Dateien ansehen
find pours -type f

# Stack starten
cd pours/deployment
docker compose up -d

Der forge-Lauf erzeugte im Test diese Dateien:

pours/deployment/compose.yaml
pours/deployment/ingester/ingester.yaml
pours/deployment/ingester/opamp.yaml
pours/deployment/telemetrystore/clickhouse/config-0-0.yaml
pours/deployment/telemetrystore/clickhouse/functions.yaml
pours/deployment/telemetrykeeper/clickhousekeeper/keeper-0.yaml

Der erste Start dauert deutlich länger als bei kleineren Stacks, weil mehrere GB an Images geladen werden. Im Test vergingen vom Aufruf bis zum vollständig gestarteten Stack rund sieben Minuten, wobei der größte Anteil auf das Herunterladen der ClickHouse- und Collector-Images entfiel. Das Kommando sollte daher nicht vorzeitig abgebrochen werden.

Die erzeugte compose.yaml verstehen

Ein Blick in die erzeugte Datei lohnt sich, weil sie die Architektur offenlegt. Der Stack besteht aus fünf dauerhaften Diensten und zwei Hilfsdiensten, die einmalig laufen und sich dann beenden.

Dienst	Image im Test	Aufgabe
signoz-signoz-0	signoz/signoz:latest	Oberfläche und API, Port 8080
ingester	signoz/signoz-otel-collector:latest	Nimmt OTLP-Daten an, Ports 4317 und 4318
signoz-telemetrystore-clickhouse-0-0	clickhouse/clickhouse-server:25.12.5	Speichert Traces, Metriken und Logs
signoz-telemetrykeeper-clickhousekeeper-0	clickhouse/clickhouse-keeper:25.12.5	Koordination und Konsens für ClickHouse
signoz-metastore-postgres-0	postgres:16	Metadaten: Nutzer, Dashboards, Alarme
signoz-telemetrystore-migrator	signoz/signoz-otel-collector:latest	Einmalige Schema-Migration, endet mit Exit 0
signoz-telemetrystore-clickhouse-user-scripts	clickhouse/clickhouse-server:25.12.5	Lädt eine Hilfsfunktion nach, endet mit Exit 0

Die wichtigsten Parameter aus der erzeugten Datei im Überblick:

Parameter	Wert	Bedeutung
SIGNOZ_SQLSTORE_PROVIDER	postgres	Metadaten liegen in PostgreSQL, nicht mehr in SQLite
SIGNOZ_TELEMETRYSTORE_PROVIDER	clickhouse	Telemetriedaten liegen in ClickHouse
SIGNOZ_OTEL_COLLECTOR_TIMEOUT	10m	Zeitlimit für Migrationsläufe des Collectors
restart	unless-stopped	Dienste starten nach Neustart automatisch wieder
healthcheck des SigNoz-Dienstes	/api/v1/health	Grundlage für den Status healthy
start_period des SigNoz-Dienstes	60s	Anlaufzeit, bevor Fehlschläge zählen

Ein Punkt verdient besondere Aufmerksamkeit: Die erzeugte Datei enthält für PostgreSQL die fest eingetragenen Zugangsdaten Benutzer signoz, Datenbank signoz und ein Standardpasswort. Der Datenbankcontainer veröffentlicht zwar keinen Port nach außen und ist nur innerhalb des Docker-Netzes erreichbar, trotzdem sollte dieses Passwort für den Produktivbetrieb über die patches-Mechanik durch ein eigenes ersetzt werden. Das Passwort muss dabei an zwei Stellen angepasst werden: in der Umgebungsvariable des Datenbankdienstes und in der Verbindungszeichenkette SIGNOZ_SQLSTORE_POSTGRES_DSN des SigNoz-Dienstes. Echte Zugangsdaten gehören nicht in ein Repository; in der Konfigurationsdatei sind sie als Platzhalter zu behandeln.

Erstkonfiguration und Administrator anlegen

Nach dem Start ist die Instanz noch ohne Benutzerkonto. Dieser Zustand lässt sich direkt über die API abfragen und liefert im Test folgende Antwort:

# Version und Einrichtungsstatus abfragen
curl -s http://127.0.0.1:18443/api/v1/version

{"version":"v0.142.0","ee":"Y","setupCompleted":false}

Das Feld setupCompleted steht auf false, solange kein Administrator existiert. In dieser Phase kann jeder, der die Oberfläche erreicht, das erste Administratorkonto anlegen. Genau deshalb darf die Instanz in diesem Zeitfenster nicht offen im Netz stehen. Der übliche Weg führt über den Browser auf die Oberfläche. Für einen automatisierbaren Aufbau geht es auch über die API, wie im Test durchgeführt:

# Erstes Administratorkonto anlegen, Werte anpassen
curl -s -X POST http://127.0.0.1:18443/api/v1/register \
  -H 'Content-Type: application/json' \
  -d '{"name":"Admin","orgId":"","orgName":"BEISPIEL GmbH","email":"admin@beispiel.de","password":"PLATZHALTER-STARKES-PASSWORT"}'

Die API antwortete mit HTTP 200 und einem Datensatz, der das Konto als "isRoot":true und "status":"active" auswies. Ein erneuter Abruf der Versions-API meldete danach "setupCompleted":true.

Nach dem Anlegen des Kontos sollten als Erstes die Aufbewahrungsfristen geprüft werden. Laut offizieller Dokumentation stehen sie standardmäßig auf 7 Tage für Logs und Traces sowie 30 Tage für Metriken und lassen sich im Bereich Settings unter General anpassen. Diese Einstellung ist der wichtigste Hebel für den späteren Speicherbedarf und wurde im Test nicht verändert.

Funktions- und Healthcheck mit echten Daten

Ein Healthcheck, der nur prüft, ob eine Weboberfläche antwortet, ist bei einer Observability-Plattform zu wenig. Aussagekräftig wird es erst, wenn nachweislich Telemetriedaten angenommen, verarbeitet und gespeichert werden. Der Reihe nach.

# Status aller Dienste anzeigen
docker compose ps --format 'table {{.Service}}\t{{.Status}}\t{{.Ports}}'

Beobachtete Ausgabe im Test:

SERVICE                                     STATUS                        PORTS
ingester                                    Up 9 minutes                  127.0.0.1:14317->4317/tcp, 127.0.0.1:14318->4318/tcp
signoz-metastore-postgres-0                 Up 9 minutes (healthy)        5432/tcp
signoz-signoz-0                             Up About a minute (healthy)   127.0.0.1:18443->8080/tcp
signoz-telemetrykeeper-clickhousekeeper-0   Up 9 minutes (healthy)        2181/tcp, 9181/tcp, 10181/tcp, 44444/tcp
signoz-telemetrystore-clickhouse-0-0        Up 9 minutes (healthy)        8123/tcp, 9000/tcp, 9009/tcp

Danach die HTTP-Prüfungen:

# Oberflaeche erreichbar?
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:18443/

# Gesundheitsendpunkt der Anwendung
curl -s http://127.0.0.1:18443/api/v1/health

Der erste Aufruf lieferte 200, der zweite {"status":"ok"}.

Nun der eigentliche Nachweis. Dafür wird ein OpenTelemetry-Trace im OTLP-JSON-Format an den Collector geschickt und anschließend direkt in ClickHouse nachgesehen, ob er dort angekommen ist. Die Testdatei wurde mit einem kleinen Python-Aufruf erzeugt, damit Zeitstempel und IDs gültig sind:

# Beispiel-Trace erzeugen
python3 -c "
import json, time, random
now = time.time_ns()
d = {'resourceSpans': [{
  'resource': {'attributes': [{'key': 'service.name', 'value': {'stringValue': 'sedv-testservice'}}]},
  'scopeSpans': [{'scope': {'name': 'sedv-manual'}, 'spans': [{
    'traceId': '%032x' % random.getrandbits(128),
    'spanId': '%016x' % random.getrandbits(64),
    'name': 'sedv-testspan',
    'kind': 2,
    'startTimeUnixNano': str(now),
    'endTimeUnixNano': str(now + 50000000),
    'status': {'code': 1}}]}]}]}
open('trace.json', 'w').write(json.dumps(d))
"

# Trace an den Collector senden
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST http://127.0.0.1:14318/v1/traces \
  -H 'Content-Type: application/json' \
  -d @trace.json

Der Collector antwortete mit 200. Nach etwa 20 Sekunden Wartezeit wurde der Datenbestand geprüft:

# Nachsehen, ob der Trace in ClickHouse liegt
docker compose exec -T signoz-telemetrystore-clickhouse-0-0 \
  clickhouse-client -q "SELECT serviceName, name, count() FROM signoz_traces.distributed_signoz_index_v3 WHERE serviceName='sedv-testservice' GROUP BY serviceName, name"

sedv-testservice	sedv-testspan	1

Damit ist der komplette Weg belegt: Anwendung sendet über OTLP, Collector nimmt an, ClickHouse speichert. Dieselbe Prüfung wurde für Logs wiederholt, indem eine Logzeile an /v1/logs geschickt wurde. Auch hier antwortete der Endpunkt mit 200, und die Abfrage auf signoz_logs.distributed_logs_v2 lieferte die gesendete Zeile mit dem Schweregrad ERROR zurück.

Ein Detail aus dem Test gehört an diese Stelle, weil es leicht zu Fehldiagnosen führt: Unmittelbar nach dem Start wies der OTLP-Endpunkt Verbindungen noch ab. Der Aufruf endete mit Recv failure: Connection reset by peer und curl meldete den Code 000. Die Ursache stand im Log des Collectors: Er baut über das OpAMP-Protokoll erst eine Verbindung zum SigNoz-Dienst auf, um seine Konfiguration zu beziehen, und lehnt vorher Daten ab. Erst nach der Meldung Connected to the server. Applying default config. nahm der Endpunkt Daten an. Nach dem Start also einige Minuten Geduld einplanen, bevor die Aufnahme als defekt eingestuft wird.

Persistente Daten, Volumes und Rechte

Der Stack legt vier benannte Docker-Volumes an. Sie sind der einzige Ort, an dem dauerhafte Daten liegen; die Container selbst sind austauschbar.

Volume	Inhalt	Größe im Test
signoz-telemetrystore-0-0-data	ClickHouse: Traces, Metriken, Logs	55,4 MB
signoz-metastore-postgres-0-data	PostgreSQL: Nutzer, Dashboards, Alarme	68,3 MB
signoz-telemetrykeeper-0-data	ClickHouse Keeper: Koordinationsdaten	2,7 MB
signoz-telemetrystore-user-scripts	Nachgeladene Hilfsfunktion für Quantile	1,4 MB

Diese Werte stammen aus einem frisch aufgesetzten Testsystem ohne nennenswerte Datenmenge und sagen nichts über den Produktivbedarf aus. Die Größenordnung dort bestimmen zwei Faktoren: die Menge eingehender Spans und Logzeilen sowie die eingestellte Aufbewahrungsfrist. Wer Traces von einer stark genutzten Anwendung ungefiltert aufnimmt, erzeugt schnell zweistellige Gigabyte-Mengen pro Woche. Gegenmittel sind eine kürzere Aufbewahrung und Sampling im Collector, also das Verwerfen eines Teils der Traces bereits bei der Aufnahme.

Benannte Volumes sind hier die richtige Wahl und sollten nicht ohne Not durch Bind-Mounts auf Verzeichnisse des Hosts ersetzt werden. ClickHouse und PostgreSQL laufen in ihren Images unter jeweils eigenen Benutzerkennungen, und bei Bind-Mounts muss man die Eigentümerrechte des Host-Verzeichnisses passend setzen, sonst verweigert die Datenbank den Start. Mit benannten Volumes übernimmt Docker das.

Der belegte Platz lässt sich so einsehen:

# Volumes und ihre Groesse auflisten
docker system df -v | grep signoz

# Platzbedarf innerhalb des ClickHouse-Containers
docker compose exec -T signoz-telemetrystore-clickhouse-0-0 du -sh /var/lib/clickhouse

Der zweite Befehl lieferte im Test 76M /var/lib/clickhouse.

Sichere Netzwerkfreigabe, Reverse Proxy und TLS

Die Standardkonfiguration veröffentlicht Port 8080 auf allen Schnittstellen. Das ist für eine Plattform, die Telemetriedaten der gesamten Anwendungslandschaft enthält, die falsche Voreinstellung. In Traces und Logs stehen regelmäßig Datenbankabfragen, Pfade, Parameter und teils auch personenbezogene Daten. Diese Oberfläche gehört nicht ungeschützt ins Netz.

Die empfohlene Grundregel: sämtliche Ports nur an 127.0.0.1 binden, wie oben in der patches-Sektion gezeigt, und den Zugriff ausschließlich über einen Reverse Proxy mit TLS und zusätzlicher Authentifizierung führen. Zwei Punkte sind dabei zu unterscheiden.

• Die Oberfläche auf Port 8080: Zugriff über HTTPS, idealerweise zusätzlich hinter einer vorgelagerten Authentifizierung oder auf ein VPN beschränkt.
• Die OTLP-Endpunkte auf 4317 und 4318: Hier senden die instrumentierten Anwendungen ihre Daten hinein. Diese Endpunkte sind in der Standardkonfiguration ohne Authentifizierung erreichbar. Wer sie über das Internet öffnet, erlaubt jedem das Einspeisen beliebiger Telemetriedaten. Sie gehören in ein internes Netz, ein VPN oder hinter einen Proxy, der eigene Zugangsdaten verlangt.

Eine beispielhafte nginx-Konfiguration für die Oberfläche, die WebSocket-Verbindungen korrekt weiterreicht:

server {
    listen 443 ssl http2;
    server_name signoz.beispiel.de;

    # Zertifikatspfade an die eigene Umgebung anpassen
    ssl_certificate     /etc/letsencrypt/live/signoz.beispiel.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/signoz.beispiel.de/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:18443;
        proxy_http_version 1.1;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Fuer Live-Ansichten in der Oberflaeche notwendig
        proxy_set_header Upgrade    $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Laengere Abfragen ueber grosse Zeitraeume brauchen Zeit
        proxy_read_timeout 300s;
    }
}

Diese Proxy-Konfiguration wurde im Rahmen dieses Tests nicht aufgesetzt und ist daher als dokumentiert, aber nicht selbst getestet zu betrachten. Getestet wurde ausschließlich der direkte Zugriff auf den lokal gebundenen Port.

Backup und Wiederherstellung

Bei SigNoz sind zwei Datenbestände zu sichern, und sie haben sehr unterschiedliche Bedeutung. Der PostgreSQL-Metastore enthält Benutzerkonten, Dashboards, Alarmregeln und Einstellungen. Das ist die eigentliche Arbeit, die in eine Installation fließt, und der Datenbestand ist klein. ClickHouse enthält die Telemetriedaten selbst, ist um Größenordnungen größer und verliert mit jedem Tag an Wert, weil die Aufbewahrungsfrist ohnehin läuft.

Daraus folgt eine klare Priorisierung: Der Metastore muss regelmäßig gesichert werden. Für ClickHouse ist eine Sicherung in vielen Umgebungen verzichtbar, solange man akzeptiert, dass nach einem Totalverlust die Historie fehlt, die Plattform aber mit den Dashboards sofort weiterarbeitet.

Die Sicherung des Metastores erfolgt mit pg_dump aus dem laufenden Container:

# Metastore sichern, mit DROP-Anweisungen fuer sauberes Einspielen
docker compose exec -T signoz-metastore-postgres-0 \
  pg_dump -U signoz -d signoz --clean --if-exists > signoz-meta.sql

# Groesse pruefen
ls -lh signoz-meta.sql

Im Test entstand eine Datei von 262 KB für eine frische Installation mit einem Benutzerkonto.

Eine Sicherung, die nie zurückgespielt wurde, ist keine Sicherung. Die Wiederherstellung wurde deshalb vollständig durchgespielt, inklusive absichtlichem Datenverlust. Dabei traten zwei Stolpersteine auf, die in der Anleitung stehen müssen.

Erstens lässt sich die Benutzertabelle nicht einfach leeren: Der Versuch scheiterte mit ERROR: update or delete on table "users" violates foreign key constraint "factor_password_user_id_fkey". Zweitens blockiert der laufende SigNoz-Dienst mit seinen offenen Verbindungen das Löschen der Datenbank. Der Dienst muss vorher gestoppt werden. Der funktionierende Ablauf:

# Anwendung stoppen, damit keine Verbindungen offen sind
docker compose stop signoz-signoz-0

# Datenbank verwerfen und leer neu anlegen
docker compose exec -T signoz-metastore-postgres-0 \
  psql -U signoz -d postgres -c "DROP DATABASE signoz WITH (FORCE);"
docker compose exec -T signoz-metastore-postgres-0 \
  psql -U signoz -d postgres -c "CREATE DATABASE signoz OWNER signoz;"

# Sicherung einspielen, bei jedem Fehler abbrechen
docker compose exec -T signoz-metastore-postgres-0 \
  psql -U signoz -d signoz -v ON_ERROR_STOP=1 -q < signoz-meta.sql

# Anwendung wieder starten
docker compose start signoz-signoz-0

Der Nachweis, dass die Wiederherstellung wirklich funktioniert hat, wurde über ein Merkmal geführt, das vor dem Löschen existierte. Vor der Sicherung meldete die Abfrage auf die Benutzertabelle die Adresse des angelegten Administrators. Nach dem Verwerfen der Datenbank scheiterte dieselbe Abfrage erwartungsgemäß mit ERROR: relation "users" does not exist. Nach dem Einspielen der Sicherung lieferte sie den Datensatz wieder zurück. Der Aufruf der Versions-API meldete nach dem Neustart erneut "setupCompleted":true, und die Oberfläche antwortete wieder mit HTTP 200. Die zuvor eingespeisten Traces in ClickHouse waren unverändert vorhanden, weil dieser Datenbestand von der Wiederherstellung nicht berührt wurde.

Für ClickHouse gibt es eine eingebaute Sicherungsfunktion über den Befehl BACKUP. Sie wurde in diesem Test nicht ausgeführt und ist daher hier nur als Hinweis auf die Möglichkeit aufgeführt, nicht als geprüfte Anleitung.

Updates und Rollback-Grenzen

Bei einem Foundry-Aufbau laufen Updates über die Konfigurationsdatei, nicht über manuelles Bearbeiten der Compose-Datei. Der Ablauf ist immer derselbe: casting.yaml anpassen, neu erzeugen, Stack aktualisieren.

# Aktuelle Images laden
docker compose pull

# Stack mit den neuen Images neu erstellen
docker compose up -d

# Danach Status pruefen
docker compose ps

Wichtiger als der Update-Befehl ist eine Empfehlung zur Konfiguration. Die erzeugte Datei verwendet für die SigNoz-Komponenten das Tag latest. Für einen Produktivbetrieb ist das die falsche Wahl, weil ein beliebiger docker compose pull unangekündigt eine neue Hauptversion einspielen kann. Die Dokumentation zeigt, wie sich eine feste Version in der Konfigurationsdatei hinterlegen lässt:

spec:
  signoz:
    spec:
      image: signoz/signoz:v0.142.0

Zu den Rollback-Grenzen gehört eine unbequeme Wahrheit. Ein Rückschritt auf eine ältere Version ist nur dann gefahrlos, wenn zwischen den Versionen keine Schema-Migration stattgefunden hat. Der Dienst signoz-telemetrystore-migrator führt beim Start Migrationen in ClickHouse aus. Ältere Anwendungsversionen kommen mit einem bereits migrierten Schema unter Umständen nicht mehr zurecht. Vor einem größeren Versionssprung gehört deshalb eine Sicherung des Metastores an den Anfang, und der Sprung sollte, wenn irgend möglich, zuerst auf einem Testsystem erfolgen. Ein reiner Image-Rückschritt ohne Datensicherung ist kein verlässlicher Rollback-Plan.

Ein weiterer Punkt betrifft Foundry selbst. Die erzeugten Dateien in pours/ werden bei jedem forge-Lauf überschrieben. Wer dort direkt Hand anlegt, verliert seine Änderungen beim nächsten Update stillschweigend. Alle dauerhaften Anpassungen gehören in die casting.yaml, die zusammen mit der erzeugten casting.yaml.lock in die Versionsverwaltung gehört.

Typische Fehler mit Diagnose und Lösung

Die folgenden Fehlerbilder traten im Test tatsächlich auf oder sind in der offiziellen Dokumentation beschrieben. Die Herkunft ist jeweils angegeben.

Fehlerbild	Ursache	Lösung
Bind for 127.0.0.1:18080 failed: port is already allocated (im Test beobachtet)	Der Hostport war bereits durch einen anderen Dienst belegt	Freien Port suchen und in der casting.yaml ändern, dann forge erneut ausführen
Recv failure: Connection reset by peer am OTLP-Port, curl meldet 000 (im Test beobachtet)	Collector hat seine Konfiguration noch nicht vom SigNoz-Dienst bezogen	Abwarten, bis im Collector-Log Connected to the server erscheint
violates foreign key constraint factor_password_user_id_fkey (im Test beobachtet)	Benutzerdatensätze sind über Fremdschlüssel verknüpft	Nicht einzelne Tabellen leeren, sondern die Datenbank komplett verwerfen und aus der Sicherung neu aufbauen
DROP DATABASE schlägt fehl, Datenbank in Benutzung (im Test beobachtet)	Der SigNoz-Dienst hält offene Verbindungen	Vorher docker compose stop signoz-signoz-0 ausführen
Container starten immer wieder neu (laut Dokumentation)	Zu wenig Arbeitsspeicher für Docker	Mindestens 4 GB für Docker bereitstellen
clickhouse-keeper stürzt mit Exit-Code 139 ab (laut Dokumentation)	Speicherzugriffsfehler unter der Virtualisierung von Docker Desktop unter Windows	Native Docker Engine innerhalb von WSL 2 verwenden
deploy/docker existiert nicht im Repository (im Test bestätigt, GitHub-API liefert 404)	Die gebündelten Compose-Dateien sind seit v0.130.0 abgekündigt	Foundry verwenden, wie in dieser Anleitung beschrieben

Für die Diagnose sind vor allem die Logs der einzelnen Dienste hilfreich. Der Collector loggt im JSON-Format, was auf der Konsole unübersichtlich wirkt, sich aber gut filtern lässt:

# Letzte Zeilen eines bestimmten Dienstes ansehen
docker compose logs --tail=50 ingester

# Logs der Oberflaeche live mitlesen
docker compose logs -f signoz-signoz-0

# Bei Problemen mit foundryctl ausfuehrliche Ausgabe anfordern
foundryctl forge -f casting.yaml --debug

Ein Hinweis zur Interpretation: Die Dienste signoz-telemetrystore-migrator und signoz-telemetrystore-clickhouse-user-scripts erscheinen in docker compose ps -a mit dem Status Exited (0). Das ist korrekt und kein Fehler. Beide erledigen einmalige Aufgaben beim Start und beenden sich danach planmäßig. Nur ein Exit-Code ungleich 0 wäre ein Problem.

Saubere Deinstallation

Beim Entfernen ist der Unterschied zwischen zwei Befehlen entscheidend, und die Verwechslung kostet alle Daten.

Warnung: Der Parameter -v löscht alle Volumes und damit sämtliche Telemetriedaten, Dashboards, Alarmregeln und Benutzerkonten unwiderruflich. Es gibt danach keine Wiederherstellung ohne vorherige Sicherung. Vor diesem Befehl unbedingt den Metastore sichern, falls die Daten noch gebraucht werden.

# Variante 1: Container stoppen und entfernen, DATEN BLEIBEN erhalten
docker compose down

# Variante 2: Container UND alle Volumes entfernen, DATEN SIND WEG
docker compose down -v

# Kontrolle, dass keine Volumes uebrig sind
docker volume ls | grep signoz

# Nicht mehr benoetigte Images entfernen
docker image rm signoz/signoz:latest signoz/signoz-otel-collector:latest

# Erzeugte Dateien und das Werkzeug entfernen
rm -rf /opt/signoz/pours /opt/signoz/bin /opt/signoz/casting.yaml.lock

Nach dem Aufräumen des Testaufbaus wurde geprüft, dass keine Volumes mit dem Namensbestandteil signoz zurückblieben. Wer nur ein Update oder eine Reparatur vornehmen will, verwendet ausschließlich docker compose down ohne -v.

Was in dieser Anleitung getestet wurde

Zur Einordnung der Ergebnisse gehört Transparenz darüber, was tatsächlich ausgeführt wurde und was aus der Dokumentation stammt.

• Tatsächlich ausgeführt und beobachtet: Installation von foundryctl v0.2.17, Erzeugung der Compose-Dateien mit gauge und forge, Anpassung der Ports über patches, Start des kompletten Stacks, Statusabfrage aller Dienste, HTTP-Prüfung von Oberfläche und Gesundheitsendpunkt, Anlegen des Administratorkontos über die API, Versand eines OTLP-Traces und einer OTLP-Logzeile mit anschließendem Nachweis in ClickHouse, Messung von Speicherverbrauch und Volume-Größen, vollständiger Sicherungs- und Wiederherstellungsdurchlauf des Metastores inklusive absichtlichem Datenverlust, Abbau des Stacks.
• Nur dokumentiert, hier nicht selbst getestet: die nginx-Reverse-Proxy-Konfiguration mit TLS, der Betrieb unter Windows mit WSL 2, der optionale MCP-Server auf Port 8000, die Sicherung von ClickHouse über den BACKUP-Befehl, die Migration einer bestehenden Alt-Installation von den abgekündigten Compose-Dateien auf Foundry sowie das Ändern der Aufbewahrungsfristen in der Oberfläche.
• Nicht geprüft werden konnte die Bedienung der grafischen Oberfläche selbst, da der Test ausschließlich über Kommandozeile und API erfolgte. Die HTTP-Antwort 200 belegt, dass die Oberfläche ausgeliefert wird, nicht jedoch die Funktion einzelner Dashboards.

Einordnung für Unternehmen

SigNoz ist dann interessant, wenn eigene Anwendungen betrieben werden und die Frage nach der Ursache von Langsamkeit oder Fehlern regelmäßig auftaucht. Der Aufwand für Einrichtung und Betrieb ist real, aber überschaubar, sofern jemand im Haus mit Docker vertraut ist. Die Bindung an OpenTelemetry ist dabei der strategisch wichtigste Punkt: Die Instrumentierung der eigenen Anwendungen bleibt auch dann nutzbar, wenn die Plattform darunter später wechselt.

Wer dagegen hauptsächlich Server und Netzwerkkomponenten überwacht und keine eigene Softwareentwicklung betreibt, fährt mit einem schlankeren Werkzeug besser. Die Frage lautet nicht, welches Werkzeug das mächtigere ist, sondern ob überhaupt Anwendungscode existiert, der instrumentiert werden kann. Ohne Traces aus der eigenen Anwendung nutzt man von SigNoz nur einen Bruchteil und zahlt trotzdem den vollen Betriebsaufwand für ClickHouse.

Ein letzter Hinweis zum Datenschutz: Traces und Logs enthalten regelmäßig Inhalte, die unter die DSGVO fallen, etwa Benutzerkennungen, IP-Adressen oder Parameter aus Formularen. Vor dem Produktivbetrieb sollte geklärt werden, welche Attribute erfasst werden und ob im Collector Felder entfernt oder unkenntlich gemacht werden müssen. Die selbst gehostete Variante hat hier den Vorteil, dass diese Daten das eigene Rechenzentrum nicht verlassen.

Passende Anleitungen auf S-EDV

• Prometheus-Monitoring-Stack mit Docker aufbauen: der klassische Weg für Infrastruktur-Metriken, die passende Wahl, wenn keine Traces aus eigenem Anwendungscode anfallen.
• Logs zentralisieren mit Grafana Loki: reine Log-Sammlung ohne Traces, deutlich schlanker im Betrieb als ein kompletter Observability-Stack.
• Grafana-Dashboards bauen: Datenquelle und Panel: nützlich zum Vergleich, weil SigNoz Dashboards und Datenquellen in einer eigenen Oberfläche mitbringt.

Quellen

• SigNoz Docs: Install SigNoz on Docker Standalone, offizielle Installationsdokumentation, Stand der Seite laut Fußnote 14. Juli 2026, abgerufen am 17.09.2026.
• GitHub: SigNoz/signoz, Repository mit Quellcode und Lizenz, Kennzahlen über die GitHub-API abgerufen am 17.09.2026.
• SigNoz Release v0.142.0, Release-Notes vom 16.09.2026, abgerufen am 17.09.2026.
• SigNoz deploy/README.md, Abkündigungshinweis zu install.sh und den gebündelten Compose-Dateien, abgerufen am 17.09.2026.
• Foundry-Dokumentation: Patches, Referenz zu den JSON-Patch-Operationen nach RFC 6902, abgerufen am 17.09.2026.