kibana 中使用script 处理时间
Elasticsearch • laoyang360 回复了问题 • 2 人关注 • 1 个回复 • 1917 次浏览 • 2019-01-14 22:39
社区日报 第509期 (2019-01-14)
社区日报 • cyberdak 发表了文章 • 0 个评论 • 1056 次浏览 • 2019-01-14 14:00
http://t.cn/Eq9VgsV
2.在kibana中集中管理rollup任务
http://t.cn/EqtKAf7
3.在es崩溃以后自动重启
http://t.cn/Eq9IJFG
编辑:cyberdak
归档:https://elasticsearch.cn/article/6330
订阅:https://tinyletter.com/elastic-daily
社区日报 第508期 (2019-01-13)
社区日报 • 至尊宝 发表了文章 • 0 个评论 • 1348 次浏览 • 2019-01-13 10:43
http://t.cn/EqcmScm
2.使用ANTLR从GSA迁移到Elasticsearch。
http://t.cn/Eqc3j1w
3.(自备梯子)将定义2019年的技术。
http://t.cn/EqUQ61i
编辑:至尊宝
归档:https://elasticsearch.cn/article/6329
订阅:https://tinyletter.com/elastic-daily
logstash6.3处理filebeat过滤不生效
Logstash • bellengao 回复了问题 • 1 人关注 • 1 个回复 • 1481 次浏览 • 2019-01-13 00:24
maxwell+kafka+logstash同步数据的时候碰到mysql中的null值取不到
Logstash • bellengao 回复了问题 • 2 人关注 • 1 个回复 • 2102 次浏览 • 2019-01-13 00:12
社区日报 第507期 (2019-01-12)
社区日报 • bsll 发表了文章 • 0 个评论 • 1789 次浏览 • 2019-01-12 16:53
1、在kibana里创建、管理、可视化汇总数据
[http://t.cn/EqtKAf7](http://t.cn/EqtKAf7)
2、在Spring Boot使用ES教程
[http://t.cn/Eqt9rC4](http://t.cn/Eqt9rC4)
3、一周热点:GitHub提供免费私有Repo
[http://t.cn/EGmbUQX](http://t.cn/EGmbUQX)
es聚合高阶API中设计到script脚本的,灵活度比较大,怎么深入学习?
Elasticsearch • God_lockin 回复了问题 • 2 人关注 • 1 个回复 • 3230 次浏览 • 2019-01-12 15:08
ElasticSearch java api,想要实现一次请求查询多个类型的同时,每个类型只取固定数量的数据
Elasticsearch • HelloClyde 回复了问题 • 5 人关注 • 4 个回复 • 4784 次浏览 • 2019-01-12 10:55
es 平滑升级,从1.7升级到5.5或6.x
Elasticsearch • fanmo3yuan 回复了问题 • 4 人关注 • 3 个回复 • 3804 次浏览 • 2019-01-12 10:55
查询效率和mapping的关系
Elasticsearch • elasticStack 回复了问题 • 6 人关注 • 7 个回复 • 3523 次浏览 • 2019-01-11 14:35
社区日报 第506期(2019-1-11)
社区日报 • laoyang360 发表了文章 • 0 个评论 • 1224 次浏览 • 2019-01-11 12:44
http://t.cn/EqLtnXp
2、Elasticsearch索引管理利器——Curator深入详解
http://t.cn/EqL9Tdq
3、ES分片分配策略
http://t.cn/EqLc7XK
编辑:铭毅天下
归档:https://elasticsearch.cn/article/6327
订阅:https://tinyletter.com/elastic-daily
ES集群写入性能问题
Elasticsearch • zqc0512 回复了问题 • 7 人关注 • 3 个回复 • 7140 次浏览 • 2019-01-11 10:59
ES中是否无法实现 mysql 类似的 join
Elasticsearch • fanmo3yuan 回复了问题 • 5 人关注 • 4 个回复 • 6590 次浏览 • 2019-01-11 10:50
如何让kibana零等待时间升级插件(前后端分离的部署)
Kibana • 点火三周 发表了文章 • 1 个评论 • 3026 次浏览 • 2019-01-11 10:30
正如官方文档所自豪宣称的那样。Kibana更多的是一个平台,一个可以让插件独立开发,“独立部署”的可扩展性平台,可以让我们自由的发挥自己的想象力和能力,根据自己的需求往上添加原生Kibana所不提供的功能。你可以开发一个新的app,也可以只部署一个后台服务,也可以是一个隐藏的跳转页面,这些,都有赖于plugin的方式,自由的在kibana上install, update和remove。
问题描述
以上。看起来是比较美好的,但硬币的反面是kibana作为一个单页应用,任何都其他功能都是"/"路径下都一个子path,任何插件的安装(除非是一个纯后台的服务,但我没有测试)都需要和主页面、所有已安装都插件产生联系,即每次插件都变动,都需要将所有的页面和js重新bundle一次。这个捆绑不是简单的捆绑,而是经过优化后的打包操作,相当耗时。重点是,按照目前的方式,optimize(bundle)的过程必须是现场的,即必须在正在运行的kibana服务器上进行,因此在以下情况下你可能会遇到麻烦:
- 你的kibana服务作为一个生产服务,不能停
- 你没有给kibana做双活
- 因为只是一个前端,你给kibana分配的硬件资源很少(单核2G,双核4G)
- 你使用的是6.3之后的版本,kibana已经默认安装了xpack。或者你是之前的版本,自己手动安装了xpack
这时,你若是安装或者更新插件(包括remove插件),都可能会因为optimize过程占用大量的cpu和内存资源,而造成kibana停止服务响应。
这里有一个小tips,如果你开发了多个插件,需要同时更新当时候,安装当时候请使用命令
kibana-plugin install --no-optimize file:///path_to_your_file
,当全部的插件都安装完了之后,再重启kibana,一次性的执行optimize流程,或者通过bin/kibana --optimize
命令触发
Kibana架构简述
如果我们的目标是让kibana零等待时间升级插件,找到解决方案的前提是我们能够了解Kibana的软件架构和部署方式。
首先,我们需要知道的是Kibana是一个基于node的web应用,前端后端都主要使用的javascript。web后端使用的hapi作为web服务器应用程序。并且node无需安装,已经包含在了kibana目录下。(node目录)
以下是kibana的目录,所有的插件都安装在plugins目录,而所有打包后的内容都放在optimize目录。
shell<br /> ├── LICENSE.txt<br /> ├── NOTICE.txt<br /> ├── README.txt<br /> ├── bin<br /> ├── config<br /> ├── data<br /> ├── node<br /> ├── node_modules<br /> ├── optimize<br /> ├── package.json<br /> ├── plugins<br /> ├── src<br /> └── webpackShims<br />
plugins目录(这里,我有两个插件):
shell<br /> .<br /> ├── kibana_auth_plugin<br /> │ ├── index.js<br /> │ ├── node_modules<br /> │ ├── package.json<br /> │ ├── public<br /> │ ├── server<br /> │ └── yarn.lock<br /> └── system_portal<br /> ├── index.js<br /> ├── node_modules<br /> ├── package.json<br /> ├── public<br /> ├── server<br /> └── yarn.lock<br />
每个插件都是类似的目录结构。public
目录存放的是前端的页面和js,server
目录存放的是后端的js。这里最终要的信息是,插件的开发其实也是一种 前后端分离的架构 。插件安装后后端主程序会调用server
目录下的文件,而前端public目录下的文件会被压缩后打包到optimize
目录,详见如下。
optimize目录:
shell<br /> ├── bundles<br /> │ ├── 176bcca991b07a6ec908fc4d36ac5ae0.svg<br /> │ ├── 45c73723862c6fc5eb3d6961db2d71fb.eot<br /> │ ├── 4b5a84aaf1c9485e060c503a0ff8cadb.woff2<br /> │ ├── 69d89e51f62b6a582c311c35c0f778aa.svg<br /> │ ├── 76a4f23c6be74fd309e0d0fd2c27a5de.svg<br /> │ ├── 7c87870ab40d63cfb8870c1f183f9939.ttf<br /> │ ├── apm.bundle.js<br /> │ ├── apm.entry.js<br /> │ ├── apm.style.css<br /> │ ├── kibana-auth-plugin.bundle.js<br /> │ ├── kibana-auth-plugin.entry.js<br /> │ ├── kibana-auth-plugin.style.css<br /> │ ├── canvas.bundle.js<br /> │ ├── canvas.entry.js<br /> │ ├── canvas.style.css<br /> │ ├── cc17a3dbad9fc4557b4d5d47a38fcc56.svg<br /> │ ├── commons.bundle.js<br /> │ ├── commons.style.css<br /> │ ├── dashboardViewer.bundle.js<br /> │ ├── dashboardViewer.entry.js<br /> │ ├── dashboardViewer.style.css<br /> │ ├── dfb02f8f6d0cedc009ee5887cc68f1f3.woff<br /> │ ├── fa0bbd682c66f1187d48f74b33b5bbd0.svg<br /> │ ├── graph.bundle.js<br /> │ ├── graph.entry.js<br /> │ ├── graph.style.css<br /> │ ├── infra.bundle.js<br /> │ ├── infra.entry.js<br /> │ ├── infra.style.css<br /> │ ├── kibana.bundle.js<br /> │ ├── kibana.entry.js<br /> │ ├── kibana.style.css<br /> │ ├── ml.bundle.js<br /> │ ├── ml.entry.js<br /> │ ├── ml.style.css<br /> │ ├── monitoring.bundle.js<br /> │ ├── monitoring.entry.js<br /> │ ├── monitoring.style.css<br /> │ ├── space_selector.bundle.js<br /> │ ├── space_selector.entry.js<br /> │ ├── space_selector.style.css<br /> │ ├── src<br /> │ ├── stateSessionStorageRedirect.bundle.js<br /> │ ├── stateSessionStorageRedirect.entry.js<br /> │ ├── stateSessionStorageRedirect.style.css<br /> │ ├── status_page.bundle.js<br /> │ ├── status_page.entry.js<br /> │ ├── status_page.style.css<br /> │ ├── system_portal.bundle.js<br /> │ ├── system_portal.entry.js<br /> │ ├── system_portal.style.css<br /> │ ├── timelion.bundle.js<br /> │ ├── timelion.entry.js<br /> │ ├── timelion.style.css<br /> │ ├── vendors.bundle.js<br /> │ └── vendors.style.css<br />
前端浏览器在访问"/"目录的时候会最先获取到kibana.*.js
相关的文件。我们看一下
kibana.entry.js
, 里面是包含了所有插件的信息的,即,每次插件的变动,这些文件也会跟着跟新
```js
/** - Kibana entry file
* - This is programmatically created and updated, do not modify
* - context: ä
"env": "production",
"kbnVersion": "6.5.0",
"buildNum": 18730,
"plugins": Ä
"apm",
"apm_oss",
"beats_management",
"kibana_auth_plugin",
"canvas",
"cloud",
"console",
"console_extensions",
"dashboard_mode",
"elasticsearch",
"graph",
"grokdebugger",
"index_management",
"infra",
"input_control_vis",
"inspector_views",
"kbn_doc_views",
"kbn_vislib_vis_types",
"kibana",
"kuery_autocomplete",
"license_management",
"logstash",
"markdown_vis",
"metric_vis",
"metrics",
"ml",
"monitoring",
"notifications",
"region_map",
"reporting",
"rollup",
"searchprofiler",
"spaces",
"state_session_storage_redirect",
"status_page",
"system_portal",
"table_vis",
"tagcloud",
"tile_map",
"tilemap",
"timelion",
"vega",
"watcher",
"xpack_main"
Å
å
*/
// import global polyfills before everything else
import 'babel-polyfill';
import 'custom-event-polyfill';
import 'whatwg-fetch';
import 'abortcontroller-polyfill';
import 'childnode-remove-polyfill';
import ä i18n å from 'Ékbn/i18n';
import ä CoreSystem å from 'kibanaCore'
const injectedMetadata = JSON.parse(document.querySelector('kbn-injected-metadata').getAttribute('data'));
i18n.init(injectedMetadata.legacyMetadata.translations);
new CoreSystem(ä
injectedMetadata,
rootDomElement: document.body,
requireLegacyFiles: () => ä
require('plugins/kibana/kibana');
å
å).start()
```
优化部署的方案(前后端分离的部署)
我们已经初步了解了kibana和kibana plugins的架构。那kibana插件的安装方案是怎么样的呢?
kibana为了简化我们的工作,只需要我们将打包好的源码丢给kibana,然后执行命令:kibana-plugin install file:///path_to_your_file
,这样貌似省事,但也把所有的工作都丢给了kibana服务器去完成。
在kibana服务器性能不佳的情况下,这部分工作可能会造成服务中断。因此,我们要代替kibana服务器完成这部分工作,做一个前后端分离的部署。
后端部署
后端部署的速度是极快的,只需要把文件解压缩到具体目录就可以:
<br /> `kibana-plugin install --no-optimize file:///path_to_your_file`<br />
这里特别要注意:--no-optimize
参数是必须的,这时,插件的安装只是一个解压的过程,不会让kibana服务器去做繁重的optimize工作。注意,执行这一步之后,不能重启kibana服务器,否则会自动做optimize
前端部署
这里说的前端,主要是指bundle之后的内容。在你的开发环境上,安装插件。当插件安装完成后,把bundles目录整体打包(bundles.zip)。将打包好之后的内容,上传到kibana服务器,删除旧的
optimize/bundles
目录,把打包好的bundles目录解压到optimize
目录下
注意,这里开发环境上的kibana版本,和kibana安装的插件必须是和生产环境上是一致的,否则会造成无法启动或者自动重做optimize
重启kibana服务器
当以上两步完成之后,重启kibana service即可,你会发现,内容已经更新,但是不会触发任何的optimize过程。
参考示例
以下是该过程的一个ansible playbook供大家参考
```yaml
---
- name: deploy bundles zip
copy: src=bundles.zip dest={{kibana_home}}/optimize force=yes mode={{file_mask}}
- name: deploy system plugins zip
copy: src=system_portal-0.0.0.zip dest={{kibana_home}}/ force=yes mode={{file_mask}}
- name: deploy auth zip
copy: src=kibana_auth_plugin-6.5.0.zip dest={{kibana_home}}/ force=yes mode={{file_mask}}
- name: remove system plugin
shell: "{{kibana_home}}/bin/kibana-plugin remove system_portal"
ignore_errors: True
- name: remove auth plugin
shell: "{{kibana_home}}/bin/kibana-plugin remove kibana_auth_plugin"
ignore_errors: True
- name: install system plugin
shell: "{{kibana_home}}/bin/kibana-plugin install --no-optimize file://{{kibana_home}}/system_portal-0.0.0.zip"
register: install_state
- name: install auth plugin
shell: "{{kibana_home}}/bin/kibana-plugin install --no-optimize file://{{kibana_home}}/kibana_auth_plugin-6.5.0.zip"
register: install_state
failed_when: "'Extraction complete' in install_state.stdout_lines"
- name: delete old bundls
file: dest={{kibana_home}}/optimize/bundles state=absent
- name: delete old bundls
unarchive:
src: "{{kibana_home}}/optimize/bundles.zip"
dest: "{{kibana_home}}/optimize/"
copy: no
group: "kibana"
owner: "kibana"
mode: "{{file_mask}}"
- name: delete zip files
file: dest={{kibana_home}}/optimize/bundles.zip state=absent
- name: restart kibana
become: yes
service: name={{kibana_init_script | basename}} state=restarted enabled=yes
- name: deploy bundles zip
使用join field做父子关系查询疑惑
Elasticsearch • json_111 回复了问题 • 5 人关注 • 3 个回复 • 3915 次浏览 • 2019-01-11 09:53