Kibana 7.8.0 的 Dashboard 是我做过日志分析项目后最常用的一个功能。很多人一上来就埋头做可视化图表，做完之后才发现不知道怎么把这些图表组合成一个能日常盯控的页面；还有的人把 Dashboard 建出来了，但时间范围、刷新频率、数据粒度全都没配合好，实际用起来总觉得别扭。这篇文章就把我从环境准备到面板布局、再到共享和排查的完整经验捋一遍，目标是让拿到 Kibana 7.8.0 的人能踏踏实实把 Dashboard 用起来。
1. Dashboard 到底是什么，为什么要用版本 7.8.0
1.1 Dashboard 在 Kibana 里的定位
Kibana 是 Elasticsearch 的可视化前端，但 Elasticsearch 本身只负责存储和检索数据，它不会帮你把数据"画出来"。Dashboard 就是 Kibana 里负责组合展示的那一层：它把多个已经做好的可视化图表、文本说明、搜索栏、过滤条件聚合到一个页面上，让你不用每次都去翻一个个孤立的图表，而是一眼看到全局状态。
我在实际项目里最典型的用法是这样的：服务器日志进了 Elasticsearch，索引模式建好之后，我先做了几个单独的可视化——访问量折线图、错误类别饼图、响应时间分布柱状图、TOP 请求地址列表。单独看每个图都能用，但每次排查问题都要点来点去，效率很低。把这些图放进同一个 Dashboard 之后，配合全局时间筛选，整个系统的运行状态就全部集中在一个页面上，排查问题时只需要拖动时间范围，所有图表同步变化，这个体验是单看图表完全比不了的。
Dashboard 解决的核心问题不是"怎么画图"，而是"怎么把散落的图变成一个可用于持续观察、定位和汇报的统一视图"。它向上承接 Kibana 的 Discover 和 Visualize，向下对接 Elasticsearch 的聚合查询，是日志分析、业务监控、运维大屏这些场景里最常被打开的那一屏。
1.2 为什么专门说 7.8.0 这个版本
Kibana 7.8.0 是 7.x 中期一个比较稳定的版本，它的 Dashboard 体验和更早的 6.x 相比有明显改进：面板之间的拖拽缩放更顺滑，支持了 dashboard 级别的 iframe 嵌入参数，也引入了更细的日期格式控制。和 8.x 相比，7.8.0 又保留了不少老用户熟悉的操作习惯，没有强制走新版 navigational 布局思路。简单说，7.8.0 属于"功能完整、交互传统、踩坑资料多"的版本，适合作为入门版本，踩到的坑基本都能在社区里找到答案。
如果你的环境还是 6.x，看完这篇文章后升级思路也会很清晰，因为 7.8.0 的 Dashboard 核心交互逻辑和 6.x 是一脉相承的，只是布局和部分菜单位置变了。如果你已经上了 8.x，下面讲的索引模式、创建可视化、面板管理这些底层概念也完全通用。
1.3 Dashboard 与其他 Kibana 功能的配合关系
想用好 Dashboard，必须先理解它依赖的几个前置模块：
- 索引模式（Index Pattern）：Dashboard 里的所有图表都不是凭空画出来的，每个可视化背后都绑定一个或多个索引模式。索引模式定义了"从哪个索引读数据""哪个字段是时间字段""哪些字段是 keyword 类型可以做聚合"。我在实际使用中见过不少人跳过索引模式直接去建 Dashboard，结果图表里没有数据，回头才发现是索引模式没配好。
- 可视化库（Visualize Library）：7.8.0 的 Dashboard 不是直接在页面里画图，而是先把图建在可视化库里，再引用到 Dashboard 上。这也意味着同一个可视化可以被多个 Dashboard 复用，改一处，所有引用它的位置都会更新。
- Discover：Discover 负责原始数据检索，Dashboard 里的每个图表通常是从 Discover 的检索逻辑演变而来的。两者的过滤语法和字段选择逻辑一致。
弄清楚这层关系，你就知道入门 Dashboard 的正确顺序应该是：先准备好 Elasticsearch 里的数据和索引模式，再做若干个可视化，最后创建 Dashboard 把这些可视化按布局组合起来。顺序反了，后面返工是必然的。
2. 环境准备：数据、索引模式和基础校验
2.1 部署和初始化的几个要点
Kibana 7.8.0 的安装本身不复杂，tar 包解压后改一下kibana.yml里的server.host、elasticsearch.host就行。但有几个细节直接影响 Dashboard 后面的使用体验，我建议你在开始前就确认好。
第一，Kibana 和 Elasticsearch 的大版本必须匹配。7.8.0 的 Kibana 对接 7.8.x 的 Elasticsearch 最稳妥，差一个大版本很容易出现索引数据读取异常或者可视化查询报错。第二，确认kibana.yml里没有把server.basePath或server.rewriteBasePath设置得过于复杂，否则 Dashboard 里的资源路径会出错，图表加载不出来。第三，内存规划要稍微留点余量，Kibana 7.8.0 默认 JVM 堆设置比较保守，但 Dashboard 页面里图表一多，浏览器端的渲染压力和 Kibana 服务端的数据聚合压力都会上升，建议给 Kibana 所在节点至少 4GB 可用内存。
我见过最典型的入门事故是：Kibana 启动成功了，Discover 也能查数据，但 Dashboard 页面打开后图表一直转圈。后来排查发现是 Kibana 服务端请求 Elasticsearch 的聚合超时了，因为默认的elasticsearch.requestTimeout在某些慢查询场景下不够用。如果你也遇到这种情况，可以先在kibana.yml里把elasticsearch.requestTimeout调大一点，比如从默认的 30000 改成 60000，先让功能跑起来，再考虑查询优化。
2.2 导入一份适合练手的示例数据
刚开始学 Dashboard，我不建议直接用生产环境指标，因为数据字段太复杂，一会儿是嵌套对象，一会儿是数组，新手很容易被绕晕。更好的做法是导入一份结构简单的示例数据。Kibana 7.8.0 自带 Sample Data，在首页左侧菜单里可以找到 "Add sample data"，里面包含三套：Sample web logs、Sample flight data、Sample ecommerce orders。
我最推荐的是 Sample web logs，它模拟了一周左右的 Web 访问日志，字段包括timestamp、request、status_code、bytes、machine.os等，结构非常直观，很适合练习折线图、柱状图、饼图和表格。导入之后，系统会自动生成对应的索引模式，比如kibana_sample_data_logs，并且在 Dashboard 里直接预置了几个样例面板。
这里我强烈建议你做两件事：第一，把预置的 Sample dashboard 打开仔细点一遍，看每个面板背后的可视化是什么类型、用的什么聚合；第二，不要只停留在"看"，用同样的数据自己重新建几个图表，做一次"复制预置面板"的练习。这一步对入门特别有效，因为你能同时看到"别人怎么配"和"自己怎么配"的差别，比空看文档印象深得多。
2.3 索引模式里最容易忽略的两个配置
索引模式的创建路径是 Management → Index Patterns → Create index pattern。这块有两个配置点直接影响 Dashboard 的图表正确性，很多人在这里踩坑。
第一个是时间字段的选择。创建索引模式时，Kibana 会扫描索引里可以被识别为时间的字段，如果你的索引里有多个时间字段，一定要选对。Dashboard 里最常用的"全局时间过滤器"依赖的就是这个字段，选错了会出现时间范围拖动完全没反应的怪现象。第二个是字段的聚合类型。某些字符串字段默认会被映射成text类型，不能直接做聚合，需要切换成对应的keyword字段。在索引模式页面里能看到字段列表，凡是标识为keyword的字段才适合做 bucket 聚合。
我建议在创建完索引模式后，先到 Discover 里验证一下数据能不能正常查出、时间过滤是否有结果，确认基础没问题再进入可视化环节。这一步看起来多此一举，实际上能帮你把问题和 Dashboard 本身隔离开，后面排查范围会小很多。
3. 核心实操：从零创建你的第一个 Dashboard
3.1 Dashboard 的创建入口和画布认识
Kibana 7.8.0 中进入 Dashboard 的入口在左侧菜单的 "Dashboard"，点进去之后如果还没有任何面板，页面会提示创建新的 Dashboard。点创建后，你会进入一个带网格背景的空白画布，右上角有 "Add"、"Options"、"Save" 这几个关键按钮。
这个空白画布其实就是一张可自由布局的网格纸，Kibana 默认把画布切成了若干列，每个面板可以按网格吸附放置和拖拽调整大小。我在做第一个项目时直接用了默认画布，后来发现默认宽度下图表太挤，于是改到 Options 里把 "Use margins" 关闭，让面板之间的空隙变小，画面一下子紧凑了很多。如果你做的 Dashboard 要投到监控大屏上，这个设置还挺重要的，不然面板之间的白边会很浪费屏幕空间。
创建 Dashboard 本身不用写代码，核心动作就三个：添加面板、调整布局、保存。但能不能把这三个动作做好，取决于你对可视化和 Dashboard 之间关系的理解。
3.2 在 Dashboard 里直接创建可视化的完整流程
Kibana 7.8.0 的 Dashboard 支持在页面里直接新建可视化，不用先跑到 Visualize 库再回来添加。具体操作是：进入 Dashboard 编辑状态后，点击 "Add" 按钮，在弹出的面板选择窗口左下角有一个 "Create new visualization" 入口，点击后可以选择可视化类型。
从入门角度，我建议第一个图表选择"Vertical bar"（垂直柱状图），因为它最直观。创建过程中你会遇到几个关键选项：
- 数据源：选择刚才准备好的示例数据索引模式，比如
kibana_sample_data_logs。 - 指标（Metrics）：默认是
Count，也就是统计文档数量。你也可以换成Average、Sum等，这是 Y 轴的值来源。 - 分桶（Buckets）：X 轴通常按时间分组，选择
Date Histogram，字段选时间字段，间隔默认Auto。如果看到图表乱七八糟，多半是这里的时间间隔设置不对。
我这里详细说一下时间间隔的选择逻辑。如果时间过滤器选的是"最近 15 分钟"，数据按分钟聚合是比较合适的；如果选"最近 30 天"，按分钟聚合会生成海量 bucket，图表既难看又慢。Kibana 的Auto选项会根据时间范围自动算间隔，大多数情况下够用；但如果你要固定粒度，比如每个柱代表一小时，就手动把间隔选成Hourly。我在实际监控中更倾向于手动控制间隔，因为固定粒度更容易在不同时间范围的对比中保持一致性。
配置完指标和 Buckets 后，点击页面顶部的播放按钮运行查询，图表下方会显示结果。如果结果符合预期，点击 "Save" 保存到可视化库，然后在 Dashboard 页面里就会看到这个新面板已经自动出现。
3.3 创建不同类型的图表并理解它们的适用场景
入门阶段至少要会做三种类型的图表，它们覆盖了绝大多数监控场景。
第一种是折线图或柱状图，用于看趋势。比如按小时统计请求量，能直观看出业务高峰和低谷。第二种是饼图或占比图，用于看分布。比如按machine.os或者status_code分组，看各类型的占比，适合分析错误率、用户分布等。第三种是数据表格，用于看明细。比如按来源 IP 或 URL 分组后列出 Top 10，配合排序可以快速找到访问量最高的地址。
这里我提醒一点：同一个数据源，用不同的聚合方式会得到完全不同的结论。比如统计"平均响应时间"，如果你用Average对日志里的字段求平均，异常值会被拉高，反应不灵敏；换成Percentiles取 P95 或 P99，才能更真实反映大多数请求的体验。Kibana 7.8.0 的可视化配置里支持这些聚合类型，不用写复杂的查询语句就能实现，入门阶段非常友好。
做完这三种图表后，回到 Dashboard 页面，点击 "Save" 输入名称，比如"Web 访问分析概览"，你的第一个 Dashboard 就保存成功了。之后每次打开 Dashboard 列表，找到这个名称点击即可进入查看。
3.4 面板布局、命名和删除操作的几个细节
Dashboard 保存后，如果想调整面板位置，点击右上角的 "Edit" 进入编辑模式，然后直接拖拽每个面板的标题栏就可以移动位置，拖拽边缘可以调整大小。布局上没有绝对的标准，但我个人有几个习惯：
- 最上面放全局性指标，比如总的请求量、错误率，用 Metric 类型的面板；
- 中间放趋势类图表，折线图或柱状图，用于观察时间变化；
- 底部放明细表格和分布图，方便下钻查看。
面板的命名也要注意。Kibana 默认面板名称来自可视化的标题，如果可视化标题叫"请求量趋势"，面板就显示这个名字。但在 Dashboard 里，你可能想让面板名称更贴合当前视图的语义，可以编辑面板标题。双击面板标题区域或点击面板上的编辑图标，在配置里修改 "Panel title" 就行。这个细节很多人忽略，导致 Dashboard 上的标题和实际数据含义对不上，汇报时被问得哑口无言。
删除面板也很简单，编辑模式下每个面板右上角都有一个 X 按钮，点击确认即可。这里要注意，删除面板只是把它从 Dashboard 里移除，并不会删除可视化库里的原始图表，所以你不用太担心误删后数据丢失，重新添加一次即可。
4. Dashboard 的时间控制、共享与自动化
4.1 时间过滤器是 Dashboard 的灵魂
Dashboard 右上角的时间过滤器（Time Range）可以理解为整个页面的"全局视角"。你在右上角选了"最近 24 小时"，页面上所有面板都会默认按这个时间范围刷新，除非某个面板自己配置了独立的时间范围。
这个机制用好了非常强大，但也是新手比较容易迷的地方。比如你做了一个柱状图，按天显示最近 7 天的数据，再把这个图表放进 Dashboard，同时 Dashboard 全局时间范围选的也是最近 7 天，两者叠加没问题。但如果你在 Dashboard 上单独把某个面板的时间范围改成"最近 90 天"，那么这个面板就会无视全局时间，只显示最近 90 天的数据。这会导致一个问题：全局时间一改，大部分面板都跟着变了，唯独那个面板不动，如果忘了这层设置，你会以为图表坏了。
我在实际项目中用 Dashboard 做月度汇报时，会把"上月数据总览"单独设成固定时间范围，让它不随全局时间变化，这样汇报时无论我怎么调整当前时间，那个面板永远是上个月的数据，非常方便。
时间过滤器旁边还有一个刷新按钮，可以设置自动刷新频率，比如每 5 秒、每 10 秒、每 30 秒刷新一次。做监控大屏时，我通常设置为 30 秒到 1 分钟刷新；如果刷新太频繁，Elasticsearch 的压力会明显增加，尤其是聚合查询比较多的时候，反而会把集群拖慢。
4.2 Dashboard 的保存、管理、导入导出
保存后的 Dashboard 可以在 Dashboard 列表页看到，支持按名称搜索、按标签过滤。7.8.0 里还能对 Dashboard 做导入导出，操作路径是 Management → Saved Objects。你可以把一个 Dashboard 导出为 JSON 文件，再在另一套环境里导入。这个功能在从测试环境迁移到生产环境时特别有用，我经常把一组已经调好的 Dashboard 一次性导出，然后在生产环境导入，省去了重新画图的重复劳动。
导入导出有一点要注意：Dashboard 本身只是容器，它引用的可视化对象、索引模式必须一起导出，否则到新环境后 Dashboard 会提示找不到某些依赖。在 Saved Objects 界面里点击某个 Dashboard 的导出按钮，Kibana 会询问是否同时导出相关对象，建议选择"包含相关对象"，这样可以避免遗漏。
另外，Dashboard 列表页里可以对每个 Dashboard 进行编辑、复制、删除和分享。复制功能我经常用：先复制一份作为备份，再在副本上做改动实验，确认没问题后再覆盖正式版，这样能避免把线上 Dashboard 改坏。
4.3 共享链接和嵌入页面的操作细节
Kibana 7.8.0 的 Dashboard 支持生成只读链接，点击 Dashboard 页面顶部的 "Share" 按钮，可以选择 "Snapshot"（快照链接）或 "Saved object"（保存对象链接）。快照链接会把当前的时间范围和过滤器状态一并固定下来，适合发给别人看某个特定时段的数据；保存对象链接则保留 Dashboard 的实时状态，跟随打开时的默认设置。
如果你想把 Dashboard 嵌入到自己的运维平台或企业门户里，Kibana 在 Share 界面提供了 iframe 嵌入代码。这里就要用到我们前面配好的server.basePath了，如果那个配置不对，嵌入代码的地址可能无法访问。嵌入时还可以通过 URL 参数控制只显示某个面板，比如embed=true&query=(language:kuery,query:'status_code:>=500')，这样嵌入页面一开始就带上了错误状态过滤，打开即是"只看错误"的视图，非常实用。
我做内部工具时，会把几个关键的 Dashboard 用 iframe 嵌到团队的导航页面里，让大家不用登录 Kibana 就能看到核心指标。需要注意 iframe 如果被浏览器拦截跨域或安全策略限制，可以通过 Kibana 配置里设置允许的嵌入来源，或者简单地在部署时让嵌入页面和 Kibana 同源，实际操作中同源方案最省事。
5. 常见问题与排查技巧实录
5.1 打开 Dashboard 后图表没有数据
这个现象太常见了，我在帮同事排查时总结出三个最可能的原因。
第一，先确认 Kibana 顶部的时间范围选的是不是"最近 15 分钟"，而你的数据是上周的，那自然看不到。这种问题最简单，把时间范围改成"最近 30 天"或"今年至今"就好。第二，确认索引模式是否正确。如果 Dashboard 里的某个可视化引用的索引模式和你实际存储数据的索引不匹配，图表必然没数据。第三，确认查询语句本身是否有限制。比如你在 Discover 里保存过一个带过滤条件的搜索，把这个搜索作为某个可视化的基础时，过滤条件会一直生效，导致 Dashboard 上看起来"没数据"。
我遇到过一次最隐蔽的情况：Dashboard 上大多数面板都有数据，唯独某一个表格面板为空，排查后发现，这个可视化里配置了一个 filter，条件是某个字段等于一个已经不再出现的值，数据源本身没问题，是过滤条件过时了。查这类问题最快的方式是打开可视化编辑页，直接看查询条件和预览结果。
5.2 图表数据对不上 Discover 里的结果
Dashboard 里某个面板显示的数值和 Discover 里搜出来的记录数不一致，这也是高频问题。原因通常在聚合层面：可视化里的Count指标统计的是匹配查询的文档数，但如果你在可视化里加了分组或过滤条件，结果自然和 Discover 的原始检索结果不同。
比如你想统计"每个状态码的请求数"，在饼图里按status_code字段分组统计，每个扇区显示的是一个分组内的数量，把所有扇区加起来会和 Discover 的总数一致；但如果某个字段值是空值，它可能被归到一个空分组里，在图表展示时被隐藏，于是总数对不上。要解决这个问题，你可以把空值分组也显示出来，或者在可视化的高级选项里调整对空值的处理方式。
这个问题的本质是：Discover 告诉你"有多少条记录"，Dashboard 里的可视化告诉你"这些记录按某个规则分布后每个桶里有多少条"。"分布"必然会有边界情况，理解这一点后，数据对不上的焦虑感会小很多。
5.3 Dashboard 加载缓慢和查询超时的排查方向
Dashboard 上的面板越多，打开时需要执行的 Elasticsearch 聚合请求就越多。如果一个页面同时有十几个图表，每个都做多种聚合，加载变慢是很正常的。我常用的优化手段有几个：
- 减少不必要的面板，把查看频率低的面板移除或放到单独的 Dashboard 里；
- 在可视化配置中减少分桶数量，比如把 Top 20 改成 Top 10；
- 尽量在可视化里预聚合数据，避免对原始日志做深层大聚合；
- 检查是否有某个面板的查询特别复杂，比如使用了大量
wildcard或正则过滤，这类查询在日志量大时非常拖速度。
如果遇到 Kibana 页面一直转圈但浏览器控制台没有明显报错，多半是 El库asticsearch 侧的聚合响应超时。除了前面提到的调整elasticsearch.requestTimeout，还要看下 Elasticsearch 集群的 CPU 和内存，如果查询并发太高，建议降低自动刷新频率，或者把时间范围缩小到更合理区间。
5.4 一个我自己排查过的实战案例
有次我在做某个线上系统的访问监控，Dashboard 建好后大部分图表正常，但其中一个折线图总是每隔一段时间就出现断点，数据像被切掉了一段。一开始怀疑是采集端丢数据，检查了很久发现采集正常。后来打开那个可视化的编辑页，把鼠标移到断点位置，发现那段时间区间内根本没有文档记录，而全局其他图表却有数据。
继续排查才发现，这个可视化单独设置了一个 filter，条件是某台机器的名称。那台机器在那段时间做了升级，日志里主机名字段变成了新值，所以旧条件匹配不到任何数据。把 filter 改成匹配一组主机名后，曲线就连续了。这个案例给我的启发是：Dashboard 入门阶段最容易出问题的不是图表配置，而是"数据语义"没想清楚。你要时刻记得图表背后的数据是什么、从哪里来、在什么条件下才会出现。
6. 我用了这么久 Dashboard 的一点体会和一个小技巧
最后说点更贴近日常操作的经验。用 Kibana 7.8.0 的 Dashboard 做监控，最容易忽视的是"可维护性"。很多人把图表做出来就不管了，等到数据结构发生变化，比如某个 field 从keyword变成text，整个 Dashboard 的图表可能全都要逐个修。所以我在一开始就会给每个可视化命名时加上来源和用途，比如"线上-nginx-请求量趋势-5m"，这样后面维护时只看名称就能快速定位。另一个实用技巧是在面板的注释区写清楚这个图表的统计口径，比如"统计的是状态码 200 的请求，不含静态资源"。这样任何接手的人都不会猜错语义。
还有一个提升使用体验的小技巧：把 Dashboard 的 URL 保存到浏览器书签时，可以在 URL 后面加上时间过滤参数，比如?_g=(time:(from:now-7d,to:now))。这样每次打开书签就直接看到最近 7 天的视图，不用手动去点时间选择器。我工作时通常会保存几个不同时间范围的快捷入口：最近 1 小时、最近 24 小时、最近 7 天，切换效率比在页面里点快很多。
Kibana 7.8.0 的 Dashboard 看着简单，但真正用好它需要对数据、聚合和查询语义都有清晰理解。先把索引模式弄明白，再把可视化的聚合方式吃透，最后用 Dashboard 把这些结果组织成适合观察的视图，这条路走通之后，你会发现日志分析和监控变得顺手很多，也为后面学习更复杂的告警和机器学习功能打好了基础。
