Wouldn’t it be great if web apps and websites just worked the way they did in testing and staging? Unfortunately, it seems as soon as you release them into the wild, things start going wrong. When you’re getting calls from users or seeing availability alerts, getting your hands on the right data from your IIS logs can make a big difference in how quickly you respond.
DevOps practitioners and IT pros know the first step is to plan for service issues and enable IIS logging. This helps ensure you have the data you need to troubleshoot IIS issues when they happen.
Let’s walk through enabling IIS logging, and I’ll share some tips on what to look for in your IIS logs when there’s an issue.
How to Enable Logging in IIS
If you’re running Windows Server 2012 or Windows 8, you can enable logging for IIS with the following steps.
Open the Internet Information Services (IIS) Manager and select the website you want to enable logging for in the Connections tree view.
Double-click Logging in the Features View.
Select a log format on the Logging page, accessible in the Log
File section under Format.
Next, decide on a location to store the log file by specifying a path under Directory. By default, log files will be placed in %SystemDrive%\inetpub\logs\LogFiles, but you can customize it to store files wherever you want.
Last, click Apply in the Actions pane.
IIS can write log messages in a variety of formats. The default format is the W3C Extended log format, which allows you to customize the data written to your logs. W3C is also ASCII-based, so it’s easy to send logs and parse messages in SolarWinds® Papertrail™.
If you select the W3C format when enabling logging, you can also pick fields you want logged. For example, for each query to your web server you can record the date and time, client IP address, server IP address, and HTTP status code simply by checking the box next to the fields.
These are the default fields for the W3C format for IIS 10.0:
date — The date on which the activity occurred (YYYY-MM-DD).
s-ip — The IP address of the server on which the log file entry was generated.
cs-method — The action being taken by the client, e.g., GET or POST.
cs-uri-stem — The file being requested.
cs-uri-query — The query, if any, the client was trying to perform. A Universal Resource Identifier (URI) query is only needed for dynamic pages.s-port — The port number being accessed by the client.
cs-username — The name of the authenticated user who accessed the server. Anonymous users are indicated by a hyphen.
c-ip — IP address of the client accessing the web server.
cs(User-Agent) — The browser used by the client to access the web server.
cs(Referer) — The site the user last visited. This site provided a link to the current site.
sc-status — The HTTP status code.
sc-substatus — The substatus error code.
sc-win32-status — The Windows status code.
time-taken — The length of time the action took, in milliseconds.
It’s also a good idea to choose a log file rollover schedule when you enable logging. Log files can grow to be very large, especially for web servers that receive a lot of traffic, so limiting the size of each individual log file makes them more manageable.
You can schedule how often you want a new log file to be created under the Log File Rollover section, where you can pick between Hourly, Daily, Weekly, and Monthly. Alternatively, you can opt to have your log file rolled over once it reaches a certain size.
How to View IIS log Files
Here’s an example of an IIS log entry that recorded a 404 HTTP status code when a user tried to access a non-existent URL: http://localhost/app03/.
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip
cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2020-01-27 11:55:17 ::1 GET /app03/—80—::1
Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko
)+Chrome/62.0.3202.94+Safari/537.36 - 404 0 2 9 The first line displays headers describing the log file format, and the second line contains the log entry.
Even though a number of tools are available for viewing log files locally on your Windows machine, such as Microsoft Log Parser, getting a holistic view of all the web events can be challenging. With Papertrail, the logs from the different web application components and services can be in a single view, and you can search events in context to troubleshoot faster. You can send IIS log files to
Papertrail using third-party tools such as Nxlog or Eventlog-to-Syslog by transmitting the plain-text files to the Papertrail syslog server.
How to Analyze IIS Log Files
Papertrail makes searching and analyzing IIS log files easy. The search syntax is similar to Google and supports boolean operators such as AND, OR, and
NOT. You can combine individual expressions to form more complex queries. For example, this search query will return all HTTP GET requests to web apps located at URIs /app01/ and /app02/:
GET (/app01 OR /app02) Papertrail also supports a negation operator (–) to match log entries that do not contain a string. To find all IIS log messages without 404 HTTP status codes, you can use the following search query:
404 Of course, some issues can only be diagnosed while watching the events unfold in real time. The live tail feature in Papertrail lets you do so and allows you to pause, scroll, and search through log messages in real time. You can also filter incoming logs from the Papertrail event viewer to trim down the size of your logs and focus on the parts that really matter.
Because Papertrail allows you to search across your log data from one place, the log velocity analytics view is a good place to start your troubleshooting. This view shows you event volume over time for your logs. You can spot spikes in events and click on the graph to see messages, source, and other details.
If you plan ahead and set up IIS logging and consolidate your web application logs in Papertrail, you’ll have the tools you need to troubleshoot quickly.