分布式应用日志的集中化存储

对于很多分布式的大流量产品（比如：计数器）来说，随着服务器的分布，日志的集中管理就变得有些麻烦：比如前端多台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： 并发的数据分析 大规模系统的关键是设计方便让数据能够被多台服务器并发处理

作者： 车东 发表于：2006-01-18 12:01 最后更新于：2007-04-15 19:04
版权声明：可以转载，转载时请务必以超链接形式标明文章 分布式应用日志的集中化存储 的原始出处和作者信息及 本版权声明。
http://www.chedong.com/blog/archives/001111.html

« TWiki DakarRelease安装备忘 | (回到Blog入口)|(回到首页) | FeedBurner的更新频度: 30分钟同步一次 » [再编辑]