rnjn

Your organisation has invested millions in observability tools. You have dashboards for everything. Your teams dutifully instrument their services. Yet when incidents strike, engineers still spend hours hunting through disparate systems, correlating timestamps manually, and guessing at root causes. When the CEO forwards a customer complaint asking “are we down?”, that’s when the dev team gets to know about incidents.

You’re experiencing observability theatre, the expensive illusion of system visibility without its substance.

Metric Registry https://metric-registry.base14.io/ is a growing searchable catalog of observability metrics extracted directly from source repositories across the OpenTelemetry, Prometheus, and Kubernetes ecosystems. It scans code, documents and websites to gather this data.

If you've ever tried to answer "what metrics does my stack actually emit?", you know the pain. Observability metrics are scattered across hundreds of repositories, exporters, and instrumentation libraries. The OpenTelemetry Collector Contrib repo alone has over 100 receivers, each emitting dozens of metrics. Add Prometheus exporters for PostgreSQL, Redis, MySQL, Kafka. Then Kubernetes metrics from kube-state-metrics and cAdvisor. Then your application instrumentation across Go, Java, Python, and JavaScript.

Each source uses different formats:

    OpenTelemetry Collector uses metadata.yaml files

    Prometheus exporters define metrics in Go code via prometheus.NewDesc()

    Python instrumentation uses decorators and meter APIs

    Some sources just have documentation (if you're lucky)

You can see the details of how the registry was built on the repo - https://github.com/base-14/metric-library . the current setup scans through many sources and has details for 3700+ metrics. The scan runs every night(/day depending on where you live)

founder at base14 here, the company that is building Scout. Thanks for the feedback. we do something similar for tracing as well, but pgX does a bit more than that - engineers should be able to trace (like you mention) and see and analyse the condition of the DB. for eg - correlate query slowdown to locks, vacuums etc. all on one screen, or a couple of clicks. We are building some specialised explorers like pgX for postgres. Essentially we are building telemetry readers for components that send relevant metrics and logs through to a telemetry data lake. for each component/domain we find from experts what they look at for analysis and incidents, and bring that to a full stack "unified" dashboards/mcp.

Scout is our otel-native observability product (data lake, UI, alerts, analytics, mcp, the works). what we call pgX in the blog is an add-on to Scout.

founder at base14 here, the company that is building Scout. Thanks for the feedback, I will work on bettering my messaging. Scout is an otel-native observability platform (data lake, UI, alerts, analytics, mcp, the works). We are building some specialised explorers (suffix 'X' for explorers) like pgX for postgres. Essentially we are building telemetry readers for components that send relevant metrics and logs through to a telemetry data lake. for each component/domain we find from experts what they look at for analysis and incidents, and bring that to a full stack "unified" dashboard. and we go beyond what a regular prometheus endpoint provides. thanks again.

very interesting solution. and great idea to have a playground. would love to know some details on the implementation of the architecture you have shared - 1. how do you query across multiple files, do you have a query engine like data fusion doing that heavy lifting, or is this a custom implementation ? 2. how do you manage a WAL with real time query-ability across files ? have you seen any failures (recent entries missing sort of issues) Thanks, once again really interesting design and intuitively looks more economical.

Curious to know what you mean by "early phase" here.