沙龙晃荡 | 去哪儿、陌陌、ThoughtWorks在主动化运维中的实践！10.28不见不散！

Send([]Data) error 

数据收集对象比较

今朝社区已经不乏大年夜量优良的数据收集对象，如有名的 Elastic Stack(Elasticsearch、Logstash、Kibana)中的 Logstash;CNCF 基金会琅绫擎有名的 Fluentd;InfluxData 公司 TICK Stack 中的 Telegraf;Google 出品为 Kubernetes 定制的 cAdvisor;Apache 基金会中的顶级项目 Flume。除了早期出生的诸如 Fluentd、Flume 等项目，其他项目都是为特定的平台营业定制而成，然后在随后的开源中赓续进化，变得更为通用。所以针对特定营业量身定制一款数据收集对象，是一个较为广泛的需求，也是出现如斯多“轮子”的重要原因。

让我们先来看看这几种有名开源数据收集对象有哪些特点。

Flume: 毋庸置疑，在流式数据处理的场景中，Flume 绝对是开源产品中的不二选择。其架构分为 Source、Channel、Sink 三部分，分别负责大年夜上游办事端获取数据、暂存数据以及解析并发送到下流。Flume 尤以灵活的扩大性和强大年夜的容错处理才能著称，异常合适在大年夜数据量的情况下做数据解析、中转以及高低游适配的工作。另一方面，Flume 也有一些缺点，如解析与发送都耦合在 Sink 模块，用户在编写 Sink 插件时不得不编写解析的逻辑，无法复竽暌姑一些惯例的解析方法;依附 JVM 运行情况，作为办事端法度榜样可以接收，然则安排和运行一个数据收集客户端法度榜样则变得相对粗笨;Flume 的设备融合了 Channel 部分，根本设备并不简单，用户想用起来须要的前置常识较多。

Logstash: 跟着 Elastic Stack 广受热捧，Logstash 天然也成为了技巧圈家喻户晓的对象，而 Logstash 本身的强大年夜功能也确切名副其实，其架构分为 Inputs、Filters 以及 Outputs 三部分。Inputs 作为所有输入端的集合，包含了各类数据输入插件;Filters 包含解析与数据转换两部分的插件集合，个中就包含了大年夜名鼎鼎的 Grok 解析方法，几乎可以解析所有类型的数据;Outputs 则是输出端的集合。毫无疑问，Logstash 几乎是应用 Elastic Stack 筹划时作为数据收集的独一选择。然则同样的，Logstash 也是基于 JVM 运行的，作为一个客户端法度榜样相对较重;当你欲望把它作为一个 agent 收集一些机械的根本信息时，它也力所不及。于是除了 Logstash 之外 Elastic Stack 家族中又增长了 beats 这个成员，然则如不雅仅仅选择 beats，其功能又太过薄弱。

Fluentd: Fluentd 也是数据收集界的老牌重量级选手，如不雅你玩容器、玩 Kubernetes，那么就必定据说过 CNCF(Cloud Native Computing Foundation)，而 Fluentd 就是个中的一员，成为了容器圈里多半人日记收集处理的首选。Fluentd 的架构与 Logstash 类似，也大年夜致分为输入、输出以及中心的处理层，但与之不合的是，个中心的处理层除了包含惯例的 filter(解析) 以及 buffer(数据暂存) 以外，还包含了一个 routing(路由) 功能，这是 Fluentd 的一大年夜特点。routing 功能使得 Fluentd 可以或许将本身称为一个同一的日记治理中心层，将所有的数据输入和输出治理起来，按照需求将输入的数据路由到一个或多个输出端。这是一个异常先辈的设计，其他类似的开源软件往往要写多份设备文件才能达到这个效不雅。Fluentd 由 CRuby 实现，机能表示优良但依附 Ruby 情况;相较于前面两者，Fluentd 插件支撑相对较少;其设备也过于复杂，应用门槛较高。

Telegraf/cAdvisor: 这两款均是 Go 说话编写的┞冯对体系信息数据收集的开源对象，其侧重点在 metric 收集，相较于通用的日记收集和处理，其功能面较窄，然则机能方面均表示优良。Telegraf 合营 influxdb，可以让你对机械各个维度的信息管窥蠡测;而 cAdvisor 更是 Kubernetes 的亲儿子，处理容器资本信息几无敌手。然则这两款对象并无意于发力通用数据收集的功能，功能上可能无法知足一些日记收集的场景。

懂得了以上这些开源软件的特点后，下面我们开端深刻介绍构建一款数据收集对象会碰到哪些设计与挑衅，以此为你的营业量身定制。

数据收集对象设计

架构设计

主流数据收集对象的主架构基本分为 reader、parser，以及 sender 三部分，如图 1 所示。除了这三个日记收集惯例构成部分，还应当包含可选模块，如基于解析过后的数据转换 (filter/transformer) 以及数据暂存管道 (Channel/Buffer)。为了尽可能复竽暌姑，每个构成部分都应当是插件式的，可以编写不合类型插件并且灵活地组装。Channel/Buffer 部分也应当供给基于内存或者基于磁盘的选择。

图 1 数据收集架构设计

对于 Reader、Parser、Sender 等插件合营组装的营业数据收集单位，我们称之为一个运行单位 (Runner)，数据收集对象必须可以同时运行多个 Runner，且每个 Runner 可以支撑更新。

更新可以经由过程多种方法实现，最惯例的是手动更新设备然后重启;更好的设计是支撑热更新，不须要重启，主动辨认设备文件的变更;还可以设计一个漂亮的 web 界面做设备的变革，以此引导用户应用处解决数据收集设备复杂、用户应用门槛高的难题。所以在整体架构之上还应当构建一个简单的 API 层，支撑 web 界面的功能。

说话选择

　　推荐阅读

　　微软又推黑科技新招 Edge浏览器读网页

沙龙晃荡 | 去哪儿、陌陌、ThoughtWorks在主动化运维中的实践！10.28不见不散！【编辑推荐】微软联袂FB推出开源项目 打造共享神经收集模型微软Skype开启第二轮Cortana整合，可参加对话傍边作为助手微软>>>详细阅读

本文标题：数据收集工具的设计与最佳实践

地址：http://www.17bianji.com/lsqh/38064.html

 1/2    1