golang-observabilitylisted

# Go Observability Create telemetry that answers a defined operational question without leaking data or destabilizing the system. Start from the service's existing conventions and backend. ## Frame the question Inspect current logging, metrics, tracing, profiling, middleware, dashboards, alerts, privacy rules, and deployment topology. Identify: - the user-visible behavior or failure being investigated; - service boundaries and asynchronous hops; - existing service-level indicators and objectives; - the telemetry backend's naming, cardinality, retention, and sampling constraints; - data classified as secrets, personal information, or regulated content. Do not introduce OpenTelemetry, Prometheus, a vendor agent, or another backend merely to follow a default architecture. ## Instrument stable boundaries Prefer instrumentation at request, job, queue, database, and external-client boundaries over logs at every function. ### Logs - Use the project's structured logger and stable field names. - Include correlation identifiers when already available, but do not treat a request ID as authentication. - Record an error once at the layer that can add useful outcome context; avoid repeated stack traces at every return. - Keep secrets, credentials, authorization headers, session data, raw request bodies, and sensitive identifiers out of logs. - Avoid attacker-controlled text in unstructured log lines; structured fields reduce log-forging ambiguity. Choose levels by operator action