背景
分布式日志方案
作为互联网公司,每天庞大的日志数据将是一笔宝贵的财富,对大规模日志数据进行采集、追踪、处理将是非常有收益的。一些开源项目的出现,也极快地促进了这个方面工作的进展。
本文针对据目前流行的日志框架,主要根据互联网的一些资料,结合自己的一些了解,对一些关键因素进行横向的对比,比便对技术选型提供参考。
关键要素
配置(Configuration)
客服端如何发现服务端?(不好的方式:固定配置。好的方式:基于zookeeper的pub-sub)
怎么配置消息路由?(点对点;广播;通过brokers路由消息(kafka))
容错(Failure and Recovery)
当集群中的一个节点出错,系统是如何什么方式进行buffer的?
系统是否保证数据传输过程的高可用,一旦发送,即保证到达。
系统是否支持树状集群。
维护管理(Maintenance)
本地的日志是否可以被配置成持久化,都提供了哪些支持?
如果日志数据被发送,消息是否是有序的?
Kafka
Kafka是一个大型分布式日志框架,实际更是消息中间件(类似RabbitMQ,ActiveMQ,etc)。但是他不同于一般的消息中间件,不遵从消息队列的协议,一般消息中间件的协议里面消息是不能被消费者删除掉的(或者标记成删除)。
体系架构:
Kafka设计的目标:高吞吐量
数据被存储在OS pagecache,这使得消息的数据存储不能可能造成out of memory。Kafka
宣称他们改进了Varnish的pagecache-centric design。消息在brokers上被保存在文件上并建索引。消息根据到达的时间戳是有序的, 不产生二次索引,这样就可以很容易进行顺序文件访问和高效的磁盘扫描,即便是在数据量很大的情况下。文件通过Java中的 FileChannel.transferTo发送,操作系统层面是sendFile(),这样避免了额外的数据考虑。这个号称“Zero-copy”的机制比直接存内存的消息队列性能好上很多,具体原因可以看主创团队如何解释。
消息的状态维护是消费者自己负责的,通过Zookeeper来协调一致性。负载均衡和分布式消息的分区也是Zookeeper来实现的。这意味着,所有消息随机的分布在各个broker上,每个broker都注册到Zooker上。每个消息的生产者可以通过broker列表来选择一个broker去发送消息。Kafka在producer和broker层都不提供保障机制。消费端负责保存消息状态。但是Broker可以保留缓存一个固定时间段的消息。比如LinkderIn保留一个星期的数据在每个broker上,这意味着如果消费者fail,那么在一个星期内,这个消费者如果重启,它能够衔接上原来的顺序接着消费。
Pros
• 支持发布/订阅机制
• 通过OS pagecache + sendfile(),JVM内存占用低
• 客户端API支持多语言
• Brokers不保存状态,有助于吞吐量的提升
• 使用ZooKeeper来做配置管理和容错
Cons
• 用Scala开发实行,必须跑在JVM上
• 没有消息可靠性保证,必须自己去监控消息数据丢失
• 没有像Flume数据流的概念,必须通过订阅消息的方式
See Also
• Kafka Design Document
• Why is Kafka faster than other Message Queues?
• Really good presentation from LinkedIn on Kafka's architecture.
• Kafka whitepaper
Flume
Flume是一个分布式、可靠、高可用的海量日志聚合系统,支持在系统中定制各类数据发送方,用于收集数据;同时,Flume提供对数据的简单处理,并写到各种数据接收方的能力。
Flume 在0.9.x and 1.x之间有较大的架构调整,1.x版本之后的改称Flume NG,0.9.x的称为Flume OG。New和Old的分界岭如下。
体系架构:
Flume NG 体系架构
Flume OG 体系架构
Flume NG在之前版本的基础上进行了重构和精简,去除了Zookeeper对于集中式配置管理、负载均衡和集群管理的支持,而专注于对数据流的采集和传输。对于每个服务器Node的配置,都需要自行在Node上配置。没法说这样的简化是好是坏,需求不一样,评价自然不同。因为Flume OG已经不再进行版本更新,所以后面讨论的Flume都是指Flume NG。
Flume Age是一个运行在JVM中的进程,主要任务是把Event(消息)从外部的一个source开始流向到下一个结点。Flune NG 有一个“数据流”的概念。
数据源(source):消费Events消息,并把消息传递出去。比如一个Avro的source能够接收来自Avro客户端采集到的或者其他Agent的sink发送过来的Event消息。当source接收到Event,它把消息保存到一个或者多个channel中,直到消费者通过sink来消费Event。sink把消息从channel中移出,并放到外部的存储(如HDFS,通过HDFS sink)或者是把消息推向另外一个Flume Agent的source。
Flume提供了各种source的实现,包括Avro Source、Exce Source、Spooling Directory Source、NetCat Source、Syslog Source、Syslog TCP Source、Syslog UDP Source、HTTP Source、HDFS Source,etc。
Flume也提供了各种sink的实现,包括HDFS sink、Logger sink、Avro sink、File Roll sink、Null sink、HBase sink,etc。
Flume对于Channel,则提供了Memory Channel、JDBC Chanel、File Channel,etc。
Pros
可靠,多层消息容错保障机制。
由Cloudera支持,已经有整套的log到HDFS实现
基于配置部署即可,不需要额外的开发工作
source、sink、channel有丰富的协议、门类实现
Cons
Java实现,必须运行在JVM上
如果sink堵塞,会产生大量的备份日志
没有publish/subscribe机制
Flume已经停止开发,Flume NG的版本正在逐渐稳定中
负载均衡、集群管理、配置管理需要自己集成其他例如Zookeeper等框架实现
See Also
• Flume User Guide.
• Flume Cookbook.
• Issues to be aware of when using Flume in production.
• blog post about production trouble with Flume. (This guy might not know what he was doing though.)
• publish/subscribe upcoming in Flume-NG
Chuwa
Chukwa是Hadoop的一个子项目,致力于大规模日志收集和分析。Chukwa是建立在Hadoop分布式文件系统(HDFS)和MapReduce框架之上,并继承了Hadoop的可扩展性和鲁棒性。Chukwa还包括一个灵活,功能强大的工具包,用于显示监测和分析结果,以充分利用此收集的数据。
体系架构:
其中主要的部件为:
1. Agent:负责采集最原始的数据,并发送给collectors。Agent添加了“watchdog”机制,一旦agent出现故障,会自动重启终止的数据采集进程,防止数据源的数据丢失。
2. Adaptor: 直接采集数据的接口和工具,chukwa对以下常见的数据来源包括命令行输出、log 文件和 httpSender等提供了实现。一个 agent 可以管理多个 adaptor 的数据采集。
3. Collectors:负责收集 agents 收送来的数据,并定时写入集群中。Collector负责把大量小文件合并成少量大文件,再写入集群,以发挥hadoop在处理少量大文件上的优势。Collertor层实现了负载均衡,agent随机从列表中选择collertor来发送数据。
4. map/reduce jobs:定时启动,负责把集群中的数据分类、排序、去重和合并
5. HICC:负责数据的展示。
Pros
hadoop的子项目,有一套统一的大数据支持的生态环境
yahoo推动,版本更新较快
有监测和分析结果显示的web-portal工具
有对于大量少文件合并成少量大文件的处理,能够最大化hadoop威力
对于数据分类、排查,去重、合并,现成的方案实现
内置了两个mapreduce作业,分别用于获取data和将data转化为结构化的log。存储到datastore(可以是数据库或者HDFS等)中
Conns
数据收集和处理的实时性要求不高
Java实现,运行在JVM上
可供个性化实现的接口不多,除了Storage端
比较重量级的一套方案,适用于大型的集群
See Also
• Chukwa Documentation
• Hadoop Wiki Chukwa
Scribe
Scribe是facebook开源的日志收集系统,在facebook内部已经得到大量的应用。 Scribe是基于一个使用非阻断C++服务器的thrift服务的实现。它能够从各种日志源上收集日志,存储到
一个中央存储系统 (可以是NFS,分布式文件系统等)上,以便于进行集中统计分析处理。它为日志的“分布式收集,统一处理”提供了一个可扩展的,高容错的方案。
体系架构:
Scribe从各种数据源上收集数据,放到一个共享队列上,然后push到后端的中央存储系上。当中央存储系统出现故障时,scribe可以暂时把日志写到本地文件中,待中央存储系统恢复性能后,scribe把本地日志续传到中央存储系统上。
(1) scribe agent
scribe agent实际上是一个thrift client。 向scribe发送数据的唯一方法是使用thrift client,scribe内部定义了一个thrift接口,用户使用该接口将数据发送给server。
(2) scribe
scribe接收到thrift client发送过来的数据,根据配置文件,将不同topic的数据发送给不同的对象。scribe提供了各种各样的store,如 file, HDFS等,scribe可将数据加载到这些store中。
(3) 存储系统
存储系统实际上就是scribe中的store,当前scribe支持非常多的store,包括file(文件),buffer(双层存储,一个主储存,一个副存储),network(另一个scribe服务器),bucket(包含多个 store,通过hash的将数据存到不同store中),null(忽略数据),thriftfile(写到一个Thrift TFileTransport文件中)和multi(把数据同时存放到不同store中)。
Pros
多客户端语言支持(Thrift提供支持)
C++实现
支持日志分类和自动切分(按照文件大小和时间切分)
配置简单、灵活
Conns
不再是一个活跃项目,Facebook正在逐渐冷落它
有可能会有单点故障(中心服务器、本地服务器、收集日志的客户端程序)
日志切换可能导致日志丢失
See Also
• Is Scribe Still Maintained?
• Why did Facebook develop a new logging service?. In particular check out Sam Rash's answer and presentation on Calligraphus and Facebook's data freeway.
• What's Up Scribe? - Otto's blog post on Scribe packaging and summary of Calligraphus.
概括
总的特性比对,可以用一张表概括之。比对表格
国内一些大型的互联网公司都各自在大数据的采集和分析上开始发力,同时也根据各自的情况“因地制宜”地发展了一些自己的日志系统,其实声势较大的首推淘宝的TimeTunnel。
TimeTunnel是一个基于thrift通讯框架搭建的实时数据传输平台,具有高性能、实时性、顺序性、高可靠性、高可用性、可扩展性等特点。TimeTunnel的设计和Kafka有一些类似,但是在不少地方都进行了改进。TimeTunnel在更新多个版本之后也已经开源,有兴趣的可以看看。
TimeTunnel wiki
TimeTunnel code
相关推荐
通过对网络流量、系统日志等数据的实时分析,可以及时发现并处理这些威胁。 5. 移动代理与多级监控 移动代理技术在分布式环境中扮演着类似免疫细胞的角色,可以在网络的不同位置自由移动,执行监控任务。多级监控...
如果将分布式系统比作高速公路网,每个前端的请求就相当于高速上行驶的车辆,而处理请求的应用就是高速上的收费站,在收费站上将车辆通行信息记录成日志,包括时间、车牌、站点、公路、价格等,如果将所有收费站上的...
在日志分析中,日志被视为系统的"感官",因为它们记录了系统的各种活动和异常,为安全分析提供了丰富的信息来源。然而,日志数据通常海量且复杂,传统的分析方法难以准确和及时地从中发现潜在的安全问题。Apache ...
6. **分布式系统**:在分布式环境中,不同节点之间的通信可以类比为信号传输,理解信号传播延迟、信号干扰等问题有助于设计高效且可靠的分布式架构。 7. **算法设计**:在信号处理中,有很多算法可以用于优化和解析...
总结来说,这个压缩包提供了一个基于JAVA的自定义日志库,其功能和架构设计受到了Apache Log4J的启发,同时考虑了在分布式系统中的应用。开发者可以利用这个库来记录和管理应用程序的运行日志,而且可能通过特定的...
它最初被设计为一个高吞吐量、低延迟的发布订阅消息系统,现在已经成为大数据领域的重要组件,广泛应用于日志收集、流式数据处理和实时分析等多个场景。 **1. Kafka的核心概念** - **主题(Topic)**:主题是Kafka...
它通过将一些常见的功能,如监控、日志记录和路由,从共享资源卸载到一个辅助服务实例中,从而提高分布式系统的性能和可维护性。本文将详细介绍大使模式的意图、解释、编程示例、适用场景、优点和权衡、实际应用以及...
例如,在分布式系统中,如果负载均衡策略调整导致请求处理时间先出现拐点并趋于平缓,可能意味着新的配置提供了更高的处理能力或更低的延迟。 以上是将化学平衡专题的知识点转换为IT领域的解释。然而,请注意,这些...
关于如何使用Zookeeper,它作为一个分布式协调服务,在分布式系统中的角色可以类比为一个提供集中服务的管理员,它管理着配置信息、控制数据同步、协调分布式锁和命名空间等。在使用Zookeeper时,我们需要遵循其设计...
Hadoop广泛应用于数据挖掘、日志分析、互联网搜索、推荐系统等领域。通过其分布式处理能力,可以处理PB级别的数据,帮助企业快速提取有价值的信息,支持决策制定。 三、Hadoop底层实现原理 1. HDFS:HDFS采用主从...
5. 区域特性:在部署分布式系统或云计算资源时,会根据区域的网络条件、法律法规、用户密度来选择服务器的位置,这与城市选址考虑气候、地形、水源等因素类似。 6. 技术创新与产业发展:新兴技术和高技术产业的发展...
在软件网络技术领域,这可以类比为数据的分类与管理,不同的数据类型(如日志、用户信息、无效链接等)需要采用不同的存储和处理策略。 生活垃圾的贮存是考虑到垃圾产生量的不均衡性和环境适应性。在IT领域,这类似...
基于代理的分布式数据挖掘系统设计.caj 基于信息熵的地学空间数据挖掘模型.caj 基于关联规则的舰艇故障诊断数据挖掘系统结构框架.caj 基于增强型算法并能自动生成规则的模糊神经网络控制器.pdf 基于多媒体数据库的...
基于代理的分布式数据挖掘系统设计.caj 基于信息熵的地学空间数据挖掘模型.caj 基于关联规则的舰艇故障诊断数据挖掘系统结构框架.caj 基于增强型算法并能自动生成规则的模糊神经网络控制器.pdf 基于多媒体数据库的...
基于代理的分布式数据挖掘系统设计.caj 基于信息熵的地学空间数据挖掘模型.caj 基于关联规则的舰艇故障诊断数据挖掘系统结构框架.caj 基于增强型算法并能自动生成规则的模糊神经网络控制器.pdf 基于多媒体数据库的...
- **数据集**:这是主框架存储的主要单元,类似于分布式系统中的文件。包括不同类型的数据集及其管理方式。 - **TSO 和 ISPF/PDF**:交互式会话管理和文件编辑工具,用于编写和调试程序。 - **作业控制语言 (JCL)**...
基于代理的分布式数据挖掘系统设计.caj 面向集成竞争情报系统的数据挖掘应用研究.caj 基于小波理论的数据挖掘方法研究.caj 基于粗糙集理论的数据挖掘算法及其应用研究.kdh 数据挖掘技术及其应用123.caj 基于数据挖掘...
RabbitMQ 支持多种消息协议,具备高可用性和伸缩性,是分布式系统中常用的消息队列服务之一。 #### 二、RabbitMQ 的核心概念 在了解 RabbitMQ 的具体工作方式之前,首先需要掌握几个核心概念: 1. **生产者...
- **日志收集**:Kafka可以作为日志聚合系统的中间层,收集各种应用的日志数据。 - **流处理**:与Spark、Flink等流处理引擎结合,实现数据的实时处理和分析。 - **消息传递**:作为企业服务总线(ESB)的组件,...
2. 邻居效应(Neighbor Effect):在分布式系统或云计算环境中,邻近节点的性能、资源消耗或行为可能会影响到同一集群中的其他服务。例如,如果一个服务在高负载下消耗大量CPU,可能导致其他服务的性能下降,这与Mr ...