Basic logging

Basic logging is the first and most primitive form of production visibility: writing text output to stdout, stderr, or a log file so that when something goes wrong you have some record of what happened. At this level, logging means console.log, print(), System.out.println(), or their equivalents scattered through the codebase wherever a developer thought they might need to debug something. The output is unstructured prose - sentences like "got here", "user id is 42", "something went wrong" - with no consistent format, no severity levels enforced uniformly, and no aggregation layer collecting logs from multiple instances.

Most codebases start here and many stay here longer than they should. The logs exist on individual servers, in container stdout that evaporates when the container restarts, or in files that get rotated and deleted. Retrieving them requires SSH access to the machine, knowledge of which server handled the request, and patience. In a multi-instance or containerized environment, logs from different replicas are siloed - you might find the log for one request on server A and never know that the related error occurred on server B.

For a team not yet using AI agents, basic logging is painful but survivable. Developers debug production issues by SSHing into boxes, grepping log files, and piecing together narratives from scattered output. It is slow and unpleasant but possible. For a team using AI agents, basic logging is a dead end. Agents cannot grep across distributed log files over SSH. They have no queryable interface into production state. When a production incident occurs, an agent has no input channel to investigate it - the logs are inaccessible, unsearchable, and structurally opaque even if retrieved.

The practical ceiling of basic logging is clear: it works for a single developer debugging a single-instance application on a machine they control. The moment you have multiple instances, containers, or multiple developers needing simultaneous access to log data, the approach breaks down. Recognizing basic logging as a maturity floor - something to move past, not optimize - is the first step toward production observability.

Understanding what basic logging cannot do shapes the upgrade path:

• No aggregation means no cross-service correlation - when a request spans three services, basic logging gives you three separate log streams with no way to link them to a single trace
• Unstructured output blocks programmatic analysis - you cannot query "all errors from the payment service in the last hour" when the log format is inconsistent prose
• Ephemeral storage loses history - container restarts, log rotation, and instance termination destroy the evidence you need for post-incident analysis
• No agent input channel - AI agents investigating production issues need a queryable, structured interface; basic logging provides neither queryability nor structure
• Debugging requires human presence at the machine - every production investigation requires a developer to manually access infrastructure, which does not scale and cannot be delegated to agents

1. Audit your current log output - Search for all logging calls in your codebase (console.log, print, logger.info, etc.) and catalog what you have. Most teams discover logs are far more scattered and inconsistent than they realized. This audit becomes the basis for your structured logging migration.
2. Add consistent severity levels - Even before moving to structured logging, enforce a four-level scheme everywhere: DEBUG, INFO, WARN, ERROR. Replace bare console.log calls with severity-labeled equivalents. This is the minimum prerequisite for any alerting.
3. Stop writing logs to files; write to stdout - In containerized environments, stdout is the correct log destination. Container orchestrators (Kubernetes, ECS) collect stdout automatically. Writing to files in containers creates the worst of both worlds: ephemeral storage with no collection.
4. Identify the five most important events in your application - For each service, pick the five things you most need to know about: requests received, errors thrown, external calls made, authentication events, data mutations. Ensure these events are logged at every occurrence before worrying about anything else.
5. Set up centralized collection immediately - Even with unstructured logs, push them somewhere you can search. A simple ELK stack, Datadog log ingestion, or even Cloudwatch Logs is dramatically better than logs that live only on servers. This single step transforms "logs require SSH" into "logs require a browser tab."
6. Plan for structured logging as the next step - Basic logging is a known floor. Set a team goal to move to structured JSON logging within one sprint cycle. The upgrade cost is low and the observability payoff is immediate.

Logging sensitive data. Unstructured log output frequently captures request bodies, headers, and parameters that include passwords, tokens, PII, and payment data. When logs are just console.log(request), the full object - including sensitive fields - goes to the log stream. This creates a compliance liability and a security risk. Before centralizing any logs, audit what is actually in them.

Believing that more logging is better. Teams responding to poor observability often add more log statements everywhere, producing high-volume noise that makes the signal harder to find. A production service logging 10,000 lines per second of unstructured prose is harder to debug than one logging 100 lines per second of structured, severity-labeled events. Volume is not visibility.

Treating log files as the archive. Developers who grew up with on-premises servers often treat log files as the permanent record. In containerized, cloud, or auto-scaling environments, log files are destroyed routinely. Any log that is not shipped to a centralized system within seconds of being written should be considered lost.

Not correlating log output to deployment events. At the basic logging level, teams rarely know which deployment caused a change in log patterns. When error rates spike, there is no easy way to answer "did this start after the 2pm deploy?" Tagging logs with deployment version - even as a simple prefix - transforms post-incident investigation from guesswork to fact.

Skipping basic logging entirely and jumping to complex setups. Some teams try to go from no logging to full OTel instrumentation in one step and stall because the scope is too large. Basic logging is a valid intermediate state. Get logs flowing somewhere centralized first, then improve structure incrementally.