Logging is crucial 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.
In Windows7 operating system, IIS logging should be considered rather than optional components necessary for ISS. 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, select the appropriate logging level
in IIS7.0 version, the system administrator can select 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, in order to select the appropriate log format
If you choose to log the site level to manage the case, the log format has several options. 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 creating a website 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.
course, different log file format, its stored contents 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. Under
three, select the appropriate coding format
general, IIS log file encoding format, there are two, respectively, UTF-8 and ANSI formats. 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.
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 rotation If the IIS log records are kept in a file, the file is obviously a long-update mechanism
. 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
can create a new log file based on time, you can also create a new log file depending on the size of the log file. You can select Maximum File Size in the IIS Log Manager. Then enter a suitable size. 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. In addition
manager also provides other useful options, namely whether to file naming and rollover local time users. 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.