[de107549]

You’re absolutely right — while most observability vendors support receiving data via OTLP, they often convert it into a proprietary data format. This strips away the power of OpenTelemetry’s semantic conventions, such as OTel Resources. These conventions are incredibly powerful for adding context and correlating metrics, logs, and spans seamlessly. If you haven’t tried leveraging them yet, it’s worth it — the difference is huge.

Another key source of lock-in is dashboards and alerts. Teams often invest time creating hundreds of dashboards and alerting rules, only to face the painful process of recreating them when switching tools.

At Dash0, we tackle these lock-in points head-on: 1. PromQL for everything — not just metrics but also logs and spans. Plus, you can import/export Prometheus alerts (as code), making it easy to reuse existing projects like Awesome Prometheus Alerts: https://samber.github.io/awesome-prometheus-alerts/ 2. Perses for dashboards — a CNCF-backed open standard. You can import/export dashboards (as code), ensuring portability and independence from any vendor.

By adopting open standards like OpenTelemetry, PromQL, and Perses, you keep your observability stack flexible, portable, and future-proof — no more vendor lock-in.