1. 400+节点的Elasticsearch集群运维经验。 http://t.cn/EbJXsTM

2. Elasticsearch index、create和update的源码分析。 http://t.cn/EbJSwbP

3. 全文搜索引擎选Elasticsearch还是Solr？。 http://t.cn/EbJSRp9

• 编辑：bsll

• 归档：https://elasticsearch.cn/article/6311

• 订阅：https://tinyletter.com/elastic-daily

Elastic stack不停的迭代中狂奔。在最新的V6.5版本发布后，我们可以发现，其路线图已经越来越倾向于成为一个全栈的，全链路的，从下至上，从底层硬件资源数据一直到上层用户数据，从资源监控，到性能监控，直至安全审计的智能化运维系统了。这其中解决的一个痛点是：企业中存在各种各样的业务系统，每个系统又存在不同的数据源和存储数据的数据库；同时在运维管理层面上，又各种不同的监控系统（资源监控，性能监控，安全和审计）以及上层的可视化系统。这样，导致运维人员需要面对繁多的系统、入口和数据维度，在处理问题时，需要登录不同的平台，并且无法对数据进行有效的关联分析，因此，是迫切需要一个强大的平台，能够快速便捷的处理这些问题的。 我们可以看到，从不停发布的beats，以及beats里面不停添加的modules：

以及支持的各种数据指标模版：

elastic stack在加速将越来越多的数据需要汇聚到一起，并且提供一个统一的接口进入，这就是Kibana。这里，我不打算深入的比较Kibana和Grafana，简单说一句，就是grafana的主要场景只是dashboard，并不适合将其用作一个将所有数据集中到一起，需要做各种维度的查询，分析，安全检查等功能的portal。所以，这里我们讨论的是Kibana上如何展示其他数据源的数据。

为什么是prometheus而不是beats

在这个人人上云的时代，无论是open stack还是K8S，最流行的资源监控软件我看到的是prometheus，特别是以node_exporter为基础的一系列metric采集工具，为prometheus提供了各种维度的监控数据。而对应的，elastic stack也提供了类似filebeat, metricbeat, packatbeat等一系列工具和对应的数据template。

我没有深入使用过prometheus，但作为一个beats的资深用户，我还是感觉到beats还存在诸多的问题，特别是filebeat上幽灵般存在的内存占用过多的问题，导致大规模在所有的节点上安装beats成为一种风险。并且，最主要的一个点，我觉得是beats采集的数据，是依赖于整个elastic stack进行展示的，而作为云的运维人员，其关心的重点是每个虚拟机，容器的资源监控情况，metric和alart是其重心，而非query，search，security等功能。并且安装一个prometheus，比安装整个elastic stack简便得多，消耗的资源也小的多。所以，普遍的，从主机运维人员的角度，肯定首选安装prometheus的exporter来作资源的监控，而非安装beats。

为什么Kibana上需要集成prometheus的数据

正因为之前所讲的，我们试图使用elastic stack作为一个多维度的统一的数据入口和展示工具，要求我们必须能在Kibana看到硬件资源监控级别的指标，而elastic stack提供的beats等工具，却并不为云运维人员所待见（因为他们更喜欢prometheus，而非elastic stack，原因见以上）。因此，如果我们需要将elastic stack打造为一套全栈的智能运维系统，大多数情况下，prometheus成为必须跨越的一个槛。

将prometheus上的数据转移到elasticsearch

这是我想到的第一个解决方案。可惜logstash上没有prometheus的input plugins。所以，我们还是需要beats。注意，在metricbeat上有一个prometheus的module，号称可以 fetch metric from prometheus exporter，但实际上只是一个乌龙，这个module的并不能从成千上万的云主机或者容器中拉取数据，它能做的只是获取prometheus服务器节点prometheus这个进程的基本数据，然并卵。 这里给大家介绍的是两个社区提供prometheus相关的beats：

但建议大家还是自己写一个beat吧，代码可以参考prombeat。 不过如果你仔细观看prometheus里面的数据，都是num type的，将其转存到elasticsearch绝对不是一个经济的选择：

将grafana集成到kibana中

这是为什么我在一开始提到了grafana，虽然它不适合做portal，但是极其适合做dashboard，而kibana又是如此的开放，随便做个插件，可以轻松的跳转到grafana的dashboard上。而grafana与prometheus又是如此的登对，看看grafana上的各种专业而美丽的prometheus的dashboard吧：

我们要做的是做一个kibana的插件，然后将关键参数传递给grafana，并跳转：

虽然kibana和grafana是两个不同的工具，但并不妨碍我们将它们放在一起工作。而Kibana的开放性和基于插件的独立开发模式，让我们可以更方便的将各种好用的开源工具集成到一起，这里展示的Kibana与grafana和promethues的集成，希望能给到你一些微光。

欢迎来到 Elastic 社区电台的第九期节目，我们本期节目的嘉宾是来自于 vivo 互联网负责搜索业务研发的杨振涛，vivo 从 Elasticsearch 2.1.1 版本开始，如今使用 100 多个 Elasticsearch 集群来支撑全球 2 亿多台手机每天的各种搜索请求，如 vivo 的应用商店、游戏、音乐、主题、壁纸、铃声等各种手机服务背后的搜索服务，也包括产品配件、售后、FAQ 等企业门户官网的搜索请求。今天让我们一起走进 vivo，看看 vivo 具体是如何使用 Elasticsearch 来解决这些搜索问题的。

可以点击下面的任意链接来收听（时长约 50 分钟）：

• Apple iTunes: https://itunes.apple.com/cn/podcast/elastic-社区电台/
• 喜马拉雅：https://www.ximalaya.com/keji/14965410/146649768
• 蜻蜓 FM：https://www.qingting.fm/channels/244978/programs/10396421

嘉宾

杨振涛，vivo 互联网搜索引擎架构师，专注于数据的存储、检索与可视化，以及 DevOps 与软件过程改进。Elastic 中文社区深圳地区负责人，发起并组织 Elasticsearch、Redis、Jenkins 等主题的技术沙龙，并参与多个开源项目的文档翻译和中文化工作。 技术翻译爱好者，InfoQ 中文社区编辑，TED Translator。

主持人

Elastic 技术布道师，曾勇（Medcl）。

关于 vivo

vivo为一个专注于智能手机领域的手机品牌，vivo和追求乐趣、充满活力、年轻时尚的群体一起打造拥有卓越外观、专业级音质、极致影像、愉悦体验的智能产品，并将敢于追求极致、持续创造惊喜作为vivo的坚定追求。

关于 Elastic 社区电台

Elastic 开源社区举办的一款播客类节目， 邀请来自开源社区的用户，一起聊聊 Elastic 开源产品的使用案例、经验分享、架构变迁等等。

相关链接

• 社区活动计划

• vivo 招聘页面

​首先还是祝大家圣诞快乐，既然是节日，我们就讨论一个比较轻松的话题。如何使用6.5引入数据管道处理器来更好的治理预定义好的数据管道。

背景

2018这一年来拜访了很多用户，其中有相当一部分在数据摄取时遇到包括性能在内的各种各样的问题，那么大多数在我们做了ingest节点的调整后得到了很好的解决。Ingest节点不是万能的，但是使用起来简单，而且抛开后面数据节点来看性能提升趋于线性。所以我一直本着能用ingest节点解决的问题，绝不麻烦其他组件的大体原则 ：-）

下面快速回顾一下ingest节点的角色定位。

使用场景

通过上面的图纸我们很容易看到ingest节点可以在数据被索引之前，通过预定义好的处理管道对其进行治理。但这里一直存在一个局限性，就是只能通过一条管道。那么一直以来应对这个不便的方案就是把所有的处理器和细节全部配置到当前管道下。那么带来的问题也是比较明显的：

• 复制、粘贴很多相同的管道配置在不同数据管道里
• 非常难管理、维护冗长的管道
• 如果要更新一个处理细节的话要找到定位所有使用过这个逻辑的管道

其实这块对于开发的同学们很好理解，当你经常复制、粘贴代码的时候，就是时候好好思考一下了。我想说到这里大家其实已经明白了，这个管道处理器实际就是提供了一个允许你在一个管道内调用其他管道的方案。

他的使用非常简单，就像函数调用一样只有一个必要参数name：

{
  "pipeline": {
    "name": "<其他管道的名称 - 英文字符>"
  }
}

当然，也像其他处理器一样提供了on_failure参数来处理错误，并且还有一个非常实用的if参数来判断是否执行这个管道，这里就不做详细介绍了。

举例

这里我们用一个非常简单的案例来看看如何使用管道处理器。

假设在Elastic公司，我们使用员工卡来作为进入公司和各个部门以及房间的钥匙，并且这些刷卡事件也会被记录下来。那么由于上班卡机和门禁供应商不同，数据格式也不一样。但是最后都有一个通用的逻辑，就是除了事件发生的时间，我们还会记录下数据录入到Elasticsearch的时间。

首先我们看一下原始数据：

# 公司正门卡机数据
2018-12-25T08:59:59.312Z,front_door,binw,entered

# 架构部门禁数据
@timestamp=2018-12-25T09:15:34.414Z device_id=recreation_hall user=binw event=entered

那如果在6.5之前，我们定义2条管道是这个样子

1. 正门卡机管道

   • grok 解析数据
   • 打上数据录入的时间戳
   • 明确录入时间戳的处理器
2. 门禁数据管道
   • KV 解析数据
   • 打上数据录入的时间戳
   • 明确录入时间戳的处理器

很明显又66.67%的配置都是重复的，所以这里我们可以更优雅的解决这个问题

1. 统一的数据录入时间戳处理器
   • 打上数据录入的时间戳
   • 明确录入时间戳的处理器

PUT _ingest/pipeline/pl_cmn
{
  "description": "刷卡数据通用管道",
  "processors": [
    {
      "set": {
        "field": "ingest_timestamp",
        "value": "{{_ingest.timestamp}}"
      }
    },
    {
      "set": {
        "field": "cmn_processed",
        "value": "yes"
      }
    }
  ]
}

2. 正门卡机管道
   • grok 解析数据
   • <调用管道 pl_cmn>

POST _ingest/pipeline/_simulate
{
  "pipeline": {
    "description": "正门打卡机数据处理管道",
    "processors": [
      {
        "grok": {
          "field": "message",
          "patterns": [
            "%{TIMESTAMP_ISO8601:@timestamp},%{WORD:device_id},%{USER:user},%{WORD:event}"
          ]
        }
      },
      {
        "pipeline": {
          "name": "pl_cmn"
        }
      }
    ]
  },
  "docs": [
    {
      "_source": {
        "message": "2018-12-25T08:59:59.312Z,front_door,binw,entered"
      }
    }
  ]
}

3. 门禁数据管道
   • KV 解析数据
   • <调用管道 pl_cmn>

POST _ingest/pipeline/_simulate
{
  "pipeline": {
    "description": "架构部门禁数据处理管道",
    "processors": [
      {
        "kv": {
          "field": "message",
          "field_split": " ",
          "value_split": "="
        }
      },
      {
        "pipeline": {
          "name": "pl_cmn"
        }
      }
    ]
  },
  "docs": [
    {
      "_source": {
        "message": "@timestamp=2018-12-25T09:15:34.414Z device_id=recreation_hall user=binw event=entered"
      }
    }
  ]
}

好啦，这个例子非常简单。但当面对复杂业务场景的时候，会让你整个数据管道的管理比以前整齐很多。再结合合理的架构和数据治理，ingest节点也可以让你的整个数据处理能力有所提升。

写在最后

在文章的例子里，我们往索引里灌注的是一个个的事件数据。那要如何对数据中的实体进行有效的分析呢？那不得不说到面向实体的数据模型设计。Elasticsearch本身也提供了工具能让我们快速实现，让我们明年有机会的时候再与大家分享吧。最后还是祝愿大家度过一个愉快的圣诞节和元旦！

一、分词插件

1、分词器概念

在 ES 中，分词器的作用是从文本中提取出若干词元（token）来支持索引的存储和搜索，分词器（Analyzer）由一个分解器（Tokenizer）、零个或多个词元过滤器（TokenFilter）组成。

分解器用于将字符串分解成一系列词元，词元过滤器的作用是对分词器提取出来的词元做进一步处理，比如转成小写，增加同义词等。处理后的结果称为索引词（Term），引擎会建立 Term 和原文档的倒排索引（Inverted Index），这样就能根据 Term 很快到找到源文档了。

2、选择分词器

目前 ES 分词插件的选择性还是很多的，分词插件的核心就是提供各种分词器（Analyzer）、分解器（Tokenizer）、词元过滤器（TokenFilter）；根据依赖的核心分词包（分词算法）的不同显现出不同的差异性，除了分词算法之外，是否支持用户自定义词典，是否支持词典热更新等其他附加功能也是选择分词插件时需要参考的。

下面列出选择分词插件需要考虑的因素（仅供参考）：

• 分词准确性：大家都希望分词结果能够尽可能准确，与分词准确性直接相关的就是用户词典了，此外才是分词算法；
• 分词算法：个人认为无需纠结于分词算法，大多数分词包提供的分词算法都比较类似，选择时不需要过于纠结；
• 分词速度：这个与分词算法直接相关，基于词典的分词算法一般比基于模型的分词算法要快；基于词典如果考虑词频、命名实体识别、词性标注则会慢一些；
• 启动速度：当词典较大时，初始化词典会比较慢，某些分词器会对词典进行缓存，第二次启动会非常速度；
• 内存占用：与分词算法、词典大小、模型大小均有关系，设计精巧的算法对内存占用较小；
• 易用性：分词器是否开箱即用，是否可以直接使用在线链接或者压缩包进行安装，是否需要复杂的配置；
• 扩展性：是否支持用户自定义词典、是否支持自定义分词算法、是否支持热更新等；
• 是否开源：开源的分词器在遇到问题的时候可以自己进行深度调试，甚至可以进行二次开发；
• 社区活跃度：这个看一下 github 的 star 数或者依赖的分词包的 star 数和 issue 数目即可判定；
• 更新频率：是否能够与最新版的 ES 同步更新。

二、HanLP 简介

HanLP 是一系列模型与算法组成的 NLP 工具包，具备功能完善、性能高效、架构清晰、语料时新、可自定义的特点,详情可参考 github 介绍：https://github.com/hankcs/HanLP。

选择 HanLP 作为核心的分词包开发 ES 分词插件，主要考虑以下因素：

• HanLP 是 Java 分词包中最为流行的；
• HanLP 提供了多种分词器，既可以基于词典也可以基于模型（在一亿字的大型综合语料库上训练的分词模型）；
• HanLP 坚持使用明文词典，这样可以借助社区的力量对词典不断进行完善；
• 完善的开发文档和代码样例，较为活跃的用户群体；
• 个人参与了部分功能的开发，对代码结构较为熟悉。

三、开发分词插件

1、代码结构

• conf：插件的配置文件、HanLP 的配置文件、Java 安全策略文件；
• scr.main.java.assemby：插件打包（maven-assembly-plugin）配置文件；
• org.elasticsearch.plugin.hanlp.analysis：分词插件核心构建器；
• org.elasticsearch.plugin.hanlp.conf：管理插件配置、分词器配置以及 HanLP 配置；
• org.elasticsearch.plugin.hanlp.lucene：HanLP 中文分词 Lucene 插件，对 Lucune 分词进行实现；
• scr.main.resources：插件属性文件所在目录

2、TokenStream

Analyzer 类是一个抽象类，是所有分词器的基类，它通过 TokenStream 类将文本转换为词汇单元流；TokenStream 有两种实现 Tokenizer（输入为 Reader） 和 TokenFilter（输入为另一个 TokenStream）。

TokenStream 基本使用流程：

1. 实例化 TokenStream，向 AttributeSource 添加/获取属性（词汇单元文本、位置增量、偏移量、词汇类型等）；
2. 调用 reset() 方法，将流（stream）重置到原始（clean）状态；
3. 循环调用 incrementToken() 方法，并处理 Attribute 属性信息，直到它返回 false 表示流处理结束；
4. 调用 end() 方法，确保流结束（end-of-stream）的操作可以被执行；
5. 调用 close() 方法释放资源。

// 实例化 TokenStream
TokenStream tokenStream = new IKAnalyzer().tokenStream("keywords",new StringReader("思想者"));
// 向 AttributeSource 添加/获取属性
CharTermAttribute attribute = tokenStream.addAttribute(CharTermAttribute.class);
// 将流（stream）重置到原始（clean）状态
tokenStream.reset();
// 判断是否还有下一个 Token
while(tokenStream.incrementToken()) {
  System.out.println(attribute);
}
tokenStream.end();
tokenStream.close();

综上，开发 Tokenizer 或者 TokenFilter 时，需要重点关注 reset、incrementToken、end、close 四个方法的实现。

3、开发中的小技巧

获取插件目录或文件目录

//获取插件根目录
private static Path getPluginPath() {
    return env.pluginsFile().resolve("analysis-hanlp");
}
//获取插件目录下的文件
private static Path getDefDicConfigPath() {
    return env.pluginsFile().resolve("analysis-hanlp/hanlp.properties").toAbsolutePath();
}

插件属性文件

如果希望插件属性文件（plugin-descriptor.properties）能够自动根据 pom.xml 中的属性进行赋值，则需要将文件防止到 resources 文件夹下。

插件版本兼容性

从实际测试来看：

• ES5.X 及其以上的代码是完全复用的，也就是说代码逻辑不需要调整；
• ES5.X 到 ES6.2.X 的插件是可以通用的，其特征是打包的时候需要将插件的文件全部打包到 elasticsearch 文件夹下；
• ES6.3.X 以上的插件是可以通用的，打包的时候插件的文件全部打包到根目录即可。

也就是说，如果你升级了新版本 ES，对于插件升级，大多数情况只需要修改下 plugin-descriptor.properties 文件中 ES 的版本号即可。

4、安全策略文件

在插件开发中经常会使用到文件读取、属性读取、网络链接等功能，如果不提前注册安全策略，在调用这些功能的时候会报以下错误java.security.AccessControlException: access denied。

官方给出的解决方案就是新建一个 plugin-security.policy 文件，然后在文件中声明需要的权限信息，最后在打包的时候将文件放置到插件的根目录，这样在使用 zip 包进行安装的时候，ES 会提示用户插件所需的权限信息，需要用户确认后插件才能正常安装。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@     WARNING: plugin requires additional permissions     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
* java.io.FilePermission <<ALL FILES>> read,write,delete
* java.lang.RuntimePermission createClassLoader
* java.lang.RuntimePermission getClassLoader
* java.lang.RuntimePermission setContextClassLoader
* java.net.SocketPermission * connect,resolve
* java.util.PropertyPermission * read,write
See http://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html
for descriptions of what these permissions allow and the associated risks.

Continue with installation? [y/N]y
-> Installed analysis-hanlp

5、安全策略的坑

最开始认为只需要添加了 policy 文件，且打包到正确的位置即可解决插件的权限问题，因为在插件安装的时候 ES 已经提示了所需权限，但是代码在实际执行的时候依旧报 AccessControlException 的错误。

参考了多个 HanLP 的 ES 分词插件，都没有获得较好的方法，后来考虑到 IK 分词器远程加载词典时，需要网络连接权限，就去看了下其远程词典加载的代码，最终找到了正确的使用方法。

// 需要特殊权限的代码
AccessController.doPrivileged((PrivilegedAction<Segment>) () -> {
    Segment segment;
    if (config.getAlgorithm().equals("extend")) {
        segment = new ViterbiSegment();
    } else {
        segment = HanLP.newSegment(config.getAlgorithm());
    }
    // 在此处显示调用一下分词，使得加载词典、缓存词典的操作可以正确执行
    System.out.println( segment.seg("HanLP中文分词工具包！"));
    return segment;
});

四、插件特色

简单介绍一下插件的特点：

• 内置多种分词模式，适合不同场景；
• 内置词典，无需额外配置即可使用；
• 支持外置词典，用户可自定义分词算法，基于词典或是模型；
• 支持分词器级别的自定义词典，便于用于多租户场景；
• 支持远程词典热更新（待开发）；
• 拼音过滤器、繁简体过滤器（待开发）；
• 基于词语或单字的 ngram 切分分词（待开发）。

Github 地址：https://github.com/AnyListen/elasticsearch-analysis-hanlp