Article title: Apache log: error log. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
The error log and access log are also Apache standard logs. This article analyzes the content of error logs, describes how to set options related to error logs, how to classify document errors and CGI errors, and how to conveniently view log content.
I. location and content
The previous article discussed Apache access logs, including its content, format, and options related to how to set access logs. This article will discuss another Apache standard log-error log.
Error logs are different from access logs in both format and content. However, the error log and access log also provide a wealth of information, which can be used to analyze the server running status and where the problem occurs.
The file name of the error log is error_log, but for Windows, the file name of the error log is error. log. You can use the ErrorLog command to set the location of the error log:
ErrorLog logs/error. log
Unless the file location starts with "/", the file location is relative to the ServerRoot directory. If Apache is installed by default, the error log should be located in/usr/local/apache/logs. However, if Apache is installed using a certain package manager, the error log may be elsewhere.
As shown in its name, the error log records various errors encountered during server operation, as well as some common diagnostic information, such as when the server is started and when it is closed.
We can set the log file record information level to control the number and type of log file record information. This is set through the LogLevel command. by default, this command sets an error level, that is, records events that are called errors. For a complete list of various options that can be set in this command, see the apachedocumentation for http://www.apache.org/docs/mod/core.html?loglevel.
In most cases, the content we see in the log file falls into two categories: document errors and CGI errors. However, configuration errors may occasionally occur in the error log, as well as the server startup and shutdown information mentioned above.
II. document error
Document errors correspond to the 400 series of code in the server response. The most common error is the 404 error -- Document Not Found (this Document is Not Found ). Besides the 404 error, user authentication error is also a common error.
404 error occurs when the resource requested by the user (that is, the URL) does not exist. it may be caused by a URL error or because the original document on the server is deleted or moved for some reason.
By the way, according to Jakob Nielson, we should never move or delete any resources of the Web site without providing redirection or other remedial measures. For more information about Nielson, see http://www.zdnet.com/devhead/alertbox /.
When a user cannot open a document on the server, the error log contains the following records:
[Fri Aug 18 22:36:26 2000] [error]
[Client 192.168.1.6] File does not exist:
/Usr/local/apache/bugletdocs/Img/south-korea.gif
As you can see, just like the access log access_log file, the error log records are also divided into multiple items.
The error records start with the date/time mark. Note that their format is different from the date/time format in access_log. The format in access_log is called "standard English format". This may be a joke of history, but it is too late to change it.
The second item of the error record is the current record level, which indicates the severity of the problem. This level of information may be any level listed in the LogLevel instruction documentation (see the previous LogLevel link). The error level is between the warn level and the crit level. 404 belongs to the error level, which indicates that a problem is encountered, but the server can still run.
The third item in the error record indicates the IP address used by the user to send the request.
The last record is the real error message. For Error 404, it also provides a complete path to indicate the files the server is trying to access. This information is useful when we expect a file to have a 404 error at the target location. At this time, this error is often caused by server configuration errors, virtual hosts in which files are actually located, different from what we expected, or unexpected situations.
The error records due to user authentication problems are as follows:
[Tue Apr 11 22:13:21 2000]
[Error] [client 192.168.1.3] user rbowen @ rcbowen.
Com: authentication failure for "/cgi-bin/hirecareers/company. cgi ":
Password mismatch
Note: Because document errors are the direct results of user requests, they will also be recorded in the access log.
III. CGI error
The main purpose of the error log is probably the CGI program that diagnoses abnormal behavior. For further analysis and processing convenience, all content output by CGI program to STDERR (Standard Error, Standard Error device) will go directly to the Error log. This means that if a problem occurs in any well-written CGI program, the error log will tell us detailed information about the problem.
However, outputting CGI program errors to the error log also has its disadvantages. the error log will contain a lot of content without standard format, this makes it quite difficult to use an automatic error log analysis program to analyze useful information.
The following is an example of an error record in the error log when debugging the Perl CGI code:
[Wed Jun 14 16:16:37 2000] [error] [client 192.168.1.3] Premature
End of script headers:/usr/local/apache/cgi-bin/HyperCalPro/announcement. cgi
Global symbol "$ rv" requires explicit package name
/Usr/local/apache/cgi-bin/HyperCalPro/announcement. cgi line 81.
Global symbol "% details" requires explicit package name
/Usr/local/apache/cgi-bin/HyperCalPro/announcement. cgi line 84.
Global symbol "$ Config" requires explicit package name
/Usr/local/apache/cgi-bin/HyperCalPro/announcement. cgi line 133.
The CGI error is in the same format as the preceding 404 error, including the date/time, error level, customer address, and error message. However, there are several lines of CGI error messages, which often interferes with the work of some error log analysis software.
With this error message, even if you are not familiar with Perl, you can find a lot of information about the error. for example, you can easily find out which lines of code has a problem. Perl has a sound mechanism for reporting program errors. Of course, the information output from different programming languages to error logs is different.
Due to the special nature of the CGI program running environment, if there is no error log help, most CGI program errors will be difficult to solve.
Many complained in the email list or newsgroup that they had a CGI program and the Server returned an Error when the webpage was opened, such as "Internal Server Error ". We can be sure that these people have not read the server error log, or do not know the existence of the error log. In most cases, the error log can precisely indicate the location of the CGI error and how to correct it.
4. View log files
I often tell people that while developing, I will constantly check server logs so that I can immediately know what went wrong. But the answer I get is often silence. At first, I thought this silence meant "of course you have to do this." Then I realized that the true meaning of this silence was "I don't know what others do, but I did not do it myself ."
However, let's take a look at how to conveniently view server log files. Connect to the server via telnet and enter the following command:
Tail-f/usr/local/apache/logs/error_log
This command will display the last few lines of the log file. if new content is added to the log file, it will immediately display the newly added content.
Windows users can also use this method. for example, they can use various Unix tool packages provided for Windows. I personally love a tool called AINTX that can be used in http://maxx.mc.net /~ Jlh/nttools/index.htm.
Another alternative is to use the following Perl code, which utilizes a module called File: Tail:
Use File: Tail;
$ File = File: Tail-> new ("/some/log/file ");
While (defined ($ line = $ file-> read )){
Print "$ line ";
}
No matter which method is used, opening multiple terminal windows at the same time is a good habit: for example, displaying error logs in one window and access logs in another window. In this way, we can learn what happened on the website at any time and solve it immediately.
In the next article in the Apache log series, we will discuss how to customize server logs, that is, how to record all the information we want in log files and exclude all the information we don't want.
After that, we will also discuss how to process log files, that is, how to generate statistical reports from log files. In the last few articles, we will also discuss how to redirect logging to a specified program instead of saving it to a log file so that the program can handle the newly generated log data in real time, for example, you can save the log data to the database, or send the log information to the system administrator by email when some critical errors occur.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
