A useful log helps answer a question. It records enough context to connect an event to a request or a change, while leaving out values that do not belong in a diagnostic record.
Start with the event
Choose fields around the work being observed: a timestamp with a clear time zone, an operation, a result, and a duration. Add an identifier when several records need to be connected.
Prefer consistent field names and units. A duration recorded in milliseconds is easy to compare when every producer uses the same convention. The unit should be explicit rather than implied.
Leave credentials out
Passwords, private keys, and authorization tokens should not appear in a log. Avoid recording entire headers or request bodies by default. A query string can contain sensitive information even when the path itself looks harmless.
Redaction is useful, but collecting less is a stronger starting point. Decide what is needed before the event is emitted, then check the resulting output.
Record changes as well as errors
An error becomes more understandable when it can be compared with a deployment, configuration change, or service restart. Keep a short change record with the previous state, the intended difference, and the way to undo it.
Finally, give logs a lifecycle. Decide where they live, who can read them, and how long they are retained. A small, deliberate record is easier to search and easier to maintain.