Logging fails in a small number of recognisable ways. Here is how to identify each one quickly and what actually fixes it.
Work down the chain rather than guessing. Is the application writing? Check locally with docker logs <container> or journalctl -u <service> -n 100. If nothing is there, the usual causes are a log level set to warning or above in production config, output going to a file inside the container that nothing collects, or buffered stdout in a process that has not flushed. In Python that last one is common: run with PYTHONUNBUFFERED=1 or the logs appear only when the buffer fills. If the application is writing but the platform shows nothing, the collector is the problem — check its own logs, which are frequently the only thing that will tell you a parse rule is rejecting every line.
Find the offender by volume before changing anything. Group log count by service and by log line pattern over the last 24 hours; the answer is almost always one of three things — a debug logger left enabled after a deploy, a health check endpoint logging every request from a load balancer probing every few seconds, or an error loop logging a full stack trace thousands of times a minute. Fixes, in order: exclude health check paths at the collector, sample successful requests while keeping all errors, and rate-limit repeated identical errors so a loop produces one line plus a count. Then set an alert on ingestion volume so the next occurrence is caught in hours.
Nearly always mixed output on the same stream. One library logs JSON and another logs plain text, or a startup banner precedes the structured lines, and the parser gives up. Check by looking at raw lines rather than the platform's rendered view. Fix by configuring every logger in the process through one handler, and by routing anything you cannot control — a framework's access log, for instance — through a collector rule that wraps it into a JSON envelope rather than letting it break the stream.
Three causes. The container has no timezone set, so it logs in UTC while the application assumes local, or the reverse. The platform is using ingestion time rather than the event's own timestamp because the timestamp field is not in a recognised format. Or clocks have drifted because NTP is not running. Log in UTC with an explicit offset in RFC 3339 format, configure the collector to parse that field explicitly rather than autodetecting it, and confirm time sync on the host.
Multiline handling. Every collector has a multiline rule — the reliable configuration matches a line that starts with a timestamp as the beginning of a new event and treats everything else as a continuation. The better fix is to not emit multiline logs at all: structured loggers can serialise an exception into a single JSON field, which keeps the trace intact through every hop.
No correlation ID. Generate one at the edge if the incoming request does not carry one, propagate it in a header, put it in a context object, and include it on every log line automatically through the logger's configuration rather than by passing it into each call. OpenTelemetry's trace and span IDs do this as a side effect of instrumentation, which is a good reason to adopt it even if you never look at a trace waterfall.
Log rotation is missing or misconfigured. For containers, set the Docker log driver's max-size and max-file options — the default json-file driver has no limit and will consume the disk. For files on a host, check that logrotate actually has a rule for your path and that the process reopens its file after rotation, or it will keep writing to a deleted inode while the disk stays full and the file appears empty.