Re: [logs] Apache Logs

From: Bill Burge (billat_private)
Date: Tue Jan 29 2002 - 13:48:38 PST

  • Next message: Nate Campi: "Re: [logs] Apache Logs"

    Wow...  I too wish I could gen some real numbers for you, but all I have is anecdotal:
    Current host is an OpenBSD 2.9 running the generic syslog for that build, logging via UDP.  24 hours of web logs, from 4 apache servers, have broken the 5 million lines mark without loosing enough lines to make the log analyzer complain about "broken" sessions.
    In the past, I had a heavily logging Cisco PIX sending to a Cobalt RAQ via UDP and lost many lines (I don't remember the numbers, but it was enough to consider it useless).  When we repointed it to a Sun Ultra 60, we got all lines of output.  With the nature of business being what it was, they were unwilling to pay me to quantify it - only to fix it.  ;-)
    Bill Burge
    *********** REPLY SEPARATOR  ***********
    On 1/29/2002 at 3:54 PM Marcus J. Ranum wrote:
    >>As you say,
    >>there's way too much in a busy server's access log.
    >I'm kind of curious about this: does anyone have any numbers they'd
    >care to share about logging rates and server log rates? How many
    >entries/second does a busy server's access log collect? I assume
    >they are stdio buffered so they come in approximately BUFSIZ chunks,
    >so it's probably pretty efficient, no? Does anyone have any numbers
    >for when syslogd begins to puke? Since it's using unix domain UDP
    >(in general) my guess is that the failure mode would be UDP packets
    >getting dropped on the output queue: which is system dependent. BSD
    >systems will do it differently from STREAMs systems which will
    >do it differently from Linux systems, etc, etc.
    >I guess I've heard a lot of people talk about syslog bogging down under
    >load but I've never seen any measures behind the claim; can anyone
    >provide some hard information? I don't feel like writing a syslogd torture
    >test - has anyone? Are we operating on hearsay?
    >Marcus J. Ranum          Chief Technology Officer, NFR Security, Inc.
    >To unsubscribe, e-mail: loganalysis-unsubscribeat_private
    >For additional commands, e-mail: loganalysis-helpat_private
    To unsubscribe, e-mail: loganalysis-unsubscribeat_private
    For additional commands, e-mail: loganalysis-helpat_private

    This archive was generated by hypermail 2b30 : Tue Jan 29 2002 - 14:01:20 PST