SigNoz: OpenTelemetry-natives APM mit Metriken, Logs und Traces in einem

Was ist SigNoz?

SigNoz ist eine OpenTelemetry-native All-in-one-Observability-Plattform. 2021 in Indien gestartet, mittlerweile in Version 0.55+ (Mai 2026) ein etablierter Player im OSS-Monitoring-Bereich und die wohl ernsthafteste freie Alternative zu Datadog. Lizenz: MIT – komplett frei, ohne Klauseln, ohne Open-Core-Limits.

Das Konzept: Metriken, Logs und Traces in einer UI, eingespeist über den OpenTelemetry-Protokoll (OTLP). Statt drei getrennte Backends zu betreiben (Prometheus für Metriken, Loki für Logs, Tempo für Traces), sammelt SigNoz alles in einer ClickHouse-Datenbank und bietet eine einheitliche Abfrage-Oberfläche. Damit reduziert sich der Setup-Aufwand drastisch – und Cross-Korrelation (Trace zu Log zu Metrik) wird trivial.

ClickHouse als Backend: SigNoz nutzt ClickHouse, die spalten-orientierte Analytics-Datenbank. Das gibt ihm für Logs eine deutlich bessere Performance als Loki (volltext-Suche schnell), für Metriken konkurrenzfähige TSDB-Performance, und für Traces hohe Skalierbarkeit. Footprint: deutlich grösser als Prometheus (mindestens 4 GB RAM, 30 GB Disk für ein KMU-Setup), aber ein einzelner Stack ersetzt drei getrennte.

OpenTelemetry-First: alle Eingaben gehen über den OpenTelemetry-Collector. Das Protokoll OTLP ist Industrie-Standard und wird von OpenTelemetry-SDKs in 11 Sprachen unterstützt (Java, Python, Node.js, Go, .NET, Ruby, etc.). Wer seine Anwendungen mit OTel instrumentiert, ist herstellerunabhängig – gleicher Code läuft mit SigNoz, Datadog, Jäger, Tempo, Honeycomb.

Mai 2026 Status: SigNoz hat sich nach drei Jahren breiter Adoption als ernster Spieler etabliert. Kommerzielle Cloud-Variante (signoz.io) mit EU-Region verfügbar. Self-host-Variante läuft produktiv bei mittelgrossen KMU und Startups. Vergleich zu Grafana-LGTM-Stack: SigNoz ist kohaerenter (eine UI, ein Backend) – Grafana-Stack ist flexibler (jede Komponente austauschbar). Beide ernsthafte Optionen.

Warum es zählt

SigNoz schliesst eine Lücke, die der Grafana-Stack offen lässt: einheitliche Cross-Korrelation von Metriken, Logs und Traces ohne 3 separate Backends zu betreiben.

KMU-Tauglichkeit (Mai 2026): Wer Mai 2026 bei Null beginnt und sofort Observability braucht, hat eine echte Alternative zu Grafana-LGTM. SigNoz-Setup via docker-compose ist ein einzelner Stack, ein Frontend, eine Datenbank. Lernkurve niedriger – eine Abfrage-Syntax (PromQL-ähnlich) statt drei (PromQL plus LogQL plus TraceQL). Für ein 5-Personen-Team ohne dedizierte DevOps-Stelle der ehrlichere Weg.

CH-DSG-Fit: self-host auf Hetzner Falkenstein läuft problemlos. Cloud-Variante hat eine EU-Region (Frankfurt) – Auftragsverarbeitungs-Vertrag mit SigNoz Inc. möglich. Damit ist auch für Treuhand/Anwalts-Mandanten ein konformer Betrieb möglich, ohne in die Self-host-Komplexität zu gehen.

OpenTelemetry-Strategie: wer 2026 neue Anwendungen instrumentiert, sollte OTel wählen – herstellerunabhängig, breit unterstützt, klare Spezifikation. SigNoz nimmt OTLP nativ entgegen, ohne Konvertierung. Damit ist die Anwendung zukunftssicher: später könnte ein Wechsel zu Datadog oder Tempo ohne Code-Änderung erfolgen.

Cross-Korrelation in einem UI: ein konkreter Vorteil im Daily-Operations. Ein Alert "API-Latenz P95 über 2s" führt in SigNoz mit einem Klick auf die Logs des betroffenen Service in derselben Zeit, dann auf den Trace einer langsamen Anfrage, dann auf die DB-Query, die den Trace dominiert. Im Grafana-Stack ist das auch möglich, braucht aber drei Datasources mit Cross-Links – funktional äquivalent, aber spürbar mehr Reibung.

APM-Funktionen: SigNoz hat klassische APM-Features eingebaut – Service-Map, Slowest-Endpoints, Error-Rate per Service, Apdex-Score. Im Grafana-Stack braucht es Custom-Dashboards dafür. SigNoz liefert das out of the box. Für Teams ohne tiefes Observability-Knowhow ist das ein echter Zeitsparer.

Wie es funktioniert

SigNoz hat drei Hauptkomponenten: der OpenTelemetry-Collector (Ingestion), ClickHouse (Storage), und das Query-Service plus Frontend (UI). Alle laufen in einem docker-compose-Bundle.

docker-compose.yml-Skizze (vereinfacht – das offizielle Repo bietet ein vollständiges Bundle):

```yaml services: clickhouse: image: clickhouse/clickhouse-server:23.11 volumes: [clickhouse-data:/var/lib/clickhouse] otel-collector: image: signoz/signoz-otel-collector:0.88.0 command: ["--config=/etc/otel-collector-config.yaml"] ports: ["4317:4317", "4318:4318"] query-service: image: signoz/query-service:0.55.0 depends_on: [clickhouse] frontend: image: signoz/frontend:0.55.0 ports: ["3301:3301"] depends_on: [query-service] volumes: clickhouse-data: ```

Nach dem Start ist die UI auf http://server:3301 erreichbar. Admin-Account anlegen, fertig.

Datenfluss: (1) Anwendungen senden Telemetry via OTLP (HTTP oder gRPC) an den OTel-Collector. (2) Der Collector pre-prozessiert (Sampling, Filterung, Anreicherung) und schreibt nach ClickHouse. (3) Das Query-Service liest aus ClickHouse und beantwortet UI-Anfragen.

Anwendungs-Instrumentierung: typischerweise via OpenTelemetry-SDK. Beispiel Node.js:

```javascript const { NodeSDK } = require("@opentelemetry/sdk-node"); const sdk = new NodeSDK({ resource: new Resource({"service.name": "my-api"}), traceExporter: new OTLPTraceExporter({url: "http://signoz:4318/v1/traces"}), }); sdk.start(); ```

Danach werden HTTP-Requests, Datenbank-Queries, externe API-Aufrufe automatisch als Traces eingelesen.

Logs: separat über FluentBit, Vector oder den OTel-Collector als Log-Receiver. Logs werden mit Trace-IDs verknüpft, damit ein Klick im Trace direkt auf die zugehörigen Logs führt.

Metriken: Prometheus-Endpoints werden via OTel-Collector gescraped und in OTLP-Format konvertiert. Custom-Metriken via OpenTelemetry-Metrics-SDK. PromQL-ähnliche Abfragesprache in der UI, mit zusätzlicher Builder-Oberfläche.

Alerts: in der UI definierbar, basierend auf Schwellwerten oder PromQL-ähnlichen Ausdrücken. Receiver: Slack, PagerDuty, Webhook, E-Mail, Telegram (via Webhook-Brücke).

Setup in 5 Schritten

1. 01Offizielles SigNoz docker-compose-Bundle aus github.com/SigNoz/signoz clonen, .env mit Cluster-Name und Region anpassen.
2. 02Memory-Limits in der compose: ClickHouse min 4 GB, OTel-Collector 1 GB, Frontend 256 MB. Auf KMU-Host total mind. 6 GB RAM freihalten.
3. 03docker compose up -d, UI auf Port 3301 öffnen, Admin-Account anlegen, Workspace-Konfiguration speichern.
4. 04Erste Anwendung instrumentieren: OpenTelemetry-SDK für Node.js/Python/Go installieren, OTEL_EXPORTER_OTLP_ENDPOINT auf SigNoz zeigen, Trace-Export prüfen.
5. 05Alerts konfigurieren: Schwellwert-Alerts auf Service-Latenz P95, Error-Rate > 5%, Apdex < 0.7 – Receiver Telegram-Webhook oder Slack.

Wann SigNoz einsetzen

SigNoz ist die richtige Wahl, wenn (a) das Setup Microservices oder mehrere Anwendungen hat, die voneinander abhängen, (b) Traces relevant sind (nicht nur Metriken), (c) OpenTelemetry strategisch eingesetzt werden soll, (d) ein einheitliches Observability-Backend gewünscht ist statt drei separater Komponenten.

Konkrete Fälle: Eine SaaS-Plattform mit Frontend, API, Worker-Queue, externer LLM-Anbindung – vier Services, jede Anfrage durchläuft alle. Mit SigNoz wird der gesamte Pfad in einem Trace sichtbar, inklusive Latenz pro Hop. Ein RAG-System mit Embedding-Generation, Qdrant-Query, LLM-Call – wo verbringt eine durchschnittliche Anfrage die meisten Sekunden? SigNoz zeigt es sofort. Ein Treuhand-Workflow mit n8n, Mahnung-Generator, PDF-Engine, Brevo-Versand – Cross-Service-Tracing macht stille Fehler sichtbar.

Gute Wahl auch für Teams, die OpenTelemetry-First setzen wollen. Wer 2026 neue Microservices schreibt und OTel als Standard etabliert, sollte SigNoz statt Grafana-LGTM prüfen – der Match ist enger, weniger Konvertierung nötig.

Wann NICHT

SigNoz ist die falsche Wahl, wenn (a) der Stack nur einen Container hat – Overkill, Uptime Kuma reicht, (b) Traces nicht gebraucht werden – Prometheus plus Grafana ist schlanker, (c) ClickHouse-Wartung als Risiko gesehen wird – die Datenbank braucht Backup-Strategie und kann bei Konfigurations-Fehlern viel RAM verbrauchen, (d) das Team bereits einen ausgereiften Grafana-Stack hat – Migration nicht trivial.

Fallen: SigNoz ohne Sampling-Strategie deployen – bei hohem Trace-Volumen explodiert die ClickHouse-Disk. Empfohlene Default: 10% Head-Sampling für Production. OTel-Collector ohne Memory-Limits laufen lassen – kann den Host füllen. SigNoz-Cloud ohne Prüfung des EU-Region-Setups einsetzen – Standard ist US-Region.

Nicht-empfohlene Muster: SigNoz und Grafana-LGTM parallel betreiben – die Use-Cases überlappen sich, das ist Konfusion ohne Mehrwert. ClickHouse als allgemeine Analytics-DB missbrauchen – sie ist optimiert für SigNoz-Workload, nicht für generelle BI-Abfragen.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. SigNoz – Documentation · 2026-05
2. SigNoz – GitHub repository · 2026-04
3. OpenTelemetry – Specification and SDKs · 2026-05
4. SigNoz Cloud – Pricing tiers · 2026-05