VMware ESXi and vSphere Cluster Management

Understanding and Using Error Logs

Learn what error logs contain, where to find them, how to interpret common failures, and how to troubleshoot applications, web servers, databases, and systems safely.

An error log is a record of failures and diagnostic messages generated by software or infrastructure. It may contain warnings, exceptions, startup failures, permission problems, connection errors, and resource-limit events. Reading the right log at the right time is one of the most reliable ways to diagnose technical problems.

This lesson covers application, web-server, database, operating-system, container, and browser-side logs. It also explains how to interpret entries, investigate recurring failures, protect sensitive information, and manage log storage.

What an Error Log Is

An error log is a chronological collection of diagnostic events. Each individual record is called a log entry. Entries commonly describe warnings, failures, exceptions, rejected operations, or conditions that may cause a later failure.

An exception is a runtime condition that interrupts normal application flow. A stack trace is the sequence of function or method calls that shows where an exception occurred. An error code is a standardized or software-specific identifier for a failure.

Error logs help with:

• Incident investigation: determining what happened during an outage or failed request.
• Root-cause analysis: finding the underlying condition that produced the observed failure.
• Recurring-problem detection: identifying patterns such as repeated timeouts, memory exhaustion, or unauthorized requests.
• Verification: confirming whether a corrective change stopped new errors.

Error Logs Compared with Other Logs

These categories can overlap. For example, an application may write access, audit, and error events to one structured logging system. The important distinction is the purpose of each event, not only the filename.

Where Error Logs Come From

• Operating systems and services: Kernels, authentication services, schedulers, web servers, queues, and background workers write system or service events.
• Web servers: Apache HTTP Server and Nginx record configuration failures, upstream failures, permission problems, and request-processing errors.
• Application runtimes: PHP, Python, Java, Node.js, and other runtimes report exceptions, warnings, missing modules, failed imports, and startup problems.
• Database servers: Database logs contain connection failures, authentication errors, query errors, schema problems, deadlocks, replication issues, and capacity warnings.
• Containers: Applications often write to standard error, called stderr, which the container runtime collects. Container platforms may provide commands or dashboards for viewing those streams.
• Cloud and managed platforms: Provider dashboards may expose application logs, platform events, load-balancer errors, function logs, and database logs.
• Browsers and clients: Browser developer tools can show JavaScript exceptions, failed network requests, certificate errors, and blocked resources. These are useful when the server appears healthy but the user interface fails.

Understanding a Log Entry

Formats differ between products. A plain-text entry, JSON event, and system journal record may present the same information differently. Look for these fields:

A request ID identifies one request. A correlation ID is a shared identifier used to link related events across services. Process IDs, thread IDs, user IDs, timestamps, and hostnames provide additional ways to connect entries.

Example Entry

2026-08-25T10:14:32Z ERROR checkout-worker request_id=7f31 user=42 payment.py:118 - KeyError: currency
Traceback: validate_order - charge_card - payment.py:118

This entry says that the checkout worker recorded an error at a known time, during a request associated with user 42. The failure occurred at line 118 in payment.py, and the stack trace identifies the call path. The request ID can be searched in the web-server and database logs.

Log Levels and Severity

A log level is a severity classification assigned to a message. Names and exact meanings vary by software, so always consult the product's documentation. A warning in one system may be treated as an error in another.

Finding the Correct Error Log

Log locations are configurable and platform-specific. Do not assume that a default path is the active path. A service can write to a file, the system journal, standard error, a container collector, or a centralized logging platform.

Useful Linux Commands

tail -n 100 /path/to/error.log

Displays the most recent 100 lines. Use the actual configured path.

tail -f /path/to/error.log

Follows new entries as they are written. Use it during a controlled reproduction, then stop it with Ctrl+C.

grep -i "error" /path/to/error.log
grep -iE "fatal|exception|denied|timeout" /path/to/error.log

Search for likely terms. Narrow the search further with a timestamp, request ID, filename, or error code whenever possible.

journalctl -u service-name --since "2026-08-25 10:00:00"
journalctl -u service-name -f

Reads systemd-managed service events for a time range or follows new events. Replace service-name with the actual unit.

Representative Logging Configuration

ErrorLog /var/log/apache2/error.log
LogLevel warn

error_log /var/log/nginx/error.log warn;

log_errors = On
error_log = /path/to/php-error.log
display_errors = Off

These are representative settings, not universal paths. Validate configuration before restarting a production service, and ensure the service account can write to the selected destination.

How to Read and Interpret Errors

1. Start with the symptom time. Record when the user saw the failure, including timezone. Allow for clock differences between hosts.
2. Find the relevant request or event. Search the web-server, application, and system logs around that time.
3. Look for the first relevant error. The last message may be a consequence of an earlier failure. For example, a web server may report an upstream timeout after the application crashed.
4. Read surrounding entries. A few entries before and after the main message can reveal configuration loading, authentication, dependency, or retry context.
5. Trace dependent failures. Connect application errors to database, cache, queue, DNS, TLS, or operating-system events.
6. Separate symptom from cause. An HTTP 500 response is a symptom; the underlying cause may be a missing dependency, invalid configuration, or database failure.
7. Use identifiers to join logs. Search for request IDs, correlation IDs, process IDs, user IDs, hostnames, and exact timestamps across services.

Example: A Generic HTTP 500 Error

A browser displaying an HTTP 500 status does not identify the root cause. First match the request time in the web-server access and error logs. Then search the application log for the same request ID or time window. The earliest relevant entry might show a fatal application error, an unhandled exception, a configuration parse error, or an upstream-service failure. Follow the stack trace to its source file and line, inspect the named dependency or setting, correct the cause, and repeat the request.

Common Error Categories

Safe Troubleshooting Workflow

1. Reproduce or identify the event. Record the affected URL, operation, user impact, host, and precise time.
2. Collect a relevant window. Gather only the needed lines before and after the event, plus related service logs. Preserve the original evidence.
3. Form a hypothesis from evidence. For example, a permission-denied entry naming an application file suggests checking the service account and that file's access path.
4. Check the likely cause. Inspect configuration, permissions, dependencies, connectivity, service status, and resource state.
5. Apply one minimal change. Avoid changing several settings at once; otherwise you cannot determine which change mattered.
6. Retest and verify. Repeat the affected operation and confirm both that it works and that new related errors are absent.
7. Document the result. Record the root cause, evidence, corrective action, rollback method, and prevention step.

Deleting a log does not fix the problem. It removes evidence and may hide a storage-management issue. If storage is critically low, preserve the relevant evidence first and follow the retention or incident procedure before removing anything.

Scenario: The Web Server Cannot Read an Application File

An error such as permission denied names the file the web server could not access. Compare that path with the file's ownership and permissions, identify the web-server service account, and check directory access at every level of the path. Make the least disruptive correction, such as adjusting deployment ownership or a narrowly scoped permission, then repeat the request and verify that no new access errors appear.

Scenario: A Database-Backed Application Fails Intermittently

Search application logs for connection timeouts, connection-refused messages, pool exhaustion, or query failures. Correlate those timestamps with database logs and service-availability metrics. Check database health, network reachability, connection limits, and pool configuration. Increasing timeouts alone may conceal capacity or availability problems rather than solve them.

Scenario: A Service Will Not Start After a Configuration Change

Read the startup failure from the service log or journal. Common clues include a syntax error, unknown directive, missing certificate, address already in use, or permission denied. Use the service's configuration-validation command when available, correct the named issue, and only then restart. Confirm that the service is active and that dependent requests succeed.

Scenario: Errors Occur Only Under Load

Compare error timestamps with traffic and resource metrics. Look for out-of-memory events, too many open files, worker exhaustion, connection-pool exhaustion, and timeouts. Check process, memory, file-descriptor, connection, and CPU limits. Address the capacity limit or inefficient workload instead of only increasing timeout values.

Scenario: The Log File Cannot Be Written

Typical messages are no space left on device, permission denied, and read-only file system. Check storage capacity and inode availability, verify directory ownership and service-account write access, and inspect log rotation. Also investigate filesystem health before restarting repeatedly.

Log Rotation, Retention, and Centralization

Log rotation is the process of closing, renaming, compressing, removing, and replacing log files on a schedule or when they reach a size threshold. Rotation prevents one file from growing indefinitely.

df -h
du -sh /var/log/*

df -h shows filesystem capacity. du -sh /var/log/* helps identify large entries under a log directory. Investigate before deleting files, preserve evidence, and follow the retention policy.

• Choose retention periods based on operational, legal, and security requirements.
• Compress older logs to reduce storage use.
• Ensure rotation also works for applications that keep file handles open.
• Monitor disk space and inode usage so logging does not consume the entire filesystem.
• Use centralized logging when multiple hosts or services must be searched together.
• Make temporary increases in debug or verbose logging only for a controlled investigation, then reduce the level afterward.

Centralized log aggregation makes correlation, searching, retention, and alerting easier. It also creates another security boundary, so protect transport, storage, access permissions, and deletion controls.

Security and Privacy

Logs may contain usernames, IP addresses, filesystem paths, request parameters, query data, tokens, session identifiers, email addresses, and detailed internal errors. Treat them as potentially sensitive operational data.

• Restrict log access to people and services that need it.
• Redact credentials, access tokens, session identifiers, and unnecessary personal data.
• Do not publish raw production logs in public posts or broadly visible tickets.
• Share the smallest useful time window and remove unrelated records.
• Use encrypted transport and suitable access controls for centralized logs.
• Disable detailed error display to visitors in production while keeping secure server-side logging enabled.

For example, PHP production settings commonly use log_errors = On and display_errors = Off. Detailed stack traces should go to a protected log destination, not to the browser.

Exam-Relevant Notes

• A log entry's timestamp is meaningful only when its timezone and clock accuracy are understood.
• The last error is not necessarily the root cause; find the first relevant failure and inspect preceding context.
• Access logs describe requests, while error logs describe failures and diagnostic conditions.
• Log levels vary by software; use severity to prioritize, not as an absolute universal definition.
• Always verify the configured log destination instead of relying only on common default paths.
• Request IDs and correlation IDs connect events across web servers, applications, databases, and other services.
• Log rotation controls storage growth; deleting logs is not a troubleshooting fix.
• Production systems should log diagnostic details securely without displaying them to end users.

Summary

Error logs provide chronological evidence about warnings, failures, exceptions, and infrastructure conditions. Effective troubleshooting starts by matching a symptom to its time, locating the configured logs, reading surrounding context, and following identifiers across services. Classify the error, test a focused hypothesis, make one minimal change, retest, and document the result. Good retention, rotation, centralized search, and privacy controls make logs useful without allowing them to become a storage or security problem.

Continue with Error Log for this topic's reference path.