Also, I don't need to worry about files across servers and rolling log files that file logs usually entail.
1) REST+JSON API made integrating it super-simple (had to add a single line to NLog to set MIME types to make Couch happy)
2) We use SDB in our service; so if SDB blows up, not only would things break, we couldn't easily get at our logs to see why.
Biggest drawback I've found to Couch in this context is that it loves to devour disk space; you quickly learn to cron some compaction jobs.
-------- Please vote for Peecho in the race for the Accenture Innovation Awards: http://goo.gl/3xLlC
We use a decidedly low-tech scheme. We log everything to files on local storage. Then we use a command line tool to periodically sync these to S3. Each instance gets its own folder.
When we want to query, we have several options. We can run good old grep or tail on one instance -- or on several instances with pssh. We can use the S3 command line tool to process multiple files on an admin machine. Or we could use Hadoop to mess with files in S3 (haven't done that yet...!)
Not as snazzy as having each log record stored in a structured fashion, but it's a lot cheaper than SimpleDB.
What do you do when your fleet gets big enough that you start getting throttled?
What's the query latency?
How do you delete old log data?
