Kafka・Iceberg・Flinkで作るsyslog/authlog分析基盤まとめ
はじめに
syslog / authlog を対象に、
検索・集計・可視化できるログ分析基盤を構築しました。
本記事では、これまで構築してきた内容をベースに
- 全体アーキテクチャ
- 設計思想
- データフロー
- パフォーマンス改善ポイント
- 実運用でのハマりどころ
をまとめます。
※個別の設計は末尾の関連記事を参照してください
全体アーキテクチャ
アーキテクチャの考え方
この基盤は以下の思想で設計しています。
バッチ + リアルタイムの両立
-
バッチ（Hive経由）
- 正確な履歴データ
- 再処理可能
-
リアルタイム（Flink）
- ほぼ即時反映
- 秒〜分単位分析
👉 2系統に分けることで柔軟性を確保
各レイヤーの役割
rsyslog / fluentd （ログ整形・送付）
- syslog / authlog の整形・送付
Kafka（キュー処理）
- syslog / authlog のキュー処理実施
- Kafkaから抽出したデータを、Kafka Connect HDFS SinkからHDFSへ収集し、
生ログ保管を実施 - Flinkで収集しリアルタイム解析・データ保管実施
HDFS
- 生ログをそのまま保存
- 生ログフォーマット：JSON
- 構造化データ,Iceberg実データも保管
Hive（Curated）
- JSON → 構造化（Parquet）
- パーティション：
dt
役割：
- パース処理の分離
- 再利用性向上
Iceberg（分析基盤）
本構成の中核
sparkを使用してHiveで構造化したデータをIcebergへ保管する
特徴：
- 列指向（高速）
- DELETE可能
- snapshot管理
設計：
- partition:
days(ts), host - カラム：
- ts（timestamp）
- dt（date）
- hr（hour）
👉 Grafana/Trinoで扱いやすくするため
Flink（リアルタイム処理）
Kafkaから生ログをリアルタイム取得し、
解析に使用するデータに変換し、Icebergへ保管します
Kafka → Flink → Iceberg
- 1分単位集計
- window処理
- 即時反映
例テーブル：
syslog_host_1mauthlog_host_1m
Trino（SQLエンジン）
- Iceberg / Hive 両方を参照
- Grafanaのバックエンド
Spark
- Iceberg / Hive 両方を参照
- データの再編集の実施
Grafana（可視化）
- 時系列グラフ
- ホスト別集計
- 上位ランキング
Zeppelin（可視化）
- 手動解析実施
- データ再編集実施
Elasticsearch / Kibana（全文検索・調査）
Iceberg を正本として、Elasticsearch / Kibana を検索・調査用に追加しています。
役割：
- Kibana Discover によるログ検索
- host / program / message などの条件検索
- エラーメッセージの全文検索
- 直近ログの素早い調査
ポイントは以下です。
Iceberg = 正本
Elasticsearch = 検索用キャッシュ
Elasticsearch が壊れても Iceberg から再投入できるため、
既存のログ保管・分析基盤を崩さずに検索性を追加できます。
Elasticsearch / Kibana の追加については以下にまとめています。
データフロー
バッチ処理
Kafka → HDFS → Hive → Iceberg
検索用投入
Iceberg → Spark Batch → Elasticsearch → Kibana
リアルタイム処理
Kafka → Flink → Iceberg
設計のポイント
なぜCurated層を入れたか
- JSONのままでは遅い
- 毎回パースは非効率
👉 一度Parquet化して再利用
raw → Icebergにしなかった理由
- パース負荷が高い
- 再処理が難しい
👉 Hiveを挟むことで安定化
Icebergを採用した理由
- DELETE可能
- snapshotで履歴管理
- compaction対応
👉 運用しやすい
Icebergにおけるテーブル運用は以下にまとめています。
Flink導入理由
- リアルタイム集計が必要
- Kafkaとの親和性が高い
Elasticsearch / Kibana を後付けにした理由
- Iceberg を正本として維持したい
- Grafana / Trino は集計分析に強い
- Kibana はログ本文の検索や障害調査に強い
- 検索基盤を分離すると、障害時も再投入で復旧しやすい
👉 集計分析は Iceberg / Trino / Grafana、ログ調査は Elasticsearch / Kibana と役割分担しています。
時刻設計
- ts：一意の時刻情報で保持
- 表示：毎指摘にJSTを指定して変換(クエリツールによって)
- dt：日単位フィルタ用
- hr：時単位フィルタ用
👉 利用するツールによってts列のタイムゾーンが変わるため、
適宜ツール側でタイムゾーン変換をしてください。
以下に時刻設計内容をまとめています。
パフォーマンス改善
実測例：
| 処理 | 時間 |
|---|---|
| Hive（従来） | 約10分 |
| Iceberg | 約40秒 |
👉 桁違いに高速化
クエリ例
件数
SELECT COUNT(*) FROM iceberg.logs.syslog_iceberg;
時系列
SELECT
date_trunc('hour', ts) AS time,
COUNT(*) AS cnt
FROM iceberg.logs.syslog_iceberg
GROUP BY 1
ORDER BY 1;
ホスト別
SELECT
host,
COUNT(*) AS cnt
FROM iceberg.logs.syslog_iceberg
GROUP BY host
ORDER BY cnt DESC
LIMIT 10;
運用設計
日次バッチ
- curated → iceberg 取り込み
メンテナンス
- snapshot削除
- compaction
- Elasticsearch インデックス削除
- Elasticsearch への再投入
HDFS管理
- corruptionチェック
- retention管理
ハマりどころ
実際にハマったポイント：
- timezoneズレ（UTC/JST）
- HiveとSparkで結果が違う
- Zeppelinの表示制限
- Flinkジョブ再起動問題
- Kafka lag
- Elasticsearch の JVM / メモリ設定
- Kibana の Data View / 時刻フィールド設定
👉 ほぼここで詰まる
LLM連携（発展）
- OpenWebUI + FastAPI
- 自然言語 → SQL
例：
昨日のSSHログイン成功数
👉 SQLを書かなくても分析可能
この構成でできること
- リアルタイム監視
- 過去分析
- ホスト別ランキング
- 異常検知の基盤
- Kibana による全文検索
- 障害発生時のログ調査
まとめ
- バッチとリアルタイムを分離
- Icebergを中心に統合
- SQLで全て分析可能
- Elasticsearch / Kibana によりログ検索も可能
👉 実用レベルのログ分析基盤が構築できる
ログ解析基盤構築に使用したハードについて
ログ解析基盤について、基本的にはProxmoxで仮想マシンを構築する前提であるため、
以下のスペックのPCを用意すれば構築できると思います。
(特にメモリについてはVMを30台近く立ち上げるため、基本はメモリ2Gで割り振りますが、
余裕を持ってこのぐらい欲しいです。)
・CPU Corei7 10700
・メモリ DDR4 96GB
・SSD 1.5TB(1TB & 500GBで分散させてもよい。)
・RTX5060(LLMまで構築する場合のみ)
使用していないゲーミングPCなどあれば挑戦してみてもいいかもしれません。
VMスペック(特に手順書指定がない場合、以下のスペックで各種構築できます。)
- 2 vCPU
- 2GB RAM
- 30GB 記憶容量
- Ubuntu24.04
参考記事（詳細設計）