Do I have to abandon OpenTelemetry?
No — it is the ingestion path. Middle Monitor speaks OTLP over protobuf, and the SDKs are thin wrappers over the OpenTelemetry SDKs.
Middle Monitor is OpenTelemetry-native, so it ingests the same trace, metric and log data you would otherwise route into a self-hosted stack — already correlated, without the operational burden of running the stack.
The Prometheus, Grafana and Jaeger stack is open source, vendor-neutral and infinitely customizable, and it is the right answer for teams who want to own their data plane end to end. Middle Monitor trades some of that control for not having to operate it.
Point your existing OTLP exporters at Middle Monitor. Because the SDKs wrap OpenTelemetry rather than replacing it, the instrumentation you already wrote keeps working.
A self-hosted stack usually means Prometheus for metrics, Jaeger for traces, Loki for logs and something else for errors, each with its own storage, retention and dashboards. Here the four signals arrive through one ingestion path and are queried in one interface, and the incident engine correlates anomalies across them by time window.
Alert rules, notification channels and incident correlation are part of the platform, including consecutive-failure smoothing so transient blips do not page.
HTTP, ping, SQL, certificate and SNMP checks run alongside your application telemetry, covering ground that usually needs Blackbox Exporter plus glue.
No — it is the ingestion path. Middle Monitor speaks OTLP over protobuf, and the SDKs are thin wrappers over the OpenTelemetry SDKs.
Your instrumentation stays standard OpenTelemetry, so it can fan out to another backend at the exporter level.