diff options
| author | 2011-07-21 19:10:20 -0400 | |
|---|---|---|
| committer | 2011-07-21 19:10:38 -0400 | |
| commit | f1fd1c9714256bb9b212462dd31ca6dc56ea31ef (patch) | |
| tree | 6d3aaaf843f758f5cd7dd2dc7641dca6ed4badca /docs/node5.html | |
add in project web page
Diffstat (limited to 'docs/node5.html')
| -rw-r--r-- | docs/node5.html | 1270 |
1 files changed, 1270 insertions, 0 deletions
diff --git a/docs/node5.html b/docs/node5.html new file mode 100644 index 0000000..e9a593c --- /dev/null +++ b/docs/node5.html | |||
| @@ -0,0 +1,1270 @@ | |||
| 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> | ||
| 2 | |||
| 3 | <!--Converted with LaTeX2HTML 2002-1 (1.68) | ||
| 4 | original version by: Nikos Drakos, CBLU, University of Leeds | ||
| 5 | * revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan | ||
| 6 | * with significant contributions from: | ||
| 7 | Jens Lippmann, Marek Rouchal, Martin Wilck and others --> | ||
| 8 | <HTML> | ||
| 9 | <HEAD> | ||
| 10 | <TITLE>4 FAQ</TITLE> | ||
| 11 | <META NAME="description" CONTENT="4 FAQ"> | ||
| 12 | <META NAME="keywords" CONTENT="documentation"> | ||
| 13 | <META NAME="resource-type" CONTENT="document"> | ||
| 14 | <META NAME="distribution" CONTENT="global"> | ||
| 15 | |||
| 16 | <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> | ||
| 17 | <META NAME="Generator" CONTENT="LaTeX2HTML v2002-1"> | ||
| 18 | <META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> | ||
| 19 | |||
| 20 | <LINK REL="STYLESHEET" HREF="documentation.css"> | ||
| 21 | |||
| 22 | <LINK REL="next" HREF="node6.html"> | ||
| 23 | <LINK REL="previous" HREF="node4.html"> | ||
| 24 | <LINK REL="up" HREF="documentation.html"> | ||
| 25 | <LINK REL="next" HREF="node6.html"> | ||
| 26 | </HEAD> | ||
| 27 | |||
| 28 | <BODY > | ||
| 29 | <!--Navigation Panel--> | ||
| 30 | <A NAME="tex2html219" | ||
| 31 | HREF="node6.html"> | ||
| 32 | <IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A> | ||
| 33 | <A NAME="tex2html215" | ||
| 34 | HREF="documentation.html"> | ||
| 35 | <IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A> | ||
| 36 | <A NAME="tex2html209" | ||
| 37 | HREF="node4.html"> | ||
| 38 | <IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A> | ||
| 39 | <A NAME="tex2html217" | ||
| 40 | HREF="node1.html"> | ||
| 41 | <IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A> | ||
| 42 | <BR> | ||
| 43 | <B> Next:</B> <A NAME="tex2html220" | ||
| 44 | HREF="node6.html">About this document ...</A> | ||
| 45 | <B> Up:</B> <A NAME="tex2html216" | ||
| 46 | HREF="documentation.html">Installing and Running mod_log_sql</A> | ||
| 47 | <B> Previous:</B> <A NAME="tex2html210" | ||
| 48 | HREF="node4.html">3 Configuration</A> | ||
| 49 | <B> <A NAME="tex2html218" | ||
| 50 | HREF="node1.html">Contents</A></B> | ||
| 51 | <BR> | ||
| 52 | <BR> | ||
| 53 | <!--End of Navigation Panel--> | ||
| 54 | <!--Table of Child-Links--> | ||
| 55 | <A NAME="CHILD_LINKS"><STRONG>Subsections</STRONG></A> | ||
| 56 | |||
| 57 | <UL> | ||
| 58 | <LI><A NAME="tex2html221" | ||
| 59 | HREF="node5.html#SECTION00051000000000000000">4.1 General module questions</A> | ||
| 60 | <UL> | ||
| 61 | <LI><A NAME="tex2html222" | ||
| 62 | HREF="node5.html#SECTION00051100000000000000">4.1.1 Why log to an SQL database?</A> | ||
| 63 | <LI><A NAME="tex2html223" | ||
| 64 | HREF="node5.html#SECTION00051200000000000000">4.1.2 Why use MySQL? Are there alternatives?</A> | ||
| 65 | <LI><A NAME="tex2html224" | ||
| 66 | HREF="node5.html#SECTION00051300000000000000">4.1.3 Is this code production-ready?</A> | ||
| 67 | <LI><A NAME="tex2html225" | ||
| 68 | HREF="node5.html#SECTION00051400000000000000">4.1.4 Who's using mod_log_sql?</A> | ||
| 69 | <LI><A NAME="tex2html226" | ||
| 70 | HREF="node5.html#SECTION00051500000000000000">4.1.5 Why doesn't the module also replace the Apache ErrorLog?</A> | ||
| 71 | <LI><A NAME="tex2html227" | ||
| 72 | HREF="node5.html#SECTION00051600000000000000">4.1.6 Does mod_log_sql work with Apache 2.x?</A> | ||
| 73 | <LI><A NAME="tex2html228" | ||
| 74 | HREF="node5.html#SECTION00051700000000000000">4.1.7 Does mod_log_sql connect to MySQL via TCP/IP or a socket?</A> | ||
| 75 | <LI><A NAME="tex2html229" | ||
| 76 | HREF="node5.html#SECTION00051800000000000000">4.1.8 I have discovered a bug. Who can I contact?</A> | ||
| 77 | </UL> | ||
| 78 | <BR> | ||
| 79 | <LI><A NAME="tex2html230" | ||
| 80 | HREF="node5.html#SECTION00052000000000000000">4.2 Problems</A> | ||
| 81 | <UL> | ||
| 82 | <LI><A NAME="tex2html231" | ||
| 83 | HREF="node5.html#SECTION00052100000000000000">4.2.1 Apache segfaults when using PHP and mod_log_sql</A> | ||
| 84 | <LI><A NAME="tex2html232" | ||
| 85 | HREF="node5.html#SECTION00052200000000000000">4.2.2 Apache appears to start up fine, but nothing | ||
| 86 | is getting logged in the database</A> | ||
| 87 | <LI><A NAME="tex2html233" | ||
| 88 | HREF="node5.html#SECTION00052300000000000000">4.2.3 Why do I get the message ``insufficient configuration info to | ||
| 89 | establish database link'' in my Apache error log?</A> | ||
| 90 | <LI><A NAME="tex2html234" | ||
| 91 | HREF="node5.html#SECTION00052400000000000000">4.2.4 My database cannot handle all the open connections from mod_log_sql, | ||
| 92 | is there anything I can do?</A> | ||
| 93 | <LI><A NAME="tex2html235" | ||
| 94 | HREF="node5.html#SECTION00052500000000000000">4.2.5 Why do I occasionally see a ``lost connection to MySQL server'' | ||
| 95 | message in my Apache error log?</A> | ||
| 96 | </UL> | ||
| 97 | <BR> | ||
| 98 | <LI><A NAME="tex2html236" | ||
| 99 | HREF="node5.html#SECTION00053000000000000000">4.3 Performance and Tuning</A> | ||
| 100 | <UL> | ||
| 101 | <LI><A NAME="tex2html237" | ||
| 102 | HREF="node5.html#SECTION00053100000000000000">4.3.1 How well does it perform?</A> | ||
| 103 | <LI><A NAME="tex2html238" | ||
| 104 | HREF="node5.html#SECTION00053200000000000000">4.3.2 Do I need to be worried about all the running MySQL children? Will | ||
| 105 | holding open <I>n</I> Apache-to-MySQL connections consume a lot of | ||
| 106 | memory? </A> | ||
| 107 | <LI><A NAME="tex2html239" | ||
| 108 | HREF="node5.html#SECTION00053300000000000000">4.3.3 My webserver cannot handle all the traffic that my site receives, | ||
| 109 | is there anything I can do?</A> | ||
| 110 | <LI><A NAME="tex2html240" | ||
| 111 | HREF="node5.html#SECTION00053400000000000000">4.3.4 What is the issue with activating delayed | ||
| 112 | inserts?</A> | ||
| 113 | </UL> | ||
| 114 | <BR> | ||
| 115 | <LI><A NAME="tex2html241" | ||
| 116 | HREF="node5.html#SECTION00054000000000000000">4.4 ``How do I...?'' - accomplishing certain tasks</A> | ||
| 117 | <UL> | ||
| 118 | <LI><A NAME="tex2html242" | ||
| 119 | HREF="node5.html#SECTION00054100000000000000">4.4.1 I am using LogSQLMassVirtualHosting, and sometimes a single VirtualHost | ||
| 120 | gets logged to two different tables. How do I prevent that?</A> | ||
| 121 | <LI><A NAME="tex2html243" | ||
| 122 | HREF="node5.html#SECTION00054200000000000000">4.4.2 How do I extract the data in a format that my analysis tool can understand?</A> | ||
| 123 | <LI><A NAME="tex2html244" | ||
| 124 | HREF="node5.html#SECTION00054300000000000000">4.4.3 How can I log mod_usertrack cookies?</A> | ||
| 125 | <LI><A NAME="tex2html245" | ||
| 126 | HREF="node5.html#SECTION00054400000000000000">4.4.4 What if I want to log more than one cookie? What is the difference | ||
| 127 | between LogSQLWhichCookie and LogSQLWhichCookies?</A> | ||
| 128 | <LI><A NAME="tex2html246" | ||
| 129 | HREF="node5.html#SECTION00054500000000000000">4.4.5 What are the SSL logging features, and how do I activate them?</A> | ||
| 130 | </UL></UL> | ||
| 131 | <!--End of Table of Child-Links--> | ||
| 132 | <HR> | ||
| 133 | |||
| 134 | <H1><A NAME="SECTION00050000000000000000"> | ||
| 135 | 4 FAQ</A> | ||
| 136 | </H1> | ||
| 137 | |||
| 138 | <P> | ||
| 139 | |||
| 140 | <H2><A NAME="SECTION00051000000000000000"> | ||
| 141 | 4.1 General module questions</A> | ||
| 142 | </H2> | ||
| 143 | |||
| 144 | <P> | ||
| 145 | |||
| 146 | <H3><A NAME="SECTION00051100000000000000"></A><A NAME="sub:why"></A> | ||
| 147 | <BR> | ||
| 148 | 4.1.1 Why log to an SQL database? | ||
| 149 | </H3> | ||
| 150 | |||
| 151 | <P> | ||
| 152 | To begin with, let's get it out of the way: logging to a database | ||
| 153 | is not a panacea. But while there are complexities with this solution, | ||
| 154 | the benefit can be substantial for certain classes of administrator | ||
| 155 | or people with advanced requirements: | ||
| 156 | |||
| 157 | <P> | ||
| 158 | |||
| 159 | <UL> | ||
| 160 | <LI>Chores like log rotation go away, as you can DELETE records from the | ||
| 161 | SQL database once they are no longer useful. For example, the excellent | ||
| 162 | and popular log-analysis tool Webalizer (http://www.webalizer.com) | ||
| 163 | does not need historic logs after it has processed them, enabling | ||
| 164 | you to delete older logs. | ||
| 165 | </LI> | ||
| 166 | <LI>People with clusters of web servers (for high availability) will benefit | ||
| 167 | the most - all their webservers can log to a single SQL database. | ||
| 168 | This obviates the need to collate/interleave the many separate logfiles, | ||
| 169 | which can be / highly/ problematic. | ||
| 170 | </LI> | ||
| 171 | <LI>People acquainted with the power of SQL SELECT statements will know | ||
| 172 | the flexibility of the extraction possibilities at their fingertips. | ||
| 173 | </LI> | ||
| 174 | </UL> | ||
| 175 | For example, do you want to see all your 404's? Do this: | ||
| 176 | |||
| 177 | <P> | ||
| 178 | |||
| 179 | <DL COMPACT> | ||
| 180 | <DT> | ||
| 181 | <DD>select remote_host,status,request_uri,bytes_sent,from_unixtime(time_stamp) | ||
| 182 | |||
| 183 | <P> | ||
| 184 | from acc_log_tbl where status=404 order by time_stamp; | ||
| 185 | |||
| 186 | <P> | ||
| 187 | </DD> | ||
| 188 | </DL> | ||
| 189 | <DIV ALIGN="CENTER"> | ||
| 190 | <TABLE CELLPADDING=3 BORDER="1"> | ||
| 191 | <TR><TD ALIGN="LEFT">remote_host</TD> | ||
| 192 | <TD ALIGN="LEFT">status</TD> | ||
| 193 | <TD ALIGN="LEFT">request_uri</TD> | ||
| 194 | <TD ALIGN="LEFT">bytes_sent</TD> | ||
| 195 | <TD ALIGN="LEFT">from_unixtime(time_stamp)</TD> | ||
| 196 | </TR> | ||
| 197 | <TR><TD ALIGN="LEFT">marge.mmm.co.uk</TD> | ||
| 198 | <TD ALIGN="LEFT">404</TD> | ||
| 199 | <TD ALIGN="LEFT">/favicon.ico</TD> | ||
| 200 | <TD ALIGN="LEFT">321</TD> | ||
| 201 | <TD ALIGN="LEFT">2001-11-20 02:30:56</TD> | ||
| 202 | </TR> | ||
| 203 | <TR><TD ALIGN="LEFT">62.180.239.251</TD> | ||
| 204 | <TD ALIGN="LEFT">404</TD> | ||
| 205 | <TD ALIGN="LEFT">/favicon.ico</TD> | ||
| 206 | <TD ALIGN="LEFT">333</TD> | ||
| 207 | <TD ALIGN="LEFT">2001-11-20 02:45:25</TD> | ||
| 208 | </TR> | ||
| 209 | <TR><TD ALIGN="LEFT">212.234.12.66</TD> | ||
| 210 | <TD ALIGN="LEFT">404</TD> | ||
| 211 | <TD ALIGN="LEFT">/favicon.ico</TD> | ||
| 212 | <TD ALIGN="LEFT">321</TD> | ||
| 213 | <TD ALIGN="LEFT">2001-11-20 03:01:00</TD> | ||
| 214 | </TR> | ||
| 215 | <TR><TD ALIGN="LEFT">212.210.78.254</TD> | ||
| 216 | <TD ALIGN="LEFT">404</TD> | ||
| 217 | <TD ALIGN="LEFT">/favicon.ico</TD> | ||
| 218 | <TD ALIGN="LEFT">333</TD> | ||
| 219 | <TD ALIGN="LEFT">2001-11-20 03:26:05</TD> | ||
| 220 | </TR> | ||
| 221 | </TABLE> | ||
| 222 | </DIV> | ||
| 223 | |||
| 224 | <P> | ||
| 225 | |||
| 226 | <DL COMPACT> | ||
| 227 | <DT> | ||
| 228 | <DD><P> | ||
| 229 | </DD> | ||
| 230 | </DL>Or do you want to see how many bytes you've sent within a certain | ||
| 231 | directory or site? Do this: | ||
| 232 | |||
| 233 | <P> | ||
| 234 | |||
| 235 | <DL COMPACT> | ||
| 236 | <DT> | ||
| 237 | <DD>select request_uri,sum(bytes_sent) as bytes,count(request_uri) as howmany from | ||
| 238 | |||
| 239 | <P> | ||
| 240 | acc_log_tbl where request_uri like '%mod_log_sql%' group by request_uri order | ||
| 241 | |||
| 242 | <P> | ||
| 243 | by howmany desc; | ||
| 244 | |||
| 245 | <P> | ||
| 246 | </DD> | ||
| 247 | </DL> | ||
| 248 | <DIV ALIGN="CENTER"> | ||
| 249 | <TABLE CELLPADDING=3 BORDER="1"> | ||
| 250 | <TR><TD ALIGN="LEFT">request_uri</TD> | ||
| 251 | <TD ALIGN="LEFT">bytes</TD> | ||
| 252 | <TD ALIGN="LEFT">howmany</TD> | ||
| 253 | </TR> | ||
| 254 | <TR><TD ALIGN="LEFT">/mod_log_sql/style_1.css</TD> | ||
| 255 | <TD ALIGN="LEFT">157396</TD> | ||
| 256 | <TD ALIGN="LEFT">1288</TD> | ||
| 257 | </TR> | ||
| 258 | <TR><TD ALIGN="LEFT">/mod_log_sql/</TD> | ||
| 259 | <TD ALIGN="LEFT">2514337</TD> | ||
| 260 | <TD ALIGN="LEFT">801</TD> | ||
| 261 | </TR> | ||
| 262 | <TR><TD ALIGN="LEFT">/mod_log_sql/mod_log_sql.tar.gz</TD> | ||
| 263 | <TD ALIGN="LEFT">9769312</TD> | ||
| 264 | <TD ALIGN="LEFT">456</TD> | ||
| 265 | </TR> | ||
| 266 | <TR><TD ALIGN="LEFT">/mod_log_sql/faq.html</TD> | ||
| 267 | <TD ALIGN="LEFT">5038728</TD> | ||
| 268 | <TD ALIGN="LEFT">436</TD> | ||
| 269 | </TR> | ||
| 270 | </TABLE> | ||
| 271 | </DIV> | ||
| 272 | |||
| 273 | <P> | ||
| 274 | |||
| 275 | <DL COMPACT> | ||
| 276 | <DT> | ||
| 277 | <DD><P> | ||
| 278 | </DD> | ||
| 279 | </DL>Or maybe you want to see who's linking to you? Do this: | ||
| 280 | |||
| 281 | <P> | ||
| 282 | |||
| 283 | <DL COMPACT> | ||
| 284 | <DT> | ||
| 285 | <DD>select count(referer) as num,referer from acc_log_tbl where | ||
| 286 | |||
| 287 | <P> | ||
| 288 | request_uri='/mod_log_sql/' group by referer order by num desc; | ||
| 289 | |||
| 290 | <P> | ||
| 291 | </DD> | ||
| 292 | </DL> | ||
| 293 | <DIV ALIGN="CENTER"> | ||
| 294 | <TABLE CELLPADDING=3 BORDER="1"> | ||
| 295 | <TR><TD ALIGN="LEFT">num</TD> | ||
| 296 | <TD ALIGN="LEFT">referer</TD> | ||
| 297 | </TR> | ||
| 298 | <TR><TD ALIGN="LEFT">271</TD> | ||
| 299 | <TD ALIGN="LEFT">http://freshmeat.net/projects/mod_log_sql/</TD> | ||
| 300 | </TR> | ||
| 301 | <TR><TD ALIGN="LEFT">96</TD> | ||
| 302 | <TD ALIGN="LEFT">http://modules.apache.org/search?id=339</TD> | ||
| 303 | </TR> | ||
| 304 | <TR><TD ALIGN="LEFT">48</TD> | ||
| 305 | <TD ALIGN="LEFT">http://freshmeat.net/</TD> | ||
| 306 | </TR> | ||
| 307 | <TR><TD ALIGN="LEFT">8</TD> | ||
| 308 | <TD ALIGN="LEFT">http://freshmeat.net</TD> | ||
| 309 | </TR> | ||
| 310 | </TABLE> | ||
| 311 | </DIV> | ||
| 312 | |||
| 313 | <P> | ||
| 314 | |||
| 315 | <DL COMPACT> | ||
| 316 | <DT> | ||
| 317 | <DD><P> | ||
| 318 | </DD> | ||
| 319 | </DL>As you can see, there are myriad possibilities that can be constructed | ||
| 320 | with the wonderful SQL SELECT statement. Logging to an SQL database | ||
| 321 | can be really quite useful! | ||
| 322 | |||
| 323 | <P> | ||
| 324 | |||
| 325 | <H3><A NAME="SECTION00051200000000000000"> | ||
| 326 | 4.1.2 Why use MySQL? Are there alternatives?</A> | ||
| 327 | </H3> | ||
| 328 | |||
| 329 | <P> | ||
| 330 | MySQL is a robust, free, and very powerful production-quality database | ||
| 331 | engine. It is well supported and comes with detailed documentation. | ||
| 332 | Many 3rd-party software pacakges (e.g. Slashcode, the engine that | ||
| 333 | powers Slashdot) run exclusively with MySQL. In other words, you will | ||
| 334 | belong to a very robust and well-supported community by choosing MySQL. | ||
| 335 | |||
| 336 | <P> | ||
| 337 | That being said, there are alternatives. PostgreSQL is probably MySQL's | ||
| 338 | leading "competitor" in the free database world. | ||
| 339 | There is also an excellent module available for Apache to permit logging | ||
| 340 | to a PostgreSQL database, called pgLOGd (http://www.digitalstratum.com/pglogd/). | ||
| 341 | |||
| 342 | <P> | ||
| 343 | |||
| 344 | <H3><A NAME="SECTION00051300000000000000"> | ||
| 345 | 4.1.3 Is this code production-ready?</A> | ||
| 346 | </H3> | ||
| 347 | |||
| 348 | <P> | ||
| 349 | By all accounts it is. It is known to work without a problem on many-thousands-of-hits-per-day | ||
| 350 | webservers. Does that mean it is 100% bug free? Well, no software | ||
| 351 | is. But it is well-tested and believed to be fully compatible with | ||
| 352 | production environments. (The usual disclaimers apply. This software | ||
| 353 | is provided without warranty of any kind.) | ||
| 354 | |||
| 355 | <P> | ||
| 356 | |||
| 357 | <H3><A NAME="SECTION00051400000000000000"> | ||
| 358 | 4.1.4 Who's using mod_log_sql?</A> | ||
| 359 | </H3> | ||
| 360 | |||
| 361 | <P> | ||
| 362 | Good question! It would be great to find out! If you are a production-level | ||
| 363 | mod_log_sql user, please contact the maintainer, Chris Powell (chris@grubbybaby.com) | ||
| 364 | so that you can be mentioned here. | ||
| 365 | |||
| 366 | <P> | ||
| 367 | |||
| 368 | <H3><A NAME="SECTION00051500000000000000"> | ||
| 369 | 4.1.5 Why doesn't the module also replace the Apache ErrorLog?</A> | ||
| 370 | </H3> | ||
| 371 | |||
| 372 | <P> | ||
| 373 | There are circumstances when that would be quite unwise - for example, | ||
| 374 | if Apache could not reach the MySQL server for some reason and needed | ||
| 375 | to log that fact. Without a text-based error log you'd never know | ||
| 376 | anything was wrong, because Apache would be trying to log a database | ||
| 377 | connection error to the database... you get the point. | ||
| 378 | |||
| 379 | <P> | ||
| 380 | Error logs are usually not very high-traffic and are really best left | ||
| 381 | as text files on a web server machine. | ||
| 382 | |||
| 383 | <P> | ||
| 384 | |||
| 385 | <H3><A NAME="SECTION00051600000000000000"> | ||
| 386 | 4.1.6 Does mod_log_sql work with Apache 2.x?</A> | ||
| 387 | </H3> | ||
| 388 | |||
| 389 | <P> | ||
| 390 | As of this writing, no. The Apache Group significantly altered the | ||
| 391 | module API with the release of Apache 2.0. All modules written for | ||
| 392 | 1.3, including mod_log_sql, will not work with 2.0. | ||
| 393 | |||
| 394 | <P> | ||
| 395 | mod_log_sql will eventually be ported to Apache 2.x, but not immediately. | ||
| 396 | It is going to take some time, and there are other features that have | ||
| 397 | higher priority. Please sign up for the announcements list (on the | ||
| 398 | main website) or monitor the website for updates to learn when the | ||
| 399 | port (and other releases) are available. | ||
| 400 | |||
| 401 | <P> | ||
| 402 | <OPINION>If you're a *NIX user, stick with Apache 1.3.x for now. | ||
| 403 | Major modules like mod_ssl and PHP are not even ready for 2.0 yet, | ||
| 404 | and the main benefits in 2.0 are for Win32 users anyway. Apache 1.3.x | ||
| 405 | is rock-stable and performs equally well on *NIX as 2.0.</OPINION> | ||
| 406 | |||
| 407 | <P> | ||
| 408 | |||
| 409 | <H3><A NAME="SECTION00051700000000000000"> | ||
| 410 | 4.1.7 Does mod_log_sql connect to MySQL via TCP/IP or a socket?</A> | ||
| 411 | </H3> | ||
| 412 | |||
| 413 | <P> | ||
| 414 | It depends! This is not determined by mod_log_sql. mod_log_sql | ||
| 415 | relies on a connection command that is supplied in the MySQL API, | ||
| 416 | and that command is somewhat intelligent. How it works: | ||
| 417 | |||
| 418 | <P> | ||
| 419 | |||
| 420 | <UL> | ||
| 421 | <LI>if the specified MySQL database is on the same machine, the connection | ||
| 422 | command uses a socket to communicate with MySQL | ||
| 423 | </LI> | ||
| 424 | <LI>if the specified MySQL database is on a different machine, mod_log_sql | ||
| 425 | connects using TCP/IP. | ||
| 426 | </LI> | ||
| 427 | </UL> | ||
| 428 | You don't have any control of which methodology is used. You can fine-tune | ||
| 429 | some of the configuration, however. The L<SMALL>OG</SMALL>SQLS<SMALL>OCKET</SMALL>F<SMALL>ILE</SMALL> | ||
| 430 | runtime configuration directive overrides the default of ``/var/lib/mysql/mysql.sock'' | ||
| 431 | for socket-based connections, whereas the L<SMALL>OG</SMALL>SQLTCPP<SMALL>ORT</SMALL> command | ||
| 432 | allows to you override the default TCP port of 3306 for TCP/IP connections. | ||
| 433 | |||
| 434 | <P> | ||
| 435 | |||
| 436 | <H3><A NAME="SECTION00051800000000000000"> | ||
| 437 | 4.1.8 I have discovered a bug. Who can I contact?</A> | ||
| 438 | </H3> | ||
| 439 | |||
| 440 | <P> | ||
| 441 | Please contact the maintainer (chris@grubbybaby.com)! Your | ||
| 442 | comments, suggestions, bugfixes, bug catches, and usage testimonials | ||
| 443 | are always welcome. As free software, mod_log_sql is intended to | ||
| 444 | be a community effort - any code contributions or other ideas will | ||
| 445 | be fully and openly credited, of course. | ||
| 446 | |||
| 447 | <P> | ||
| 448 | |||
| 449 | <H2><A NAME="SECTION00052000000000000000"> | ||
| 450 | 4.2 Problems</A> | ||
| 451 | </H2> | ||
| 452 | |||
| 453 | <P> | ||
| 454 | |||
| 455 | <H3><A NAME="SECTION00052100000000000000"> | ||
| 456 | 4.2.1 Apache segfaults when using PHP and mod_log_sql</A> | ||
| 457 | </H3> | ||
| 458 | |||
| 459 | <P> | ||
| 460 | This occurs if you compiled PHP with MySQL database support. PHP utilizes | ||
| 461 | its internal, bundled MySQL libraries by default. These conflict with | ||
| 462 | the ``real'' MySQL libraries linked by mod_log_sql, causing | ||
| 463 | the segmentation fault. | ||
| 464 | |||
| 465 | <P> | ||
| 466 | The solution is to configure PHP to link against the real MySQL libraries | ||
| 467 | and recompile mod_php. Apache will run properly once the modules | ||
| 468 | are all using the same version of the MySQL libraries. | ||
| 469 | |||
| 470 | <P> | ||
| 471 | |||
| 472 | <H3><A NAME="SECTION00052200000000000000"></A><A NAME="faq:NothingLogged"></A> | ||
| 473 | <BR> | ||
| 474 | 4.2.2 Apache appears to start up fine, but nothing | ||
| 475 | is getting logged in the database | ||
| 476 | </H3> | ||
| 477 | |||
| 478 | <P> | ||
| 479 | If you do not see any entries in the access_log, then something is | ||
| 480 | preventing the inserts from happening. This could be caused by several | ||
| 481 | things: | ||
| 482 | |||
| 483 | <P> | ||
| 484 | |||
| 485 | <UL> | ||
| 486 | <LI>Improper privileges set up in the MySQL database | ||
| 487 | </LI> | ||
| 488 | <LI>You aren't hitting a VirtualHost that has a LogSQLTransferLogTable | ||
| 489 | entry | ||
| 490 | </LI> | ||
| 491 | <LI>You didn't specify the right database host or login information | ||
| 492 | </LI> | ||
| 493 | <LI>Another factor is preventing a connection to the database | ||
| 494 | </LI> | ||
| 495 | </UL> | ||
| 496 | Important: it is improper to ask for help before you have followed | ||
| 497 | these steps. | ||
| 498 | |||
| 499 | <P> | ||
| 500 | First examine the MySQL log that you established in step <A HREF="node4.html#step:EnaLog">6</A> | ||
| 501 | of section <A HREF="node4.html#sub:PrepDb">3.1</A>. Ensure that the INSERT statements are | ||
| 502 | not being rejected because of a malformed table name or other typographical | ||
| 503 | error. By enabling that log, you instructed MySQL to log every connection | ||
| 504 | and command it receives - if you see no INSERT attempts in the log, | ||
| 505 | the module isn't successfully connecting to the database. If you see | ||
| 506 | nothing at all in the log - not even a record of your administrative | ||
| 507 | connection attempts, then you did not enable the log correctly. If | ||
| 508 | you do see INSERT attempts but they are failing, the log should tell | ||
| 509 | you why. | ||
| 510 | |||
| 511 | <P> | ||
| 512 | Second, confirm that your L<SMALL>OG</SMALL>SQL* directives are all correct. | ||
| 513 | |||
| 514 | <P> | ||
| 515 | Third, examine the Apache error logs for messages from mod_log_sql; | ||
| 516 | the module will offer hints as to why it cannot connect, etc. | ||
| 517 | |||
| 518 | <P> | ||
| 519 | The next thing to do is recompile the module with debugging output | ||
| 520 | activated. change the "#undef DEBUG" on line 8 | ||
| 521 | of mod_log_sql.c to "#define DEBUG" and recompile/reinstall. | ||
| 522 | The module will now output copious notes about what it is doing, and | ||
| 523 | this will help you (and the maintainer) solve the problem. In order | ||
| 524 | to see the debugging messages, ensure that you make them visible using | ||
| 525 | the L<SMALL>OG</SMALL>L<SMALL>EVEL</SMALL> directive <B>in the main server config | ||
| 526 | as well as in each</B> <B>V<SMALL>IRTUAL</SMALL>H<SMALL>OST</SMALL></B> <B>config:</B> | ||
| 527 | |||
| 528 | <P> | ||
| 529 | |||
| 530 | <DL COMPACT> | ||
| 531 | <DT> | ||
| 532 | <DD>LogLevel debug | ||
| 533 | |||
| 534 | <P> | ||
| 535 | ErrorLog /var/log/httpd/server-messages | ||
| 536 | </DD> | ||
| 537 | </DL> | ||
| 538 | <P> | ||
| 539 | |||
| 540 | <H3><A NAME="SECTION00052300000000000000"> | ||
| 541 | 4.2.3 Why do I get the message ``insufficient configuration info to | ||
| 542 | establish database link'' in my Apache error log?</A> | ||
| 543 | </H3> | ||
| 544 | |||
| 545 | <P> | ||
| 546 | At a minimum, L<SMALL>OG</SMALL>SQLD<SMALL>ATABASE</SMALL> and L<SMALL>OG</SMALL>SQLL<SMALL>OGIN</SMALL>I<SMALL>NFO</SMALL> | ||
| 547 | must be defined in order for the module to be able to establish a | ||
| 548 | database link. If these are not defined or are incomplete you will | ||
| 549 | receive this error message. | ||
| 550 | |||
| 551 | <P> | ||
| 552 | |||
| 553 | <H3><A NAME="SECTION00052400000000000000"> | ||
| 554 | 4.2.4 My database cannot handle all the open connections from mod_log_sql, | ||
| 555 | is there anything I can do?</A> | ||
| 556 | </H3> | ||
| 557 | |||
| 558 | <P> | ||
| 559 | The rule of thumb: if you have <I>n</I> webservers each configured | ||
| 560 | to support <I>y</I> M<SMALL>AX</SMALL>C<SMALL>LIENTS</SMALL>, then your database must be | ||
| 561 | able to handle <IMG | ||
| 562 | WIDTH="41" HEIGHT="29" ALIGN="MIDDLE" BORDER="0" | ||
| 563 | SRC="img3.png" | ||
| 564 | ALT="$n\times y$"> simultenous connections <I>in the worst | ||
| 565 | case.</I> Certainly you must use common sense, consider reasonable traffic | ||
| 566 | expectations and structure things accordingly. | ||
| 567 | |||
| 568 | <P> | ||
| 569 | Tweaking my.cnf to scale to high connection loads is imperative. But | ||
| 570 | if hardware limitations prevent your MySQL server from gracefully | ||
| 571 | handling the number of incoming connections, it would be beneficial | ||
| 572 | to upgrade the memory or CPU on that server in order to handle the | ||
| 573 | load. | ||
| 574 | |||
| 575 | <P> | ||
| 576 | Jeremy Zawodny, a highly respected MySQL user and contributor to Linux | ||
| 577 | Magazine, has this very helpful and highly appropriate article on | ||
| 578 | tuning MySQL: http://jeremy.zawodny.com/blog/archives/000173.html | ||
| 579 | |||
| 580 | <P> | ||
| 581 | Please remember that mod_log_sql's overriding principle is <B>performance</B> | ||
| 582 | - that is what the target audience demands and expects. Other database | ||
| 583 | logging solutions do not open and maintain many database connections, | ||
| 584 | but their performance suffers drastically. For example, pgLOGd funnels | ||
| 585 | all log connections through a separate daemon that connects to the | ||
| 586 | database, but that bottlenecks the entire process. mod_log_sql achieves | ||
| 587 | performance numbers an order of magnitude greater than the alternatives | ||
| 588 | because it dispenses with the overhead associated with rapid connection | ||
| 589 | cycling, and it doesn't attempt to shoehorn all the database traffic | ||
| 590 | through a single extra daemon or proxy process. | ||
| 591 | |||
| 592 | <P> | ||
| 593 | |||
| 594 | <H3><A NAME="SECTION00052500000000000000"> | ||
| 595 | 4.2.5 Why do I occasionally see a ``lost connection to MySQL server'' | ||
| 596 | message in my Apache error log?</A> | ||
| 597 | </H3> | ||
| 598 | |||
| 599 | <P> | ||
| 600 | This message may appear every now and then in your Apache error log, | ||
| 601 | especially on very lightly loaded servers. This doesn't mean that | ||
| 602 | anything is necessarily wrong. Within each httpd child process, mod_log_sql | ||
| 603 | will open (and keep open) a connection to the MySQL server. MySQL, | ||
| 604 | however, will close connections that haven't been used in a while; | ||
| 605 | the default timeout is 8 hours. When this occurs, mod_log_sql will | ||
| 606 | notice and re-open the connection. That event is what is being logged, | ||
| 607 | and looks like this: | ||
| 608 | |||
| 609 | <P> | ||
| 610 | |||
| 611 | <DL COMPACT> | ||
| 612 | <DT> | ||
| 613 | <DD>[Tue Nov 12 19:04:10 2002] [error] mod_log_sql: first attempt failed, | ||
| 614 | |||
| 615 | <P> | ||
| 616 | API said: error 2013, Lost connection to MySQL server during query | ||
| 617 | |||
| 618 | <P> | ||
| 619 | [Tue Nov 12 19:04:10 2002] [error] mod_log_sql: reconnect successful | ||
| 620 | |||
| 621 | <P> | ||
| 622 | [Tue Nov 12 19:04:10 2002] [error] mod_log_sql: second attempt successful | ||
| 623 | </DD> | ||
| 624 | </DL>Reference: MySQL documentation (http://www.mysql.com/documentation/mysql/bychapter/manual_Problems.html#Gone_away) | ||
| 625 | |||
| 626 | <P> | ||
| 627 | |||
| 628 | <H2><A NAME="SECTION00053000000000000000"> | ||
| 629 | 4.3 Performance and Tuning</A> | ||
| 630 | </H2> | ||
| 631 | |||
| 632 | <P> | ||
| 633 | |||
| 634 | <H3><A NAME="SECTION00053100000000000000"> | ||
| 635 | 4.3.1 How well does it perform?</A> | ||
| 636 | </H3> | ||
| 637 | |||
| 638 | <P> | ||
| 639 | mod_log_sql scales to very high loads. Apache 1.3.22 + mod_log_sql | ||
| 640 | was benchmarked using the "ab" (Apache Bench) program | ||
| 641 | that comes with the Apache distribution; here are the results. | ||
| 642 | |||
| 643 | <P> | ||
| 644 | Overall configuration: | ||
| 645 | |||
| 646 | <P> | ||
| 647 | |||
| 648 | <UL> | ||
| 649 | <LI>Machine A: Apache webserver | ||
| 650 | </LI> | ||
| 651 | <LI>Machine B: MySQL server | ||
| 652 | </LI> | ||
| 653 | <LI>Machines A and B connected with 100Mbps Ethernet | ||
| 654 | </LI> | ||
| 655 | <LI>Webserver: Celeron 400, 128 MB RAM, IDE storage | ||
| 656 | </LI> | ||
| 657 | </UL> | ||
| 658 | Apache configuration: | ||
| 659 | |||
| 660 | <P> | ||
| 661 | |||
| 662 | <DL COMPACT> | ||
| 663 | <DT> | ||
| 664 | <DD>Timeout 300 | ||
| 665 | |||
| 666 | <P> | ||
| 667 | KeepAlive On | ||
| 668 | |||
| 669 | <P> | ||
| 670 | MaxKeepAliveRequests 100 | ||
| 671 | |||
| 672 | <P> | ||
| 673 | KeepAliveTimeout 15 | ||
| 674 | |||
| 675 | <P> | ||
| 676 | MinSpareServers 5 | ||
| 677 | |||
| 678 | <P> | ||
| 679 | StartServers 10 | ||
| 680 | |||
| 681 | <P> | ||
| 682 | MaxSpareServers 15 | ||
| 683 | |||
| 684 | <P> | ||
| 685 | MaxClients 256 | ||
| 686 | |||
| 687 | <P> | ||
| 688 | MaxRequestsPerChild 5000 | ||
| 689 | |||
| 690 | <P> | ||
| 691 | LogSQLTransferLogFormat AbHhmRSsTUuvc | ||
| 692 | |||
| 693 | <P> | ||
| 694 | LogSQLWhichCookie Clicks | ||
| 695 | |||
| 696 | <P> | ||
| 697 | CookieTracking on | ||
| 698 | |||
| 699 | <P> | ||
| 700 | CookieName Clicks | ||
| 701 | </DD> | ||
| 702 | </DL>"ab" commandline: | ||
| 703 | |||
| 704 | <P> | ||
| 705 | |||
| 706 | <DL COMPACT> | ||
| 707 | <DT> | ||
| 708 | <DD>./ab -c 10 -t 20 -v 2 -C Clicks=ab_run http://www.hostname.com/target | ||
| 709 | </DD> | ||
| 710 | </DL>( 10 concurrent requests; 20 second test; setting a cookie "Clicks=ab_run"; | ||
| 711 | target = the mod_log_sql homepage. ) | ||
| 712 | |||
| 713 | <P> | ||
| 714 | Ten total ab runs were conducted: five with MySQL logging enabled, | ||
| 715 | and five with all MySQL directives commented out of httpd.conf. Then | ||
| 716 | each five were averaged. The results: | ||
| 717 | |||
| 718 | <P> | ||
| 719 | |||
| 720 | <UL> | ||
| 721 | <LI>Average of five runs employing MySQL <I>and</I> standard text logging: | ||
| 722 | <B>139.01 requests per second, zero errors</B>. | ||
| 723 | </LI> | ||
| 724 | <LI>Average of five runs employing <I>only</I> standard text logging: | ||
| 725 | <B>139.96 requests per second, zero errors</B>. | ||
| 726 | </LI> | ||
| 727 | </UL> | ||
| 728 | In other words, any rate-limiting effects on this particular hardware | ||
| 729 | setup are not caused by MySQL. Note that although this very simple | ||
| 730 | webserver setup is hardly cutting-edge - it is, after all, a fairly | ||
| 731 | small machine - 139 requests per second equal over <I>twelve million | ||
| 732 | hits per day.</I> | ||
| 733 | |||
| 734 | <P> | ||
| 735 | If you run this benchmark yourself, take note of three things: | ||
| 736 | |||
| 737 | <P> | ||
| 738 | |||
| 739 | <OL> | ||
| 740 | <LI>Use a target URL that is on your own webserver :-). | ||
| 741 | </LI> | ||
| 742 | <LI>Wait until all your connections are closed out between runs; after | ||
| 743 | several thousand requests your TCP/IP stack will be filled with hundreds | ||
| 744 | of connections in TIME_WAIT that need to close. Do a "netstat | ||
| 745 | -t|wc -l" on the webserver to see. If you don't wait, you | ||
| 746 | can expect to see a lot of messages like "ip_conntrack: | ||
| 747 | table full, dropping packet" in your logs. (This has nothing | ||
| 748 | to do with mod_log_sql, this is simply the nature of the TCP/IP | ||
| 749 | stack in the Linux kernel.) | ||
| 750 | </LI> | ||
| 751 | <LI>When done with your runs, clean these many thousands of requests out | ||
| 752 | of your database: | ||
| 753 | </LI> | ||
| 754 | </OL> | ||
| 755 | |||
| 756 | <DL COMPACT> | ||
| 757 | <DT> | ||
| 758 | <DD>mysql> delete from access_log where agent like 'ApacheBench%'; | ||
| 759 | |||
| 760 | <P> | ||
| 761 | mysql> optimize table access_log; | ||
| 762 | </DD> | ||
| 763 | </DL> | ||
| 764 | <P> | ||
| 765 | |||
| 766 | <H3><A NAME="SECTION00053200000000000000"> | ||
| 767 | 4.3.2 Do I need to be worried about all the running MySQL children? Will | ||
| 768 | holding open <I>n</I> Apache-to-MySQL connections consume a lot of | ||
| 769 | memory? </A> | ||
| 770 | </H3> | ||
| 771 | |||
| 772 | <P> | ||
| 773 | Short answer: you shouldn't be worried. | ||
| 774 | |||
| 775 | <P> | ||
| 776 | Long answer: you might be evaluating at the output of ``ps -aufxw'' | ||
| 777 | and becoming alarmed at all the 7MB httpd processes or 22MB mysqld | ||
| 778 | children that you see. Don't be alarmed<I>.</I> It's true that mod_log_sql | ||
| 779 | opens and holds open many MySQL connections: each httpd child maintains | ||
| 780 | one open database connection (and holds it open for performance reasons). | ||
| 781 | Four webservers, each running 20 Apache children, will hold open 80 | ||
| 782 | MySQL connections, which means that your MySQL server needs to handle | ||
| 783 | 80 simultaneous connections. In truth, your MySQL server needs to | ||
| 784 | handle far more than that if traffic to your website spikes and the | ||
| 785 | Apache webservers spawn off an additional 30 children each... | ||
| 786 | |||
| 787 | <P> | ||
| 788 | Fortunately the cost reported by 'ps -aufxw' is deceptive. This is | ||
| 789 | due to an OS memory-management feature called ``copy-on-write.'' | ||
| 790 | When you have a number of identical child processes (e.g. Apache, | ||
| 791 | MySQL), it would appear in ``ps'' as though each one occupies | ||
| 792 | a great deal of RAM - as much as 7MB per httpd child! In actuality | ||
| 793 | each additional child only occupies a small bit of extra memory - | ||
| 794 | most of the memory pages are common to each child and therefore shared | ||
| 795 | in a ``read-only'' fashion. The OS can get away with this because | ||
| 796 | the majority of memory pages for one child are identical across all | ||
| 797 | children. Instead of thinking of each child as a rubber stamp of the | ||
| 798 | others, think of each child as a basket of links to a common memory | ||
| 799 | area. | ||
| 800 | |||
| 801 | <P> | ||
| 802 | A memory page is only duplicated when it needs to be written to, hence | ||
| 803 | ``copy-on-write.'' The result is efficiency and decreased memory | ||
| 804 | consumption. ``ps'' may report 7MB per child, but it might really | ||
| 805 | only ``cost'' 900K of extra memory to add one more child. It is | ||
| 806 | <B>not</B> <B>correct</B> to assume that 20 Apache | ||
| 807 | children with a VSZ of 7MB each equals <!-- MATH | ||
| 808 | $(20\times 7MB)$ | ||
| 809 | --> | ||
| 810 | <IMG | ||
| 811 | WIDTH="90" HEIGHT="32" ALIGN="MIDDLE" BORDER="0" | ||
| 812 | SRC="img4.png" | ||
| 813 | ALT="$(20\times 7MB)$"> of memory | ||
| 814 | consumption - the real answer is much, much lower. The same ``copy-on-write'' | ||
| 815 | rules apply to all your MySQL children: 40 mysqld children @ 22MB | ||
| 816 | each <B>do not</B> occupy 880MB of RAM. | ||
| 817 | |||
| 818 | <P> | ||
| 819 | The bottom line: although there is a cost to spawn extra httpd or | ||
| 820 | mysqld children, that cost is not as great as ``ps'' would lead | ||
| 821 | you to believe. | ||
| 822 | |||
| 823 | <P> | ||
| 824 | |||
| 825 | <H3><A NAME="SECTION00053300000000000000"> | ||
| 826 | 4.3.3 My webserver cannot handle all the traffic that my site receives, | ||
| 827 | is there anything I can do?</A> | ||
| 828 | </H3> | ||
| 829 | |||
| 830 | <P> | ||
| 831 | If you have exhausted all the tuning possibilities on your existing | ||
| 832 | server, it is probably time you evaluated the benefits of clustering | ||
| 833 | two or more webservers together in a load-balanced fashion. In fact, | ||
| 834 | users of such a setup are mod_log_sql's target audience! | ||
| 835 | |||
| 836 | <P> | ||
| 837 | |||
| 838 | <H3><A NAME="SECTION00053400000000000000"></A><A NAME="sub:DelayedInsFAQ"></A> | ||
| 839 | <BR> | ||
| 840 | 4.3.4 What is the issue with activating delayed | ||
| 841 | inserts? | ||
| 842 | </H3> | ||
| 843 | |||
| 844 | <P> | ||
| 845 | There are several. | ||
| 846 | |||
| 847 | <P> | ||
| 848 | |||
| 849 | <OL> | ||
| 850 | <LI>INSERT DELAYED is a specific syntax to MySQL and is not supported | ||
| 851 | by any other database. Ergo, why is it needed, and what MySQL deficiency | ||
| 852 | is it working around? INSERT DELAYED is a kluge. | ||
| 853 | </LI> | ||
| 854 | <LI>The MySQL documentation is unclear whether INSERT DELAYED is even | ||
| 855 | necessary for an optimized database. It says, ``The DELAYED option | ||
| 856 | for the INSERT statement is a MySQL-specific option that is very useful | ||
| 857 | if you have clients that can't wait for the INSERT to complete.'' | ||
| 858 | But then it goes on to say, ``Note that as MyISAM tables supports | ||
| 859 | concurrent SELECT and INSERT, if there is no free blocks in the middle | ||
| 860 | of the data file, you very seldom need to use INSERT DELAYED with | ||
| 861 | MyISAM.'' | ||
| 862 | </LI> | ||
| 863 | <LI>Because INSERT DELAYED returns without waiting for the data to be | ||
| 864 | written, a hard kill of your MySQL database at the right (wrong?) | ||
| 865 | moment could lose those logfile entries. | ||
| 866 | </LI> | ||
| 867 | <LI>As of MySQL version 3.23.52, the error return functions disagree after | ||
| 868 | a failed INSERT DELAYED: mysql_errno() always returns 0, even if | ||
| 869 | mysql_error() returns a textual error. I have reported this bug to | ||
| 870 | the MySQL folks. However, we have no way of knowing what solution | ||
| 871 | they will adopt to fix this, and with the worst case solution mod_log_sql | ||
| 872 | would not be able to tell if anything went wrong with a delayed insert. | ||
| 873 | </LI> | ||
| 874 | </OL> | ||
| 875 | Instead of delayed inserts, you may wish to utilize InnoDB tables | ||
| 876 | (instead of the standard MyISAM tables). InnoDB tables suppot row-level | ||
| 877 | locking and are recommended for high-volume databases. | ||
| 878 | |||
| 879 | <P> | ||
| 880 | If after understanding these problems you still wish to enable delayed | ||
| 881 | inserts, section <A HREF="node4.html#sub:DelayedIns">3.5.4</A> discusses how. | ||
| 882 | |||
| 883 | <P> | ||
| 884 | |||
| 885 | <H2><A NAME="SECTION00054000000000000000"> | ||
| 886 | 4.4 ``How do I...?'' - accomplishing certain tasks</A> | ||
| 887 | </H2> | ||
| 888 | |||
| 889 | <P> | ||
| 890 | |||
| 891 | <H3><A NAME="SECTION00054100000000000000"> | ||
| 892 | 4.4.1 I am using LogSQLMassVirtualHosting, and sometimes a single VirtualHost | ||
| 893 | gets logged to two different tables. How do I prevent that?</A> | ||
| 894 | </H3> | ||
| 895 | |||
| 896 | <P> | ||
| 897 | Proper usage of the Apache runtime S<SMALL>ERVER</SMALL>N<SMALL>AME</SMALL> directive and | ||
| 898 | the directive U<SMALL>SE</SMALL>C<SMALL>ANONICAL</SMALL>N<SMALL>AME </SMALL>O<SMALL>N</SMALL> (or DNS) are necessary | ||
| 899 | to prevent this problem. ``On'' is the default for U<SMALL>SE</SMALL>C<SMALL>ANONICAL</SMALL>N<SMALL>AME</SMALL>, | ||
| 900 | and specifies that self-referential URLs are generated from the S<SMALL>ERVER</SMALL>N<SMALL>AME</SMALL> | ||
| 901 | part of your VirtualHost: | ||
| 902 | |||
| 903 | <P> | ||
| 904 | <BLOCKQUOTE> | ||
| 905 | With UseCanonicalName on (and in all versions prior to 1.3) Apache | ||
| 906 | will use the ServerName and Port directives to construct the canonical | ||
| 907 | name for the server. With UseCanonicalName off Apache will form self-referential | ||
| 908 | URLs using the hostname and port supplied by the client if any are | ||
| 909 | supplied (otherwise it will use the canonical name, as defined above). | ||
| 910 | [From the Apache documentation http://httpd.apache.org/docs/mod/core.html#usecanonicalname] | ||
| 911 | |||
| 912 | </BLOCKQUOTE> | ||
| 913 | The module inherits Apache's ``knowledge'' about the server name | ||
| 914 | being accessed. As long as those two directives are properly configured, | ||
| 915 | mod_log_sql will log to only one table per virtual host while using | ||
| 916 | L<SMALL>OG</SMALL>SQLM<SMALL>ASS</SMALL>V<SMALL>IRTUAL</SMALL>H<SMALL>OSTING</SMALL>. | ||
| 917 | |||
| 918 | <P> | ||
| 919 | |||
| 920 | <H3><A NAME="SECTION00054200000000000000"> | ||
| 921 | 4.4.2 How do I extract the data in a format that my analysis tool can understand?</A> | ||
| 922 | </H3> | ||
| 923 | |||
| 924 | <P> | ||
| 925 | mod_log_sql would be virtually useless if there weren't a way for | ||
| 926 | you to extract the data from your database in a somewhat meaningful | ||
| 927 | fashion. To that end there's a Perl script enclosed with the distribution. | ||
| 928 | That script (make_combined_log.pl) is designed to extract N-many | ||
| 929 | days worth of access logs and provide them in a Combined Log Format | ||
| 930 | output. You can use this very tool right in /etc/crontab to extract | ||
| 931 | logs on a regular basis so that your favorite web analysis tool can | ||
| 932 | read them. Or you can examine the Perl code to construct your own | ||
| 933 | custom tool. | ||
| 934 | |||
| 935 | <P> | ||
| 936 | For example, let's say that you want your web statistics updated once | ||
| 937 | per day in the wee hours of the morning. A good way to accomplish | ||
| 938 | that could be the following entries in /etc/crontab: | ||
| 939 | |||
| 940 | <P> | ||
| 941 | |||
| 942 | <DL COMPACT> | ||
| 943 | <DT> | ||
| 944 | <DD># Generate the temporary apache logs from the MySQL database (for webalizer) | ||
| 945 | |||
| 946 | <P> | ||
| 947 | 05 04 * * * root make_combined_log.pl 1 www.grubbybaby.com > /var/log/temp01 | ||
| 948 | |||
| 949 | <P> | ||
| 950 | # Run webalizer on httpd log | ||
| 951 | |||
| 952 | <P> | ||
| 953 | 30 04 * * * root webalizer -c /etc/webalizer.conf; rm -f /var/log/temp01 | ||
| 954 | </DD> | ||
| 955 | </DL>Or if you have a newer system that puts files in /etc/cron.daily etc., | ||
| 956 | create a file called ``webalizer'' in the cron.daily subdirectory. | ||
| 957 | Use the following as the contents of your file, and make sure to chmod | ||
| 958 | 755 it when done. | ||
| 959 | |||
| 960 | <P> | ||
| 961 | |||
| 962 | <DL COMPACT> | ||
| 963 | <DT> | ||
| 964 | <DD>#!/bin/sh | ||
| 965 | |||
| 966 | <P> | ||
| 967 | /usr/local/sbin/make_combined_log.pl 1 www.yourdomain.com > /var/log/httpd/templog | ||
| 968 | |||
| 969 | <P> | ||
| 970 | /usr/local/bin/webalizer -q -c /etc/webalizer.conf | ||
| 971 | |||
| 972 | <P> | ||
| 973 | rm -f /var/log/httpd/templog | ||
| 974 | </DD> | ||
| 975 | </DL>See? Easy. | ||
| 976 | |||
| 977 | <P> | ||
| 978 | |||
| 979 | <H3><A NAME="SECTION00054300000000000000"></A><A NAME="sec:cookie"></A> | ||
| 980 | <BR> | ||
| 981 | 4.4.3 How can I log mod_usertrack cookies? | ||
| 982 | </H3> | ||
| 983 | |||
| 984 | <P> | ||
| 985 | A number of people like to log mod_usertrack cookies in their Apache | ||
| 986 | TransferLog to aid in understanding their visitors' clickstreams. | ||
| 987 | This is accomplished, for example, with a statement as follows: | ||
| 988 | |||
| 989 | <P> | ||
| 990 | |||
| 991 | <DL COMPACT> | ||
| 992 | <DT> | ||
| 993 | <DD>LogFormat "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-Agent}i\"" \"%{cookie}n\"" | ||
| 994 | </DD> | ||
| 995 | </DL>Naturally it would be nice for mod_log_sql to permit the admin to | ||
| 996 | log the cookie data as well, so as of version 1.10 you can do this. | ||
| 997 | You need to have already compiled mod_usertrack into httpd - it's | ||
| 998 | one of the standard Apache modules. | ||
| 999 | |||
| 1000 | <P> | ||
| 1001 | First make sure you have a column called "cookie" | ||
| 1002 | in the MySQL database to hold the cookies, which can be done as follows | ||
| 1003 | if you already have a working database: | ||
| 1004 | |||
| 1005 | <P> | ||
| 1006 | |||
| 1007 | <DL COMPACT> | ||
| 1008 | <DT> | ||
| 1009 | <DD>alter table acc_log_tbl add column cookie varchar(255); | ||
| 1010 | </DD> | ||
| 1011 | </DL>Next configure your server to set usertracking cookies as follows, | ||
| 1012 | and make sure you include the new 'c' directive in your L<SMALL>OG</SMALL>SQLT<SMALL>RANSFER</SMALL>L<SMALL>OG</SMALL>F<SMALL>ORMAT</SMALL>, | ||
| 1013 | which activates cookie logging. Here's an example: | ||
| 1014 | |||
| 1015 | <P> | ||
| 1016 | |||
| 1017 | <DL COMPACT> | ||
| 1018 | <DT> | ||
| 1019 | <DD><VirtualHost 1.2.3.4> | ||
| 1020 | |||
| 1021 | <P> | ||
| 1022 | CookieTracking on | ||
| 1023 | |||
| 1024 | <P> | ||
| 1025 | CookieStyle Cookie | ||
| 1026 | |||
| 1027 | <P> | ||
| 1028 | CookieName Foobar | ||
| 1029 | |||
| 1030 | <P> | ||
| 1031 | LogSQLTransferLogFormat huSUsbTvRAc | ||
| 1032 | |||
| 1033 | <P> | ||
| 1034 | LogSQLWhichCookie Foobar | ||
| 1035 | |||
| 1036 | <P> | ||
| 1037 | </VirtualHost> | ||
| 1038 | </DD> | ||
| 1039 | </DL>The first three lines configure mod_usertrack to create a COOKIE | ||
| 1040 | (RFC 2109) format cookie called Foobar. The last two lines tell mod_log_sql | ||
| 1041 | to log cookies named Foobar. You have to choose which cookie to log | ||
| 1042 | because more than one cookie can/will be sent to the server by the | ||
| 1043 | client. | ||
| 1044 | |||
| 1045 | <P> | ||
| 1046 | Recap: the 'c' character <I>activates</I> cookie logging, and the | ||
| 1047 | L<SMALL>OG</SMALL>SQLW<SMALL>HICH</SMALL>C<SMALL>OOKIE</SMALL> directive <I>chooses</I> which cookie to | ||
| 1048 | log. | ||
| 1049 | |||
| 1050 | <P> | ||
| 1051 | FYI, you are advised NOT to use C<SMALL>OOKIE</SMALL>S<SMALL>TYLE </SMALL>C<SMALL>OOKIE2</SMALL> - it | ||
| 1052 | seems that even newer browsers (IE 5.5, etc.) have trouble with the | ||
| 1053 | new COOKIE2 (RFC 2965) format. Just stick with the standard COOKIE | ||
| 1054 | format and you'll be fine. | ||
| 1055 | |||
| 1056 | <P> | ||
| 1057 | Perform some hits on your server and run a select: | ||
| 1058 | |||
| 1059 | <P> | ||
| 1060 | |||
| 1061 | <DL COMPACT> | ||
| 1062 | <DT> | ||
| 1063 | <DD>mysql> select request_uri,cookie from access_log where cookie is not null; | ||
| 1064 | |||
| 1065 | <P> | ||
| 1066 | </DD> | ||
| 1067 | </DL> | ||
| 1068 | <DIV ALIGN="CENTER"> | ||
| 1069 | <TABLE CELLPADDING=3 BORDER="1"> | ||
| 1070 | <TR><TD ALIGN="LEFT">request_uri</TD> | ||
| 1071 | <TD ALIGN="LEFT">cookie</TD> | ||
| 1072 | </TR> | ||
| 1073 | <TR><TD ALIGN="LEFT">/mod_log_sql/</TD> | ||
| 1074 | <TD ALIGN="LEFT">ool-18e4.dyn.optonline.net.130051007102700823</TD> | ||
| 1075 | </TR> | ||
| 1076 | <TR><TD ALIGN="LEFT">/mod_log_sql/usa.gif</TD> | ||
| 1077 | <TD ALIGN="LEFT">ool-18e4.dyn.optonline.net.130051007102700823</TD> | ||
| 1078 | </TR> | ||
| 1079 | <TR><TD ALIGN="LEFT">/mod_log_sql/style_1.css</TD> | ||
| 1080 | <TD ALIGN="LEFT">ool-18e4.dyn.optonline.net.130051007102700823</TD> | ||
| 1081 | </TR> | ||
| 1082 | </TABLE> | ||
| 1083 | </DIV> | ||
| 1084 | |||
| 1085 | <P> | ||
| 1086 | |||
| 1087 | <DL COMPACT> | ||
| 1088 | <DT> | ||
| 1089 | <DD><P> | ||
| 1090 | </DD> | ||
| 1091 | </DL> | ||
| 1092 | <P> | ||
| 1093 | |||
| 1094 | <H3><A NAME="SECTION00054400000000000000"> | ||
| 1095 | 4.4.4 What if I want to log more than one cookie? What is the difference | ||
| 1096 | between LogSQLWhichCookie and LogSQLWhichCookies?</A> | ||
| 1097 | </H3> | ||
| 1098 | |||
| 1099 | <P> | ||
| 1100 | As of version 1.17, you have a choice in how you want cookie logging | ||
| 1101 | handled. | ||
| 1102 | |||
| 1103 | <P> | ||
| 1104 | If you are interested in logging only one cookie per request, follow | ||
| 1105 | the instructions in section <A HREF="node5.html#sec:cookie">4.4.3</A> above. That cookie will | ||
| 1106 | be logged to a column in the regular access_log table, and the actual | ||
| 1107 | cookie you want to log is specified with L<SMALL>OG</SMALL>SQLW<SMALL>HICH</SMALL>C<SMALL>OOKIE</SMALL>. | ||
| 1108 | Don't forget to specify the 'c' character in L<SMALL>OG</SMALL>SQLT<SMALL>RANSFER</SMALL>L<SMALL>OG</SMALL>F<SMALL>ORMAT</SMALL>. | ||
| 1109 | |||
| 1110 | <P> | ||
| 1111 | If, however, you need to log multiple cookies per request, you must | ||
| 1112 | employ the L<SMALL>OG</SMALL>SQLW<SMALL>HICH</SMALL>C<SMALL>OOKIES</SMALL> (note the plural) directive. | ||
| 1113 | The cookies you specify will be logged to a separate table (as discussed | ||
| 1114 | in section <A HREF="node4.html#secMulTable">3.5.2</A>), and entries in that table will be | ||
| 1115 | linked to the regular access_log entries via the unique ID that is | ||
| 1116 | supplied by mod_unique_id. Without mod_unique_id the information | ||
| 1117 | will still be logged but you will be unable to correlate which cookies | ||
| 1118 | go with which access-requests. Furthermore, with L<SMALL>OG</SMALL>SQLW<SMALL>HICH</SMALL>C<SMALL>OOKIES</SMALL>, | ||
| 1119 | you do <B>not</B> need to include the 'c' character in L<SMALL>OG</SMALL>SQLT<SMALL>RANSFER</SMALL>L<SMALL>OG</SMALL>F<SMALL>ORMAT</SMALL>. | ||
| 1120 | |||
| 1121 | <P> | ||
| 1122 | L<SMALL>OG</SMALL>SQLW<SMALL>HICH</SMALL>C<SMALL>OOKIE</SMALL> and L<SMALL>OG</SMALL>SQLW<SMALL>HICH</SMALL>C<SMALL>OOKIES</SMALL> can coexist | ||
| 1123 | without conflict because they operate on entireley different tables, | ||
| 1124 | but you're better off choosing the one you need. | ||
| 1125 | |||
| 1126 | <P> | ||
| 1127 | |||
| 1128 | <H3><A NAME="SECTION00054500000000000000"> | ||
| 1129 | 4.4.5 What are the SSL logging features, and how do I activate them?</A> | ||
| 1130 | </H3> | ||
| 1131 | |||
| 1132 | <P> | ||
| 1133 | Note: you do <B>not</B> need to compile SSL support into mod_log_sql | ||
| 1134 | in order to simply use it with a secure site. You only need to compile | ||
| 1135 | SSL support into mod_log_sql if you want to log SSL-specific data | ||
| 1136 | such as the cipher type used, or the keysize that was negotiated. | ||
| 1137 | If that information is unimportant to you, you can ignore this FAQ. | ||
| 1138 | |||
| 1139 | <P> | ||
| 1140 | By adding certain characters to your L<SMALL>OG</SMALL>SQLT<SMALL>RANSFER</SMALL>L<SMALL>OG</SMALL>F<SMALL>ORMAT</SMALL> | ||
| 1141 | string you can tell mod_log_sql to log the SSL cipher, the SSL keysize | ||
| 1142 | of the connection, and the maximum keysize that was available. This | ||
| 1143 | would let you tell, for example, which clients were using only export-grade | ||
| 1144 | security to access your secure software area. | ||
| 1145 | |||
| 1146 | <P> | ||
| 1147 | You can compile mod_log_sql with SSL logging support if you have | ||
| 1148 | the right packages installed. If you already have an SSL-enabled Apache | ||
| 1149 | then you by definition have the correct packages already installed: | ||
| 1150 | OpenSSL and mod_ssl. | ||
| 1151 | |||
| 1152 | <P> | ||
| 1153 | You need to ensure that your database is set up to log the SSL data. | ||
| 1154 | Issue the following commands to MySQL if your access table does not | ||
| 1155 | already have them: | ||
| 1156 | |||
| 1157 | <P> | ||
| 1158 | |||
| 1159 | <DL COMPACT> | ||
| 1160 | <DT> | ||
| 1161 | <DD>alter table access_log add column ssl_cipher varchar(25); | ||
| 1162 | |||
| 1163 | <P> | ||
| 1164 | alter table access_log add column ssl_keysize smallint unsigned; | ||
| 1165 | |||
| 1166 | <P> | ||
| 1167 | alter table access_log add column ssl_maxkeysize smallint unsigned; | ||
| 1168 | </DD> | ||
| 1169 | </DL>Finally configure httpd.conf to activate the SSL fields. Note that | ||
| 1170 | this is only meaningful in a VirtualHost that is set up for SSL. | ||
| 1171 | |||
| 1172 | <P> | ||
| 1173 | |||
| 1174 | <DL COMPACT> | ||
| 1175 | <DT> | ||
| 1176 | <DD><VirtualHost 1.2.3.4:443> | ||
| 1177 | |||
| 1178 | <P> | ||
| 1179 | LogSQLTransferLogFormat AbHhmRSsTUuvc<B>Qqz</B> | ||
| 1180 | |||
| 1181 | <P> | ||
| 1182 | </VirtualHost> | ||
| 1183 | </DD> | ||
| 1184 | </DL>The last three characters (Qqz) in the directive are the SSL ones; | ||
| 1185 | see section <A HREF="node4.html#sub:Frmat">3.6.17</A> in the directives documentation for details | ||
| 1186 | of the L<SMALL>OG</SMALL>SQLT<SMALL>RANSFER</SMALL>L<SMALL>OG</SMALL>F<SMALL>ORMAT</SMALL> directive. | ||
| 1187 | |||
| 1188 | <P> | ||
| 1189 | Restart Apache, then perform some hits on your server. Then run the | ||
| 1190 | following select statement: | ||
| 1191 | |||
| 1192 | <P> | ||
| 1193 | |||
| 1194 | <DL COMPACT> | ||
| 1195 | <DT> | ||
| 1196 | <DD>mysql> select remote_host,request_uri,ssl_cipher,ssl_keysize,ssl_maxkeysize | ||
| 1197 | |||
| 1198 | <P> | ||
| 1199 | from access_log where ssl_cipher is not null; | ||
| 1200 | |||
| 1201 | <P> | ||
| 1202 | </DD> | ||
| 1203 | </DL> | ||
| 1204 | <DIV ALIGN="CENTER"> | ||
| 1205 | <TABLE CELLPADDING=3 BORDER="1"> | ||
| 1206 | <TR><TD ALIGN="LEFT">remote_host</TD> | ||
| 1207 | <TD ALIGN="LEFT">request_uri</TD> | ||
| 1208 | <TD ALIGN="LEFT">ssl_cipher</TD> | ||
| 1209 | <TD ALIGN="LEFT">ssl_keysize</TD> | ||
| 1210 | <TD ALIGN="LEFT">ssl_maxkeysize</TD> | ||
| 1211 | </TR> | ||
| 1212 | <TR><TD ALIGN="LEFT">216.190.52.4</TD> | ||
| 1213 | <TD ALIGN="LEFT">/dir/somefile.html</TD> | ||
| 1214 | <TD ALIGN="LEFT">RC4-MD5</TD> | ||
| 1215 | <TD ALIGN="LEFT">128</TD> | ||
| 1216 | <TD ALIGN="LEFT">128</TD> | ||
| 1217 | </TR> | ||
| 1218 | <TR><TD ALIGN="LEFT">216.190.52.4</TD> | ||
| 1219 | <TD ALIGN="LEFT">/dir/somefile.gif</TD> | ||
| 1220 | <TD ALIGN="LEFT">RC4-MD5</TD> | ||
| 1221 | <TD ALIGN="LEFT">128</TD> | ||
| 1222 | <TD ALIGN="LEFT">128</TD> | ||
| 1223 | </TR> | ||
| 1224 | <TR><TD ALIGN="LEFT">216.190.52.4</TD> | ||
| 1225 | <TD ALIGN="LEFT">/dir/somefile.jpg</TD> | ||
| 1226 | <TD ALIGN="LEFT">RC4-MD5</TD> | ||
| 1227 | <TD ALIGN="LEFT">128</TD> | ||
| 1228 | <TD ALIGN="LEFT">128</TD> | ||
| 1229 | </TR> | ||
| 1230 | </TABLE> | ||
| 1231 | </DIV> | ||
| 1232 | |||
| 1233 | <P> | ||
| 1234 | |||
| 1235 | <DL COMPACT> | ||
| 1236 | <DT> | ||
| 1237 | <DD> | ||
| 1238 | </DD> | ||
| 1239 | </DL> | ||
| 1240 | <P> | ||
| 1241 | <HR> | ||
| 1242 | <!--Navigation Panel--> | ||
| 1243 | <A NAME="tex2html219" | ||
| 1244 | HREF="node6.html"> | ||
| 1245 | <IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A> | ||
| 1246 | <A NAME="tex2html215" | ||
| 1247 | HREF="documentation.html"> | ||
| 1248 | <IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A> | ||
| 1249 | <A NAME="tex2html209" | ||
| 1250 | HREF="node4.html"> | ||
| 1251 | <IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A> | ||
| 1252 | <A NAME="tex2html217" | ||
| 1253 | HREF="node1.html"> | ||
| 1254 | <IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A> | ||
| 1255 | <BR> | ||
| 1256 | <B> Next:</B> <A NAME="tex2html220" | ||
| 1257 | HREF="node6.html">About this document ...</A> | ||
| 1258 | <B> Up:</B> <A NAME="tex2html216" | ||
| 1259 | HREF="documentation.html">Installing and Running mod_log_sql</A> | ||
| 1260 | <B> Previous:</B> <A NAME="tex2html210" | ||
| 1261 | HREF="node4.html">3 Configuration</A> | ||
| 1262 | <B> <A NAME="tex2html218" | ||
| 1263 | HREF="node1.html">Contents</A></B> | ||
| 1264 | <!--End of Navigation Panel--> | ||
| 1265 | <ADDRESS> | ||
| 1266 | Chris Powell | ||
| 1267 | 2002-12-18 | ||
| 1268 | </ADDRESS> | ||
| 1269 | </BODY> | ||
| 1270 | </HTML> | ||
