Adding Logging and Metrics

When a vibe-coded app misbehaves in production, you're blind unless you instrumented it. Logs, metrics, and traces are the three lenses that let you see inside a running system.

This lesson uses your AI assistant to add observability that answers real questions instead of producing noise.

Each pillar answers a different question. Logs tell you what happened in one event. Metrics tell you how often and how much over time. Traces tell you how a single request moved across services.

Knowing which to reach for keeps your instrumentation focused and your bills sane.

A wall of free-text print statements is unsearchable. Structured logs emit JSON with consistent fields, so you can filter by user, route, or status in seconds.

Ask the assistant to replace ad-hoc logging with a structured logger and a standard field schema.

A single user action can touch many log lines and several services. Without a shared identifier you can't tell which lines belong together.

Generate a request ID at the edge and thread it through every log and downstream call so one trace tells the whole story.

Logging everything at one level is the same as logging nothing useful. Levels let you stay quiet in normal operation and verbose when investigating.

Have the assistant assign sensible levels and make verbosity configurable per environment without a redeploy.

Logs are read by many people and often shipped to third-party tools. A password, token, or full credit-card number in a log line is a breach waiting to happen.

Ask the assistant to add redaction so sensitive fields are masked before anything is written.

For metrics, start with the four golden signals: latency, traffic, errors, and saturation. They cover most of what you need to know about service health.

Let the assistant instrument these as counters and histograms you can graph and alert on.

System health is only half the picture. Signups, checkouts, and failed payments tell you whether the product is actually working for users.

Ask for custom metrics on the events that matter to the business so a silent revenue drop becomes visible immediately.

When a request fans out across services and a database, a trace shows the timeline of every span so you can see exactly where the time went.

Have the assistant wire up a tracing standard so spans propagate automatically across service boundaries.

Raw metrics are useless until someone can read them at a glance. A good dashboard is organized around the questions you'll ask during an incident.

Ask the assistant to define panels for error rate, p95 latency, and the key business counters, with thresholds marked.

The goal of observability is fast answers, not data hoarding. Too many logs and metrics cost money and bury the signal you need.

Periodically prune what you never query, keep field names consistent, and make sure every metric maps to a question someone actually asks.

Test your understanding of logging and metrics.

Observability rests on three pillars: structured, correlated, redacted logs; the golden-signal and business metrics that surface trends; and distributed traces that show a request's full path.

Prompt your assistant to instrument each deliberately, build dashboards around real questions, and prune anything that produces noise instead of answers.