日志架构（一）背景

[size=xx-large]一 局势[/size]
在我厂工作3年有余了。整理一下关于日志中心研发架构的事情吧。时隔2年了，2012年的夏天，受董总任命，刘总突然遭受日志凌乱困扰，派去研发我厂的日志中心。当时情况混乱，群雄逐鹿，各系统日志记录情况迥异，无法收拾残局，我厂有没有明确的方案出台，刘总派吾挂帅出征，前去清剿，统一日志。

[size=xx-large]二 背景[/size]
[b]目标[/b]
用户行为分析；
降低日志记录的复杂度；
提升日志记录质量；

[b]问题[/b]
日志组件与代码耦合度高，并且缺乏规范性；
日志文件分散较广，难以收集；
日志保存分散，机器被格式化或者误删除操作，日志会丢失；

[b]现状[/b]
1.动态WEB
业务系统中开发公共action
日志记录代码与业务代码耦合
期望：日志中心，公共JS

2.静态HTML
业务系统中开发action
日志的记录与业务系统耦合度较高
有后端公共组件负责生成公共头信息
期望：日志中心，集中在前端解决

3.移动、WAP
WAP是应用层记录
转码
nginx记录了cookie,header,url后面的参数及upstream的日志，有部分数据需要经过业务系统

开放平台
客户端复杂，有浏览器，手机，前置机，无法规范记录日志行为，只能通过SDK为手段，用户驱动为导向进行日志记录
期望：日志中心和统一的SDK

手机客户端
手机客户端生产日志，并进行组装与缓存；
统一发送到AF服务端，服务端有专门的controller接收文件并保存到日志文件中
独立的controller
有一部分数据需要上传后获取，需要经过业务系统

地图
后端的日志和业务代码耦合，没有使用AOP
期望：推荐研究srcibe

[size=xx-large]我厂架构[/size]
[img]http://dl2.iteye.com/upload/attachment/0093/6550/da45a038-461e-37a7-a64a-530d5584d31a.gif[/img]


[size=xx-large]问题解答[/size]
1、PC客户端，移动客户端的日志收集问题，你怎么解决的？
PC和移动端，采取批量日志上传，首先本地缓存，当网络连接上的时候上传。

2、收集的日志为什么建了两个hadoop集群，仅为了区分原始数据与分析后数据吗？有什么深层次原因？
在进行hive运算的时候，执行大量的的map/reduce任务，导致系统卡死。而且读取的时候，文件夹会被锁上，无法写入。

3、日志分析展示用了什么工具吗？日志的全文检索呢？
用HIVE解析，购买了一套BI工具