DataPipeline可以帮企业数据集成解决哪些核心难题?

hugotu 发表了文章 • 0 个评论 • 83 次浏览 • 2018-05-11 17:18 • 来自相关话题

DataPipeline已经完成了很多优化和提升工作,可以很好地解决当前企业数据集成面临的很多核心难题。


1. 任务的独立性与全局性。

从Kafka设计之初,就遵从从源端到目的的解耦性。下游可以有很多个Consumer,如果不是具有这种解耦性,消费端很难扩展。企业做数据集成任务的时候,需要源端到目的端的协同性,因为企业最终希望把握的是从源端到目的端的数据同步拥有一个可控的周期,并能够持续保持增量同步。在这个过程中,源端和目的端相互独立的话,会带来一个问题,源端和目的端速度不匹配,一快一慢,造成数据堆积现象严重。所以,企业用户在建立一个数据任务之后,我们希望对任务进行缓冲的控制,避免数据丢失。


2. 任务并行化的方式。

如果企业客户有1000张数据表需要建立数据集成的任务,就要考虑用什么方式进行任务切分最佳。其中一种方式是把1000张表切分成若干个任务。这种情况下,Source Task的负载很难做到均衡,Sink Task可以消费多个Topics,依然存在负载不均的问题,每个任务负载多少张表其实是很难均衡的。每增加一个任务都会触发Rebalance机制。可以想象,每一张表都通过Source Connector和Sink Connector初始化一个源端和目的端任务,会大大增加Rebalance的开销。


3. 异构数据的映射。

在给企业客户做数据集成的时候,50%几率都会遇到一些脏活累活——异构数据源的映射(Mapping)。这个映射对很多互联网公司来说不是那么严重什么事儿,因为数据库设计的都比较符合规范,对字段的命名方式等都会比较“优雅”(统一)。但是在传统企业里,由于很多业务系统都会外包,还有一些意识的原因,导致数据库设计的没有那么规范和统一。用Kafka Connect做数据集成的时候,需要尽可能做到异构数据精准的还原,尤其金融行业客户对此要求比较高。另外,当确实遇到数据之间不匹配的情况时,可以在业务数据之间进行比较合理的映射。




另外,源端的Source Record包含了每一列的基本数据类型(INT16、STRING等)以及可选的meta信息(例如“name”)。目的端处理Sink Record的时候,需要依据基本数据类型以及meta信息决定映射关系。




4. Schema变化的处理策略。

给企业做数据集成的时候,需要根据数据源Schema的变化给出对应的处理策略。基于Kafka Connect框架,我们提供了以下几种处理策略:

(1)Backward Compatibility:可使用最新的Schema一致访问所有数据,e.g. 删除列、添加具有默认值的列。

(2)Forward Compatibility:可使用最旧的Schema一致访问所有数据,e.g. 删除具有默认值的列。

(3)Full Compatibility:可任意使用新旧Schema访问所有数据。


Kafka Connect推荐使用Backward Compatibility,这也是Schema Registry的默认值。另外,企业用户还会提出源端删除列,目的端需要忽略,源端添加具有默认值列,目的端需要跟随等需求,都以Task为单位进行配置和实现。

更多关于实时数据集成的问题,欢迎关注DataPipeline微信公众号,或直接访问官方网址申请试用:www.datapipeline.com
 

企业数据集成面临的4个挑战

hugotu 发表了文章 • 0 个评论 • 77 次浏览 • 2018-05-11 17:16 • 来自相关话题

什么是数据集成?最简单的应用场景就是:一个数据源,一个数据目的地,数据目的地可以是个数据仓库,把关系型数据库的数据同步到数据仓库里,就形成了一次数据集成。

我们先来看一个真实的数据集成案例。

G公司是DataPipeline的一个典型客户,拥有近千个数据源,类型主要包括Oracle、SQL Server、MySQL等。根据业务的需要和现有的基础设施情况,这些数据源分别需要同步到不同的目的端,类型主要包括MySQL、HDFS、Kafka等。基于以上背景,G公司的具体要求如下:

1. 需要支持约5TB日新增数据量的同步,今年将增长5-10倍。

2. 这些数据一部分数据源要求实时同步,另一部分可接受定时同步。

3. 缺乏强大的运维人才,现有数据源的业务承载压力有限,对压力非常的敏感,要求进行限流。

4. 从这些数据源到目的地的同步都是Kettle写脚本实现的,管理起来比较混乱,要求通过一个管理平台对任务进行集中化的配置和管理。

5. 上游的数据源和下游的数据目的都不稳定,随时可能出现各种问题,要求通过一个高可用的平台以减少数据传输中断的影响。

6. 当数据同步任务被随机的暂停/恢复时,要求可以保证数据的完整性。

7. 当数据源和目的地随机出现故障和过载时,要求可以保证数据的完整性。

8. 当数据源Schema发生变化时,要求可以根据业务需求灵活配置目的地策略。

G公司的案例只是当前企业数据集成需求的一个典型应用场景。事实上,无论是互联网企业还是传统企业,在面临数据集成的时候都会遇到以下4个挑战:

1. 数据源的异构性:传统ETL方案中,从数据源到目的地的同步都是脚本实现的,异构数据源就意味着企业要做大量的适配工作。

2. 数据源的动态性:在数据集成时,上游的数据源端经常会发生各种变化,有些数据源可能被删掉一些结构,这可能会影响到后续数据分析的结果。

3. 任务的可伸缩性:当数据集成只有几个数据源,系统压力的问题不太突出。当数据集成面临的是成百上千个数据源时,多任务并行就需要进行一些限速与缓冲的调度,让读写速度相互匹配。

4. 任务的容错性:当数据在传输过程中出现问题的时候,是否可以实现断点重传,且不产生重复的数据。

以上也是DataPipeline要为企业数据集成过程中解决的最关键的4个问题。

更多关于实时数据集成的问题,欢迎关注DataPipeline微信公众号,或直接访问官方网址申请试用:www.datapipeline.com
 

DataPipeline基于Kafka Connect在数据集成做了哪些提升?

hugotu 发表了文章 • 0 个评论 • 75 次浏览 • 2018-05-11 16:53 • 来自相关话题

在不断满足当前企业客户数据集成需求的同时,DataPipeline也基于Kafka Connect 框架做了很多非常重要的提升。

1. 系统架构层面。

DataPipeline引入DataPipeline Manager的概念,主要用于优化Source和Sink的全局化生命周期管理。当任务出现异常时,可以实现对目的端和全局生命周期的管理。例如,处理源端到目的端读取速率不匹配以及暂停等状态的协同。


为了加强系统的健壮性,我们把Connector任务的参数保存在ZooKeeper中,方便任务重启后读取配置信息。

DataPipeline Connector通过JMX Client将统计信息上报Dashboard。在Connector中在技术上进行一些封装,把一些通用信息,比如说Connector历史读取信息,跟管理相关的信息都采集到Dashboard里面,提供给客户。

2. 任务并行模式。

DataPipeline在任务并行方面做了一些加强。我们在具体服务客户的时候也遇到这样的问题,需要同步数十张表。在DataPipeline Connector中,我们允许每个Task内部可以定义和维护一个线程池,通过控制线程并发数,并且每个Task允许设置行级别的IO控制。而对于JDBC类型的Task,我们额外允许配置连接池的大小,减少上游和下游资源的开销。

3. 规则引擎。

DataPipeline在基于Kafka Connect做应用时的基本定位是数据集成。数据集成过程中,不应当对数据进行大量的计算,但是又不可避免地要对一些字段进行过滤,所以在产品中我们也在考虑怎样提供一种融合性。

虽然Kafka Connect提供了一个Transformation接口可以与Source Connector和Sink Connector进行协同,对数据进行基本的转换。但这是以Connector为基本单位的,企业客户需要编译后部署到所有集群的节点,并且缺乏良好的可视化动态编译调试环境支持。


基于这种情况,DataPipeline产品提供了两种可视化配置环境:基本编码引擎(Basic Code Engine)和高级编码引擎(Advanced Code Engine)。前者提供包括字段过滤、字段替换和字段忽略等功能,后者基于Groovy可以更加灵活地对数据处理、并且校验处理结果的Schema一致性。对于高级编码引擎,DataPipeline还提供了数据采样和动态调试能力。


4. 错误队列机制。

我们在服务企业客户的过程中也看到,用户源端的数据永远不会很“干净”。不“干净”的数据可能来自几个方面,比如当文件类型数据源中的“脏记录”、规则引擎处理特定数据产生未预期的异常、因为目的端Schema不匹配导致某些值无法写入等各种原因。

面对这些情况,企业客户要么把任务停下来,要么把数据暂存到某处后续再处理。而DataPipeline采取的是第二种方式,通过产品中错误队列预警功能指定面对错误队列的策略,支持预警和中断策略的设置和实施等,比如错误队列达到某个百分比的时候任务会暂停,这样的设置可以保证任务不会因少量异常数据而中断,被完整记录下来的异常数据可以被管理员非常方便地进行追踪、排查和处理。企业客户认为,相比以前通过日志来筛查异常数据,这种错误队列可视化设置功能大大提升管理员的工作效率。

在做数据集成的过程中,确实不应该对原始数据本身做过多的变换和计算。传统ETL方案把数据进行大量的变换之后,虽然会产生比较高效的输出结果,但是当用户业务需求发生变化时,还需要重新建立一个数据管道再进行一次原始数据的传输。这种做法并不适应当前大数据分析的需求。

基于这种考虑,DataPipeline会建议客户先做少量的清洗,尽量保持数据的原貌。但是,这并不是说,我们不重视数据质量。未来的重要工作之一,DataPipeline将基于Kafka Streaming将流式计算用于数据质量管理,它不对数据最终输出的结果负责,而是从业务角度去分析数据在交换过程中是否发生了改变,通过滑动窗口去判断到底数据发生了什么问题,判断条件是是否超出一定比例历史均值的记录数,一旦达到这个条件将进一步触发告警并暂停同步任务。

总结一下,DataPipeline经过不断地努力,很好地解决了企业数据集成过程需要解决异构性、动态性、可伸缩性和容错性等方面的问题;基于Kafka Connect的良好基础支撑构建了成熟的企业级数据集成平台;基于Kafka Connect进行二次封装和扩展,优化了应用Kafka Connect时面临的挑战:包括Schema映射和演进,任务并行策略和全局化管理等。未来,Datapipeline将会基于流式计算进一步加强数据质量管理。

更多关于实时数据集成和Kafka Connect的问题,欢迎关注DataPipeline微信公众号,或直接访问官方网址申请试用:DataPipeline​www.datapipeline.com
 

Elasticsearch 移除 type 之后的新姿势

medcl 发表了文章 • 0 个评论 • 433 次浏览 • 2018-05-03 15:41 • 来自相关话题

随着 7.0 版本的即将发布,type 的移除也是越来越近了,在 6.0 的时候,已经默认只能支持一个索引一个 type 了,7.0 版本新增了一个参数 include_type_name ,即让所有的 API 是 type 相关的,这个参数在 7.0 默认是 true,不过在 8.0 的时候,会默认改成 false,也就是不包含 type 信息了,这个是 type 用于移除的一个开关。

让我们看看最新的使用姿势吧,当 include_type_name 参数设置成 false 后:

  • 索引操作:PUT {index}/{type}/{id}需要修改成PUT {index}/_doc/{id}
  • Mapping 操作:PUT {index}/{type}/_mapping 则变成 PUT {index}/_mapping
  • 所有增删改查搜索操作返回结果里面的关键字 _type 都将被移除
  • 父子关系使用 join 字段来构建


    ```

    创建索引

    PUT twitter
    {
    "mappings": {
    "_doc": {
    "properties": {
    "type": { "type": "keyword" },
    "name": { "type": "text" },
    "user_name": { "type": "keyword" },
    "email": { "type": "keyword" },
    "content": { "type": "text" },
    "tweeted_at": { "type": "date" }
    }
    }
    }
    }

    修改索引

    PUT twitter/_doc/user-kimchy
    {
    "type": "user",
    "name": "Shay Banon",
    "user_name": "kimchy",
    "email": "shay@kimchy.com"
    }

    搜索

    GET twitter/_search
    {
    "query": {
    "bool": {
    "must": {
    "match": {
    "user_name": "kimchy"
    }
    },
    "filter": {
    "match": {
    "type": "tweet"
    }
    }
    }
    }
    }

    重建索引

    POST _reindex
    {
    "source": {
    "index": "twitter"
    },
    "dest": {
    "index": "new_twitter"
    }
    }
    ```

    相关链接:

  • [removal-of-types](https://www.elastic.co/guide/e ... to80)
  • [#15613](https://github.com/elastic/ela ... 435920)
  • [join filed](https://www.elastic.co/guide/e ... n.html)

本人小白一个 哪位大佬告诉我怎么赢日志的时间作为kbiana的时间戳

chao 回复了问题 • 3 人关注 • 1 个回复 • 378 次浏览 • 2018-03-27 10:05 • 来自相关话题

springboot 项目启动 报Failed to load plugin class [org.elasticsearch.xpack.XPackPlugin]]

回复

Creamice 发起了问题 • 1 人关注 • 0 个回复 • 264 次浏览 • 2018-03-22 17:33 • 来自相关话题

Docker 社区版中 Kubernetes 开启

well 发表了文章 • 0 个评论 • 170 次浏览 • 2018-03-07 14:11 • 来自相关话题

Docker 社区版从 17.12 版本开始已经提供了对 Kubernetes 的支持。但是由于其安装过程依赖的镜像服务在国内访问很不稳定,很多朋友都无法配置成功。阿里提供了一个简单的工具帮助大家开启 Docker 社区版的Kubernetes 功能

开启 Kubernetes 从 Docker 官方站点下载并安装 Docker for Mac 或 Docker for Windows

在 Docker -> Preferences ... 中,配置 registry mirror 为 https://registry.docker-cn.com

具体步骤参考: https://github.com/wellpeng/k8s-for-docker-desktop
 

Elastic 中文社区运维监控实战 (2) - 总体方案

medcl 发表了文章 • 0 个评论 • 818 次浏览 • 2018-02-01 21:18 • 来自相关话题

接上一篇:[Elastic 中文社区运维监控实战 (1) - 序](https://elasticsearch.cn/article/470)

本文为系列文章第二篇,主要介绍如何把 Elastic 中文社区的网站服务器监控起来,对有同样想了解如何使用 Elastic Stack 来做运维监控的同学,可以作为一个很好的参考和入门资料,学习门槛定义为入门级。

本节内容


在深入到具体的监控指标收集的细节之前,今天先主要介绍一下 Elastic 中文社区的总体方案。这样我们在动手之前会有一个总体的思路和对所用工具有一个大致的了解。



## 技术选型

> 工欲善其事必先利其器

前面已经提到我们要对服务器进行各项性能指标的监控以及日志的监控。

看起来很复杂,因为有很多信息需要收集。
好在我们有 Elastic Stack,使用它们来作为我们的监控工具,整个工作就变得简单了,我们结合我们社区监控的这个场景,具体来看的话,需要的工具主要是如下几个:

* 监控数据存储:[Elasticsearch](https://www.elastic.co/cn/products/elasticsearch)

Elasticsearch 是一个分布式的 RESTful 风格的搜索和数据分析引擎。简单易用,用户众多,性能优良,久经考验,支持单节点部署到虚拟机,并可随着业务增长无缝伸缩扩容至上千个节点规模的集群,PB 级别数据也不在话下。

日志数据和指标监控数据都能放,通过集中式存储所有的这些时序型数据,可以快速方便的对这些数据进行分析和关联,实在是排障运维和性能调优的不二选择,你如果还不知道 Elasticsearch,那我只能说你真的是 out 了。

* 日志数据收集:[Filebeat](https://www.elastic.co/cn/products/beats/filebeat)

Elastic Beats 家族的一员,Go 语言编写,轻量级,无依赖,这样就可以很方便的完成收集端的部署,所以如果你的场景和我一样, 可以优先使用 Filebeat 代替 Logstash 来收集日志,当然如果有日志的进一步加工,可以让 Filebeat 把数据发送给 Logstash,然后 Logstash 处理完之后再发送给 Elasticsearch。

Filebeat 使用很灵活,可以指定你的日志路径来进行收集,还可以对数据进行预过滤,对于一些常见的监控需求,Filebeat 以模块的方式替你打包好了一切,如:日志路径配置、解析规则、机器学习的任务,甚至还自带 Dashboard,简单几个操作,就可以完成从数据收集到最终可视化分析的所有工作。

* 指标数据收集:[Metricbeat](https://www.elastic.co/cn/products/beats/metricbeat)

我们这次需要监控的服务器都是一些常规的指标,而 Metricbeat 刚好都支持这些指标的收集,你说这不巧了不是。

Metricbeat 同样也是 Elastic Beats 家族的一员,同样也是开源的。定位是一个轻量级的监控指标采集器,采用 Go 语言编写,同样提供的是一个很小的无依赖的二进制文件包,能够收集服务器(Linux、Windows、Mac)本身的运行指标,如: CPU 使用率、内存、文件系统、磁盘 IO 和网络 IO 统计数据等,还能获取服务器上面的各项服务的运行指标,常见的如: Apache、NGINX、MongoDB、MySQL、PostgreSQL、Prometheus、Redis 等都有直接支持,并且内置了 Elasticsearch 索引和 mapping 设置,以及 Ingest pipeline 设置,还提前预置了不少 Kibana 的 Dashboard,开箱即用、即分析。

* 数据分析展现:[Kibana](https://www.elastic.co/cn/products/kibana)

和 Elasticsearch 工作的最佳拍档,结合 Elasticsearch 的实时分析能力,可以非常方便的对各种数据进行搜索和分析,你可以灵活的自定义的各种图形展现和 Dashboard,不用编写一行代码,即可进行数据分析,除了分析,还整合了 Elastic Stack 的各个产品的管理功能,作为 Elastic Stack 的图形交互终端。

除了上面这些工具,后续我们还可以考虑使用 [Auditbeat](https://www.elastic.co/cn/products/beats/auditbeat) 来收集服务器的安全行为日志,使用 [Heartbeat](https://www.elastic.co/cn/products/beats/heartbeat) 来监控各个服务的端口是否正常,我们先完成基本的监控之后,再慢慢将这些加上。

可以看到,我们没有用到 [Logstash](https://www.elastic.co/cn/products/logstash),是的,这个规模的监控,可以不考虑 Logstash,这样我们可以做到架构简单和足够的轻量级。

上面列的这些软件都是 [Elastic](https://www.elastic.co) 家族的产品,并且都是开源的,所有的源码都在:https://github.com/elastic/

## 部署方案

在收集数据之前,我们需要明确我们数据放在哪里,毫无疑问,所有的数据都将放在 Elasticsearch 里面,不过 Elasticsearch 不能部署在 Elastic 中文社区的这台服务器上面,一个是资源的限制,另外一个是基于安全的考虑,如果 Elastic 社区的服务器挂了,数据不光收不到,连什么时候挂的都不知道。所以我们需要把 Elasticsearch 服务搭建在别的地方,有多种选择:

* 使用 [Elastic Cloud](https://www.elastic.co/cn/cloud),很方便就能开通,缺点国内访问速度慢,暂时还没开放机器学习的功能。
* 使用[阿里云的 Elasticsearch](https://data.aliyun.com/product/elasticsearch),Elastic 官方合作伙伴,国内唯一包含 X-Pack 的完整功能的 Elasticsearch 云服务,国内访问速度快。
* 自己搭建的 Elasticsearch 集群。

使用[阿里云的 Elasticsearch](https://data.aliyun.com/product/elasticsearch) 无疑很方便,不过我家里刚好有一台服务器,型号 HP Gen8,16GB 内存,上面运行了 SmartOS,跑几个 zone 很轻松,每天用来备份社区的数据库,再来起一个 Elasticsearch 服务也很方便,通过路由器将内网 IP 映射出去,让社区服务器将监控数据发送到这台服务器上面来,安全上面,需要保证这台服务器不被黑客攻击,需要做一些必要的访问控制,可以使用 X-Pack 的身份验证,结合 IP 白名单功能,只允许内网和 Elastic 中文社区服务器的 IP 访问。

我们将之命名为:Ops Center,方便后面招呼。

可以看到,Elastic 社区服务器除了启动 Filebeat 和 Metricbeat 之外,不需要额外做什么服务器本身的设置。

这里画一个简单的部署拓扑图,方便理解:

deploy2.png


今天主要写到这里,后面将具体介绍它们的安装部署过程。

Elastic 中文社区运维监控实战 (1) - 序

medcl 发表了文章 • 1 个评论 • 809 次浏览 • 2018-01-25 21:47 • 来自相关话题



本文为系列文章第一篇,主要介绍如何把 Elastic 中文社区的网站服务器监控起来,对有同样想了解如何使用 Elastic Stack 来做运维监控的同学,可以作为一个很好的参考和入门资料,学习门槛定义为入门级。

首先,我们要监控的网站,也就是大家现在正在访问的 Elastic 官方中文社区,网址:[elasticsearch.cn](https://elasticsearch.cn/),这个网站基于开源的 [WeCenter](https://github.com/wecenter/wecenter/) 搭建,开发语言是 PHP,后端数据库是 MySQL,目前只有一台服务器,由 [ConvertLab](http://convertlab.com/) 友情无偿赞助,大写的赞!再次感谢!

服务器部署环境是 Ubuntu 16.04.2,部署了以下服务及软件:

  • Nginx - Http 反向代理,不要介绍了吧
  • PHP-FPM - 一个常用的 PHP FastCGI 管理
  • Elasticsearch - Elasticsearch 服务,用于社区的垂直搜索服务 [Elastic 情报局](https://index.elasticsearch.cn) 服务
  • GOPA - 可以说是为社区而写的,一个轻量级的爬虫,用于爬取 Elatic 周边相关相关资料,创建索引存放到 Elasticsearch 里面,提供垂直搜索服务,[代码地址](https://github.com/infinitbyte/gopa)
  • Grok Debugger - 一个 Java 的 Grok pattern 调试服务,方便大家调试 Grok 日志解析规则,访问地址:[grok.elasticsearch.cn](http://grok.elasticsearch.cn/)

    服务器上所有的财产就这些了,一个平淡无奇的网站,基本上所有的东西都能公开访问到,这个网站的目的就是为所有 Elastic 爱好者服务的,供大家交流和沟通的专属平台,所以请各位黑客大侠不要再扫描和攻击啦,画一个简单的拓扑图如下所示:

    topology.png



    作为一个合格的网管,除了重启服务器之外,还必须要保证网站的正常运行,所以了解网站的运行情况就变成了一个需要解决的首要问题,我们可以先把任务具体列一下:

  • 网站是否正常访问,各项服务有没有挂
  • 网站访问情况如何,用户访问速度如何
  • 网站访客统计分析,访客相关数据分析
  • 服务器的各项指标,详细指标监控分析
  • 服务器的各项服务,日志集中分析处理
  • 服务器是否很安全,有没有黑客来造访
  • 数据是否安全备份,有没有定期测试过

    实在编不下去了(话说对的还蛮齐),说人话就是监控起服务器的各项指标和收集服务的日志,然后出几个分析的 Dashboard,监控报警整起来。

    我们这次需要用到的工具主要就是 Elastic Stack 啦,Elastic Stack 包括 Elasticsearch、Logstash、Beats 和 Kibana,版本都用最新的 6.x,再结合我们实际的数据和实际的需求,在后面的文章里面,我会具体介绍它们是什么以及如何使用。

    今天先写到这里,明天写监控指标的收集,此系列文章暂且定为需要 100 期完成。(开个玩笑,哈哈)。

请问在elastic官网论坛上如何将DSL语句粘贴成文本框

laoyang360 回复了问题 • 2 人关注 • 1 个回复 • 221 次浏览 • 2018-01-08 19:49 • 来自相关话题

ELK能进行数据运算后统计吗?

living 回复了问题 • 4 人关注 • 3 个回复 • 478 次浏览 • 2017-12-05 15:39 • 来自相关话题

那家公司或者团队有基于ELK实现SIEM的项目经验?

回复

fengdasima 发起了问题 • 1 人关注 • 0 个回复 • 399 次浏览 • 2017-10-31 10:22 • 来自相关话题

关于complete suggest的使用疑问

回复

wc_learning_ES 发起了问题 • 0 人关注 • 0 个回复 • 1430 次浏览 • 2017-07-14 17:48 • 来自相关话题

请教新手学习Elastic进阶路径

medcl 回复了问题 • 6 人关注 • 3 个回复 • 2255 次浏览 • 2017-05-26 18:56 • 来自相关话题

ELK学习资料整理

lsyoung 发表了文章 • 0 个评论 • 3180 次浏览 • 2017-04-14 10:17 • 来自相关话题

刚开始学习使用ELK,整理一个学习资料列表,当做备忘录。
 
1.第一个当然是官方文档
  • ElasticSearch参考手册,学习 DSL查询语法,包括查找(query)、过滤(filter)和聚合(aggs)等。
  • Logstash参考手册,学习数据导入,包括输入(input)、过滤(filter)和输出( output)等,主要是filter中如何对复杂文本 进行拆分和类型 转化。
  • Kibana参考手册,使用Kibana提供的前端界面对数据进行快速展示,主要是对Visulize 模块的使

2.中文文档

 
欢迎补充……