Connect Vortos to external observability, alerting, and monitoring tools — Sentry, Grafana, Prometheus, Loki, Tempo, Jaeger, Datadog, Slack, and Alertmanager.

Integrations

Vortos outputs to open standards — structured JSON logs, Prometheus metrics, OpenTelemetry OTLP metrics, and OpenTelemetry traces. Any tool that speaks these standards works. This section covers step-by-step setup for the most common ones.

The three pillars of observability

Before picking tools, it helps to understand what each pillar is for:

Pillar	What it answers	Vortos output
Logs	What happened and when	Structured JSON → stderr / log files
Metrics	How much, how fast, how often	Prometheus pull, StatsD UDP, or OpenTelemetry OTLP push
Traces	Why was this request slow	OpenTelemetry OTLP

The tools below consume one or more of these pillars. Some (Grafana, Datadog) consume all three.

Tool overview

Tool	Pillar	Use case
Sentry	Logs	Error tracking and exception grouping
Slack	Logs	Real-time critical alert notifications
Prometheus	Metrics	Metrics collection and storage
Grafana	Metrics + Logs + Traces	Unified dashboards, charts, alerting
Loki	Logs	Log aggregation and search
Tempo	Traces	Distributed trace storage and search
Jaeger	Traces	Distributed trace storage (alternative to Tempo)
Datadog	All three	Fully managed APM platform
Alertmanager	Metrics	Route Prometheus alerts to Slack, email, PagerDuty

Framework-level observability capabilities

The guides above cover connecting external tools. These pages cover capabilities the framework itself adds on top of the open-standards output — generated collector configuration, tamper-evident deploy audit history, dead-man monitoring, and declared SLO resources:

Collector & Sinks

Config-only backend switching — a sink renders the collector exporter fragment; your app never touches a vendor SDK.

Deploy Audit Ledger

A hash-chained, signed, append-only record of every deploy and rollback.

Dead-Man Heartbeat

A scheduled off-host check-in, detected by absence.

Deploy Markers & SLO Resources

Dashboard annotations linked to a build, and SLOs declared as validated, version-controlled resources.

Start here — local development stack

If you want everything wired up locally in one command, start with the local stack guide. It runs Prometheus, Grafana, Loki, and Tempo together with all data sources pre-configured:

Local Stack

Docker Compose with Prometheus + Grafana + Loki + Tempo. One command, everything connected.

Framework configuration reference

Integration guides in this section focus on the external tool side — installation, accounts, and connection. For the Vortos configuration that feeds these tools, see:

Logger configuration — alerting handlers (Sentry, Slack, email), channels, log format
Metrics configuration — adapter selection, Prometheus endpoint security, StatsD host, OTLP metrics push
Tracing configuration — OpenTelemetry wiring, sampling, module disable

Error sink selection

The error sink is selectable with OBSERVABILITY_ERROR_SINK (null default, glitchtip, or sentry). A first-class Sentry driver ships alongside GlitchTip — same envelope ingest protocol — reading OBSERVABILITY_SENTRY_DSN. The configured sink is aliased to ErrorSinkInterface, so consumers inject "whatever the operator selected".

OBSERVABILITY_ERROR_SINK=sentry
OBSERVABILITY_SENTRY_DSN=https://<key>@o0.ingest.sentry.io/0

Collector receiver bind (multi-container)

The generated OTLP collector binds loopback (127.0.0.1) by default — correct for a sidecar sharing the app's network namespace, and the tracing stub now defaults its exporter to 127.0.0.1:4318 to match. When a separate worker container must emit to a shared collector on a private Docker network, bind the receiver wider:

php bin/console vortos:observability:collector --bind=0.0.0.0
# or set OBSERVABILITY_COLLECTOR_BIND=0.0.0.0

No lock-in

Vortos uses open standards throughout. Switching from Jaeger to Tempo, or from self-hosted Prometheus to Datadog, requires only a config change — no application code changes.