If you administer web servers—or any kind of Windows server, really—there is a good chance that you work at least occasionally with IIS logs. IIS logs store data from Internet Information Services (IIS), Microsoft’s website and web application hosting product.
Whether you are a seasoned IIS administrator, or just need to learn to work occasionally with IIS logs, the tips below can help you work more effectively with IIS logs.
How to access IIS Manager
Let’s start by going over the basics of accessing IIS logs using IIS Manager.
There are a few ways to locate the IIS log files in Windows Server 2012. Open the Server Manager and click IIS in the side menu located on the left side of the screen. Right-click the server that is installed under IIS, and on the menu that is displayed, click Internet Information Services (IIS) Manager.
A very important observation—The system administrator can change the directory where the log is saved. For this reason, if you are working on a new machine or configuring IIS logging for the first time, it is good to make sure the chosen path has enough space for log storage. To choose where to save the log, click “Browse …” in the Log File > Directory option. Also choose the “Site” option “One log file per”—This will generate a log file for each site hosted in IIS.
IIS Log File Formats
It’s also important to understand the different types of logging file formats available for IIS logs.
The logs have the following formats:
By default, W3C is used but can be modified. The W3C format is an extended log file and contains ASCII characters with sequences ending in LF or CRLF, and log parsers must know how to work with it. The input sequences are related to an HTTP transaction. The file contains lines with guidelines beginning with the # character. The main guidelines are:
| Version: <integer>.<integer> | The version of the extended log file format used. This draft defines version 1.0. |
| Fields: [<specifier>…] | Specifies the fields recorded in the log. |
| Software: string | Identifies the software which generated the log. |
| Start-Date: <date> <time> | The date and time at which the log was started. |
| End-Date:<date> <time> | The date and time at which the log was finished. |
| Date:<date> <time> | The date and time at which the entry was added. |
| Remark: <text> | Comment information. Data recorded in this field should be ignored by analysis tools. |
Here is a sample log format:
#Software: Internet Information Services 6.0
#Version: 1.0
#Date: 2017-05-02 17:42:15
#Fields: time c-ip cs-method cs-uri-stem sc-status cs-version
17:42:15 172.16.255.255 GET /default.html 200 HTTP/1.0
The IIS log file is also a fixed ASCII format that logs more information than other file formats. It includes basic items such as IP and username, request date and time, service status and number of bytes received, as well as detailed items of target files. This file format is separated by commas, making it easier to read while others use blanks.
An example of this format is:
192.168.114.201, -, 03/20/17, 7:55:20, W3SVC2, SALES1, 172.21.13.45, 4502, 163, 3223, 200, 0, GET, /logo.png, -, 172.16.255.255, anonymous, 03/20/01, 23:58:11, MSFTPSVC, SALES1, 172.16.255.255, 60, 275, 0, 0, 0, PASS, /intro.html, -,
The NCSA file format is also a common fixed ASCII format, available for web sites, but does not meet FTP. It stores basic information such as IIS and W3C and uses space as a separation of items.
NCSA example:
172.21.13.45 – Microsoftfred [08/Apr/2017:17:39:04 -0800] “GET /scripts/iisadmin/ism.dll?http/serv HTTP/1.0” 200 3401
Looking at the examples of log output, W3C is the better choice because it seems more complete, organized, and easy to see and understand.
Tools for Viewing IIS Logs
In my IT studies trajectory, some teachers have always stressed that a good IT professional should learn to read logs because logs help in understanding and solving problems.
This may seem like a simple thing (that many disregards), but if well used, it can save your day. It is important to be aware, to be judgmental, to separate the crucial data, and know how to read what the data offers. Many IT professionals get into big problems when they do not notice the indicators. To greatly reduce and avoid problems, we need to know how to extract this data, read it, and store it for future use.
The problem that many administrators face is how to optimize the reading of these log files. This issue can be remedied by tools that read logs by assembling information into aggregated views that make reading easier.
One such tool that improves the visualization of logs is Sumo Logic for IIS. It takes the logs to your storage location and interprets the data by displaying it in dashboards with full, customizable graphics that provide a quick understanding of the saved results.
With tools like this, it is possible to separate data and make it work for what you need. This is what makes data collection worth the time and effort.
Conclusion
To work with IIS logs, or any type of log file effectively, you need to analyze and track the logs constantly. It’s also important to adapt your monitoring strategy to your particular needs and priorities. This is not an easy task, but with the right toolset, you can do it.
Sumo Logic, a machine data analytics platform, can be used for aggregating, visualizing and alerting on logs. Sumo Logic should be part of the Swiss army knife for systems administrators—making it possible to predict and measure application usage information and application errors.
