为何要通过Kibana展示promethues的数据以及如何去做

点火三周 发表了文章 • 0 个评论 • 569 次浏览 • 2018-12-27 10:59 • 来自相关话题

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

20181227080511775.png



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

20181227080702828.png



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绝对不是一个经济的选择:

20181227091438404.png



将grafana集成到kibana中


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

20181227091946394.png



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

metric.gif



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







kibana query 大于值问题。

trycatchfinal 回复了问题 • 2 人关注 • 1 个回复 • 404 次浏览 • 2018-12-26 21:13 • 来自相关话题

kibana分别使用Timelion和饼状图显示一小时的流量结果不一样

zqc0512 回复了问题 • 3 人关注 • 4 个回复 • 407 次浏览 • 2018-12-24 08:58 • 来自相关话题

kibana可视化 中怎么 截取keyword 信息

zqc0512 回复了问题 • 5 人关注 • 4 个回复 • 488 次浏览 • 2018-12-24 08:51 • 来自相关话题

Kibana开发环境搭建问题

juin 回复了问题 • 3 人关注 • 2 个回复 • 384 次浏览 • 2018-12-21 16:31 • 来自相关话题

es有9台机器,3台master,6台data节点,那么kibana配置文件中elasticsearch.url怎么写?

Leeeo 回复了问题 • 4 人关注 • 2 个回复 • 336 次浏览 • 2018-12-21 16:22 • 来自相关话题

kibana页面的Dev Tools模块为什么不断得进行两个post请求?

rochy 回复了问题 • 2 人关注 • 1 个回复 • 183 次浏览 • 2018-12-21 14:02 • 来自相关话题

Kibana查询结果根据字段进行去重

insist_93 回复了问题 • 3 人关注 • 2 个回复 • 4050 次浏览 • 2018-12-18 09:21 • 来自相关话题

kibana visualize terms中的字段是"string",但是索引中的mapping是date

rochy 回复了问题 • 2 人关注 • 2 个回复 • 208 次浏览 • 2018-12-15 10:06 • 来自相关话题

用elasitc stack监控kafka

点火三周 发表了文章 • 0 个评论 • 473 次浏览 • 2018-12-12 11:28 • 来自相关话题

当我们搭建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里面看到:

      20181212112635653.png


      2018121211265464.png




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

Kibana优化过程(Optimize)过长或无法结束的解决方案

点火三周 发表了文章 • 5 个评论 • 486 次浏览 • 2018-12-12 11:06 • 来自相关话题

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


20181212101105813.png




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

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文件:


20181212101741186.png




而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的过程


kibana 作图 advanced 里的json input怎么使用

medcl 回复了问题 • 2 人关注 • 1 个回复 • 868 次浏览 • 2018-12-10 15:47 • 来自相关话题

kibana分析nginx日志,还在纠结用filebeat还是logstash

xiaoke 回复了问题 • 5 人关注 • 4 个回复 • 983 次浏览 • 2018-12-04 20:29 • 来自相关话题

如何更新ES中数据

tyzuo 回复了问题 • 3 人关注 • 4 个回复 • 539 次浏览 • 2018-12-04 14:49 • 来自相关话题

metricsbeat中配置的项为什么在kibana中没有生效

rojay 回复了问题 • 2 人关注 • 2 个回复 • 786 次浏览 • 2018-12-04 08:55 • 来自相关话题