Kibana 7.8.0 的 Dashboard 是我做过日志分析项目后最常用的一个功能。很多人一上来就埋头做可视化图表做完之后才发现不知道怎么把这些图表组合成一个能日常盯控的页面还有的人把 Dashboard 建出来了但时间范围、刷新频率、数据粒度全都没配合好实际用起来总觉得别扭。这篇文章就把我从环境准备到面板布局、再到共享和排查的完整经验捋一遍目标是让拿到 Kibana 7.8.0 的人能踏踏实实把 Dashboard 用起来。1. Dashboard 到底是什么为什么要用版本 7.8.01.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 PatternDashboard 里的所有图表都不是凭空画出来的每个可视化背后都绑定一个或多个索引模式。索引模式定义了从哪个索引读数据哪个字段是时间字段哪些字段是 keyword 类型可以做聚合。我在实际使用中见过不少人跳过索引模式直接去建 Dashboard结果图表里没有数据回头才发现是索引模式没配好。可视化库Visualize Library7.8.0 的 Dashboard 不是直接在页面里画图而是先把图建在可视化库里再引用到 Dashboard 上。这也意味着同一个可视化可以被多个 Dashboard 复用改一处所有引用它的位置都会更新。DiscoverDiscover 负责原始数据检索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. 核心实操从零创建你的第一个 Dashboard3.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 轴的值来源。分桶BucketsX 轴通常按时间分组选择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 参数控制只显示某个面板比如embedtruequery(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 把这些结果组织成适合观察的视图这条路走通之后你会发现日志分析和监控变得顺手很多也为后面学习更复杂的告警和机器学习功能打好了基础。 
长河君 · 2026/10/16 1:05:12 · 阅读 1.2k Kibana 7.8.0 Dashboard实战：从环境准备到面板共享与排错
Kibana 7.8.0 的 Dashboard 是我做过日志分析项目后最常用的一个功能。很多人一上来就埋头做可视化图表做完之后才发现不知道怎么把这些图表组合成一个能日常盯控的页面还有的人把 Dashboard 建出来了但时间范围、刷新频率、数据粒度全都没配合好实际用起来总觉得别扭。这篇文章就把我从环境准备到面板布局、再到共享和排查的完整经验捋一遍目标是让拿到 Kibana 7.8.0 的人能踏踏实实把 Dashboard 用起来。1. Dashboard 到底是什么为什么要用版本 7.8.01.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 PatternDashboard 里的所有图表都不是凭空画出来的每个可视化背后都绑定一个或多个索引模式。索引模式定义了从哪个索引读数据哪个字段是时间字段哪些字段是 keyword 类型可以做聚合。我在实际使用中见过不少人跳过索引模式直接去建 Dashboard结果图表里没有数据回头才发现是索引模式没配好。可视化库Visualize Library7.8.0 的 Dashboard 不是直接在页面里画图而是先把图建在可视化库里再引用到 Dashboard 上。这也意味着同一个可视化可以被多个 Dashboard 复用改一处所有引用它的位置都会更新。DiscoverDiscover 负责原始数据检索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. 核心实操从零创建你的第一个 Dashboard3.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 轴的值来源。分桶BucketsX 轴通常按时间分组选择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 参数控制只显示某个面板比如embedtruequery(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 把这些结果组织成适合观察的视图这条路走通之后你会发现日志分析和监控变得顺手很多也为后面学习更复杂的告警和机器学习功能打好了基础。