对于很多分布式的大流量产品（比如：计数器）来说，随着服务器的分布，日志的集中管理就变得有些麻烦：比如前端多台Web Server的日志统计，传统的解决方法是定期（每小时，每天）截断日志，然后通过FTP 传到一台服务器上进行统一处理，在有些日志的计算处理前，还需要考虑日志的排序问题。
[App Server] [App Server] [App Server] [App Server]
\ | | /
via FTP / SCP daily cron
| |
[Logging Server] (sort merge)
/ \
[other stats] [other stats]
这样的日志同步可以支持几台到十几台规模的并发服务。单当管理的服务器达到几十台，而且有大量的服务器中间会有上线/下线变更的时候，集中的日志定期同步更显得非常难于管理，而日志的同步由于要避开白天的高峰，往往需要用凌晨的低峰时段进行同步，24小时下来，上G的日志同步也是风险很高的操作。而成为瓶颈的日志排序合并操作也会妨碍其他后续计算的周期。
如果能实现应用分布但日志集中式的远程存储，以上的定期(压缩)同步和合并排序就都显得不必要了，而且日志的主要瓶颈：排序汇总也能省略。集中式的日志服务显然不是通过网络文件系统(NFS)，保证日志的效率和系统的容错性的关键在于：日志的处理不是要求5个9以上的精确度（少量的出入是可以接受的），因此通过UDP协议或者方式实现在小局域网内部的日志广播，然后在后面多台服务器上实现各种日志处理的并发计算。而日志的截断等操作，也可以在后台实现，从而保证前台服务的不中断进行情况下的后台并发实时计算。使用集中化的日志(centralized logging)服务后，网络结构如下：
[App Server] [App Server] [App Server] [App Server]
\ | | /
via UDP or Broadcasting
| | |
[Logging Server(syslogd)] <=backup=> [Logging Server(udplogd)] [Real time monitor]
更多参考资料：
Mod_log_spread: 基于广播的日志分布(Apache模块)
Interpreting the Data: Parallel Analysis with Sawzall： 并发的数据分析 大规模系统的关键是设计方便让数据能够被多台服务器并发处理
版权声明：可以转载，转载时请务必以超链接形式标明文章 分布式应用日志的集中化存储 的原始出处和作者信息及本版权声明。
http://www.chedong.com/blog/archives/001111.html
Comments
帅
呵呵
我前天写blog处理500G数据 就是日志的事
UDP(+buffer) 汇总收集
及时归档处理才有搞头 而且效率高 比js好的少 不过就是架构上得考虑好
由: windtear 发表于 2006年01月18日 下午01时23分
这样好搞吗？
网络不好拿不时日志不断的发？
由: etng 发表于 2006年01月19日 夜间12时11分
还是用类似计数器那样在网页里面内嵌代码来拿到日志，那样可以很方便的做日志集中
由: sbear 发表于 2006年01月22日 下午02时40分
写了一个Python的cluster处理Log，一个分部的存储底层，现在的速度20个计算节点(其中18个是存储节点)160s处理掉43G的Log.
日至集中还是直接udp发送最方便，少了很多中间环节，处理起来方便。也不用再排序了.
由: scaner 发表于 2007年01月23日 早上08时06分