Elastic Workflowsを使用したKibanaのダッシュボード表示の監視

Kibanaは各ダッシュボードが何回閲覧されたかを追跡しますが、そのデータは組み込みのダッシュボードにはネイティブに公開されていません。この記事では、Elastic Workflowsを使って30分ごとにそのデータを自動収集し、Elasticsearchにインデックス化して、その上に独自の分析を構築します。

Elastic WorkflowsはKibana内部に組み込まれた自動化エンジンで、シンプルなYAML構成を使用して多段階プロセスを定義できます。各ワークフローはスケジュールやイベント、またはElastic Agent Builderのツールとしてトリガーでき、各ステップでKibana APIを呼び出し、Elasticsearchをクエリし、データを変換できます。

具体的な例としてダッシュボードのビュー数を使用しますが、同じパターンがKibanaの保存済みオブジェクトAPIを通じて提供されるすべてのメトリックにも当てはまります。

要件

Elastic Cloudまたはセルフマネージドクラスター（バージョン9.3を実行）
ワークフローが有効（詳細設定）

何かを作る前に、どんなデータがあるのかを理解しましょう。Kibanaはほとんどの設定やメタデータを専用の内部インデックスに保存済みオブジェクトとして保存しています。Kibanaがこの方法で追跡している項目の一つに、使用量カウンターと呼ばれる、特別な保存オブジェクトタイプを使ったダッシュボードの閲覧数があります。次のように、開発ツールから直接クエリできます。

応答は下記のようになります。

counterNameフィールドはダッシュボードIDであり、countはそのダッシュボードに対する当日中の累積閲覧数です。Kibanaは、1つのダッシュボードにつき1日に1つのカウンターオブジェクトを作成します。オブジェクトIDに日付サフィックス（...views:server:20260310）が表示されます。ユーザーがダッシュボードを開くにつれて、その数は一日を通して増加していきます。

この日常的なドキュメントモデルをインデックスで複製するのではなく、ワークフローの実行ごとに1つのドキュメントを作成します。各ドキュメントは、キャプチャの瞬間におけるその日のダッシュボードの累積ビュー数を記録します。

ステップ2：宛先インデックスの作成

ダッシュボードビューのスナップショットを格納するためのインデックスが必要です。次のコマンドは明示的なマッピングで作成し、後で集約や可視化ができるようにします。Dev Toolsで実行してください：

IDと名前にkeywordマッピングを使用すると、アグリゲーションが可能になります。view_countのためにintegerを使用することは安全なデフォルト設定です。Kibanaはカウンターを毎日リセットするため、32ビットの制限（1日で20億回以上のビュー）に達することは現実的な懸念事項ではありません。数値演算も引き続きサポートしており、max、avg、minなどが含まれます。

ステップ3: ワークフローを作成する

Stack Management > Workflows > New Workflowに移動し、次のワークフローのYAML構成を貼り付けます。

次のセクションでは、ワークフローをステップごとに分解していきます。

ワークフローの仕組み

トリガー

ワークフローは30分ごとにスケジュールされたトリガーで実行されます。これにより、APIに負担をかけずに時系列データが得られます。

ダッシュボードビューを取得

kibana.requestを使ってKibanaの保存済みオブジェクトAPIを呼び出します。認証の設定は不要です。ワークフローエンジンは実行コンテキストに基づいて適切なヘッダーを自動的に添付します。

index_each_dashboard (foreach)

前のステップで返された saved_objects 配列を反復します。各反復の現在の項目は foreach.itemとして利用可能です。ループ内では、各ダッシュボードごとに2つの入れ子手順を実行します。

1. fetch_dashboard_name：

人間が読み取れるダッシュボードのタイトルを GET /api/saved_objects/dashboard/{id} を呼び出して解決します。on-failure: continue: true を追加することで、ダッシュボードが削除されてもビューカウンターが残っている場合、ループが継続して全体の実行が失敗しないようにします。

2. index_doc：

各ドキュメントをPOST /dashboard-views/_doc（明示的なIDなし）でインデックス化することで、Elasticsearchが自動でIDを生成します。これにより、毎回の実行時に新しいドキュメントが作成され、以前のスナップショットを上書きするのではなく、時間の経過とともにビューカウントの履歴が構築されます。

次の2点にご注意ください。

captured_atフィールドは日付フィルターを使ってタイムスタンプをISO 8601としてフォーマットします。それなしでは、値はJavaScriptの日付文字列として出力され（例：Tue Mar 10 2026 05:03:47 GMT+0000）、Elasticsearchは日付としてマップしません。
view_countは数値型を保持するために${{ }}構文を| plus: 0と共に用います。{{ }}を使うと文字列としてレンダリングされ、ダッシュボードでの計算操作ができなくなります。

UIでは、各ワークフローステップを快適にデバッグできます。

ステップ4：統計ダッシュボードを構築

ワークフローが数回実行されてデータが収集されたら、dashboard-views Data viewを使用してKibanaで新しいダッシュボードを作成します。

まずは以下のパネルから始めましょう：

トップのダッシュボード（閲覧数別）： X軸にdashboard_name、Y軸にlast_value(view_count)を持つ棒グラフを使用します。これはダッシュボードごとの現在の日次閲覧数を示しています。
時間経過に伴うビュー：X軸にcaptured_at、Y軸にlast_value(view_count)を用いた折れ線グラフを使用し、dashboard_nameで分類されます。各実行が新しいドキュメントを追加するため、重複を合計するのではなく、最後の値を使用して時間バケットごとのピークカウントを取得します。
現在のスナップショット：すべてのダッシュボードの最新のビュー数を表示するには、最新のcaptured_at を含むデータテーブルを使用します。

各ワークフローが新しいドキュメントを作成するため、時間範囲でフィルタリングして特定の期間のアクティビティを分析したり、週ごとの比較を行ったり、ダッシュボードのビューしきい値を下回ったときにアラートを設定したりすることができます。

まとめ

Elastic Workflowsは、ソース（Kibana API）と送信先（Elasticsearch）の両方がネイティブであるため、認証管理が全く必要なく、この種の定期的なデータ収集に適しています。ワークフローエンジンはkibana.requestとelasticsearch.requestのステップで認証を自動的に処理するため、記述するのはロジックだけです。