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的集成，希望能给到你一些微光。

当我们搭建elasitc stack集群时，大多数时候会在我们的架构中加入kafka作为消息缓冲区，即从beats -> kafka -> logstash -> elasticsearch这样的一个消息流。使用kafka可以给我们带来很多便利，但是也让我们需要额外多维护一套组件，elasitc stack本身已经提供了monitoring的功能，我们可以方便的从kibana上监控各个组件中各节点的可用性，吞吐和性能等各种指标，但kafka作为架构中的组件之一却游离在监控之外，相当不合理。

幸而elastic真的是迭代的相当快，在metricbeat上很早就有了对kafka的监控，但一直没有一个直观的dashboard，终于在6.5版本上，上新了kafka dashboard。我们来看一下吧。

安装和配置metricbeat

[安装包下载地址](https://www.elastic.co/downloads/beats/metricbeat)，下载后，自己安装。
然后，将/etc/metricbeat/modules.d/kafka.yml.disable文件重命名为/etc/metricbeat/modules.d/kafka.yml。(即打开kafka的监控)。稍微修改一下文件内容, 注意，这里需填入所有你需要监控的kafka服务器的地址：

```

Module: kafka

Docs: https://www.elastic.co/guide/e ... .html

• module: kafka
  metricsets:
  
  • partition
    
  • consumergroup
    period: 20s
    hosts: ["10...:9092","10...:9092","10...:9092","10...:9092"]
    
    

    client_id: metricbeat
    

    retries: 3
    

    backoff: 250ms
    

    
    

    List of Topics to query metadata for. If empty, all topics will be queried.
    

    topics: []
    

    
    

    Optional SSL. By default is off.
    

    List of root certificates for HTTPS server verifications
    

    ssl.certificate_authorities: ["/etc/pki/root/ca.pem"]
    

    
    

    Certificate for SSL client authentication
    

    ssl.certificate: "/etc/pki/client/cert.pem"
    

    
    

    Client Certificate Key
    

    ssl.key: "/etc/pki/client/cert.key"
    

    
    

    SASL authentication
    

    username: ""
    

    password: ""
    

    ```
    运行metricbeat，这里，一定要注意enable kibana dashboard。
    
    然后就可以在kibana里面看到：
    
    

    

    
    

    

    
    
    
    这样，我们就可以通过sentinl等类似的插件，自动做kafka的告警等功能了

使用过Kibana的同学应该都知道，当我们在kibana的配置文件中打开或者关闭功能，或者安装、卸载额外的插件后，重启kibana会触发一个优化的过程（optimize），如下图：

这个过程或长或短，视你电脑的性能而定。这里简单介绍一下该过程所要完成的事情。

Kibana是一个单页Web应用

首先，Kibana是一个单页的web应用。何为单页web应用？即所有的页面的读取都是在浏览器上完成，而与后台服务器无关。与后台服务器的通信只关乎数据，而非页面。所以，应用上所有的UI都被打包在一起，一次性的发送到了浏览器端，而不是通过URL到后台进行获取。所以，我们看到kibana的首页是下面这样的：
<a href="http://localhost:5601/app/kibana#/" rel="nofollow" target="_blank">http://localhost:5601/app/kibana#/</a>
注意这里的#后，代表#后面的内容会被浏览器提取，不往服务器端进行url的情况，而是在浏览器上进行内部重新渲染。因为所有的页面都是存储在浏览器的，所有在初次访问的时候，会加载大量的代码到浏览器端，这些代码都是被压缩过的bundle文件：

而optimize的过程，就是把这些原本可读性的源代码压缩为bundle.js的过程。因此，每当你对Kibana进行裁剪之后重启，因为前端的部分是完全由浏览器负责的，所有bundle文件需要重新生成后再发给浏览器，所以会触发optimize的过程。

Kibana在6.2.0版本之后，常规版本已经默认自带了xpack（当然，你还是可以直接下载不带xpack的开源社区版），导致Kibana的size已经到了200M左右，而且越往后的版本，功能越多，代码量越大，每次optimize的过程都会耗费更多的时间。一般来说，我们会将Kibana部署在单独的机器上，因为这仅仅是一个web后端，通常我们不会分配比较优质的资源，（2C4G都算浪费的了），这种情况下面，每次我们裁剪后重启Kibana都会耗费半个小时～1个小时的时间，更有甚者直接hang住，查看系统日志才知道OOM了。

Nodejs的内存机制

Kibana是用Nodejs编写的程序，在一般的后端语言中，基本的内存使用上基本没有什么限制，但是在nodeJs中却只能使用部分内存。在64位系统下位约为1.4G，在32位系统下约为0.7G，造成这个问题的主要原因是因为nodeJs基于V8构建，V8使用自己的方式来管理和分配内存，这一套管理方式在浏览器端使用绰绰有余，但是在nodeJs中这却限制了开发者，在应用中如果碰到了这个限制，就会造成进程退出。

Nodejs内存机制对Kibana优化的影响

因为Kibana的代码体量越来越大，将所有的代码加载到内存之后，再解析语法树，进行bundle的转换所耗费的内存已经接近1.4G的限制了，当你安装更多插件，比如sentinl的时候，系统往往已经无法为继，导致Kibana无法启动

解决方案

这种情况下，我们需要在Kibana启动的时候，指定NodeJs使用更多的内存。这个可以通过设置Node的环境变量办到。
<br /> NODE_OPTIONS="--max-old-space-size=4096"<br />
当然，我的建议是直接指定在kibana的启动脚本当中，修改/usr/share/kibana/bin/kibana文件为：
```shell

!/bin/sh

SCRIPT=$0

SCRIPT may be an arbitrarily deep series of symlinks. Loop until we have the concrete path.

while [ -h "$SCRIPT" ] ; do
ls=$(ls -ld "$SCRIPT")

Drop everything prior to ->

link=$(expr "$ls" : '.-> (.)$')
if expr "$link" : '/.*' > /dev/null; then
SCRIPT="$link"
else
SCRIPT=$(dirname "$SCRIPT")/"$link"
fi
done

DIR="$(dirname "${SCRIPT}")/.."
NODE="${DIR}/node/bin/node"
test -x "$NODE" || NODE=$(which node)
if [ ! -x "$NODE" ]; then
echo "unable to find usable node.js executable."
exit 1
fi

NODE_ENV=production exec "${NODE}" $NODE_OPTIONS --max_old_space_size=3072 --no-warnings "${DIR}/src/cli" ${@}

``<br /> 改动在最后一句：NODE_ENV=production exec "${NODE}" $NODE_OPTIONS --max_old_space_size=3072 --no-warnings "${DIR}/src/cli" ${@}`

这样，我们可以保证Kibana能顺利的完成optimize的过程