Beyond the Sidecar

Reconciling Database Telemetry Across Upstream Kubernetes Operators

Sergey Pronin Founder, Solanica Inc. · Maintainer, OpenEverest
October 15, 2026 · Online osoday.com

Open-source data platform.

Databases. Storage. LLMs. Any Kubernetes.

CNCF Sandbox

Small core. Everything else plugs in.

Pluginsextend the product
Plugin Hub
MongoDB Explorer
+
Coresmall and stable
OpenEverest
Providerswrap upstream operators
MySQL
CloudNativePG
MongoDB
ClickHouse
Valkey
+

Any upstream operator.

Plug it in. No forks.

The Problem

Prometheus is the standard.

CNCF Graduated /metrics Everywhere

But life is not
that simple.

Every operator has an opinion.

CloudNativePG
→ Prometheus its own way
Percona
→ PMM first-class
SQL Server
→ sql_exporter bolted on
?
→ ? and so on…

Same operator. Different effort.

Percona
PMM native
Prometheus doable
Coroot doable

Operators × Backends

× metrics, logs, traces
CloudNativePG
MySQL
MongoDB
SQL Server
ClickHouse
Valkey
1 integrations
Prometheus
PMM
Coroot
Datadog
Grafana Cloud
OpenTelemetry
N × M

N + M ?

Four options.

0Our stack
1Providers
2Plugins
3Contract
0

Our own stack.

CloudNativePG
MySQL
MongoDB
SQL Server
Prometheus
Our stack
Coroot
OpenTelemetry
Kills the platform. Opinionated operators push back.
1

Providers own it.

CloudNativePG
MySQL
MongoDB
SQL Server
Prometheus
PMM
Coroot
OpenTelemetry
Same logic. Every provider.
2

A plugin per backend.

CloudNativePG
MySQL
MongoDB
SQL Server
Prometheus
PMM
Coroot
OpenTelemetry
Every plugin knows every operator.
3

A contract in the middle.

CloudNativePG
MySQL
MongoDB
SQL Server
OpenEverest
Prometheus
PMM
Coroot
OpenTelemetry
N + M. Providers publish. Extensions deliver.

Monitoring, like backups.

Backups BackupClass ProviderManagedJob
Monitoring MonitoringClass ProviderManagedExtension

Every piece. Its own repo.

openeverest
Core
knows neither.
provider-*
MySQL
CloudNativePG
MongoDB
+
knows its operator.
monitoring-*
PMM Prometheus +
knows its backend.

Own repo. Own release. Own maintainers.

One Instance. Two destinations.

User picks Core binds Executor delivers
PXC
pmm-prod team-prometheus →
Provider ProviderManaged
→ PMM →
Extension ExtensionManaged
→ Prometheus

One place to look.

status:
monitoring:
sources:
metrics:
- {component: proxy, kind: haproxy, port: 8404, path: /metrics}
destinations:
- {name: pmm, mode: ProviderManaged, configured: "True"}
- {name: prometheus, mode: ExtensionManaged, configured: "True"}

What users see.

OpenEverest
✓✓✓4

Monitoring

Where should this database send its telemetry?

pmm-prodPMM · Ready
✓
team-prometheusPrometheus · Ready
✓
coroot-euCoroot · Ready
✓
otel-collectorOpenTelemetry · Ready
✓
+ Add destination
Previous Create

Database summary

1. Basic Informationorders-db · MySQL
2. Resources3 nodes
3. BackupsDaily at 1:00 AM
4. MonitoringNonepmm-prodteam-prometheus

One database. Every destination.

OpenEverest

orders-db

Up

MySQL · 3 nodes · namespace everest

Monitoring+ Add destination
pmm-prodPMM
via provider
Configuring✓ Configured
team-prometheusPrometheus
via extension
Configuring✓ Configured

Overview

EngineMySQL 8.4
BackupsDaily at 1:00 AM
MonitoringConfiguring…2 of 2 configured

↑ Instance.status.monitoring.destinations

New backend?→One extension.
New operator?→Publish sources.
New Instance?→Pick destinations.

N + M.

Join the community.

openeverest.io/community
CNCF Slack GitHub Community meetings Good first issues
Solanica OpenEverest Open Source Observability Day

Thank you.

Sergey Pronin solanica.io openeverest.io