kylin有个监控面板的功能，当我们打开该面板时，kylin页面上会多一个监控模块，该模块会记录kylin的查询以及cube相关的一些数据，如下图所示：

这个监控模块是比较重要的，因为从这可以看出kylin的使用状态和运行性能，下面我们来讲一下如何开启dashboard。

1、配置开启dashboard功能

在 kylin.properties 中设置 kylin.web.dashboard-enabled=true

开启了该配置后，在kylin页面上就可以看到dashboard监控面板，如下：

但是此时面板数据全为0，且可能会弹窗报错说查不到数据。这是正常的，因为监控面板所展示的数据要通过cube去构建，下面我们看看如何构建这些cube.

2、构建dashboard展示需要的hive表和cube

kylin 2.6.0之前的版本很麻烦，需要各种手动去操作，2.6.0之后的版本就简单很多，有现成的脚本可以直接调用，即从kylin 2.6.0 开始提供 system-cube.sh 脚本，用户可以通过执行此脚本来自动创建系统 Cube。

        创建系统 Cube：sh bin/system-cube.sh setup
        构建系统 Cube：sh bin/system-cube.sh build
        为系统 Cube 添加定时任务：sh bin/system-cube.sh cron

执行完上述三个脚本后，kylin工程里面就会有KYLIN_SYSTEM这个工程，可以看到它有如下这些信息：

 在KYLIN_SYSTEM工程里，会有五张表，对应五个模型以及cube，dashboard中的数据就是通过查询这些cube获得。当cube在自动构建完或者手动触发构建（我是直接手动点的bulid）完之后，就可以正常的查询（但是到此为止展示还有问题）。

3、开启metric上报

到上一步为止查询是没问题了，但是展示的数据都是零，查看接口也可以看到kylin服务端返回的数据就是0。如下所示：

于是推测kylin可能cube和hive中数据就为空，去hive查询发现表中数据确实为空。再推测在查询或者job构建的时候，没有把对应的度量信息上报上去。于是查询kylin所有跟metric相关的配置：

kylin.server.query-metrics2-enabled：默认值为 TRUE
kylin.metrics.reporter-query-enabled：默认值为 TRUE
kylin.metrics.reporter-job-enabled：默认值为 TRUE
kylin.metrics.monitor-enabled：默认值为 TRUE
kylin.stream.metrics.option: 是否开启Receiver端的metrics信息收集,
kylin.server.query-metrics-enabled：默认值为 FALSE，是否将查询指标收集到 JMX
kylin.server.query-metrics2-enabled：默认值为 FALSE，是否将度量上报到dropwizard

简单直接的解决办法肯定是把所有的度量上报都开启，这样页面肯定就没问题了，这里我先把正确的配置展示出来，其实我们配置下面的几个配置就够了：

kylin.web.dashboard-enabled=true 是否显示监控面板
kylin.metrics.monitor-enabled=true 是否开启监控 
kylin.server.query-metrics-enabled=true 上报查询相关信息到内存
kylin.server.query-metrics2-enabled=true 上报cube相关信息到内存
kylin.metrics.reporter-query-enabled=true 上报查询相关信息到存储器
kylin.metrics.reporter-job-enabled=true 上报job相关信息到存储器

但是知其然再知其所以然岂不是更好（我的版本是3.1.0版本，如果其它版本使用上述配置不生效，则可以参考我下面的源码追踪方式，到自己使用版本的源码中去看下如何配置），我这里展示一下如何通过源码定位我们要开启的配置，就拿query count指标展示来说，它肯定是在查询的时候把数据上报上去，所以我们去query相关的kylin源码中去debug追踪看下是否metrics上报相关的代码：

 接下来的doQueryWithCache是比较重要的，因为它包含了度量上报的信息，源码如下：

可以看到这查询结束时会有个recordMetric方法被调用，其英文含义正好是上报度量，我们到该方法中看一下：

可以看到该方法会上报两种度量信息，第一个metrics类方法是上报查询相关的度量信息，第二个metrics2方法则是上报cube相关的度量信息，这些在后续的源码中都可以自己观察到。好了，我们先看下第一个更新方法：

 可以看到这一步又有两个方法，一个是更新度量到本地，一个是更新度量到hive存储中。我们先看第一个存储到本地的方法：

 可以看到再本地存储的时候会根据 kylin.server.query-metrics-enabled 的配置值来判断是否将查询相关的度量信息存储到当前内存中，默认为false，也即不存储到本地。

接下来我们再看下存储到hive中方法的实现逻辑：

 可以看到，kylin会根据kylin.metrics.reporter-query-enabled的配置值来判断是否将查询相关的度量信息上报到hive存储中（这个配置一定要开启）。

注意，在这一步还有一个隐藏的大坑，我也是配置后发现没数据再次重新过了好几遍源码才发现的，就是在updateMetricsToReservoir方法末尾调用MetrcsManager的update去上报度量信息时会去遍历要上报的点。

 而这个集合是初始化的时候去加载的，初始化的方法如下：

只有kylin.metrics.monitor-enabled为true时，才会对activeReservoirPointers集合添加值，而官网说该配置默认为true，但是实际上查询时默认的值为false，所以这块是一块巨坑，千万不要忘记配置，而且通过这我也得出一个使用建议，那就是不要相信一些默认配置，如果有用到的配置，尽量显式去配置。 

下面我们再来看下QueryMetrics2Facade.updateMetrics方法的实现：

 可以看到kylin通过 kylin.server.query-metrics2-enabled 配置来判断是否上报cube相关的度量信息。

接下来我们在kylin.properties中再配置下述的四个配置为true，并重启kylin来看一下效果：

kylin.metrics.monitor-enabled 是否开启监控 
kylin.server.query-metrics-enabled 是否将度量信息上报存储到本地
kylin.metrics.reporter-query-enabled 是否将度量信息上报存储到特定存储器中（hive数仓）
kylin.server.query-metrics2-enabled 是否将度量上报存储到本地

重启后再发起几次查询，然后再发起kylin-system中cube的构建，可以看到dashboard的记录信息如下所示：

 到这我们基本就清楚开启哪个配置可以保证query count相关数据的上报了，其它度量的上报配置追踪方式与此类似，感兴趣的可以自己参考上述的方式进行追踪验证，如果嫌麻烦则可以直接将最开始的配置直接拷贝拿过去用即可，不过这个配置我是在3.1.0版本用的没问题，其它版本没测试过，如果有遇到配置不生效的情况，则可以参考上述过程自己去探查下具体配置哪些信息可以控制上报度量信息。

另外再说一个配置建议：尽量不要相信默认配置，如果你有用的到的配置，尽量显式去配置，因为很有可能默认配置不生效。

参考文档：

Apache Kylin | 使用 Dashboard