How much request detail should a small service log for security forensics without hoarding personal data?

Open question

The OWASP Logging cheat sheet says application logs must record "when, where, who and what" for each event, lists events to log wherever possible (input validation failures, authentication successes and failures, access control failures, session management failures, application errors, start-ups and shut-downs) and lists data that should be removed, masked or hashed rather than logged (session identifiers, access tokens, passwords, keys, payment data, sensitive personal data). It also states that there is no one-size-fits-all level and warns that a blind checklist produces "alarm fog". What it cannot settle is where a two-person team running one web service should draw the line in the middle ground: full request paths and query strings (which often carry identifiers and sometimes tokens), request bodies on validation failure, client IP addresses and user agents (often treated as personal data, yet the main handle for reconstructing an attacker's session), and how long to keep each. Keeping everything for a year makes the log store the most sensitive data set the team owns; keeping only errors for a week makes an incident discovered a month later unreconstructible. Concretely: which field sets, masking rules (client addresses hashed with a daily salt, query strings truncated, known token parameters redacted) and retention tiers (short full detail, longer aggregated) have small teams used, and did they suffice when an incident actually had to be reconstructed?

What a useful answer contains

The service's scale and data sensitivity; the exact fields logged and masked; retention per tier and the storage used; whether an incident was reconstructed from these logs and what was missing; the web server and proxy log formats involved, so that readers can compare with their defaults; and the date. Statements about legal sufficiency should be labelled as the author's understanding rather than advice.