Skip to main content
Signal routing decides which connector serves each telemetry signal for a project environment. Bindings are independent: traces can come from Tempo while logs come from Loki and metrics from Prometheus — in the same OpenLIT project.

​
Signals

Changing a binding changes where OpenLIT reads. It does not migrate historical data between backends. Ensure the new connector already holds the telemetry you expect.

​
Bind a signal

1

Open Connectors

Go to Organisation → Project → Connectors (data sources).
2

Choose environment

Bindings are unique per project + signal + environment. Match the environment on your Database Config and connectors.
3

Add or select a connector

Create an atomic connector from the supported catalog, then run health check / AI validate as needed.
4

Bind the signal

Assign traces, logs, and/or metrics to connectors that declare those capabilities. A metrics-only connector cannot be bound to traces.
When you add a Database Config, OpenLIT can seed default bindings so all signals point at that ClickHouse until you rebind them.

​
Resolution order

For every read, OpenLIT resolves the source in this order and never returns a connector that does not serve the requested signal:
1

Explicit override

Widget or API sourceId (mixed dashboards) wins when present and project-scoped. Use builtin:<databaseConfigId> for ClickHouse.
2

Per-signal binding

The binding for this project, signal, and environment.
3

Built-in ClickHouse

Active Database Config for the environment (when no explicit environment fail-closed applies).
If nothing serves the signal, OpenLIT shows a first-class no source for this signal state instead of silently reading the wrong backend.

​
Mixed dashboards

Each dashboard widget can optionally target its own connector and signal. One board can render Tempo traces next to Prometheus metrics while evaluation results still come from ClickHouse intelligence.

​
Correlation across backends

Only ClickHouse holds every signal in one store for full correlation. When signals are split:
  • Joins use declared keys (service.name, trace/span id, coding_agent.session.id).
  • Features that need correlatable logs/metrics no-op gracefully when the bound source cannot join.
  • The UI asks you to connect a correlatable source instead of returning incorrect merges.

​
Natural-language / raw SQL

Raw ClickHouse SQL (NL chat and raw-SQL widgets) requires the built-in ClickHouse path. On external connectors, use structured Telemetry, trace, and dashboard views.

​
What never leaves ClickHouse

Regardless of signal routing:
  • Evaluation results and scoring metadata
  • Dashboard / board definitions and widget layout metadata
  • Rules, vault secrets materialization, controller-derived intelligence
Raw OTLP write paths (SDK exporters, collectors) are separate from these read connectors. To mirror only AI telemetry into ClickHouse, see the OTel Collector AI filter recipe.

​
Permissions and audit

Enterprise roles control connector management: Owner and admin built-in roles include the full connector set. Members can read observability data but do not manage connectors by default. Binding and unbinding are written to the organisation audit log (connectors.connector_bound / connectors.connector_unbound) with signal, environment, next connector, and previous source when switching.

Connectors catalog

Supported OpenLIT + OpenPlait connectors and actions.

Environments

How bindings are partitioned by environment.

Database Config

ClickHouse app store and INIT_DB_* bootstrap.