Virtually all logs record events. However, the extent to which event log data is useful depends mainly on configuring the settings for log events. The same type of log could yield vastly different information based on settings like verbosity level, log retention periods, log storage configurations, and more.

With that reality in mind, let's walk through five common event log settings and discuss strategies for configuring them in ways that maximize visibility. The points below generally apply to event logs of all types – such as logs generated by Windows's event logging service, Web server logs that record operational events, application logs that register transaction events, etc.

Log Verbosity

One of the most basic settings to get right about event logs is log verbosity. Verbosity determines the number of events that logs record and the details about each event. Verbosity levels that are too high may result in more information than you need and more data than you can reasonably manage. However, if they're too low, you may not have all the necessary information to troubleshoot an issue or identify relevant trends.

There's no universally right or wrong verbosity level for all types of event logs. The correct setting for you depends on:

• How vital the log data is to your operations. Suppose it's a log for a mission-critical application or service. In that case, you'll generally want to be more verbose than you would when configuring log settings for a test/dev environment.
• How many logs are available to you. Although logging automation makes it possible to collect and analyze large volumes of event logs, you should still consider how much log data you can effectively manage based on your logging tools.
• Which types of data your resource will log at different verbosity levels. Each resource's verbosity needs will vary depending on how developers designed them. A web server, for example, may record more detail than an operating system, even if verbosity levels are the same.

So, rather than sticking with the default settings, evaluate your specific log verbosity levels and configure them accordingly. Don't be afraid to experiment with different settings to find the right one.

Format Settings

You can choose from different format settings for event logs in some cases. For instance, with Microsoft IIS, you can choose between a native IIS log format, W3C format, NCSA format, or a custom format.

Again, there is no universally right or wrong format. Generally, it's a best practice to format as many of your logs as possible in the same way. Although you can continually transform log data after collecting it to make it more consistent, choosing the same log format settings from the start allows you to skip this step.

Time Server Configuration

Most event log frameworks let you configure how to register timestamped data within the logs. You can, for example, use the host server's local time or configure timestamps based on a standard like Coordinated Universal Time (UTC).

Unless you are working with just a few log files generated by systems operating in the same time zone, it's best to set timestamps based on universal standards. You can compare events consistently across all your logs without translating between different time zones. Universal time standards also help mitigate the risk that local time systems could go out of sync, leading to difficulties in comparing log events.

Log Rotation Settings

Log rotation settings determine how long logs are stored before the system deletes them. You should base your selection for this setting on the following criteria:

• Compliance: Whether you are subject to any compliance or governance mandates that require logs to stick around for a particular period.
• Availability and Cost: How much log storage you have available, and how expensive that storage is.
• Security Risk: The extent to which you can keep log data secure while it is in storage.
• Reuse Likelihood: How likely you are to refer to historical log data in the future.

Thus, like most settings, rotation settings for event logs should be tailored to your organization's unique needs.

Log Storage Settings

You can configure settings on where you store event log data by default in many instances. You can typically choose to keep logs in a local file system, for example, or in the cloud or network storage.

The correct setting depends on how much you want to centralize log storage by default and how reliable and secure your various log storage options are. In general, storing logs in centralized storage will simplify log collection and make it more dependable because centralized storage is typically less likely to fail or be breached than are the local file systems of individual servers. Choosing centralized or remote log storage may also be more expensive or difficult to administer.

Keep in mind that you can always use tools like Mezmo to aggregate and centralize logs from multiple sources, no matter where you store the log data by default. From that perspective, the default storage settings you choose are not very important as long as you have a log aggregation tool.

Conclusion

As with most configuration options, your mileage will vary when choosing the suitable event log settings. What matters most is systematically evaluating your needs concerning settings like log verbosity level, log formatting, and log storage settings, then configuring your logs accordingly. Don't settle for the default settings, which are rarely ideal.

‍