1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
$Id: README,v 1.6 2002/05/14 21:47:15 helios Exp $
Homepage
--------
http://www.grubbybaby.com/mod_log_sql/
Approach
--------
This project was formerly known as mod_log_mysql. It has been renamed
to mod_log_sql in order to reflect the project goal of
database-inspecificity. The module currently supports MySQL, and
development for other database backends is underway.
In order to save speed and overhead, links are kept alive in between
queries. This module uses one SQL link per httpd process. Among other
things, this means that this module supports logging into only one
MySQL server, and for now, also, only one SQL database. But that's a
small tradeoff compared to the blinding speed of this module.
Virtual hosts are supported in the same manner they are in the regular
logging modules. You define some basic 'global' directives in the
main server config, then you define more specific 'local' directives
inside each virtualhost stanza.
SQL links are opened by each child process when it is born. Error reporting
is robust throughout and will let you know about database issues
in the standard Apache error-log for the server or virtual server.
A robust "preserve" capability has now been implemented. This permits
the module to preserve any failed INSERT commands to a local file on
its machine. In any situation that the database is unavailable -- e.g.
the network fails, you reboot the db host, etc. -- mod_log_sql will
note this in the error log and begin appending its log entries to the
preserve file (which is created with the user & group ID of the running
Apache process, e.g. "nobody" on many Linux installations). At the time
that your MySQL server returns to service, each of these preserve files
is easily imported because it is simply a series of SQL insert statements:
# mysql -uadminuser -p mydbname < /tmp/mysql-preserve
Supported directives
--------------------
Please see the web-based documentation for full explanation of all
supported run-time directives.
http://www.grubbybaby.com/mod_log_sql/directives.html
See the FAQ for some handy examples:
http://www.grubbybaby.com/mod_log_sql/faq.html
What gets logged by default?
----------------------------
All the data that would be contained in the "Combined Log Format"
is logged by default, plus a little extra. Your best bet is to
begin by accepting this default, then later customize the log
configuration based on your needs.
The online documentation of the run-time directives includes a full
explanation of what you can log, including examples.
Notes
-----
* You will customarily set most of your run-time configuration directives
on a per-virtualserver basis, with only MySQLMassVirtualHosting,
MySQLLoginInfo, MySQLDatabase, MySQLSocketFile, MySQLCreateTables,
and MySQLMassVirtualHosting 'outside' in the main server config. Any
directives other than those in the main config do NOT get inherited
by the virutal servers.
* The 'time_stamp' field is stored in an UNSIGNED INTEGER column, in the
standard unix "seconds since 1/1/1970 12:00:00" format. This is
superior to storing the access time as a string due to size
requirements: an UNSIGNED INT type fits in 4 bytes, whereas the Apache date
string (e.g. "18/Nov/2001:13:59:52 -0800") requires 26 bytes --
significantly larger, and those extra 22 bytes will add up over the
thousands of accesses that a busy server will experience. Besides,
an INT type is far more flexible for comparisons, etc.
In MySQL 3.21 and above you can easily convert this to a human
readable format using from_unixtime(), e.g.:
select remote_host,request_uri,from_unixtime(time_stamp) from access_log;
The enclosed perl program make_combined_log.pl shows how you can
extract your access records in a format that is completely Combined
Log Format compliant. You can then feed this to your favorite web
log analysis tool.
* The table's string values can be CHAR or VARCHAR, at a length of your choice.
VARCHAR is superior because it truncates long strings; CHAR types are
fixed-length and will be padded with spaces. Just like the
time_stamp described above, that kind of space waste will add up over
thousands of records.
* Be careful not to go overboard setting fields to NOT NULL. If a field is
marked NOT NULL then it must contain data in the INSERT or the INSERT
will fail.
* Apache normally logs numeric fields with a '-' character to mean "not
applicable," e.g. bytes_sent on a request with a 304 response code.
Since '-' is an illegal character in an SQL numeric field, such
fields are assigned the value 0 instead of '-' which, of course,
makes perfect sense anyway.
Author / Maintainer
-------------------
The actual logging code was taken from the already existing flat file
text modules, so all that credit goes to the Apache Server group.
The MySQL routines and directives were added by Zeev Suraski
<bourbon@netvision.net.il>.
All changes from 1.06+ and the new documentation were added by
Chris Powell <chris@grubbybaby.com>. It seems that the module had fallen
into the "unmaintained" category -- it hadn't been updated since 1998 --
so Chris adopted it as the new maintainer.
|
