在6.0版本以前，登录kibana之后，默认会路由到app/kibana下的discover应用。
在6.3版本以后，新增了一个home路径/app/kibana#/home?_g=h@44136fa，访问根路径\会直接跳到以上路径。

希望在kibana上做更多定制化开发的同学，或许会有需求在登录kibana之后能够跳转到自己的页面。

要完成以上需求，只需要在kibana的配置文件里面增加一行：
<br /> server.defaultRoute: /app/system_portal<br />
以上例子，我让kibana登录之后直接跳到我自己的app插件system_portal

配置默认路由的文件, src/server/http/get_default_route.js：
js<br /> import _ from 'lodash';<br /> <br /> export default _.once(function (kbnServer) {<br /> const {<br /> config<br /> } = kbnServer;<br /> // 根目录basePath加上defaultRoute<br /> return `${config.get('server.basePath')}${config.get('server.defaultRoute')}`;<br /> });<br />

默认路由就是定义在server.defaultRoute中，默认值是app/kibana，可查看src/server/config/schema.js:
``js<br /> import Joi from 'joi';<br /> import { constants as cryptoConstants } from 'crypto';<br /> import os from 'os';<br /> <br /> import { fromRoot } from '../../utils';<br /> import { getData } from '../path';<br /> <br /> export default async () => Joi.object({<br /> pkg: Joi.object({<br /> version: Joi.string().default(Joi.ref('$version')),<br /> branch: Joi.string().default(Joi.ref('$branch')),<br /> buildNum: Joi.number().default(Joi.ref('$buildNum')),<br /> buildSha: Joi.string().default(Joi.ref('$buildSha')),<br /> }).default(),<br /> <br /> env: Joi.object({<br /> name: Joi.string().default(Joi.ref('$env')),<br /> dev: Joi.boolean().default(Joi.ref('$dev')),<br /> prod: Joi.boolean().default(Joi.ref('$prod'))<br /> }).default(),<br /> <br /> dev: Joi.object({<br /> basePathProxyTarget: Joi.number().default(5603),<br /> }).default(),<br /> <br /> pid: Joi.object({<br /> file: Joi.string(),<br /> exclusive: Joi.boolean().default(false)<br /> }).default(),<br /> <br /> cpu: Joi.object({<br /> cgroup: Joi.object({<br /> path: Joi.object({<br /> override: Joi.string().default()<br /> })<br /> })<br /> }),<br /> <br /> cpuacct: Joi.object({<br /> cgroup: Joi.object({<br /> path: Joi.object({<br /> override: Joi.string().default()<br /> })<br /> })<br /> }),<br /> <br /> server: Joi.object({<br /> uuid: Joi.string().guid().default(),<br /> name: Joi.string().default(os.hostname()),<br /> host: Joi.string().hostname().default('localhost'),<br /> port: Joi.number().default(5601),<br /> maxPayloadBytes: Joi.number().default(1048576),<br /> autoListen: Joi.boolean().default(true),<br /> defaultRoute: Joi.string().default('/app/kibana').regex(/^\//,start with a slash),<br /> basePath: Joi.string().default('').allow('').regex(/(^$|^\/.*[^\/]$)/,start with a slash, don't end with one`),
rewriteBasePath: Joi.boolean().when('basePath', {
is: '',
then: Joi.default(false).valid(false),
otherwise: Joi.default(false),
}),
customResponseHeaders: Joi.object().unknown(true).default({}),
ssl: Joi.object({
enabled: Joi.boolean().default(false),
redirectHttpFromPort: Joi.number(),
certificate: Joi.string().when('enabled', {
is: true,
then: Joi.required(),
}),
key: Joi.string().when('enabled', {
is: true,
then: Joi.required()
}),
keyPassphrase: Joi.string(),
certificateAuthorities: Joi.array().single().items(Joi.string()).default(),
supportedProtocols: Joi.array().items(Joi.string().valid('TLSv1', 'TLSv1.1', 'TLSv1.2')),
cipherSuites: Joi.array().items(Joi.string()).default(cryptoConstants.defaultCoreCipherList.split(':'))
}).default(),
cors: Joi.when('$dev', {
is: true,
then: Joi.object().default({
origin: ['://localhost:9876'] // karma test server
}),
otherwise: Joi.boolean().default(false)
}),
xsrf: Joi.object({
disableProtection: Joi.boolean().default(false),
whitelist: Joi.array().items(
Joi.string().regex(/^\//, 'start with a slash')
).default(),
token: Joi.string().optional().notes('Deprecated')
}).default(),
}).default(),

logging: Joi.object().keys({
silent: Joi.boolean().default(false),

quiet: Joi.boolean()
.when('silent', {
is: true,
then: Joi.default(true).valid(true),
otherwise: Joi.default(false)
}),

verbose: Joi.boolean()
.when('quiet', {
is: true,
then: Joi.valid(false).default(false),
otherwise: Joi.default(false)
}),

events: Joi.any().default({}),
dest: Joi.string().default('stdout'),
filter: Joi.any().default({}),
json: Joi.boolean()
.when('dest', {
is: 'stdout',
then: Joi.default(!process.stdout.isTTY),
otherwise: Joi.default(true)
}),

useUTC: Joi.boolean().default(true),
})
.default(),

ops: Joi.object({
interval: Joi.number().default(5000),
}).default(),

plugins: Joi.object({
paths: Joi.array().items(Joi.string()).default(),
scanDirs: Joi.array().items(Joi.string()).default(),
initialize: Joi.boolean().default(true)
}).default(),

path: Joi.object({
data: Joi.string().default(getData())
}).default(),

optimize: Joi.object({
enabled: Joi.boolean().default(true),
bundleFilter: Joi.string().default('!tests'),
bundleDir: Joi.string().default(fromRoot('optimize/bundles')),
viewCaching: Joi.boolean().default(Joi.ref('$prod')),
watch: Joi.boolean().default(false),
watchPort: Joi.number().default(5602),
watchHost: Joi.string().hostname().default('localhost'),
watchPrebuild: Joi.boolean().default(false),
watchProxyTimeout: Joi.number().default(5 60000),
useBundleCache: Joi.boolean().default(Joi.ref('$prod')),
unsafeCache: Joi.when('$prod', {
is: true,
then: Joi.boolean().valid(false),
otherwise: Joi
.alternatives()
.try(
Joi.boolean(),
Joi.string().regex(/^\/.+\/$/)
)
.default(true),
}),
sourceMaps: Joi.when('$prod', {
is: true,
then: Joi.boolean().valid(false),
otherwise: Joi
.alternatives()
.try(
Joi.string().required(),
Joi.boolean()
)
.default('#cheap-source-map'),
}),
profile: Joi.boolean().default(false)
}).default(),
status: Joi.object({
allowAnonymous: Joi.boolean().default(false)
}).default(),
map: Joi.object({
manifestServiceUrl: Joi.string().default(' https://catalogue.maps.elastic.co/v2/manifest'),
emsLandingPageUrl: Joi.string().default('https://maps.elastic.co/v2'),
includeElasticMapsService: Joi.boolean().default(true)
}).default(),
tilemap: Joi.object({
url: Joi.string(),
options: Joi.object({
attribution: Joi.string(),
minZoom: Joi.number().min(0, 'Must be 0 or higher').default(0),
maxZoom: Joi.number().default(10),
tileSize: Joi.number(),
subdomains: Joi.array().items(Joi.string()).single(),
errorTileUrl: Joi.string().uri(),
tms: Joi.boolean(),
reuseTiles: Joi.boolean(),
bounds: Joi.array().items(Joi.array().items(Joi.number()).min(2).required()).min(2)
}).default()
}).default(),
regionmap: Joi.object({
includeElasticMapsService: Joi.boolean().default(true),
layers: Joi.array().items(Joi.object({
url: Joi.string(),
format: Joi.object({
type: Joi.string().default('geojson')
}).default({
type: 'geojson'
}),
meta: Joi.object({
feature_collection_path: Joi.string().default('data')
}).default({
feature_collection_path: 'data'
}),
attribution: Joi.string(),
name: Joi.string(),
fields: Joi.array().items(Joi.object({
name: Joi.string(),
description: Joi.string()
}))
}))
}).default(),

i18n: Joi.object({
defaultLocale: Joi.string().default('en'),
}).default(),

// This is a configuration node that is specifically handled by the config system
// in the new platform, and that the current platform doesn't need to handle at all.
__newPlatform: Joi.any(),

}).default();

正如官方文档所自豪宣称的那样。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
    
    
    
    

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