作者来自 Elastic Gustavo Llermaly学习如何使用 Elastic Workflows 每 30 分钟收集 Kibana 仪表板视图 metrics并将其索引到 Elasticsearch 中从而在你自己的数据之上构建自定义分析和可视化。动手体验 Elasticsearch深入探索 Elasticsearch Labs 仓库中的示例 notebooks开始免费云试用或现在就在本地运行 Elastic。Kibana 会跟踪每个仪表板被查看的次数但这些数据并不会在任何内置仪表板中原生展示。在本文中我们将使用 Elastic Workflows 每 30 分钟自动收集这些数据并将其索引到 Elasticsearch 中从而在其基础上构建我们自己的分析。Elastic Workflows 是 Kibana 内置的自动化引擎允许你使用简单的 YAML 配置定义多步骤流程。每个 workflow 可以通过定时、事件或作为 Elastic Agent Builder 中的工具触发每一步都可以调用 Kibana API、查询 Elasticsearch 或转换数据。我们将以仪表板查看次数为具体示例但同样的模式适用于任何通过 Kibana saved objects API 暴露的指标。前提条件Elastic Cloud 或自托管集群运行 9.3已启用 WorkflowsAdvanced settings步骤 1探索原始数据在构建任何内容之前先了解我们拥有的数据。Kibana 将大部分配置和元数据存储为 saved objects位于一个专用的内部索引中。其中一个被这样跟踪的内容是仪表板查看次数使用一种称为 usage counters 的特殊 saved object 类型。你可以通过 Dev Tools 直接查询它们GET kbn:/api/saved_objects/_find?typeusage-counterfilterusage-counter.attributes.domainId:dashboard%20and%20usage-counter.attributes.counterType:viewedper_page10000响应如下所示{ page: 1, per_page: 10000, total: 1, saved_objects: [ { type: usage-counter, id: dashboard:346f3c64-ebca-484d-9d57-ec600067d596:viewed:server:20260310, attributes: { domainId: dashboard, counterName: 346f3c64-ebca-484d-9d57-ec600067d596, counterType: viewed, source: server, count: 1 }, ... } ]counterName 字段是仪表板 ID而 count 是该仪表板在特定日期的累计查看次数。Kibana 每天为每个仪表板创建一个 counter 对象你可以在对象 ID 中看到日期后缀...viewed:server:20260310。随着用户打开仪表板count 会在一天中持续增长。我们不会在索引中复刻这种按天分文档的模型而是为每次 workflow 执行创建一个文档。每个文档记录在采集时刻该仪表板当天累计的查看次数。步骤 2创建目标索引我们需要一个索引来存储仪表板查看快照。以下命令使用显式 mappings 创建索引以便后续进行聚合和可视化。在 Dev Tools 中运行PUT dashboard-views { mappings: { properties: { captured_at: { type: date }, dashboard_id: { type: keyword }, dashboard_name: { type: keyword }, view_count: { type: integer } } } }对 ID 和名称使用 keyword mappings 可以支持聚合。对 view_count 使用 integer 是一个安全的默认选择因为 Kibana 会每天重置计数器在单日内达到 32 位上限超过 20 亿次查看并不现实。同时它仍支持数值运算例如 max、avg 和 min 等。步骤 3创建 workflow进入 Stack Management Workflows New Workflow并粘贴以下 workflow YAML 配置name: dashboard-views-ingestion triggers: - type: scheduled with: every: 30m steps: - name: fetch_dashboard_views type: kibana.request with: method: GET path: - /api/saved_objects/_find?typeusage-counterper_page10000filterusage-counter.attributes.domainId:dashboard%20and%20usage-counter.attributes.counterType:viewed - name: index_each_dashboard type: foreach foreach: {{ steps.fetch_dashboard_views.output.saved_objects }} steps: - name: fetch_dashboard_name type: kibana.request with: method: GET path: /api/saved_objects/dashboard/{{ foreach.item.attributes.counterName }} on-failure: continue: true - name: index_doc type: elasticsearch.request with: method: POST path: /dashboard-views/_doc body: dashboard_id: {{ foreach.item.attributes.counterName }} dashboard_name: {{ steps.fetch_dashboard_name.output.attributes.title }} view_count: ${{ foreach.item.attributes.count | plus: 0 }} captured_at: {{ execution.startedAt | date: %Y-%m-%dT%H:%M:%SZ }}在下一部分我们将逐步拆解这个 workflow。Workflow 的工作原理触发器该 workflow 通过定时触发器每 30 分钟运行一次。这使我们能够获取时间序列数据同时不会对 API 造成过大压力。fetch_dashboard_views使用 kibana.request 调用 Kibana saved objects API。无需设置身份验证workflow 引擎会根据执行上下文自动附加正确的 headers。index_each_dashboardforeach遍历前一步返回的 saved_objects 数组。每次迭代的当前项可通过 foreach.item 访问。在循环内部我们为每个 dashboard 运行两个嵌套步骤。1fetch_dashboard_name通过调用 GET /api/saved_objects/dashboard/{id} 获取可读的 dashboard 标题。我们添加 on-failure: continue: true这样如果某个 dashboard 已被删除但仍有 view counters循环会继续而不会导致整个执行失败。2index_doc将每条文档索引到POST /dashboard-views/_doc不指定 ID让 Elasticsearch 自动生成 ID。这样每次运行都会创建一条新文档从而保留历史 view count而不是覆盖之前的快照。值得注意的两点captured_at字段使用 date filter 格式化为 ISO 8601 时间戳。否则它会输出 JavaScript 日期字符串例如Tue Mar 10 2026 05:03:47 GMT0000Elasticsearch 无法映射为日期类型。view_count使用${{ }}语法并加上| plus: 0来保持数值类型。如果直接用{{ }}它会被渲染为字符串从而阻止仪表盘上的数学操作。UI 允许你方便地调试每一个 workflow 步骤。Step 4: 构建统计仪表盘当 workflow 运行几次并收集到数据后可以在 Kibana 中使用dashboard-views数据视图创建新的仪表盘。一些入门面板示例Top dashboards by views使用 Bar chart柱状图X 轴为dashboard_nameY 轴为last_value(view_count)。显示每个仪表盘当前的日累计访问量。Views over time使用 Line chart折线图X 轴为captured_atY 轴为last_value(view_count)按dashboard_name拆分。由于每次运行都会追加新文档使用 last value 获取每个时间桶的峰值而不是求和重复值。Current snapshot使用 Data table数据表显示最新的captured_at呈现所有仪表盘的最新访问量快照。由于每次 workflow 都会创建一个新文档你可以按时间范围过滤数据以分析特定时期的仪表盘活动、进行周比周的对比或者在仪表盘访问量低于阈值时触发告警。结论Elastic Workflows 非常适合这类周期性数据采集场景因为数据源Kibana API和目标Elasticsearch都是原生的这意味着无需管理凭据。Workflow 引擎会自动为kibana.request和elasticsearch.request步骤处理认证你只需要编写业务逻辑即可。资源Elastic WorkflowsKibana API原文https://www.elastic.co/search-labs/blog/monitor-kibana-dashboard-views-elastic-workflows