几十条业务线日志系统如何收集处理?

  在互联网迅猛发展的今天 各大厂发挥十八般武艺的收集用户的各种信息,甚至包括点击的位置,我们也经常发现自己刚搜完一个东西,再打开网页时每个小广告都会出现与之相关联的商品或信息,在感叹智能的同时不惊想 什么时候泄露的行踪。

  许多公司的业务平台每天都会产生大量的日志数据。收集业务日志数据,供离线和在线的分析系统使用,正是日志收集系统的要做的事情。

  用户的数据除了这种后台默默的收集外,还有各种运行的日志数据和后台操作日志,因此每个业务可以算是一种类型的日志,那稍大点的公司就会有几十种日志类型要收集,而且业务都分布到不同的服务器上,这就导致了日志的汇集的困难,

   在此可以用Flume来解决此类问题,参考以下架构。

  Flume是Cloudera提供的一个高可用的,高可靠的,分布式的海量日志采集、聚合和传输的系统,目前已经是Apache的一个子项目。

  Flume作为一个日志收集工具,非常轻量级,基于一个个Flume Agent,能够构建一个很复杂很强大的日志收集系统,它的灵活性和优势, 高可用性,高可靠性和可扩展性是日志收集系统所具有的基本特征。主要体现在如下几点:

  1. 模块化设计:在其Flume Agent内部可以定义三种组件:Source、Channel、Sink
  2. 组合式设计:可以在Flume Agent中根据业务需要组合Source、Channel、Sink三种组件,构建相对复杂的日志流管道
  3. 插件式设计:可以通过配置文件来编排收集日志管道的流程,减少对Flume代码的侵入性
  4. 可扩展性:我们可以根据自己业务的需要来定制实现某些组件(Source、Channel、Sink)
  5. 支持集成各种主流系统和框架:像Hadoop、HBase、Hive、Kafka、ElasticSearch、Thrift、Avro等,都能够很好的和Flume集成
  6. 高级特性:Failover、Load balancing、Interceptor等

  Flume支持在日志系统中定制各类数据发送方,用于收集数据;同时,Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。

  注:当前Flume有两个版本Flume 0.9X版本的统称Flume-og,Flume1.X版本的统称Flume-ng。由于Flume-ng经过重大重构,与Flume-og有很大不同,使用时请注意区分。

Flume的优势

      1.  Flume可以将应用产生的数据存储到任何集中存储器中,比如HDFS,HBase

      2.  当收集数据的速度超过将写入数据的时候,也就是当收集信息遇到峰值时,这时候收集的信息非常大,甚至超过了系统的写入数据能力,这时候,Flume会在数据生产者和数据收容器间做出调整,保证其能够在两者之间提供一共平稳的数据.

     3.   提供上下文路由特征

     4.   Flume的管道是基于事务,保证了数据在传送和接收时的一致性.

     5.   Flume是可靠的,容错性高的,可升级的,易管理的,并且可定制的。 

Flume具有的特征:

    1. Flume可以高效率的将多个网站服务器中收集的日志信息存入HDFS/HBase中

    2. 使用Flume,我们可以将从多个服务器中获取的数据迅速的移交给Hadoop中

    3. 除了日志信息,Flume同时也可以用来接入收集规模宏大的社交网络节点事件数据,比如facebook,twitter,电商网站如亚马逊,flipkart等

    4. 支持各种接入资源数据的类型以及接出数据类型

    5. 支持多路径流量,多管道接入流量,多管道接出流量,上下文路由等

    6. 可以被水平扩展

Flume的结构

  Agent主要由:source,channel,sink三个组件组成.

Source:

    从数据发生器接收数据,并将接收的数据以Flume的event格式传递给一个或者多个通道channal,Flume提供多种数据接收的方式,比如Avro,Thrift,twitter1%等

Channel:

   channal是一种短暂的存储容器,它将从source处接收到的event格式的数据缓存起来,直到它们被sinks消费掉,它在source和sink间起着一共桥梁的作用,channal是一个完整的事务,这一点保证了数据在收发的时候的一致性. 并且它可以和任意数量的source和sink链接. 支持的类型有: JDBC channel , File System channel , Memort channel等.

sink:

    sink将数据存储到集中存储器比如Hbase和HDFS,它从channals消费数据(events)并将其传递给目标地. 目标地可能是另一个sink,也可能HDFS,HBase.

它的组合形式举例:

  以上介绍的flume的主要组件

下面介绍一下Flume插件:

1. Interceptors拦截器

   用于source和channel之间,用来更改或者检查Flume的events数据

2. 管道选择器 channels Selectors

   在多管道是被用来选择使用那一条管道来传递数据(events). 管道选择器又分为如下两种:

   默认管道选择器:  每一个管道传递的都是相同的events

  多路复用通道选择器:  依据每一个event的头部header的地址选择管道.

3.sink线程

 用于激活被选择的sinks群中特定的sink,用于负载均衡.

由于Flume的日志源可以来自另外一个Flume,可以同时发送给多个目标,且Flume自身可以做负载,由此可以设计出高可用,可扩展,高负载的日志架构。

应用场景

     比如我们在做一个电子商务网站,然后我们想从消费用户中访问点特定的节点区域来分析消费者的行为或者购买意图. 这样我们就可以更加快速的将他想要的推送到界面上,实现这一点,我们需要将获取到的她访问的页面以及点击的产品数据等日志数据信息收集并移交给Hadoop平台上去分析.而Flume正是帮我们做到这一点。现在流行的内容推送,比如广告定点投放以及新闻私人定制也是基于次,不过不一定是使用FLume,毕竟优秀的产品很多,比如facebook的Scribe,还有Apache新出的另一个明星项目chukwa,还有淘宝Time Tunnel。

flume+kafka+storm+mysql构建大数据实时系统

 

Flume+HDFS+KafKa+Strom实现实时推荐,反爬虫服务等服务在美团的应用

Flume+Hadoop+Hive的离线分析网站用户浏览行为路径

 Flume+Logstash+Kafka+Spark Streaming进行实时日志处理分析

Flume+Spark + ELK新浪数据系统实时监控平台

 列举不完了 ……………………………………………………………………

 

时间: 2024-09-21 09:28:23

几十条业务线日志系统如何收集处理?的相关文章

教你一步搭建Flume分布式日志系统

在前篇几十条业务线日志系统如何收集处理?中已经介绍了Flume的众多应用场景,那此篇中先介绍如何搭建单机版日志系统. 环境 CentOS7.0       Java1.8 下载 官网下载 http://flume.apache.org/download.html 当前最新版  apache-flume-1.7.0-bin.tar.gz 下载后上传到CentOS中的/usr/local/ 文件夹中,并解压到当前文件中重命名为flume170    /usr/local/flume170 tar -

日志系统之Flume日志收集

最近接手维护一个日志系统,它用于对应用服务器上的日志进行收集然后提供实时分析.处理并最后将日志存储到目标存储引擎.针对这三个环节,业界已经有一套组件来应对各自的需求需求,它们是flume+kafka+hdfs/hbase.我们在实时分析.存储这两个环节,选择跟业界的实践相同,但agent是团队自己写的,出于对多种数据源的扩展需求以及原来收集日志的方式存在的一些不足,于是调研了一下flume的agent.结果是flume非常契合我们的实际需求,并且拥有良好的扩展性与稳定性.于是打算采用flume的

日志系统之扩展Flume-LineDeserializer

继续闲聊日志系统,在之前的博文里已提到我们在日志收集上的选择是flume-ng.应用程序将日志打到各自的日志文件或指定的文件夹(日志文件按天滚动),然后利用flume的agent去日志文件中收集. Deserializer简介 flume将一条日志抽象成一个event.这里我们从日志文件中收集日志采用的是定制版的SpoolDirectorySource(我们对当日日志文件追加写入收集提供了支持).从日志源中将每条日志转换成event需要Deserializer(反序列化器).flume的每一个s

日志系统之Flume采集加morphline解析

概述 这段时间花了部分时间在处理消息总线跟日志的对接上.这里分享一下在日志采集和日志解析中遇到的一些问题和处理方案. 日志采集-flume logstash VS flume 首先谈谈我们在日志采集器上的选型.由于我们选择采用ElasticSearch作为日志的存储与搜索引擎.而基于ELK(ElasticSearch,Logstash,Kibana)的技术栈在日志系统方向又是如此流行,所以把Logstash列入考察对象也是顺理成章,Logstash在几大主流的日志收集器里算是后起之秀,被Elas

通过日志监控并收集Java应用程序性能数据

引言 系统日志是应用程序问题诊断及运行维护的重要工具.Logback.Log4j 是常用于 Java 平台的日志记录 API. 目前大部分产品只是将系统重要参数.状态的变化及异常信息通过日志输出.本文将要介绍的 Perf4j 是一款专门用 于 Java 服务器端代码计时.记录日志和监控结果的开源工具包.Perf4j 对常用日志工具包进行了扩展,能够将得到的原 始性能数据进行统计并发布到可定制的输出源,如控制台.日志文件.JMX 等.Perf4j 提供了多种方式与 Java 代码集成 ,开发和系统

通过shell和redis来实现集群业务中日志的实时收集分析

在统计项目中,最难实施的就是日志数据的收集.日志分布在全国各个机房,而且数据量比较大,像rsync+inotify这种方式显然不能满足快速日志同步的要求. 当然大家也可以用fluentd和flume采集日志数据,除了这个我们也可以自己写一套简单的. 我写的这个日志分析系统 流程是: 在客户端收集数据,然后通过redis pub方式把数据发给服务端 2   服务器端是redis的sub    他会把数据统一存放在一个文件,或者当前就过滤出来 客户端收集日志的更新数据 #!/bin/bash DAT

日志系统之基于Zookeeper的分布式协同设计

最近这段时间在设计和实现日志系统,在整个日志系统系统中Zookeeper的作用非常重要--它用于协调各个分布式组件并提供必要的配置信息和元数据.这篇文章主要分享一下Zookeeper的使用场景.这里主要涉及到Zookeeper在日志系统中的使用,但其实它在我们的消息总线和搜索模块中也同样非常重要. 日志元数据 日志的类型和日志的字段这里我们统称为日志的元数据.我们构建日志系统的目的最终主要是为了:日志搜索,日志分析.这两大块我们很大程度上依赖于--ElasticSearch(关于什么是Elast

ELK统一日志系统的应用

收集和分析日志是应用开发中至关重要的一环,互联网大规模.分布式的特性决定了日志的源头越来越分散, 产生的速度越来越快,传统的手段和工具显得日益力不从心.在规模化场景下,grep.awk 无法快速发挥作用,我们需要一种高效.灵活的日志分析方式,可以给故障处理,问题定位提供更好的支持.基于全文搜索引擎 Lucene 构建的 ELKstack 平台,是目前比较流行的日志收集方解决方案. ELK系统的部署按照官方文档操作即可,相关资料也很多,这篇文章更多的关注三个组件的设计和实现,帮助大家了解这个流行的

日志系统之定时任务执行引擎

概述 最近这段时间在强化日志系统自身的稳定性和可靠性,一个稳定可靠的系统离不开监控,我们这里谈及的监控除了服务是否存活还有这些组件的核心metrics采集与抓取,为此我们将这些任务做成了定时任务来执行.由于大致的思路以及设计已经成型,所以今天来分享一下日志系统在定时任务这块的选型与设计. 组件运行时监控 从我之前分享的文章中不难看出我们日志系统的各个组件的选型: 采集agent : Flume-NG 消息系统 : Kafka 实时流处理 : Storm 分布式搜索/日志存储(暂时) : Elas