To enable IIS logging on Windows7

Logging is critical to any server. It is no exception for IIS servers. In the Windows7 operating system, there is a significant improvement over IIS logging, compared to 2003来. More than just the format of the log, or some other option, the operating system administrator has more choices. This is the basic page of IIS logging configuration management, as shown in the following illustration.

In the Windows7 operating system, IIS logging should be considered necessary for ISS rather than an optional component. This is primarily because log files are critical for managing IIS servers. If the IIS server is under security threat, you can use the log file and perform a row-checking of the internal details contained therein. You can also use the information recorded in this log file to check the maintenance process and identify problems in the system after the IIS server has failed. I would like to introduce you to the WINDOWS7 operating system IIS log records compared to the Windows2003 operating system some of the new features, and to help you deploy a handy log management mode.

First, select the appropriate logging level.

In the IIS7.0 version, the system administrator can choose the appropriate logging level to suit their needs. If you can manage logging at the server level, you can also implement it at the Web site, at the Web application file, or at the directory level. specifically to achieve at that level, mainly looking at the needs of system administrators. It should be noted, however, that the level of implementation is different, and that the supported log file formats are different. As implemented at the server level, there are only two types of log formats that are supported, namely, the "All-in-one" format and the binary format. If you choose to implement log management at the site level, there are three log formats supported, IIS, NCSA, and the format of the world in the world. and system administrators can customize the format they want by customizing them if they feel they are not satisfied. So when you choose the logging level, in addition to consider at what level of log management is more convenient and safe, but also need to combine their favorite log format. I personally like to manage the log at the site level. Because on a single server, it may be wasteful to deploy only IIS services. In other words, there may be multiple application services on the same server. In order to differentiate with other application services and server operating system logs, the author recommends that you manage at the site level. Of course, at which level of log management, there is no practical difference in the content of the log. It depends on the deployment of the server and the working habits of the system administrator.

Choose the appropriate format for logging.

If you select a site level to manage the log, the format of this log has several options. Most importantly, the system administrator can select the logging format for IIS. This IIS logging format is text-based log records. Similar to the logging format of the HTTP.sys, it is controlled by the data. However, this IIS logging format is a core mode process. The previous log records were managed through user mode. There is a big change between the two. The Hypertext Transfer Protocol listener is implemented with the name HTTP. SYS's kernel-mode device driver. HTTP. SYS is an important part of the Windows network subsystem. In previous releases, HTTP was used when creating a Web site in IIS. SYS registers the site, and then http.sys the Web request to the user-mode process that is running the Web site. At the same time, HTTP.sys will respond back to the client. In addition to retrieving the stored response from its internal cache, HTTP. SYS does not handle the requests it receives. Therefore, application-specific code will never be loaded into kernel mode. But some system administrators want HTTP.sys to run in core mode. You need to use the IIS log format at this point. In addition, IIS is text-based logging, and unlike binary format logging, you can view log information directly through tools such as a text browser. So it's more convenient to read.

Of course, the format of the log file is different and the contents are the same. So the format of the log file does not affect the actual management value of the log. However, for future management and maintenance of convenience, the author of the best to establish a system administrator in accordance with their own work habits to choose the appropriate log format.

Third, choose the appropriate encoding format.

In general, the IIS log files are encoded in two different formats, UTF-8 and ANSI two. In all of the character sets, although ANSI is more famous. But this code format can be said to be designed specifically for the English language. A garbled situation occurs when you use to store other languages. If it is not very good to support Chinese. In order to solve this problem, a new encoding format is proposed, namely UTF-8. This is a unicoded a variable-length character encoding. If Unicode characters are represented by 2 bytes, encoding to UTF-8 is likely to require 3 bytes, and if Unicode characters are represented by 4 bytes, it may take 6 bytes to encode into UTF-8. UTF-8 encoding can be read and written quickly by shielding bit and shift operation. The return result of strcmp () and wcscmp () is the same for string comparisons, making sorting easier. BYTE FF and FE will never appear in the UTF-8 encoding, so they can be used to indicate UTF-16 or UTF-32 text. UTF-8 are 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 have to understand one principle. That is, if the logs are displayed in English, then using the ANSI encoding format will not be a problem. However, if there are other languages in the log, there may be garbled characters. To this end, I suggest that the UTF-8 coding format should be used as well. After all, its support for English is also very good. It's better to set it to UTF-8 format for once and for all. Lest in the future log reading encountered garbled trouble.

Select the appropriate log file rolling update mechanism.

If you save IIS log records in one file, it is obvious that the file will be very long. It's going to be a lot of trouble when you look at the records. Therefore, it is best to be able to split the log file into small files. This is convenient with subsequent inquiries and reading. In the IIS log for the WINDOWS7 operating system, there are many ways to scroll the log files. If you can create a new log file based on time. You can implement a scrolling update of the log file by day, by week, or by month. In general, you can update by month. If the IIS server accesses more frequently, you can also shorten the time interval for scrolling updates for this log file appropriately. If you can adjust the time interval to a week or a day, and so on. How much of this time interval is good, mainly depends on the number of records. If you have a large number of log records, you can shorten the time appropriately. Conversely, if the number of log records is not large, you can create a new log file in months.

In addition to creating a new log file based on time, you can create a new log file based on the size of the log file. You can select the maximum file size in IIS Log Manager. Then enter a suitable size. In this case, when the log file reaches the specified size, the system automatically logs a switch to it. But I do not agree with this approach. Although it can control the redo log file in a reasonable size, it will break its intrinsic time link. By then, it would be very inconvenient to inquire when you encounter a problem. Therefore, the author or the establishment of a time to redo log file segmentation.

Another useful option for the manager is to name and roll the local time user file. This is a very useful option. When this option is selected, the time information is reflected in the system's automatically created log file. This can provide a lot of help for the system administrator to find log files. Especially if you divide the redo log files by file size, be sure to select this option to facilitate subsequent lookups.