1.はじめに
システム運用や障害対応の現場では、膨大なログを効率よく調査・分析することが求められます。
しかし、複数のサーバやサービスから出力されるログを一つひとつ確認するのは手間がかかり、問題の原因特定や傾向分析に時間がかかってしまいます。
こうした課題を解決するために役立つのが Elasticsearch と Kibana です。
Elasticsearchはログを検索・蓄積する基盤を提供し、Kibanaはそのデータを直感的に操作・可視化できるツールです。一方で、「どのようにログを分類できるのか」「操作方法や便利な機能には何があるのか」「実際の調査でどこを見ればよいのか」など、初めて利用するときには迷うことも多いと思います。
前回のログ転送編（Elasticsearchを利用したログ可視化基盤の構築～ログ転送編～）では、Elasticsearchのインストールからログの転送までを紹介しました。今回は、転送したログがKibana上でどのように表示されるかや、Kibanaの主な操作方法、便利な機能をまとめます。「Elasticsearchに送ったログをKibanaで見てみたい」「チームでログの傾向を共有・分析したい」といった方はぜひ参考にしてください。
2.送信するログと使用ツール
本検証では、複数のサーバから収集したログを Elasticsearch に転送し、Kibanaで可視化する構成を扱います。
1.送信するログの種類
今回の検証では、以下のログを対象としています。
①SourceServer_A
| ログA | 内容 |
|---|---|
| /var/log/maillog | メール関連ログ |
| /var/log/syslog | システムログ |
②SourceServer_B
| ログB | 内容 |
|---|---|
| event_logs | セキュリティ、システム、アプリケーション |
2. 使用するツール
下図のログ送信先サーバのスペックとツールの導入については前回記事を参照ください。
Filebeat
ログ収集ツール。Linuxサーバ上で動作し、指定したログファイル（例：/var/log/maillog）を監視・収集し、Elasticsearch（ログ送信先サーバ）に送信します。
Winlogbeat
Windowsイベントログ専用の収集ツール。Windowsサーバ上で動作し、イベントログをElasticsearch（ログ送信先サーバ）に送信します。
3.前提として知っておくべき用語
Kibanaを使ってログを検索・分析する際、画面に表示される用語や概念を理解していないと、操作に迷ったり、意図した結果が得られなかったりすることがあります。
特に インデックス（Index）、ドキュメント（Document）、フィールド（Field） は、ElasticsearchとKibanaの基本構造を理解するうえで欠かせないキーワードです。
・インデックス（Index）
説明：Elasticsearchでデータを保存するための「箱」や「データベース」に相当します。同じ種類のデータをまとめる単位であり、インデックス名によって検索対象を指定したりします。参考画像内ですとSourceServer_A、SourceServer_Bがインデックス名に相当します。
例：
ds-filebeat-8.19.0-2025.08.20-000001
→ Filebeatが収集したログを保存するインデックス（※初期設定の場合、このような表記になることがあります）
参考画像
・ドキュメント（Document）
説明：インデックスの中に含まれる「1件のデータ」です。1つのログメッセージやイベントが1ドキュメントとして保存されます。データはJSON形式で管理されます。
例：
{
"@timestamp": "2025-09-05T01:10:27.409Z",
"message": "Sep 5 10:10:24 SourceServer_A postfix/local[20996]: ...",
"host.name": "SourceServer_A"
}
参考画像
・フィールド（Field）
説明：ドキュメントの中に格納されている「項目」です。JSONのキーに相当し、検索やフィルタリングに利用できます。
参考画像
4.ログの内容を確認する方法
Kibanaでは、ログの詳細を「表形式」や「JSON形式」で確認でき、必要なフィールドを簡単に抽出できます。
ここでは、ログ詳細の表示方法と、確認すべき主要なフィールドについて解説します。
ログの詳細表示
Kibanaでログの詳細を表示する手順は、以下の通りです。
1.詳細ダイアログの切り替え
ログ一覧の左側にあるチェックボックスの右隣に、「詳細ダイアログを切り替え」ボタンがあります。
2.ログの詳細
このボタンをクリックすると、画面の右側に選択したログの詳細が表示されます。
3.表示形式の選択
詳細の表示形式は「表形式」と「JSON形式」のどちらかを選択できます。
このように表示されたElasticsearchのログは、以下のようにいくつかの項目（フィールド）ごとにデータが記録されています。
| 項目（フィールド）名 | 値の説明・例 |
|---|---|
| ＠timestamp | イベントが発生した日時（UTC）。例：2025-11-13T08:10:47.409Z（日本時間17:10:47） |
| agent.ephemeral_id | Filebeatエージェントの一時的なID（起動ごとに変化。再起動や更新で再生成されるID） |
| agent.hostname | Filebeatエージェントが動作しているホスト名（収集元サーバー名）。例：tky0ntp3001_test |
| agent.id | Filebeatエージェントに割り当てられた一意のID。再起動後も変わらない永続的なID。 |
| agent.name | エージェントの名前。通常はホスト名や、ユーザーが設定ファイルで定義した名前が反映されます。 |
| agent.type | エージェント種別。例：filebeat（ログ収集用エージェント名） |
| agent.version | Filebeatエージェントのバージョン。例：8.19.0 |
| ecs.version | Elastic Common Schemaのバージョン。例：8.0.0。データ形式の共通化ルール Elasticsearch、Filebeat、Kibanaなどの複数ツール間でデータをやりとりする際、互換性やアップグレード対応のために重要な情報 |
| host.architecture | 収集元ホストのCPUアーキテクチャ。例：x86_64 |
| host.containerized | ホストがコンテナ環境か否か。falseなら物理/仮想サーバー |
| host.hostname | 収集元ホスト名。 |
| host.id | 収集元ホストに割り当てられた一意のID。システムやOSによって生成されます。 |
| host.ip | ホストが持つネットワークインターフェースのIPアドレスのリスト。 |
| host.mac | ホストのMACアドレス。例：00-50-56-99-73-4A |
| host.name | ホストのユーザーフレンドリーな名前。通常はhost.hostnameと同義として使用されます。 |
| host.os.codename | OSのコードネーム。例："Core" |
| host.os.family | OSのファミリー（派生元）。例："redhat" |
| host.os.kernel | OSカーネルバージョン。例：3.10.0-862.3.2.el7.x86_64 |
| host.os.name | OSの名称。例："CentOS Linux" |
| host.os.name.text | OSの名称（テキスト）。例："CentOS Linux" |
| host.os.platform | OSプラットフォーム名。例："centos" |
| host.os.type | OS種別。例："linux" |
| host.os.version | OSバージョン。例："7 (Core)" |
| input.type | Filebeatのログ収集方法。例："filestream"（新しいファイル監視方式） |
| log.file.device_id | ログファイルがあるデバイスのID（マウントディスク等の識別） |
| log.file.inode | ログファイルのinode番号（一意なファイルID。OSのファイル管理用） |
| log.file.path | 収集対象のログファイルパス。例：/var/log/maillog |
| log.offset | ログファイル内の読み取り位置（バイト数）。例：57636（先頭から何バイト目か） |
| message | 実際のログメッセージ内容 |
| _id | Elasticsearchが自動生成するドキュメントID（一意のID） |
| _index | Elasticsearchインデックス名（保存先）。例：.ds-filebeat-8.19.0-2025.10.19-000003 |
| _score | Elasticsearch検索結果のスコア（該当なしならnull） |
5. 基本的な操作（Discover）
ログ管理には主にDiscoverを用います。
DiscoverはElasticsearchに格納されたログを検索・調査するための画面です。
Discoverでのセッションの保存方法と今回新たに設定した二つの送信元サーバのデータビューを設定する方法、およびログを絞り込む方法を説明します。
Discoverでのセッションの保存方法
1. インデックスを選択
画面左上の「データビュー」で、表示したいインデックス（例：SourceServer_A）を選択します。
2. 時系列でログを確認
画面上に、時系列順でログが一覧表示されます。
3. フィルターやクエリで絞り込み
画面上部の検索ボックスで、条件を指定してログを絞り込めます。
以下画像ではbounced でバウンスしたメールログだけ抽出しています。
よく使う検索条件は「保存」しておくと、次回からすぐ呼び出せます。
4. フィールドの表示・非表示
画面左側の「フィールド一覧」から、「利用可能なフィールド」を選んで表示できます。
memo
よく使うフィールド（＠timestamp、message、host.nameなど）を「頻繁に使用されるフィールド」に追加しておくと便利です。
5. セッションのタイトル・タグ管理
画像内右上の青い「保存」ボタンを押し、調査内容ごとにタイトルやタグを付けて保存できます。
例：「バウンスメール調査」「送信エラー分析」など
後から見直したり、共有したりする際に役立ちます。
データビューの項目の分け方、表示名の変更方法
１.「スタック管理」選択
Kibana 左上メニューのハンバーガーメニューを選択し、
「管理（Management）」までスクロールすると、
「スタック管理（Stack Management）」 という項目がありますのでそこをクリックします。
２.「データビュー（Data Views）」
左メニューから 「データビュー（Data Views）」 をクリックします。
３.データビューの作成
・新規で作成する場合
「データビューを作成（Create data view）」をクリックして新規作成します。
名前、インデックスパターン、タイムスタンプフィールドは任意のものを入力します。
・既に作成したデータビューの名前を変更する場合
memo
初期設定状態だとデータビューの表記が想定と異なったり、ログの送信元が複数混在して統一されませんでした。データビューの名前は変更することを推奨します。
既に作成したデータビューの名前を変更する場合は、作成済みのデータビューを選択し右上編集ボタンをクリックします。
クリックすると、名前とログの送信元を変更するメニューが開かれます。
今回はFilebeatを導入したサーバ（SourceServer_A）とWinlogbeatを導入したサーバ（SourceServer_B）があります。
この画面ではFilebeatを導入した「SourceServer_A」を選択しているので、インデックスパターンは「filebeat-*」を選択します。
同じようにWinlogbeatの方も設定すると、以下のように名前とログ送信元を分けることができました。
ログの絞り込み
1. フィルターの追加
「＋」マークを押して追加します。
演算子を選択後、messageに含まれている任意のワードを入れます。
ここでは「bounced」と「sent」を入れています。
カスタムラベルは任意のフィルター名を入力してください。
2. セッションを開く
画像内のボタンを押してセッションを開きます。
3. 作成したセッションの選択
タイトルをクリックし、作成したフィルターを表示します。
4. 検索結果の表示
検索条件は結果を除外したり、含めたりすることが可能です。
ログをbouncedに絞ると以下のように表示されました。
6. まとめ
今回は、複数のログ送信元サーバから収集したデータを Kibana 上で可視化し、基本的な調査・分析を行うための方法を紹介しました。実際に操作してみることで、Kibana の直感的なインターフェースや柔軟な検索機能を活用すれば、複雑なログでも効率よく分類・抽出できることを実感できました。
記事内では、Discover画面でのログ確認やフィルター設定、データビューの分け方、セッションの保存・管理など、実用的なポイントを押さえて解説しました。これらの機能を使いこなすことで、日々の運用監視や障害対応、統計分析といったシーンでも役立つはずです。
まだまだ分からないことや使いこなせていない機能はたくさんありますので、今後も引き続きKibanaについて知識を深めていきたいと思います。
We Are Hiring!