04-Kibana 可视化入门

ELK Stack 系列第 04 篇。前一篇已经把 Logstash 管道讲清楚：日志如何从输入进入、如何被 filter 结构化、如何输出到 Elasticsearch。本文继续把链路走完，重点讲 Kibana 如何把索引里的日志变成可检索、可解释、可复用的可视化视图。Kibana 的菜单和功能名称会随版本微调，本文按当前 Elastic 文档中的 Data View、Discover、Lens、Dashboard、KQL、Saved Objects 等概念组织。

一、Kibana 在 ELK 链路中的位置

Kibana 不是一个“漂亮报表工具”这么简单。它是 Elastic Stack 面向人的操作界面，承担三类职责：第一，帮助工程师探索 Elasticsearch 里的原始文档；第二，把字段、查询、聚合转换成图表和仪表板；第三，作为运维、安全、可观测性、告警、空间、权限等功能的入口。

在日志平台建设中，Kibana 的价值不是把所有数据都做成图，而是把“数据是否进来了”“字段是否解析正确”“异常是否能被定位”“趋势是否能被团队持续复用”这几件事串起来。一个健康的 ELK 落地顺序通常是：先有稳定采集，再有正确解析，再有可查询字段，最后才有仪表板。如果前面的索引、时间戳、字段类型没有处理好，Kibana 只能把问题暴露出来，不能替你修复数据质量。

这张图强调一个顺序：Kibana 的大多数分析能力都从 Data View 开始，然后在 Discover 中确认字段含义，再进入 Lens 和 Dashboard。不要跳过 Discover 直接做图，否则很容易在错误字段上做出看似合理的结论。

本文的目标是让你完成一个最小但完整的 Kibana 可视化闭环：

1. 确认 Elasticsearch 中已有可分析日志索引。
2. 创建或选择 Data View。
3. 在 Discover 中验证时间字段、关键字段和查询条件。
4. 用 Lens 制作几个基础图表。
5. 组合成一个可用于日常巡检的 Dashboard。
6. 掌握常见“没有数据、图表不准、字段不可聚合、时间范围不对”的排查路径。

二、准备工作：先确认数据真的可用

Kibana 的第一类问题经常不是 Kibana 问题，而是数据链路问题。进入界面前，先在 Elasticsearch 侧确认索引和文档存在。

2.1 确认索引和数据流

如果前一篇 Logstash 输出使用的是 app-logs-%{+YYYY.MM.dd} 这类索引命名，可以先检查索引列表：

curl -k -u elastic:YOUR_PASSWORD \
  "https://localhost:9200/_cat/indices/app-logs-*?v&s=index"

如果使用 Elastic Agent 或 Filebeat 的新式集成，数据可能进入 data stream，例如 logs-nginx.access-default、logs-system.syslog-default。可以用下面的命令查看：

curl -k -u elastic:YOUR_PASSWORD \
  "https://localhost:9200/_data_stream/logs-*?pretty"

需要关注四个信息：

2.2 抽样查看文档结构

不要只看索引名，还要抽样看文档。下面的查询按最近时间取 3 条日志：

curl -k -u elastic:YOUR_PASSWORD \
  -H "Content-Type: application/json" \
  "https://localhost:9200/app-logs-*/_search?pretty" \
  -d '{
    "size": 3,
    "sort": [
      { "@timestamp": { "order": "desc" } }
    ],
    "_source": [
      "@timestamp",
      "service.name",
      "log.level",
      "message",
      "http.response.status_code",
      "event.duration"
    ]
  }'

如果结果里只有 message，没有结构化字段，说明 Logstash 的 filter 还没有把日志解析到位。此时先回到 Logstash数据管道配置 检查 grok、json、date、mutate 等处理逻辑，再继续做可视化。Kibana 可以在 message 上全文搜索，但生产仪表板必须依赖稳定字段。

2.3 确认 Kibana 能连接 Elasticsearch

在 systemd 安装场景下，先确认 Kibana 服务运行：

sudo systemctl status kibana
sudo journalctl -u kibana -n 80 --no-pager

常见配置文件路径为 /etc/kibana/kibana.yml。基础连接项示例：

server.host: "0.0.0.0"
server.port: 5601
elasticsearch.hosts: ["https://127.0.0.1:9200"]
elasticsearch.username: "kibana_system"
elasticsearch.password: "YOUR_KIBANA_SYSTEM_PASSWORD"

生产环境不要把 elastic 超级用户长期配置给 Kibana 服务本身。elastic 更适合用于初始化、应急和管理操作，日常服务连接应使用专用系统用户或符合当前 Elastic 安全模型的服务配置。

三、Data View：Kibana 理解数据的入口

Elastic 早期文档和老版本界面中常见 “Index Pattern” 这个名称，当前 Kibana 更推荐使用 “Data View”。Data View 可以指向一个或多个 Elasticsearch 索引、data stream 或索引别名。官方文档也说明，Discover、Lens 等分析功能通常需要 Data View 才能访问 Elasticsearch 数据；某些场景下 ES|QL 可以不依赖 Data View，但日志平台入门阶段仍建议先掌握 Data View。

这张图说明 Data View 不是数据副本，而是 Kibana 访问数据的逻辑视图。改 Data View 不会移动 Elasticsearch 中的文档，但会影响 Kibana 里能看到哪些字段、默认使用哪个时间字段、字段如何格式化。

3.1 创建 Data View

在 Kibana 中进入：

Stack Management -> Kibana -> Data Views -> Create data view

以应用日志为例：

如果 Kibana 提示没有匹配索引，通常有三种原因：索引确实不存在；当前用户没有索引读取权限；输入的 pattern 与实际索引或 data stream 名称不匹配。不要急着刷新页面，先回到 Elasticsearch API 确认 _cat/indices 或 _data_stream 输出。

3.2 Data View 权限

创建和管理 Data View 需要 Kibana 侧的数据视图管理权限，以及 Elasticsearch 侧查看索引元数据的权限。最小权限思路可以拆成两层：

1. 平台管理员拥有 Data View 管理、Saved Objects 管理、空间管理等权限。
2. 普通运维人员拥有目标索引的 read、view_index_metadata，以及对应空间中 Dashboard/Discover/Lens 的使用权限。

如果界面上出现只读提示，或创建按钮不可见，不一定是 Kibana 异常，很可能是角色权限不足。生产环境应通过角色设计解决，而不是直接给所有人超级用户。

3.3 字段刷新与格式设置

Logstash 修改字段后，Elasticsearch mapping 会变化，Kibana Data View 字段列表未必立即展示最新字段。可以在 Data View 详情页执行刷新字段列表。刷新后检查：

• @timestamp 是否被识别为 date。
• http.response.status_code 是否可用于 Terms 或 Top values。
• event.duration、response_time、bytes 是否是 number。
• message 是否保留为全文检索字段。
• .keyword 子字段是否存在，能否用于精确聚合。

字段格式也很重要。比如字节数字可以设置为 Bytes 格式，百分比可以设置为 Percentage，持续时间字段可以根据单位设置显示格式。格式设置不会改变原始文档，但会让 Dashboard 更容易读。

当前 Kibana 还支持 runtime fields 和 ES|QL 这类更灵活的分析方式。它们适合临时探索、补充计算字段或验证新口径，但不要把所有生产字段都放到查询时计算。官方文档也提醒，runtime fields 会在查询时计算，可能影响性能。对 Dashboard 高频使用的字段，仍应优先在 Logstash、ingest pipeline 或索引模板阶段治理好。

四、Discover：先把数据看懂，再做图

Discover 是 Kibana 中最适合排查数据质量的入口。很多团队把它当“搜索日志的页面”，但它更重要的作用是验证字段、查询、时间范围和样本数据。

4.1 建立第一次查询

进入 Discover 后，选择刚才创建的 Data View，例如 app-logs。第一件事不是输入复杂查询，而是把时间范围调到你确定有数据的窗口，比如 Last 15 minutes、Last 24 hours，或者某个明确日期。

常用 KQL 示例：

log.level: "ERROR"

service.name: "payment-api" and http.response.status_code >= 500

message: "timeout" or message: "connection refused"

KQL 面向字段过滤，适合日常查询；Lucene Query Syntax 更偏传统查询表达式；ES|QL 适合管道式检索、转换和统计。入门阶段建议先用 KQL，因为它和 Dashboard filter、Lens 过滤条件的心智模型一致。

4.2 调整显示字段

默认表格可能只显示 Time 和 _source。为了让日志排查更高效，可以添加以下字段到表格：

如果字段列表中没有你期望的字段，优先检查 Logstash 解析和 Elasticsearch mapping。如果字段存在但不可聚合，通常是类型不对，或者只有 text 字段而没有 keyword 子字段。

4.3 保存 Discover 查询

常用查询可以保存，后续加入 Dashboard 或作为排障入口。例如保存一个名为 应用错误日志 - 最近 24 小时 的 Discover 视图，包含：

• Data View：app-logs
• KQL：log.level: "ERROR" or http.response.status_code >= 500
• 显示字段：时间、服务、主机、状态码、路径、消息
• 排序：按 @timestamp 降序

保存查询的价值在于团队复用。同一个问题不必每个人重新输入字段和过滤条件，值班人员打开 Dashboard 时就能直接跳到对应明细。

五、Lens：从字段到图表的最短路径

Lens 是 Kibana 中现代化的拖拽式可视化编辑器。它把“选择字段、选择聚合方式、选择图表类型”变成了更低门槛的交互流程。对于日志平台，Lens 最适合做趋势、分布、Top N、单值指标和简单对比。

这张图是做 Lens 的基本路线。关键不是先选图表，而是先问清楚“这个图要回答什么问题”，再根据字段类型选择合适的聚合方式。

5.1 图表一：日志量趋势

第一个图建议做“每分钟日志量趋势”。它回答的是：日志是否持续进入系统、是否出现流量尖峰、是否有采集中断。

配置思路：

如果日志量突然归零，先不要判断业务无请求。可能是 Filebeat 停止、Logstash pipeline 阻塞、Elasticsearch 拒写、索引生命周期切换失败，也可能只是 Dashboard 时间范围选错。这个图的价值在于第一时间暴露链路断点。

5.2 图表二：错误率与错误数量

错误数量和错误率不是一回事。只有错误数量时，高流量时段天然更高；只有错误率时，小流量样本可能被放大。入门 Dashboard 可以先放两个面板：

在 Lens 中，可以用过滤指标或公式完成类似计算。示例公式思路：

count(kql='http.response.status_code >= 500') / count()

实际字段名要以你的 ECS 映射或 Logstash 输出为准。若字段是字符串类型，例如 "500"，KQL 需要写成：

http.response.status_code: "500"

更推荐在 Logstash 或 ingest pipeline 中把状态码转换为数字，便于范围查询和聚合。

5.3 图表三：Top URL 与慢请求

日志可视化不只看错误，也要看热点和慢请求。常见图表：

如果 url.path 基数非常高，例如带订单号、用户 ID、随机 token，Top values 会被大量唯一 URL 冲散。生产环境应在采集阶段规范化路径，把 /orders/12345 归一为 /orders/{id}，或者额外写入 url.route 字段。Dashboard 不是清洗数据的地方，它只能消费已经治理好的字段。

5.4 图表四：按服务、主机、环境拆分

一个图表是否有用，很大程度取决于维度是否稳定。日志平台常用维度包括：

• service.name
• service.environment
• host.name
• kubernetes.namespace
• container.name
• log.level
• event.dataset

例如“各服务错误数 Top 10”可以快速定位哪个服务在制造告警；“各主机日志量 Top 10”可以发现异常刷日志或采集偏斜；“环境维度拆分”可以避免把测试环境噪声误判为生产事故。

在 Lens 中，Breakdown by 不宜无限增加。一个图最多拆 1 到 2 个主要维度，超过后可读性会急剧下降。复杂分析应拆成多个面板，而不是在一个图里堆满颜色。

六、Dashboard：把排查路径固化下来

Dashboard 是多个面板的组合，不是图表仓库。一个好 Dashboard 应该围绕一个稳定场景组织，例如“生产应用日志巡检”“Nginx 访问日志分析”“数据库慢查询观察”“Logstash 管道健康检查”。如果不同角色、不同问题都塞在同一个页面里，最后所有人都会迷路。

这张图给出 Dashboard 的组织方式：先判断有没有异常，再定位异常维度，最后进入明细。页面布局也应遵循这个顺序，让值班人员从上到下完成一次巡检。

6.1 一个入门 Dashboard 的布局

推荐从一个生产应用日志 Dashboard 开始：

顶部指标不要太多。运维巡检页面最怕“每个数字都重要”，结果没有一个数字能触发行动。先选择 4 到 6 个对班组有意义的指标，再随着事故复盘迭代。

6.2 时间范围与全局过滤器

Dashboard 的全局时间范围会影响所有使用同一时间字段的面板。常用时间范围：

• 生产巡检：最近 15 分钟、最近 1 小时。
• 日报复盘：昨天 00:00 到 23:59。
• 发布观察：发布前后各 30 分钟。
• 容量分析：最近 7 天、最近 30 天。

全局过滤器适合放这些维度：

service.environment: "prod"
service.name: "payment-api"
host.name: "app-01"

如果某个 filter 被 pin 到全局，它可能影响 Discover、Lens、Dashboard 等多个应用。值班时要注意过滤器是否被固定，否则可能出现“明明有数据但图上没有”的误判。

6.3 Dashboard Controls

Controls 可以把常用字段变成下拉筛选、范围筛选或时间滑块。对运维团队来说，最常见的 controls 是：

Controls 的优点是降低使用门槛，缺点是依赖字段基数和字段质量。如果 service.name 命名不统一，例如同一个服务同时出现 pay-api、payment-api、payment_service，筛选器会把团队带向错误结论。字段命名治理仍然要回到采集和规范层。

七、一个完整 walkthrough：从 Nginx 日志到访问分析仪表板

下面以 Nginx 访问日志为例，串起 Kibana 入门流程。假设 Logstash 已经把日志解析为接近 ECS 的字段：

{
  "@timestamp": "2026-06-01T06:30:00.000Z",
  "service.name": "nginx",
  "host.name": "web-01",
  "client.ip": "192.0.2.10",
  "http.request.method": "GET",
  "url.path": "/api/orders/123",
  "http.response.status_code": 200,
  "event.duration": 153000000,
  "user_agent.original": "Mozilla/5.0 ...",
  "message": "192.0.2.10 - - ..."
}

这里的 event.duration 如果使用 ECS 语义，单位通常是纳秒。你的 Logstash 管道也可以使用毫秒字段，例如 nginx.response_time_ms。关键是 Dashboard 内部要保持单位一致，并在字段名或面板标题中讲清楚。

7.1 创建 Data View

假设索引为 nginx-access-2026.06.01，Data View 配置如下：

Name: nginx-access
Index pattern: nginx-access-*
Timestamp field: @timestamp

创建后刷新字段列表，并检查：

• http.response.status_code 可聚合。
• url.path 有 keyword 可用于 Top values，或本身就是 keyword。
• event.duration 是 number。
• client.ip 类型适合过滤和聚合。

7.2 Discover 验证

在 Discover 中先执行：

service.name: "nginx"

再执行：

http.response.status_code >= 500

如果第二个查询报错或没有结果，需要确认状态码字段是不是数字。如果字段是 text，范围比较无法按预期工作。临时可以用字符串精确匹配，但长期应修正 mapping 和 Logstash 类型转换。

7.3 制作四个 Lens 面板

第一个面板：请求量趋势。

第二个面板：5xx 错误率。

第三个面板：Top URL。

第四个面板：P95 响应时间。

如果持续时间单位是纳秒，可以在 Lens 公式里换算为毫秒，或者在采集阶段新增毫秒字段。不要让 Dashboard 上的 153000000 裸露给值班人员。

7.4 组合成 Dashboard

Dashboard 命名建议：

生产 Nginx 访问日志巡检

页面顶部放 Controls：

• host.name
• http.response.status_code
• url.path

然后按“总览 -> 趋势 -> 分布 -> 明细”布局。最后加入一个 Saved Discover 面板，过滤条件为：

http.response.status_code >= 500 or event.duration > 1000000000

这样值班人员看到错误率上升时，可以直接在同一页面下方看到具体错误日志，而不是再打开 Discover 重新拼查询。

这张时序图说明 Dashboard 不是终点。真正排障时，图表提供方向，Discover 提供证据，Elasticsearch 保存可追溯的原始上下文。

八、字段设计决定可视化上限

很多 Kibana 新手问题最后都会回到字段设计。可视化面板只负责聚合和展示；字段是否稳定、类型是否正确、基数是否可控、时间是否可信，决定了图表是否有意义。

8.1 优先采用 ECS 思路

Elastic Common Schema（ECS）为日志、指标、事件提供了一套通用字段命名规范。你不一定一开始就完全覆盖 ECS，但建议优先采用以下常见字段：

采用统一字段的好处是跨服务、跨团队、跨数据源做 Dashboard 时不需要每个系统都重新适配。如果 A 服务叫 level，B 服务叫 severity，C 服务叫 logLevel，Lens 里就无法用一个过滤器完成统一分析。

8.2 text 与 keyword 的区别

Elasticsearch 中 text 适合全文检索，keyword 适合精确匹配、排序和聚合。Kibana 中最常见的困惑是：为什么某个字段能搜索，却不能放到 Terms 或 Top values 里？

通常原因是字段只有 text 类型，没有 .keyword 子字段。例如：

"url.path": {
  "type": "text"
}

更适合可视化的 mapping 是：

"url.path": {
  "type": "keyword",
  "ignore_above": 2048
}

或者同时保留 text 和 keyword：

"message": {
  "type": "text",
  "fields": {
    "keyword": {
      "type": "keyword",
      "ignore_above": 1024
    }
  }
}

日志平台中，message 更适合 text，service.name、host.name、log.level、url.path 更适合 keyword 或具备 keyword 子字段。

8.3 高基数字段谨慎做 Top N

高基数字段是指唯一值非常多的字段，例如：

• 用户 ID
• 订单 ID
• 请求 ID
• 完整 URL，尤其包含 query string
• Trace ID
• 原始 message

这些字段不是不能分析，而是不适合直接做 Top values。否则 Dashboard 会出现大量一次性值，聚合成本高，可读性低。更好的做法是：

1. 保留高基数字段用于精确下钻。
2. 增加低基数字段用于聚合，例如 url.route、error.type、service.name。
3. 对业务 ID 使用 Discover 查询，不把它们放在首页 Dashboard。

九、常见可视化问题排查

Kibana 排障要有固定路径。下面这棵决策树覆盖了最常见的入门问题。

这张图可以作为值班排障顺序。先确认时间范围和 Discover，再看字段类型，最后才怀疑 Kibana 面板本身。

9.1 Dashboard 没有数据

优先检查：

1. 时间范围是否覆盖日志时间。
2. Data View 是否匹配索引或 data stream。
3. 当前 Kibana Space 是否有对应 Saved Object。
4. 用户是否有目标索引 read 权限。
5. 面板级过滤器是否过窄。
6. 全局 pinned filter 是否来自另一个页面。

验证命令：

curl -k -u elastic:YOUR_PASSWORD \
  -H "Content-Type: application/json" \
  "https://localhost:9200/app-logs-*/_search?pretty" \
  -d '{
    "size": 0,
    "query": {
      "range": {
        "@timestamp": {
          "gte": "now-24h",
          "lte": "now"
        }
      }
    }
  }'

如果 API 有数据而 Discover 没数据，重点检查 Data View 和权限；如果 API 也没数据，回到采集链路。

9.2 字段看得到但不能做图

典型原因：

• 字段类型是 text，不能做 terms 聚合。
• 数字被写成字符串，不能做平均值、百分位、范围过滤。
• 日期字段格式不符合 mapping，导致未被识别为 date。
• Data View 字段缓存未刷新。

检查 mapping：

curl -k -u elastic:YOUR_PASSWORD \
  "https://localhost:9200/app-logs-*/_mapping/field/http.response.status_code?pretty"

如果 mapping 已经错误，不能简单靠 Kibana 修复。通常需要创建新索引模板，然后让新数据进入正确索引；历史数据如果需要修正，则通过 reindex 或 transform 迁移。

9.3 图表数字比预期大

常见原因：

排查时不要只看图，必须回到 Discover 抽样原始文档。图表是聚合结果，聚合错误往往来自源文档不一致。

9.4 Dashboard 打开很慢

可能原因包括：

• 时间范围过大，比如默认打开最近 90 天。
• 面板太多，每个面板都触发昂贵聚合。
• 对高基数字段做 terms 聚合。
• 索引分片过多或过大。
• 查询命中了过多历史索引。
• Lens 公式过于复杂。

优化策略：

1. 默认时间范围控制在最近 15 分钟到 24 小时。
2. 首页只放核心面板，深度分析拆到二级 Dashboard。
3. 避免在首页对 trace.id、message、完整 URL 做 Top values。
4. 使用索引生命周期管理和合理索引模式，让查询只扫必要数据。
5. 为常用过滤字段保证正确 mapping。

十、从入门 Dashboard 走向生产实践

入门 Dashboard 完成后，不要停留在“能看图”。生产化需要补上命名、权限、空间、版本管理和告警联动。

10.1 命名与分层

建议建立统一命名：

[环境] [系统/服务] [用途]
生产 支付服务 日志巡检
生产 Nginx 访问分析
生产 Logstash 管道健康
测试 应用错误排查

Dashboard 分层建议：

10.2 Space 与权限

Kibana Space 可以把不同团队、环境或项目的 Saved Objects 隔离开。常见做法：

• prod-ops：生产运维巡检。
• security：安全分析。
• dev：开发调试。
• shared：通用模板和示例。

权限不要只按“能不能登录 Kibana”划分，而要按“能看哪些数据、能改哪些对象、能不能导出、能不能管理 Data View”划分。生产 Dashboard 应限制编辑权限，避免值班期间误删面板。

10.3 Saved Objects 的备份与迁移

Dashboard、Lens、Data View、Saved Discover 都属于 Kibana Saved Objects。生产环境要定期导出备份，尤其在升级 Kibana、调整 Space、迁移集群前。

备份思路：

Stack Management -> Saved Objects -> Export

迁移时要注意：

• 目标环境是否存在同名 Data View。
• 索引 pattern 是否一致。
• Space 是否一致。
• 字段 mapping 是否一致。
• 版本差异是否导致可视化对象需要迁移。

对于关键 Dashboard，建议在变更前导出 NDJSON 文件并纳入内部配置库管理。这样 Kibana 升级或误操作后可以快速恢复。

Saved Objects 还要和字段变更联动。一个 Dashboard 可能依赖某个 Data View、某个字段格式、某个 Lens 公式和某个 Saved Discover。如果 Logstash 把 response_time 改成 event.duration，或者 Filebeat 把数据流命名从 nginx-access-* 改成 logs-nginx.access-*，Kibana 对象不会自动理解你的迁移意图。结果可能是面板报错、字段消失、公式返回空值，或者更隐蔽地显示错误口径。

因此，Kibana 变更也需要最小发布流程：

1. 先列出被影响的 Data View、Dashboard、Lens 和 Saved Discover。
2. 在测试 Space 或临时 Data View 中验证新字段。
3. 导出变更前 Saved Objects。
4. 更新面板和说明文字。
5. 用固定时间窗口对比新旧 Dashboard 结果。
6. 通知值班人员口径变化。

这个流程看起来比“进页面拖一下图”麻烦，但它能避免生产事故中打开 Dashboard 才发现关键面板已经失效。Kibana 页面一旦进入值班流程，它就不是个人作品，而是运维工具。

10.4 与告警联动

Dashboard 是观察工具，不是告警系统。生产日志平台需要把可视化和告警分开设计：

• Dashboard 用于观察趋势、定位问题、复盘。
• Alert 用于无人值守发现异常。
• Discover 用于取证。
• Elasticsearch 查询和索引用于保存事实。

例如 5xx 错误率超过阈值时，告警通知值班人员；值班人员打开 Dashboard 看趋势和影响范围；再进入 Discover 抽样错误日志；最后结合应用日志、链路追踪、发布记录定位根因。

这张状态图把 Dashboard 放在事件生命周期里。它最重要的作用是帮助判断异常是否扩大、处置是否有效、恢复是否稳定。

十一、验证清单

完成本文实践后，可以用下面的清单自查。

11.1 数据链路

• Elasticsearch 中能查到目标索引或 data stream。
• 最近 15 分钟或 24 小时内有文档。
• @timestamp 与真实事件时间一致。
• Logstash 输出字段符合预期。
• 没有明显重复采集。

11.2 Data View

• Data View pattern 匹配正确。
• 时间字段选择正确。
• 新字段刷新后可见。
• 常用 keyword、number、date 字段类型正确。
• 普通用户具备只读和使用权限。

11.3 Discover

• 能用 KQL 查到错误日志。
• 表格展示字段适合排障。
• 常用查询已保存。
• 抽样日志能解释 Dashboard 中的聚合结果。

11.4 Lens 和 Dashboard

• 日志量趋势能显示。
• 错误数和错误率能显示。
• Top 服务、Top 主机、Top URL 维度稳定。
• 慢请求或耗时面板单位清晰。
• Dashboard 默认时间范围合理。
• Controls 不会引入误导性过滤。
• Saved Discover 明细可以从 Dashboard 下钻。

十二、常见误区

误区一：先做 Dashboard，后治理字段。 这会导致图表反复返工。正确顺序是先稳定字段和类型，再做可视化。

误区二：所有人共用一个大 Dashboard。 不同角色关注点不同。值班、开发、SRE、安全、管理层应该有不同页面或至少不同区域。

误区三：把 Dashboard 当报表系统。 Kibana 擅长交互式探索和近实时分析，不适合承载所有固定格式报表需求。周期性管理报表可以从 Elasticsearch 导出或接入 BI 工具，但排障现场应保留 Kibana 的交互能力。

误区四：忽略时间字段。 日志进入 Elasticsearch 的时间和事件发生时间可能不同。如果 Logstash date filter 没有正确覆盖 @timestamp，Dashboard 会把旧日志显示在写入时间，影响事故判断。

误区五：直接聚合原始 message。 message 适合搜索和查看上下文，不适合做 Top N。应提取 error.type、url.route、service.name 等结构化字段。

十三、生产落地：让 Dashboard 进入日常工作流

入门 Dashboard 做完以后，真正的挑战是让它进入团队日常，而不是停留在“演示时很好看”。生产环境中的 Kibana 页面要服务三个动作：发布前后观察、告警后的快速定位、事故后的复盘改进。每一个动作对图表的要求不同，因此需要把 Dashboard 和流程绑定起来。

13.1 发布观察页面

每次应用发布后，值班人员最关心的不是所有历史趋势，而是发布窗口内的变化。可以单独建立一个“发布观察”Dashboard，默认时间范围设置为最近 2 小时，面板围绕发布影响组织：

发布观察页面应尽量少放“长期容量类”面板，例如 30 天日志总量、月度错误分布。这类面板适合周报或容量分析，不适合发布当晚判断是否回滚。发布观察的核心是对比发布前后，发现新增错误、错误率突变、延迟抬升和请求分布异常。

这张流程图把 Kibana 嵌入发布动作中。Dashboard 不负责决定是否回滚，但它必须提供足够快的证据：异常是否出现、是否扩大、是否与发布窗口重合。

13.2 日志质量治理

Dashboard 使用一段时间后，团队会发现很多问题不是图表问题，而是日志质量问题。建议每周或每两周做一次日志质量 review，重点看以下指标：

这些治理动作不一定在 Kibana 中完成，但 Kibana 会持续暴露它们。比如 Top URL 面板被订单号冲散，说明路径没有归一化；错误明细只有 NullPointerException，却不知道业务动作，说明应用日志缺少上下文字段；同一个服务在 Dashboard 中出现多个名字，说明部署配置或日志格式没有统一。

日志质量治理的判断标准也很简单：一个没有参与过该服务开发的人，能否通过 Dashboard 和 Discover 在 5 到 10 分钟内回答“哪个服务、哪个接口、哪个版本、哪个主机、什么错误、影响多大”。如果答案是否定的，就应该回到日志字段和采集规范，而不是继续堆面板。

验收时还可以让一名非系统负责人按告警消息进入页面，独立完成筛选、下钻和证据截图。只要他需要反复询问字段含义，就说明 Dashboard 还没有真正产品化。

日志质量 review 也要留下结果。哪些字段要改名，哪些面板要下线，哪些查询要保存，哪些服务需要补 trace.id，都应形成任务，而不是停留在会议讨论。Kibana 暴露的是数据问题，修复动作通常分散在应用日志规范、Filebeat 配置、Logstash pipeline、Elasticsearch 模板和 Dashboard 对象之间。没有任务闭环，下一次事故还会遇到同样的问题。

13.3 团队复用与交接

Kibana 页面一旦成为排障入口，就需要像运维脚本和配置文件一样管理。至少要做到：

1. 关键 Dashboard 有负责人。
2. 页面标题能看出环境、系统和用途。
3. 面板标题写清楚指标口径，例如“5xx 错误率”不要写成“错误”。
4. 重要过滤条件写在面板说明或 Dashboard 描述中。
5. 变更前导出 Saved Objects。
6. 下线索引或字段前先确认 Dashboard 依赖。

对于值班交接，可以把 Dashboard 与 runbook 关联起来。例如告警消息中直接附上 Kibana Dashboard 链接、默认时间范围和服务过滤条件；事故复盘中记录当时使用了哪些面板、哪些面板误导了判断、哪些字段缺失导致定位变慢。这样 Kibana 页面会随着真实故障不断演进，而不是由某个人一次性设计后长期无人维护。

13.4 从日志 Dashboard 走向可观测性视图

日志只是可观测性的一部分。成熟团队会逐步把日志、指标、链路、变更记录关联起来。Kibana 可以先从日志侧提供稳定入口，再逐步和 Metricbeat、APM、Uptime、告警、变更系统联动。

一个常见演进路线如下：

这条路线的关键是“关联字段”。日志里有 trace.id，才能跳到链路；日志里有 host.name 和 service.name，才能和主机指标、容器指标对齐；日志里有版本号或部署批次，才能判断异常是否由变更引入。Kibana 可视化入门阶段就应养成这种字段意识，否则后续接入 APM 和告警时会发现数据彼此孤立。

总结

Kibana 可视化的核心不是“会拖图表”，而是把日志平台的数据链路变成可验证的分析闭环。Data View 决定 Kibana 能看到什么，Discover 用来验证数据和字段，Lens 负责把字段转换为趋势、分布和指标，Dashboard 则把团队的排障路径固化为可复用页面。

对于刚完成 Elasticsearch 和 Logstash 部署的团队，建议先做一个小而完整的生产日志巡检 Dashboard：日志量趋势、错误数、错误率、P95 响应时间、Top 服务、Top URL、错误明细。只要这个页面能稳定回答“有没有异常、异常在哪里、证据是什么”，它就比一个堆满面板但没人能解释的大屏更有价值。

下一篇将进入《Filebeat 日志采集》，把采集端前移到业务服务器，解决“如何轻量、稳定、标准化地把文件日志送入 Elastic Stack”的问题。到那一步，本文里的 Data View、字段类型、时间范围和 Dashboard 口径会反过来约束采集端：Filebeat 不是只把文件发出去，还要让进入 Kibana 的数据能被团队读懂、筛选和复盘。

如果后续 Dashboard 口径发生变化，也要同步更新采集和解析规则。可视化不是链路末端的装饰，它会反向定义哪些日志字段真正有运营价值，哪些字段只是存储成本，也会暴露团队是否具备稳定排障语言。

这也是 Kibana 入门后最应该保留的工作习惯，并且要写进团队交接文档和事故复盘记录中。

参考资料

• Elastic Docs：Data views
• Elastic Docs：Panels and visualizations
• Elastic Docs：Dashboards
• Elastic Docs：Kibana Query Language
• Elastic Docs：Saved objects