On Mon, Aug 06, 2007 at 10:39:36AM +0200, Stig Sandbeck Mathisen wrote: > You have multiple ways for logs to enter: > > 514/udp - the good old standard. > > <whatever>/tcp - tcp syslog, queued on the client side, ensured on > the server side, possibly encrypted if data passes external > networks. > > local sockets, doors, etc... aaaaand ? how does it takes more than a fragment of CPU time ? > Logs may be filtered and classified according to priority, network, > server group, application, or facility. > > You have several places where the log data will go: > > Disk > > Database > > Some analysis application > > Custom statistics software with realtime graphs. > > IDS (Big, horrible, expensive, java-thingy. Prints Pretty Pictures) > > Local antispam-daemons. That takes CPU time but not accounted for the syslog daemon. > > Why would you need to bloat it for god's sake? It reminds me of so > > called network monitors that are so huge, that they mostly measure > > their own fat. A multi-foo syslog daemon is just plain silly. > > Not if you run a large network, cluster, server group or if you're an > internet service provider. If you get tens or hundreds of gigabytes > of logs every day, you need a good framework. A mail service for just > 1M users alone lots 1GB every few hours. Some of that is interesting, > and everything must be kept for a while. I totally fail to see why that would need any kind of CPU power to deal with. 10Gb/hour is merely 3Mo/s, so even with 10Mo/s peaks you're not even limited by your hard drive, and you don't even use a full 100Mbits link to get your datas. If you write applications that need more than one CPU to deal with such an enoooormous volume of data, then well, that's very interesting. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpPr2XqcxPu7.pgp
Description: PGP signature