ログ分析基盤に Elasticsearch / Kibana を追加してみる（設計編）

はじめに

これまで私は以下のようなログ分析基盤を構築してきました。

本構成では Grafana と Trino を利用することで、時系列分析や集計分析を実現できます。

一方で運用現場では、以下のような要求も発生します。

• 特定ホストのログだけ見たい
• sshd のログだけ見たい
• cron のログだけ見たい
• エラーメッセージで全文検索したい
• 過去数日分のログを素早く調査したい

このような用途では Kibana が非常に強力です。

そこで今回は既存の Iceberg 基盤を変更せず、Elasticsearch / Kibana を後付けする構成を検討します。

---

シリーズ構成

1. 設計編（本記事）
2. 構築編
3. 実践編
4. 運用編

---

現在のログ分析基盤

現在の構成は以下です。

各コンポーネントの役割は以下です。

コンポーネント	役割
fluentd/Kafka	ログ集約
HDFS Raw	生ログ保管
Hive Curated	整形済みデータ
Iceberg	分析用正本データ
Trino	SQL実行
Grafana	可視化

---

なぜ Kibana を追加するのか

Grafana は以下に強いです。

• 時系列分析
• 集計グラフ
• ダッシュボード
• SLA監視

一方 Kibana は以下に強いです。

• 全文検索
• ログ調査
• Discover
• フィールド検索
• インシデント解析

例えば以下のような調査です。

host=web01 の sshd ログだけ見たい

"Failed password" を含むログだけ見たい

cron の異常だけ見たい

これらは Kibana の方が圧倒的に使いやすいです。

---

Elasticsearch導入方式の比較

案1 Kafka → Logstash → Elasticsearch

メリット

• リアルタイム
• Elasticsearch標準構成

デメリット

• Logstash運用が必要
• Kafka側への影響あり

---

案2 Kafka Connect → Elasticsearch

メリット

• 構成がシンプル
• リアルタイム

デメリット

• Connect運用が増える
• Kafkaへの依存が高い

---

案3 Iceberg → Spark → Elasticsearch

メリット

• Icebergを正本化できる
• Kafka変更不要
• Flink変更不要
• 再投入容易

デメリット

• リアルタイムではない

---

採用方式

今回は案3を採用します。

理由はシンプルです。

現在の基盤では Iceberg がすでに分析用データの正本になっています。

そのため Elasticsearch は検索専用ストアとして扱う方が設計が明快です。

---

採用アーキテクチャ

---

サーバ設計

elastic1

用途

Elasticsearch
Kibana

スペック

項目	値
CPU	2 Core
Memory	4GB
Disk	30GB

---

利用テーブル

対象テーブル

前日までのデータ絵お保管しいるIcebergテーブルを取り込みます。

hive_prod.logs.syslog_iceberg
hive_prod.logs.authlog_iceberg

取得カラム

host
ts
severity
program
msg
dt
hr

---

Index設計

日次Index方式を採用します。

syslog

logs-syslog-YYYY.MM.DD

authlog

logs-authlog-YYYY.MM.DD

例

logs-syslog-2026.05.28
logs-authlog-2026.05.28

なぜ日次Indexか

• 削除が簡単
• 管理しやすい
• Kibanaとの相性が良い

---

保持期間設計

保持期間

14日

削除単位

Index単位

理由

• 運用調査用途として十分
• Elasticsearch容量を抑制可能

---

Index Template設計

{
  "index_patterns": ["logs-*"],
  "template": {
    "mappings": {
      "properties": {
        "@timestamp":{"type":"date"},
        "host":{"type":"keyword"},
        "program":{"type":"keyword"},
        "severity":{"type":"integer"},
        "msg":{"type":"text"},
        "dt":{"type":"keyword"},
        "hr":{"type":"integer"}
      }
    }
  }
}

---

Kibana設計

Data View

logs-syslog-*
logs-authlog-*

または

logs-*

Timestamp

@timestamp

---

GrafanaとKibanaの使い分け

用途	Grafana	Kibana
監視	◎	△
時系列分析	◎	○
全文検索	×	◎
ログ調査	△	◎
ダッシュボード	◎	◎

運用では以下がおすすめです。

Grafana = 監視

Kibana = 調査

---

障害時運用

今回の構成では Iceberg が正本です。

そのため Elasticsearch 側で問題が発生しても

Index削除
↓
再投入

で復旧できます。

---

将来構想

将来的には以下も検討できます。

• TLS
• 認証
• RBAC
• Elasticsearchクラスタ化
• Kafka→Elasticsearchリアルタイム連携

---

まとめ

今回の設計では

Iceberg = 正本

Elasticsearch = 検索専用

として責務を分離しました。

これにより既存の

• Kafka
• HDFS
• Hive
• Iceberg
• Trino
• Grafana

へ影響を与えることなく、Kibana による全文検索と運用分析機能を追加できます。

次回は実際に Elasticsearch と Kibana を構築し、Iceberg からデータを投入する手順を解説します。