Pricing Login
Interactive demos

Click through interactive platform demos now.

Live demo, real expert

Schedule a platform demo with a Sumo Logic expert.

Start free trial
Back to blog results

August 20, 2019 By Vince Power

Know Your Logs: IIS vs. Apache vs. NGINX Logs

Today’s web server ecosystem has three big players: IIS, Apache and NGINX. Although only two of them (Apache and, to a lesser extent, NGINX) are cross-platform, it’s increasingly important to be able to work with all three of these servers, because you never know which type of operating system and web server platform you’ll be asked to support.

That’s why understanding the nuances of IIS, Apache and NGINX logs is important. In a perfect world, all of these servers would have identical log formats and log data, but in reality they don’t.

This article explains the differences between IIS, Apache and NGINX logs, and the key information that DevOps engineers need to know in order to work with each server’s logs.

A Brief History of IIS, Apache and NGINX, and Their Logs

The IIS vs. Apache debate has been ongoing for two decades. At first, people were firmly on one side, and that side was often dictated by whether your company was exclusively Windows or had UNIX/Linux systems available. These systems had nothing in common, except that they could serve websites. Log files were as different as the operating systems they ran on. As time progressed, and we moved into the 2000s and virtualization and Linux came closer to the mainstream, organizations commonly had both Apache HTTP and IIS installations.

In the same time period, NGINX became a direct competitor to Apache HTTP. NGINX was designed to outperform Apache HTTP but also took advantage of the ecosystem built up around Apache by using its log formats to make it easier for administrators to transition from Apache to NGINX, as they could reuse existing log management solutions.

Where Are My Apache, NGINX or IIS Logs?


In IIS, log files changed default locations in version 7, which was released with Windows 2008 and Vista. In IIS 6 and before, logs were under %SystemRoot%\System32\LogFiles. With IIS 7, they moved to %SystemDrive%\inetpub\logs\LogFiles.

Within the LogFiles directory, there will be a folder created for every website or application that is set up with the Internet Information Services (IIS) Manager administration console.

The default server log folder is W3SVC1; additional folders will replace the “1” with a longer random number. By default, a new access log file is created every day with the naming syntax of “formatDDMMYY.log” where the format is NCSA, Extended, or IIS. Within the LogFiles directory, there will be a folder created for every website or application that is set up with the Internet Information Services (IIS) Manager administration console.

Here is an example showing one website and a log folder and file:

Apache HTTP

Apache HTTP logs will most commonly be found under /var/log on UNIX and Linux-based servers, especially when installed from a package. On Windows and if you compile from source, it will be under the same root directory as the configuration and binaries.

* The default file names are access_log and error_log; exceptions are noted.

When using a packaged version of Apache HTTP from most distributions, the files will be located under /var/log/httpd.If you compile from source using the default settings, then the log files will be under $PREFIX/logs. $PREFIX can be set during the compile, with the default location as /usr/local/apache2.


NGINX is much more consistent than Apache, with packages across all distributions using the same base directory of /var/log/nginx and the file names of error.log and access.log.

If compiling from source or running on Windows, then the default location is a logs directory under the base installation directory with access_log and error_log as the file names.

IIS Access Logging

As mentioned earlier, IIS has multiple formats it can save its log files in. One method is to write out a binary format which can also be written to a database, but that adds a layer of complexity to the logging infrastructure, which isn’t ideal.

Focusing on the text based-formats leaves three options: W3C Extended, IIS, and NCSA Common.

W3C Extended format really only works on a time-based file rotation, like the default of Daily as it only has the time of day, not the date.

IIS format has the most information of the three formats, and supports multiple types of file rotations like time-based or size-based.

NCSA Common is the format used by Apache HTTP, NGINX, and a few other web servers. It has a syntax that is a good balance of data compared to the other two text options.


Apache vs. NGINX Access Logging

Apache and NGINX both use NCSA Common-formatted access logging by default.

Both Apache and NGINX have the ability to customize the data in the access logs by including more or less information as required. There is a second format that is commonly used, called Combined.

Combined is based on NCSA Common with an additional two data fields added, called HTTP_Referer and User_Agent. These two fields are invaluable when using the logs as the basis for web analytics and other marketing activities like campaign tracking. Most organizations no longer use this combined format, as they have migrated to more robust JavaScript-based tracking solutions (ex: Google Analytics) for their marketing activities.

Error Logs

Error logging in the world of IIS vs. NGINX vs. Apache is much more straightforward, with the format of Date, Time, Error Code (if available), and then the output of stderr. An error can span multiple lines in a file, so it helps to have a proper log aggregation engine (ex: Sumo Logic) which understands and can process the logs properly.


IIS, Apache and NGINX logs are different in many ways. Fortunately, by leveraging modern log consolidation services like Sumo Logic, it is easy to gain a unified view across all of these platforms for both activity tracking and problem resolution. In addition, by being able to configure IIS to use NCSA formatting for access logs, searching these centralized log repositories and mining for specific data becomes both possible and routine with log consolidation tools.

Complete visibility for DevSecOps

Reduce downtime and move from reactive to proactive monitoring.

Sumo Logic cloud-native SaaS analytics

Build, run, and secure modern applications and cloud infrastructures.

Start free trial
Vince Power

Vince Power

Vince Power is a Solution Architect who has a focus on cloud adoption and technology implementations using open source-based technologies. He has extensive experience with core computing and networking (IaaS), identity and access management (IAM), application platforms (PaaS), and continuous delivery.

More posts by Vince Power.

People who read this also enjoyed