[Feature] First-class OpenTelemetry Metrics ingestion and dashboards

[Polliog]

Feature Description

Logtide already handles logs and traces via OTLP natively, but metrics support is still in its early stages. This issue tracks bringing metrics to the same level of maturity as the other two pillars, completing the three observability signals in a single self-hosted platform.

Problem/Use Case

Teams using Logtide for logs and traces still need a separate Prometheus + Grafana stack to collect and visualize application metrics. This defeats the purpose of having a unified observability platform, especially for smaller teams that don't want to operate multiple systems. Without metrics, there's no way to track request rates, latency percentiles, or saturation alongside the logs and traces that explain them.

Proposed Solution

• Full OTLP metrics ingestion endpoint (POST /v1/otlp/metrics) supporting all standard instrument types: Counter, Gauge, Histogram, Sum
• Dedicated Metrics section in the dashboard with configurable time windows (1h, 6h, 24h, 7d)
• Pre-built panels for the most common signals: request rate, error rate, latency percentiles (p50/p95/p99), resource saturation
• Support for metric labels/attributes as filterable dimensions in queries
• Cross-signal correlation: from a metric anomaly, navigate directly to the related traces and logs of the same service in that time window

Alternatives Considered

• Prometheus remote write: accepting Prometheus remote write format instead of OTLP. Rejected because it would add a secondary ingestion format to maintain and would break the OTLP-native approach already established for logs and traces.
• Dedicated time-series database: using InfluxDB or VictoriaMetrics exclusively for metrics. Rejected because it would bypass the @logtide/reservoir abstraction layer and require users to operate yet another separate service.

Implementation Details (Optional)

• Storage: metrics must be implemented through the @logtide/reservoir abstraction layer so they work transparently across all supported backends (TimescaleDB and ClickHouse). Each backend adapter implements the metrics storage interface independently, taking advantage of native capabilities — e.g. TimescaleDB continuous aggregates for rollups, ClickHouse materialized views for the same purpose at larger scale
• Ingestion: metrics processed in BullMQ workers similarly to traces, not in the HTTP handler
• Querying: the reservoir query interface should expose pre-aggregated rollups (1m/1h/1d) so the dashboard always hits pre-computed data regardless of backend, targeting <100ms render times
• API: follow the existing OTLP route pattern at packages/backend/src/modules/otlp/

Priority

• Critical - Blocking my usage of LogTide
• High - Would significantly improve my workflow
• Medium - Nice to have
• Low - Minor enhancement

Target Users

• DevOps Engineers
• Developers
• Security/SIEM Users
• System Administrators
• All Users

Additional Context

With this feature, Logtide completes the three pillars of observability (logs, traces, metrics) in a single Docker Compose deployment. The goal is not to replace Prometheus for teams that already have it, but to give teams that don't want to operate a separate metrics stack a good-enough, privacy-first, self-hosted alternative.

Contribution

• I would like to work on implementing this feature