Configuring Management IIS Logging on Windows 7

Logging is critical for any server. It is no exception for IIS servers. In the Windows 7 operating system, compared to 2003, there has been a big improvement in IIS logging. Not only the format of the log, but also some other options, the operating system administrator has more choices. As shown in the following figure, it is the basic page of IIS logging configuration management.

In the Windows 7 operating system, IIS logging should be considered a required component of the ISS rather than an optional component. This is mainly because log files are critical to managing IIS servers. If the IIS server is under security threats, log files can be utilized and a suspected review of the inherent details contained therein can be performed. If the IIS server fails, you can also use the information recorded in this log file to check the maintenance process and identify problems in the system. Here I will introduce you to some new features of the Windows 7 operating system compared to the Windows 2003 operating system, and help you deploy a handy log management mode.

First, choose the appropriate logging level.

In IIS 7.0, system administrators can choose the appropriate logging level according to their needs. If you can manage logging at the server level, you can also implement it at the website, WEB application file, or directory level. To be specific at that level, mainly depends on the needs of the system administrator. However, it should be noted that the supported log file formats are different depending on the level of implementation. As implemented at the "server" level, there are only two supported log formats, the "W3C" format and the binary format. If you choose to implement log management at the "website" level, there are three supported log formats, namely IIS, NCSA, and W3C formats. And if the system administrator feels that these formats are not enough, they can customize the format they need by "customizing". Therefore, when selecting the logging level, it is convenient and safe to manage log management at the same level. It is also necessary to combine the log format that you like. I personally like to manage the logs at the site level. Because on a server, if you only deploy IIS services, it may be wasteful. That is, there may be multiple application services on the same server. In order to distinguish it from other application services and server operating system logs, I recommend that you manage at the site level. Of course, at which level the log management is performed, there is no practical difference in the contents of the log. Mainly depends on the deployment of the server and the work habits of the system administrator.

Second, choose the appropriate format for the log record.

If you choose a site level to manage your logs, there are several options for this log format. Most importantly, the system administrator can choose the logging format of IIS. This IIS logging format is text-based logging. Similar to the W3C logging format, it is controlled by HTTP.SYS. However, this IIS logging format is a core mode process. Previous log records were managed through user mode. There is a big change between the two. The Hypertext Transfer Protocol listener is implemented as a kernel mode device driver called HTTP.SYS. HTTP.SYS is an important part of the Windows networking subsystem. In previous versions, when a website was created in IIS, the site was registered using HTTP.SYS, and then HTTP.SYS passed the web request to the user-mode process of the running website. At the same time HTTP.SYS also sends the response back to the client. In addition to retrieving stored responses from its internal cache, HTTP.SYS does not process the requests it receives. Therefore, application-specific code is never loaded into kernel mode. But some system administrators want HTTP.SYS to run in core mode. At this point you need to use the IIS log format. In addition, IIS is a text-based log record. It is different from the binary format log record. You can view the log information directly through a tool such as a text browser. So it is more convenient to read.

Of course, the format of the log file is different, and the contents stored are the same. Therefore, the format of the log file does not affect the actual management value of the log. However, in order to facilitate the management and maintenance in the future, the author establishes a system administrator to choose the appropriate log format according to his work habits.

Third, choose the appropriate encoding format.

In general, there are two encoding formats for IIS log files, UTF-8 and ANSI. In all character sets, although ANSI is more famous. But this encoding format can be said to be specifically designed for English. Garbled characters can be used when storing other languages. If you support Chinese, it is not very good. In order to solve this problem, a new encoding format, UTF-8, was deliberately proposed. This is a UNICODEd variable length character encoding. If the UNICODE character is represented by 2 bytes, encoding to UTF-8 is likely to require 3 bytes, and if the UNICODE character is represented by 4 bytes, encoding to UTF-8 may require 6 bytes. UTF-8 encoding can be quickly read and written by masking bits and shifting operations. The result of strcmp() and wcscmp() is the same when the string is compared, thus making sorting easier. Bytes FF and FE never appear in UTF-8 encoding, so they can be used to indicate UTF-16 or UTF-32 text. UTF-8 is byte order independent. Its byte order is the same in all systems.

The format of these character sets may be a bit esoteric for some system administrators. In fact, the system administrator does not need to understand so clearly. Just need to understand a principle. That is, if the logs are all in English, then there is no problem with the ANSI encoding format. However, if there are other languages ​​in the log, garbled characters may appear. For this reason, I suggest that the encoding format of UTF-8 is still good. After all, its support for English is also very good. For this reason, it is better to set it to UTF-8 format once and for all. Avoid the trouble of garbled in the log reading.

Fourth, select the appropriate log file rolling update mechanism.

If you save IIS log records in a file, obviously the file will be very long. By the time, it will be very troublesome when viewing the records. For this reason, it is best to split the log file into small files. This is convenient with subsequent queries and reading. In the IIS log of the Windows 7 operating system, a lot of methods for scrolling and updating log files are provided. For example, you can create a new log file based on time. For example, rolling updates of log files can be implemented by day, by week, or by month. Under normal circumstances, you can update by month. If the IIS server access is frequent, you can also shorten the interval between the rolling update of this log file. For example, you can adjust the time interval to one week or one day, and so on. How much is this time interval is good, mainly depends on the number of records. If the number of log records is large, you can shorten the time appropriately. Conversely, if the number of log records is not large, you can create a new log file on a monthly basis.

In addition to creating new log files based on time, you can also create new log files based on the size of the log files. You can select Maximum File Size in the IIS Log Manager. Then enter a suitable size. In this case, when the log file reaches the specified size, the system will automatically switch the log. However, I do not agree with this approach. Although it can control redo log files within a reasonable size, it breaks its inherent time connections. At that time, it will be very inconvenient to query when you encounter problems. Therefore, the author still establishes the segmentation of redo log files by time.

Another manager also offers another useful option, which is to name and roll local time user files. This is a very useful option. When this option is selected, this time information will be reflected in the log file automatically created by the system. This can be a great help for system administrators to find log files. In particular, if you split the redo log files by file size, be sure to check this option to facilitate subsequent lookups.