What is an Event Log?

Contents

In computing terms, an event is any significant action or occurrence that’s recognized by a software system. This occurrence could originate from operating systems, networks, servers, firewalls, anti-virus software, database queries, hardware infrastructure, etc. The event is typically recorded in a special file called the event log.

An event log is a chronologically ordered list of the recorded events. Note that “Event Log” is also a core component of Microsoft Windows, but this article covers the generic term used across all operating systems—including Windows.

Event logs contain crucial information that includes:

  • The date and time of the occurrence

  • The actual description of the event

  • The severity of the event

  • The application or process involved

  • Any specific code to identify the event

  • Other relevant information, like IP addresses or user names

Such information is crucial for ITOps, DevOps, and SecOps teams to understand what happened to a system—for example, whether it crashed, malicious activity occurred, or the infrastructure failed. 

In this article, we’ll examine what’s recorded in an event log, why event logs are essential, and when event logs are used.


What Does an Event Log Contain?

In computer systems, an event log captures information about both hardware and software events. These event logs can be part of the operating system or specific to an application.

Operating systems

For example, Windows Event Log entries are generated on any computer running Windows OS. These events are generally classified by one of three categories:

  1. System-related events that capture events from the operating system itself

  2. Application events logged by applications running on the Windows machine

  3. Security events that capture login and logout events 

Similarly in Linux, the Syslog (or rsyslog or journalctl) process records both OS and application-related events. In Red Hat’s Linux distros, the event log is typically the /var/log/messages file.

Applications, servers, and networking

A database event log records information that includes:

  • Access requests

  • Internal messages generated by the database engine

  • User-initiated queries

  • API requests

  • … and so on.

The SQL Server error log (usually named ERRORLOG) is an example of a database event log.

Web servers like Apache or Nginx record their events in access.log and error.log. The access log records web server connections, and the error log contains error messages generated by the software itself.

In the networking realm, a router event log records network traffic events and changes made to router configuration. Meanwhile, a firewall event log records events such as blocked traffic for specific ports.

Cloud services

In the context of cloud services, event logs like AWS CloudTrail, CloudWatch Log, or AWS Config record events sent by different services. Examples of such events can be database events from RDS instances or the output of a serverless function from Lambda.

Common Event Log Fields

An event log is a structured file containing records of event data. Typically, an event log will have a common set of fields for each event. These fields can be:

  • The classification and severity level of the event. Examples include “general information,” “warning,” or “critical error.”

  • The event timestamp

  • The source of the event, such as hardware, software, operating system, application module, library, or remote IP address

  • Optionally, the destination of the event, which can be an application or an IP address, or some other location

  • Optionally, an event number that uniquely identifies the event, such as a web server internal error code

  • The user name, for user-generated actions

  • The actual event description

The purpose of these fields is to provide all relevant information surrounding the event for analysis.

How Are Event Logs Populated?

All operating systems—and most applications—generate their own event logs. In most cases, they will continually write to the same file, starting a new file when a file-size threshold is reached. Logging may be verbose, or it may be concise. How the event log for each application is populated depends on how the application is configured to send its events to the log.

Usually, system administrators set up the event logging configuration for each application they are managing. Configuration parameters can include the name of the log file, the event-related fields to capture, the retention period for the events, the minimum severity level to log, time zone, and so on.

Software developers also use logs to capture event information from the custom applications they are developing. In fact, any custom-written application can send its events to an operating system event log as long as the application can access the log and can call the related API to post the data. For example, in the T-SQL language for Microsoft SQL Server, custom database application events can be sent to the Windows application event log.

Why Are Event Logs so Important?

Event logs are essential for root cause analysis of problems and incidents—whether those problems are due to hardware faults, OS errors, security breaches, application failures, or performance degradation. The most effective way operations teams and engineers can trace the root cause of an issue is by going through the events in the log files that preceded the incident in question.

Troubleshooting can also involve correlating and analyzing multiple event logs. 

By aggregating and correlating data from event logs across different components, a troubleshooter can construct a complete picture of that system. Modern log management depends on the ingestion of multiple event logs to reveal trends, anomalies, and patterns. This approach has become necessary for complex distributed systems, in which an issue can’t always be detectable by analyzing a single log.

This kind of in-depth collation and analysis is a crucial component of system observability, which is the ability to measure a system's current internal state from the data it generates—including event logs.

Conclusion: Introducing Humio

Equipped with this understanding of event logs, the natural next question is: What is the best way to handle them? Even though event logs are straightforward in principle, the sheer amount of data in event logs can quickly add up to terabytes of data within a high-transaction system. This volume is more than even the most experienced system administrators can be expected to analyze.

Enter Humio. Humio allows you to ingest, analyze, and report on issues from the most extensive and detailed collation of event logs. There is no limit to the amount of event log data that Humio can ingest, and it provides intelligent search and analysis capabilities that can surface hidden issues from these logs. The ability to create trends, charts, and dashboards—as well as generate alerts—makes Humio an ideal log management choice for ITOps, DevOps, and SecOps.