- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
Apache Guide: Logging, Part 2 -- Error Logs Page 2
First, we have the date/time stamp. And the first thing that you might notice
is that the format is not the same as the format in the
format that we called the "standard english format." I suspect that this is
an accident of history, and that it's probably too late to change it now. I'll
have to delve into this a little further and find out.
Next, we have the level of the message. This will be one of the levels specified
in the documentation for
LogLevel (see link above).
error is right
crit. This simply indicates how serious the problem
is. A 404 error means that you irritated someone, but your server is not
actually on fire.
The next field indicates the address of the client machine that made the request. In this case, it is a machine on my local network.
The last part of the log entry is the actual error message. In the case of a 404, it gives you the full path of the file that the server tried to serve. This is particularly useful when you're getting a 404 on a file that you just know is there. Frequently you have a configuration wrong, or the file is on a different virtual host than you thought, or some other strangeness.
Authentication errors will look very much the same:
[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 that document errors, since they are a direct result of a client request,
will be accompanied by an entry in
access_log as well.
Perhaps the most useful use of the error is troubleshooting misbehaved CGI programs. Anything that a CGI program emits to STDERR (Standard Error) gets spewed directly to the error log for your perusal. This means that (well-written) CGI programs, when they go south, will tell you, via the log file, exactly what the problem is.
The downside to this is that you end up with stuff in the error log that is not in any well-defined format, and so it makes it very hard to have any automatic error-log parsing to get useful information out.
What follows is an example of an entry in my error log from when I was hacking on some 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 "" requires explicit package name at /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 81. Global symbol "%details" requires explicit package name at /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 84. Global symbol "" requires explicit package name at /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 133. Execution of /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi aborted due to compilation errors.
OK, this entry actually does follow the same format as the 404 error above, in that it has a date, error level, and a client address. But the error message itself is several lines long, which tends to confuse some log-parsing software.
Now, even if you don't know Perl, you should be able to look at the error messages above, and glean some useful information about what went wrong. At the very least, you can tell on what lines I screwed up. Perl is really good about telling you where you made a mistake. Your mileage may vary, based on what language you are using.