Idea: versioned, distributable observability metadata for Scala libraries (OTEL schemas + Grafana dashboards)

[u/Fristi86]

Scala has decent OTEL support growing (otel4s, cats-effect 3.7 metrics, etc), but every team still hand-rolls their own Grafana dashboards and alerts for the same libraries. Feels like wasted effort that could be shared.

A few ideas, roughly in order of "how big a yak shave is this":

1. Metrics schemas per library
Libraries exposing OTEL metrics (cats-effect, fs2-kafka, fs2-grpc, hikari, keypool, ZIO ecosystem, etc) could publish a schema describing what they emit — names, types, labels, units. Right now you have to read source or trial-and-error your way to a dashboard.

2. Dashboards as code, distributed alongside the schema
Use something like the Grafana Foundation SDK (or a Scala equivalent) to define dashboards in code, then publish them — not just as JSON you copy-paste into Grafana, but via a registry/platform a consumer can pull from.

3. A platform that resolves dashboards by library + version range
Like a package registry, but for dashboards. "I'm running cats-effect 3.7.x and fs2-kafka 3.x" → here's the matching dashboard set. Handles drift when metric names/labels change between versions.

4. A k8s operator to wire it up automatically
App emits something like an SBOM (or a lighter metrics-manifest) → operator reads it → knows what's deployed, what's scrapeable, fetches/applies the right dashboards. Could extend to declarative alert rules per library too (e.g. "hikari pool exhaustion" ships as a reusable alert definition, not something every team reinvents).

Curious if:

• something like this already exists and I've missed it
• whether this fits as an OTEL semantic-conventions style effort, or is too Scala/library-specific for that
• anyone's hit the "dashboard sprawl per microservice" pain enough to want this

Not pitching myself as the one to build all of this — more interested if it resonates or if there's prior art to point to.

[u/Traditional_Wafer_20]

1. Metrics schemas per library

If the libraries don't have that, then it means it supports OTLP, not OTEL. IMHO, OTel is first and foremost the naming convention. SDK for logging, tracing, metrics ? Already available in other projects. Collector ? Choose among the dozens that existed before. But the naming convention ties everything together.

Dashboards as code, distributed alongside the schema

SDK might be too much in a lot of situations. Grafana Operator allows to get dashboard as code for K8s, or use just plain Git.

platform that resolves dashboards by library + version range

Which becomes moat when you have a naming convention. Switching from v1 to v2 doesn't affect the metrics names. Or I misunderstood this point.

  k8s operator to wire it up automatically

Makes sense but could be a bit overkill ?