优势：只需要在页面代码中操作，不需要配置服务器；数据的获取有较高的可控性，可以只在需要统计的页面植入代码；能够获取点击、响应等数据；不需要担心缓存等的影响，数据的准确度较高；可用第三方cookie实现多网站跟踪比较。
缺陷：当浏览器禁止接收图片或者禁用JS时，都可能导致数据获取的失败；只在应用服务层操作，无法获取后台的数据；对图片、文件等请求信息的获取难度相对较大；过多地JS可能导致页面性能的下降，虽然这方面的影响一般可以忽略。
Access.log
优势：简单方便，不需要修改网页代码，可以自定义日志格式；较多的现成的日志分析工具的支持（AWStats、Webalizer等）；获取网络爬虫数据的唯一途径；可以收集底层数据供反复的分析。
缺陷：数据的质量较低，网站日志包含所有日志数据，包括CSS、图片、脚本文件的请求信息，所以过滤和预处理来提升数据质量必不可少；页面缓存导致浏览无日志记录，这个是比较致命的。
分布式日志收集系统Facebook-Scribe
https://github.com/facebook/scribe
Scribe的主要功能
1.支持多种存储类型：7种并且可扩展
2.日志自动切分功能：按文件大小和时间切分
灵活的客户端
（1）支持多种常用语言（Thrift提供支持）；
（2）可与应用系统集成；可以作实现独立客户端
支持日志分类功能（Facebook有上百种日志分类）
其他功能
（1）连接池
（2）灵活的日志缓存大小
（3）多线程功能(消息队列)
（4）scribe服务器之间可以转发日志
以上功能都是可以通过配置文件来灵活配置
Scribe使用方案
（1）和产生日志文件的应用系统集成，scribe能够和各种应用系统很好的集成是因为它提供几乎所有的开发语言的开发包
（2）应用系统在本地产生日志文件，使用一个独立运行的客户端程序同样，独立的客户端也可以采用各种语言开发。
Scribe问题
1、单点故障问题
有三个地方存在单点故障：
（1）中心服务器
（2）本地服务器
（3）收集日志的客户端程序
2、日志丢失问题
当日志文件发生切分的时候可能导致日志丢失
3、历史日志收集问题
4、scribe服务器挂了没有及时通知
Scribe的系统架构
如上图所示：Scribe从各种数据源上收集数据，放到一个共享队列上，然后push到后端的中央存储系统上。当中央存储系统出现故障时，scribe可以暂时把日志写到本地文件中，待中央存储系统恢复性能后，scribe把本地日志续传到中央存储系统上。
Scribe的技术架构
如上图所示：Scribe服务器底层数据通信框架是Thrift，Thrift也是Facebook开源的，并得到了广泛的使用。也用到了C++的准标准库boost，主要使用共享指针和文件相关的功能。Thrift也用到了libevent开发库和socket编程技术。
Scribe的部署结构
分布式日志收集系统Flume
类似scribe，思路差不多
https://github.com/cloudera/flume
正如前面提到的，Flume采用了分层架构：分别为agent，collector和storage。其中，agent和collector均由两部分组成：source和sink，source是数据来源，sink是数据去向。
Flume使用两个组件：Master和Node，Node根据在Master shell或web中动态配置，决定其是作为Agent还是Collector。
系统定制记录
有些业务日志，无法通过统一的方式设计，只能由各系统定制生产数据。
采用严格的参数规范
由filter,log触发保存日志的事件，数据仍由业务系统自行生产；
优势：灵活、丰富，可以满足各种业务日志。
缺陷：无法集中管理，加大开发人员工作量。
日志收集框架比较
