When a web application displays a blank page or a server refuses a connection, the first thing an administrator does is open a file. This file is a log. It contains a timestamped record of every event that occurred on the system: a request received, an error triggered, a user authenticated. Understanding logs in computing provides a thread to trace back to the origin of a problem, verify that a service is functioning, or detect abnormal behavior.
What a log really contains and why the format changes everything
A log is an event record. Each line associates at least a date, a source, and a message. On a web server, for example, each visit generates a line that specifies the visitor’s IP address, the requested page, the HTTP response code, and the processing time.
Have you ever opened a text file filled with incomprehensible lines? That’s often an unstructured log. The message is written in free text, without a fixed format. Each application writes in its own way, making the search tedious as soon as multiple services coexist.
In contrast, a structured log in JSON organizes each field in a machine-readable way. The date, severity level, affected service, and message each occupy a dedicated field. The benefit is direct: an analysis tool can filter, sort, and cross-reference thousands of events in seconds instead of searching for patterns in plain text.
To learn everything about logs in computing, the distinction between structured and unstructured format is the first concept to master, as it conditions the next steps: collection, storage, analysis.
Log severity levels: reading the right signal at the right time
Not all recorded events have the same severity. Logging frameworks use a severity scale that allows filtering of what requires immediate attention.
- DEBUG: fine details used during development, disabled in production to avoid excessive volume.
- INFO: normal events that confirm proper functioning (service startup, successful login).
- WARN: unusual situation that does not prevent operation but signals a risk (low disk space, high latency).
- ERROR: a process has failed, a user action did not succeed. Intervention is often necessary.
- FATAL: the service stops. The entire application or server is offline.
The frequent temptation is to set everything to DEBUG to “miss nothing.” The result: files that grow by several gigabytes per day, skyrocketing storage costs, and constant noise that drown out real alerts. Choosing the right severity level reduces volume without losing useful information.
Sensitive data in logs: what should never be recorded
A log can capture almost everything that transits through an application. That’s precisely the problem. OWASP recommends excluding passwords, access tokens, session identifiers, encryption keys, and sensitive personal data from logs.
Why this caution? Because the logs themselves can become a source of data leaks. A log file stored without access restrictions exposes information that can be exploited by an attacker. When monitoring is necessary, the best practice is to mask or pseudonymize sensitive values before writing to the log.
The CNIL provides a guideline for user access and action traces: retention of six months to one year depending on the purpose. Beyond that, the collected content must remain proportionate to the actual need. Retaining complete requests for several years without defined justification exposes one to both legal and technical risks.
Protecting the integrity of logs
A modified or deleted log loses all evidential value. OWASP recommends integrity checks, restricted and monitored access, as well as safeguarding log data. A log useful for an investigation must also be trustworthy. An attacker accessing a server will often attempt to erase their traces in the logs before taking any other action.
European regulation and logging: concrete obligations
Logging is no longer just a good technical practice. The European Cyber Resilience Act includes logging security events among the requirements applicable to digital products. The NIS 2 directive, on the other hand, requires affected entities to establish incident detection and response capabilities, which implies a functional and usable logging system.
Without reliable logging, compliance with NIS 2 or CRA becomes impossible to demonstrate. These texts do not detail which tool to use, but they require the ability to trace, detect, and respond. Logs are the technical foundation of this capability.
Best practices for daily log management
Setting up logs is not enough. Their usefulness depends on how they are collected, centralized, and utilized.
- Centralizing logs from all services on a single platform avoids manual searching on each server. A collector retrieves events and sends them to a common analysis point.
- Defining a retention policy suitable for each type of log. User access traces do not have the same useful retention duration as application diagnostic logs.
- Setting up alerts for ERROR and FATAL levels to react before users report the problem.
- Regularly reviewing what is recorded. A field added during rapid development may contain personal data without anyone having anticipated it.
The value of a logging system is measured by the speed of incident resolution. A well-structured, centralized log that is purged according to clear rules transforms a multi-hour outage into a diagnosis of just a few minutes. This is what separates a team that suffers incidents from a team that anticipates them.
