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本身也提供了工具能让我们快速实现，让我们明年有机会的时候再与大家分享吧。最后还是祝愿大家度过一个愉快的圣诞节和元旦！