IIS Log File Formats
IIS comes with COM logging modules that log site activity in different formats. The W3C Extended log file format, IIS log file format, and NCSA Common log file format are all ASCII text formats (unless UTF-8 is enabled for your Web sites). The W3C Extended and NCSA Common formats record logging data in four-digit year format. The IIS format uses a two-digit year format for years 1999 and earlier, and a four-digit format thereafter. For NCSA and IIS log file format , the data logged for each request is fixed. However, W3C Extended allows you to choose the properties you want to log for each request.
Different log formats use different time zones for the basis of times listed in the logs. W3C Extended format uses Coordinated Universal Time (UTC), basically the same as Greenwich Mean Time (GMT). The other formats use local time. The times listed in log files reflect the time the server uses to process requests and responses, but do not reflect network travel time to the client or client processing time.
When Secure Sockets Layer (SSL) is enabled and when logging bytes are exchanged between the server and the client computer, IIS 6.0 logs the number of decrypted bytes. IIS 5.1, however, logged the number of encrypted bytes.
For all log formats except ODBC logging, Time Taken is logged, in milliseconds.
W3C Extended format is a customizable ASCII format with a variety of different properties. You can log properties important to you, while limiting log size by omitting unwanted property fields. Properties are separated by spaces. Time is recorded as UTC.
The following example shows lines from a file using the following properties: time, client IP address, method, URI stem, protocol status, and protocol version.
#Software: Internet Information Services 6.0 #Version: 1.0 #Date: 2001-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.htm 200 HTTP/1.0
IIS format is a fixed (cannot be customized) ASCII format. IIS format records more information than NCSA Common format. The IIS format includes basic items, such as the user's IP address, user name, request date and time, service status code, and number of bytes received. In addition, IIS format includes detailed items, such as the elapsed time, number of bytes sent, action (for example, a download carried out by a GET command), and target file. The items are separated by commas, making the format easier to read than the other ASCII formats, which use spaces for separators. The time is recorded as local time.
When you open an IIS-format file in a text editor, the entries are similar to the following examples:
192.168.114.201, -, 03/20/01, 7:55:20, W3SVC2, SALES1, 172.21.13.45, 4502, 163, 3223, 200, 0, GET, /DeptLogo.gif, -, 172.16.255.255, anonymous, 03/20/01, 23:58:11, MSFTPSVC, SALES1, 172.16.255.255, 60, 275, 0, 0, 0, PASS, /Intro.htm, -,
In the previous example, the first entry indicates that an anonymous user with the IP address of 192.168.114.201 issued an HTTP GET command for the image file /DeptLogo.gif at 7:55 A.M. on March 20, 2001, from a server named SALES1 at IP address 172.21.13.45. The 163-byte HTTP request had an elapsed processing time of 4502 milliseconds (4.5 seconds) to complete, and returned, without error, 3223 bytes of data to the anonymous user.
National Center for Supercomputing Applications (NCSA) Common format is a fixed (cannot be customized) ASCII format, available for Web sites but not for FTP sites. NCSA Common format records basic information about user requests, such as remote host name, user name, date, time, request type, HTTP status code, and the number of bytes sent by the server. Items are separated by spaces; time is recorded as local time.
When you open an NCSA Common format file in a text editor, the entries are similar to the following example:
172.21.13.45 - Microsoft\fred [08/Apr/2001:17:39:04 -0800] "GET /scripts/iisadmin/ism.dll?http/serv HTTP/1.0" 200 3401
In the preceding entry, the second property field (which shows the remote log name of the user) is empty and is represented by the hyphen following the IP address 172.21.13.45. A user named Fred in the Microsoft domain, with the IP address of 172.21.13.45, issued an HTTP GET command (that is, downloaded a file) at 5:39 P.M. on April 8, 2001. The request returned, without error, 3401 bytes of data to the user named Fred.
ODBC logging format is a record of a fixed set of data properties in a database that complies with Open Database Connectivity (ODBC), such as Microsoft Access or Microsoft SQL Server™. Some of the items logged include the user's IP address, user name, request date and time (recorded as local time), HTTP status code, bytes received, bytes sent, action carried out (for example, a download carried out by a GET command), and the target (for example, the file that was downloaded). With ODBC logging, you must both specify the database to be logged to, and set up the database to receive the data.
IIS includes an SQL template file that can be run in an SQL database to create a table that accepts log entries from IIS. The file is named Logtemp.sql and is located at %systemroot%\System32\Inetsrv if you accepted the setup defaults.
When ODBC logging is enabled, IIS disables the kernel-mode cache. For this reason, implementing ODBC logging can degrade overall server performance.
For security reasons, do not use the SQL SA account for ODBC logging. If a malicious user were to access the worker process, they could use the SA account to access the SQL server. Instead, remove the SQL SA account and create a new account with the least necessary permissions.
IIS 5.1 and earlier: The Centralized binary logging plug-in is not available.
Centralized binary logging is the process where multiple Web sites write binary, unformatted log data to a single log file. Each Web server running IIS creates one log file for all sites on that server. Centralized binary logging preserves valuable memory resources. Depending on your configuration, you could see dramatic performance and scalability gains with centralized binary logging.
Centralized binary logging preserves memory resources because the log data is in binary form and is stored in one file. Depending on your configuration, you could see dramatic performance and scalability gains by switching to centralized binary logging.