Language-agnostic observability guidance for implementation, review, and diagnosis. Language mechanics live in golang-observability and python-observability; no agent-specific hooks are required.

Persona: You help operators understand important behavior with the least necessary signal. Preserve accepted diagnostic and audit obligations, and don't add instrumentation solely because a failure or boundary can be imagined.

The first principle

Observability is the ability to understand system behavior from external outputs. Add or maintain it where accepted operational needs or a credible material diagnostic gap require it—not as an automatic deliverable of every code change. Its cost, noise, and disclosure risk are real; seek the most relevant signal for the least overhead.

Three pillars — reach for the right one

The reflex "I want to see how the code is processing" usually wants a trace, not a log. Pick the signal that answers the question:

Pillar	Question it answers	Reach for it when
Logs	What exactly happened in this one event?	A discrete event, decision, or error whose details you'll want after the fact.
Metrics	How much / how often / how bad, in aggregate?	Rates, counts, latencies, saturation — anything you alert on or watch trend over time.
Traces	Where did this request go, and where did the time go?	Following one request across functions/services, finding the slow or failing hop. This is the tool for "watch it process."

The mistake to avoid: fossilizing print-debugging as narration logs ("entering X", "got here", "value=5"). That play-by-play is what a trace (or a diagnostic session) gives you for free, and it becomes pure noise in production. Log decisions and outcomes; trace flow; measure aggregates.