HackerTrans
TopNewTrendsCommentsPastAskShowJobs

rnjn

no profile record

Submissions

Show HN: Cicada – Claude Code usage analysis TUI

github.com
2 points·by rnjn·4 maanden geleden·0 comments

Observability Theatre

rnjn.in
3 points·by rnjn·4 maanden geleden·1 comments

Show HN: Metric-Registry

metric-registry.base14.io
2 points·by rnjn·6 maanden geleden·0 comments

Metric-Registry

docs.base14.io
6 points·by rnjn·6 maanden geleden·1 comments

comments

rnjn
·4 maanden geleden·discuss
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.
rnjn
·6 maanden geleden·discuss
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)
rnjn
·6 maanden geleden·discuss
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.
rnjn
·6 maanden geleden·discuss
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.