Production observability for a solo project

TODO: Write full article. Outline below.

Why observability before launch

The cost of adding observability after an incident: you’re flying blind during the exact moments that matter most. For Rentals Hub, I decided the Golden Signals would be part of the definition of “production ready” — not a nice-to-have.

The four Golden Signals for a rental marketplace

• Latency: rentals.search.duration.ms histogram — p50/p95/p99
• Traffic: rentals.search.total, rentals.listing.views.total
• Errors: rentals.listing.create_failed.total — with asset_type and city tags
• Saturation: DB connection pool usage via Npgsql metrics, dotnet.process.memory.usage

Custom RentalsHubMeter

Walk through creating a singleton Meter("RentalsManagement.API"), why the name matches the wildcard in AddMeter("RentalsManagement.*"), and how to record tagged observations.

PII problem: phone numbers in telemetry

Listing queries include phone numbers in filter parameters. OTel would happily export these to Grafana Cloud. The fix: a custom BaseProcessor<Activity> that scans tag values for E.164 patterns and replaces them with [REDACTED] before export.

Fly.io Prometheus scraping

fly.toml [metrics] block — internal scraping without exposing /metrics publicly. How it integrates with Grafana Cloud as a data source.

The 16-panel dashboard

Row breakdown: System Health · Search Traffic · Listings · Errors · DB+Cache · Saturation. Alert rules: p95 latency > 2s, error rate > 5%, memory > 80%.