概述
对于很多分布式的大流量产品（比如：计数器）来说，随着服务器的分布，日志的集中管理就变得有些麻烦：比如前端多台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
最后
以上就是鲜艳小蜜蜂为你收集整理的分布式应用日志的集中化存储的全部内容，希望文章能够帮你解决分布式应用日志的集中化存储所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
本图文内容来源于网友提供，作为学习参考使用，或来自网络收集整理，版权属于原作者所有。
发表评论 取消回复