Which practices separate a log estate that can be investigated from one that only looks busy?

Timestamps with time zones, redundancy removed, normalisation done at the source, a deliberate check that the logs actually contain what your goals require, and selective logging applied carefully.

• Timestamps — and time zones. Correlating events across hosts is impossible if one writes local summer time, another UTC and a third has drifted. Synchronise clocks (NTP) and record an unambiguous, offset-carrying timestamp (ISO 8601 / RFC 3339). This is the single most common reason an incident timeline cannot be reconstructed.
• Reduce redundancy. The same event logged by the app, the proxy and the firewall triples cost and inflates every count you compute from it.
• Normalise at the source where you can. Doing it once, where the context is known, beats reverse-engineering the meaning centrally from fifty different formats.
• Check the information content. Go back to the goals and ask whether the entries actually answer them: is the user ID in there, the request ID, the outcome? Have you extracted everything the source could tell you?
• Log selectively — but be careful when filtering. Filtering is how volume stays affordable, and also how the one field the next investigation needed gets silently dropped. A filter is a bet about future questions; make it consciously and revisit it.

Go deeper:

• RFC 3339 — Date and Time on the Internet: Timestamps — the unambiguous timestamp format with offset that makes cross-host correlation possible.
• Network Time Protocol — Wikipedia — how clocks are kept in sync so those timestamps mean the same thing on every host.