18.7 Logs

Understanding Logs in Network Troubleshooting

Logs are written records of events that happen on devices and systems over time. In networking, they are one of the most powerful tools for understanding what really happened before, during, and after a problem.

This chapter focuses on how logs fit into monitoring and troubleshooting, what kinds of logs exist in networks, and how to read and use them effectively without going into detailed packet analysis, which will be covered separately.

Why Logs Matter in Networking

When something breaks on a network, it is easy to see the symptoms, such as users complaining that a service is down. Logs give you the story behind those symptoms. Devices and applications write events to logs every time something important happens, like a link going down, a user logging in, or a firewall blocking a connection.

Logs are useful in several situations. You can use them for real time troubleshooting, for example when a link is flapping and you want to confirm exactly when it happens. You can use them for historical analysis, for example when a user says, “The VPN did not work yesterday at 8 pm,” and you need to see what occurred at that time. Logs are also critical for security investigations. If there is a suspected attack, the logs can show failed login attempts, unusual traffic patterns, or configuration changes.

Common Sources of Logs in Networks

Many different devices and systems produce logs. Each one sees a different part of the network.

Network devices such as routers, switches, firewalls, and wireless controllers log events like interface status changes, routing updates, STP events, access control decisions, and authentication results. Servers and operating systems write system logs that record boot events, service starts and stops, resource problems like low memory, and security events like logins or permission failures. Network services such as DNS servers, DHCP servers, and web servers keep their own logs that show queries, leases, HTTP requests, and errors.

Security devices and security software also create logs. Firewalls, IDS and IPS systems, VPN concentrators, and endpoint security agents log alerts, blocked traffic, tunnel establishment, and suspicious behavior. In addition, many applications have their own application logs that focus on application level events, such as errors when talking to a database or when responding to user requests.

All of these log sources together form a picture of what is happening in the network, seen from different angles.

Local Logs vs Centralized Logging

Logs can be stored on the device where the event occurs or sent to a central system.

Local logs are kept on the device itself. For example, a router may write to its internal buffer or to files in its own storage. Local logs are simple and do not require extra infrastructure. However, they can be lost if the device reboots or the storage fills up. It is also time consuming to log in to many devices, especially in a large network.

Centralized logging collects logs from many devices into one place, often called a log server or log collector. This is usually done using syslog or another logging protocol. With centralized logging, you can search across multiple devices, correlate events, and keep logs for longer periods on larger storage systems. It also helps with security because logs from compromised devices are preserved elsewhere.

In practice, most production environments use both. Devices keep some local logs for quick checks, and also send important events to a centralized logging system.

Log Levels and Severity

Not all log messages are equally important. Devices and systems usually label each log entry with a severity level. The exact names can differ, but they typically indicate whether something is informational, a warning, or an error.

A common style is to have a scale where lower numbers mean more critical events. For instance, on many systems, level 0 is an emergency, level 1 is an alert, level 2 is critical, level 3 is an error, level 4 is a warning, level 5 is notice, level 6 is informational, and level 7 is debug. The exact names are less important than the idea that you can filter logs by importance.

Here is an example of a syslog-style mapping:

You can configure devices to send only certain severities to the central log server. For example, you might keep all levels locally, but only send warning and higher centrally to reduce noise.

Basic Structure of a Log Entry

Although formats differ, most log entries contain similar fields. Understanding these fields is essential to interpret logs correctly.

Typically, you will find a timestamp that tells you when the event happened, ideally including date, time, and time zone. There is often a hostname or device name that shows which device created the log. Many logs include a process name or component identifier, so you know which part of the system produced the message, such as “kernel,” “bgp,” or “httpd.” The severity level is often shown as a number or name. Finally, there is a message text that describes what happened, sometimes followed by codes or parameters.

An abstract example might look like this in a single line:

2026-07-02T10:14:23Z router1 bgp[1234]: WARNING: Neighbor 10.0.0.2 went down

From left to right, this contains the timestamp, device name, component, severity indication, and a human readable description. Some systems add more fields, such as a unique ID, a correlation ID, or structured key-value pairs.

When analyzing logs, you usually care most about the time, the device, and the message content, but all fields can be useful, especially when you are correlating multiple devices.

Time Synchronization and Its Importance

Since logs rely heavily on timestamps, accurate and consistent time is essential. If two devices disagree by several minutes, it becomes very difficult to line up events.

For example, if a firewall log shows a connection denied at 10:01, but the server behind it logs an error at what it thinks is 9:59, you may mistakenly conclude that the events are unrelated. When hundreds of devices are involved, even a small time drift complicates investigations.

To avoid this, networks commonly use time synchronization services. These services keep each device’s clock aligned, so that log timestamps can be reliably compared. Time accuracy is particularly important in security contexts, where you might need to reconstruct the exact sequence of events.

Reading Logs for Troubleshooting

When you troubleshoot a problem, raw logs can be overwhelming. Developing a systematic approach helps.

First, define the time window. Identify when the problem happened, then look at logs in a window starting slightly before the first symptom and ending after the last one. Next, filter on relevant devices and severities. For example, if a user cannot reach a web application, you might check the firewall, the web server, and any reverse proxy in front of it, focusing on errors and warnings.

After that, look for clear errors or repeated patterns. Interface flapping on a switch might show “link down” and “link up” messages alternating every few seconds. Authentication failures on a VPN gateway might show repeated “login failed” entries with the same username or source IP.

It is often helpful to follow the path of a connection in the logs. You may see the initial connection accepted by a firewall, then a corresponding access log on the server, and perhaps an error message on the application side. Together, these logs show where in the chain something went wrong.

Common Types of Network Log Messages

Network focused logs often fall into several recurring categories.

Interface logs show changes in physical or logical interface status, such as “interface up” or “interface down.” They can indicate cable problems, hardware issues, or intentional actions like an admin shutting an interface.

Routing logs record events like routes being added or removed, routing neighbors going up or down, or protocol specific state changes. These logs are useful when parts of the network become unreachable.

Security and firewall logs record allowed and denied connections, as well as more advanced security events. Deny logs typically include source and destination IP addresses, ports, and rules that triggered the block.

Authentication and authorization logs show successful and failed logins, privilege escalations, and changes to user roles. These are important both for operational troubleshooting and security audits.

Service logs for DNS, DHCP, VPN, and other services indicate normal operations like assignments and responses, as well as failures and misconfigurations that can break connectivity even if the underlying network is fine.

Log Retention and Storage Considerations

Logs can grow very quickly. How long you keep logs is called log retention. Longer retention helps with long term analysis and investigations of problems that are reported late, but it also requires more storage and careful management.

Some environments must follow regulations that dictate minimum log retention periods, especially for security related events. Others choose retention strategies based on business needs and storage costs. Log rotation is a common technique in which old log files are archived or deleted when they reach a certain size or age, and new files are started. Central log servers often compress old logs to save space.

The key point is to balance usefulness and practicality. Keeping every debug level log forever is unnecessary and risky. Keeping no logs or only a few hours of logs makes serious troubleshooting almost impossible.

Log Filtering, Searching, and Correlation

Modern networks produce far more logs than a person can read line by line. The ability to filter, search, and correlate logs is essential.

Filtering lets you narrow logs to relevant data, such as only error level messages, only messages containing a certain IP address, or only logs from a specific device. Searching allows you to quickly find log lines that mention a keyword, an error code, or a user name. Correlation links events across multiple devices, for example all logs that involve a specific transaction ID, or all devices that reported issues around a certain time.

Centralized log systems and specialized tools often provide dashboards, queries, and visualizations that help you spot patterns and anomalies. For basic troubleshooting, even simple text search tools can be powerful when used with a clear idea of what you are looking for.

Logs and Security Monitoring

Although this chapter focuses on troubleshooting, logs are also a foundation for security monitoring. Security teams rely on detailed logging to detect attacks, investigate incidents, and provide evidence.

Security monitoring tools ingest logs in real time, look for suspicious patterns like repeated failed logins or unusual traffic, and generate alerts. Without good log coverage and proper configuration, many attacks would leave little trace. Some security techniques and tools analyze logs specifically to spot anomalies and correlate events across many systems.

In practice, operational troubleshooting and security monitoring share the same raw data: the logs. The difference is mainly in how the logs are analyzed and for what purpose.

Best Practices for Working with Logs

For beginners, it is useful to develop some simple habits when working with logs.

Always check the time and time zone of logs before drawing conclusions. Work within a defined time window around the incident. Use filters to reduce noise and focus on relevant devices, users, or IP addresses. Look for repeating patterns and not only for single errors. Finally, whenever you find a log message that seems important, try to understand what it really means, perhaps by checking documentation or vendor references, instead of guessing.

Over time, you will begin to recognize common messages and know what they usually indicate, which makes you much faster and more accurate when diagnosing network problems.