原始日志量

每小时高的是否达到了 45303452条日志（四千五百多万条原始日志） ，某天日志量（这个随便选的）422110779 条（4亿两千多万）

需求

• 1）对原始日志按域名进行分析包括： 请求数分析、独立IP分析、PV分析、地区分布运营商分布分析（根据ip计算）、浏览器操作系统分布分析（根据原始日志的agent进行分析）、热点页面分析、文件类型分析
• 2）原始日志按域名、按天、按小时进行打包。

两种方案

方案１

• →logstash-forward(边缘设备)  
• → logstash (用logstast-before配置文件)
• → Kafka (同时依赖zookeeper)
• → logstash (用logstash-after配置文件)
• → elaticsearch 
• → python脚本
• → 统计日志本地然后上传到hadoop,各种统计结果到elasticsearch（nginx负载均衡）   
• →  界面展示

边缘节点服务器会产生很多用户请求日志，要对日志进行各种分析和原始日志打包，最终分析结果进行收费、让客户可以获取请求日志各种分析结果、为客户进行原始日志按域名按天按小时分割打包。

方案２

• –> filebeat(或flume)
• –> logstash
• –> kafka(kafka依赖zookeeper)
• –> spark统计计算
• –> 统计各种结果到elasticsearch（nginx负载均衡）
• –> 界面展示

–> flume(自定义sink插件、验证可行待完成)
–> 原始日志本地打包
–> 原始日志hadoop上传 (当然这里也可以用hbase进行日志存储)

大数据实时计算需要的几个基本组件（一定要注意版本问题，java大数据机器间通信用的是RPC 而不是restful_api,如果版本不对应很可能出现版本间的兼容问题）：

• 1.日志收集 -从CDN边缘节点服务器进行日志收集

• 2.日志缓存 -收集上来的日志存储到一个缓存设备

• 3.数据计算 -对收集的日志进行计算，域名请求数分析、地区统计等等

• 4.计算结果存储 -对各种分析结果进行存储，要方便查找

• 5.日志打包结果存储

  公司刚开始的日志系统分布：

• logstash-forward (边缘节点日志收集，上传到有logstash的机器)       -》

• kafka  强大的数据缓存组建          （由logstash收集日志到kafka）    -》

• elasticsearch (分布式、可扩展、实时的搜索与数据分析引擎)  (用logstash从kafka取出数据存到es)  ->

• spark（大规模数据计算引擎，从es取出原始日志然后通过spark计算结果）    -》

• elasticsearch （进行计算结果数据存储），hadoop（原始日志打包存储） -》

• nginx  + django服务  进行反向代理、负载均衡、地址隐藏            django进行界面展示-》

• 可客户直接访问观看

  版本

  zookeeper 3.4.7
  kafka_2.11-0.8.2.1
  logstash-2.2.2
  elasticsearch-2.4.6
  hadoop-2.6.4
  spark-1.6.1

  问题

  现在这样的系统由于经常出现问题，es报红，或者计算有问题等，这是由于刚开始一个人做完还没完全稳定就直接撤人了，转了几次到了我手里（因为我懂java，android但是部门基本上是以python为主）。到我手里了是个挑战也是一个机遇嘛，然后就开始了填坑之旅。。。。。。。。。。。。
  还有一点是这样不能够很好的保持数据的实时性。　

  改进：

  其中遇到也解决了各种问题，就举例最主要的两个。
      1.线上的客户投诉获取不到原始日志，没那么多时间弄懂了再改进所以解决是 –》 写python脚本（到了这家公司开始用与部门统一的python）—》功能是从elasticsearch获取到某个域名原始日志然后写入本地文件（虽然不会写，但是这么多年编程scala的大概对日志的处理逻辑还是能看懂的），本地压缩，然后python调用hadoop本地命令行将日志上传到hadoop，先临时解决了问题
      2.elasticsearch报红、kafka堆积
      不知道怎样解决，只能看日志了，尝试用elasticsearch升级到了5.5.2，发现不会出现这样的问题。  但是又出现了新的问题：spark不能兼容这样的es版本，  给老大反映情况（提了 我倾向的用python脚本计算这一条路和对es降级尝试的路），听命于领导就先对原来的elasticsearch-2.4.6进行了配置改动-但是发现还是偶尔会出现es报红的情况。    只能用另一条路用python脚本代替spark，使用es自身的聚合功能进行计算，这样就解决了问题。
      总结：所以最后的解决办法是 去掉spark        先用python脚本直接聚合统计方式请求es获取结果,这样也满足线上要求，就先这样了。

  结果：

• logstash-forward (边缘节点日志收集，上传到有logstash的机器)       -》

• kafka  强大的数据缓存组建          （由logstash收集日志到kafka）    -》

• elasticsearch (分布式、可扩展、实时的搜索与数据分析引擎)  (用logstash从kafka取出数据存到es)  ->

• python脚本（调用elasticsearch的resultful_api获取统计结果，同时打包原始日志到本地上传到hadoop）    -》

• elasticsearch （进行计算结果数据存储），hadoop（原始日志打包存储） -》

• nginx  + django服务  进行反向代理、负载均衡、地址隐藏            django进行界面展示-》

• 客户直接访问观看

  版本

  zookeeper 3.4.7       
  kafka_2.11-0.8.2.1   
  logstash-2.2.2    
  elasticsearch-5.5.2      
  hadoop-2.6.4   
  python以及python elasticsearch库

  现在的架构：

  公司在我刚开始接手的同时已经公司招聘了一个大数据人员（但不是本部门的），本部门也要有新项目有更大的数据量要计算需要跟他对接，但是等了好几个月仍然没有啥成果，老大忍不住了让我去看看他的大数据代码、提改进建议催进度（他主要用spark最终结果存到hbase，java写的代码），然后发现代码写的比较烂（因为java基本的静态变量 方法封装 继承多态等一看就是新手），业务逻辑也有点问题-跟老大反映，但是不同部门管不着也不能说啊，细节不说了，最终又开始了新架构的尝试之旅。

• 1.filbeat 边缘节点日志收集，上传到有logstash的机器（或者可以用flume)    -》

• 2.kafka  强大的数据缓存组件         （由logstash收集日志到kafka）    -》

• 3.spark（大规模数据计算引擎，从kafka取出日志，通过scala编写的spark代码把计算结果存入es）    -》

• 4.elasticsearch （进行计算结果数据存储） -》 

• 5.nginx + django   界面展示或接口让客户获取服务

同时并行的原始日志打包   （刚开始日志打包考虑到了用spark或者flume直接上传到hadoop，但是后来发现现有机器这样的速度赶不上实际需要，）

• 3.flume(自定义sink插件，filter插件 从kafka的另一个topic中获取日志数据，把日志按域名，按小时打包到本地）     -》
• 4.python 调用hadoop命令行上传本地打包好的日志到hadoop ->
• 5.nginx + django   界面展示或接口让客户获取服务

版本信息

apache-flume-1.6.0-bin  hadoop-2.6.4   kafka_2.11-1.0.0  spark-1.6.1-bin-hadoop2.6
elasticsearch-5.5.2     hbase         jdk1.8.0_144  logstash-6.1.1    zookeeper-3.4.5
jdk1.7.0_45(刚开始hadoop使用 后来spark要求更高就用了1.8版本） 

监控

当然每个阶段都需要增加监控，这里用的是zabbix监控配合脚本监控