はじめに
前回の記事では、以下のようなログ収集・蓄積基盤を構築しました。
- rsyslog / Fluentd によるログ転送
- Kafka によるメッセージキューイング
- Kafka Connect HDFS Sink による HDFS への保存
- Hive による SQL 参照
- raw / curated の二層構成
- 保持・隔離・件数比較を含む運用設計
ここまででも「ログを集めて保存し、SQL で確認する」ことは十分に実現できます。
ただ、運用を進めていくと、次のような課題が見えてきました。
- SQL 実行基盤をもう少し高速・軽量にしたい
- Parquet ファイル群を“テーブル”としてより安全に扱いたい
- Grafana から見やすく可視化したい
- 日々増えていくログに対して、保守しやすい分析基盤にしたい
そこで今回は、既存の基盤に対して以下を追加しました。
- Apache Iceberg
- Trino
- Grafana
これにより、ログ分析基盤としてかなり“使える”状態まで進化しました。
拡張前の全体構成
拡張後の全体構成
ポイントは、HDFS 上の raw データをそのまま残しつつ、分析用途は Iceberg テーブルへ寄せる という構成にしたことです。
これにより、保存と分析の責務を分けつつ、運用しやすい形にできます。
なぜ Iceberg を入れたのか
これまでの curated テーブルの課題
従来は Hive 外部テーブル + Parquet で curated データを管理していました。
この構成でも基本的な分析はできますが、運用が進むと以下のような悩みが出てきます。
- Parquet ファイルが増えてくると管理がつらい
- 小さいファイルが大量にできる
- 「今このテーブルはどのファイル群を見ているか」が曖昧になりやすい
- 更新・再投入・再生成の運用をきれいに整理しにくい
Iceberg を入れることで、HDFS 上のファイル群を“テーブルとしてきちんと管理”できる ようになります。
Iceberg のメリット
Iceberg を使うと、単なる「Parquet ファイルの置き場」ではなく、
メタデータ付きのテーブル としてデータを扱えます。
主なメリットは以下です。
-
スナップショット管理
- テーブルの状態を履歴として持てる
-
ファイル管理の改善
- どのデータファイルが有効かをテーブルメタデータで管理できる
-
小さいファイル問題への対策
- compaction（ファイル統合）がしやすい
-
Trino / Spark など複数エンジンから扱いやすい
- 将来の拡張性が高い
特に、自宅ラボのように
「まずは動かしながら、後から構成を育てていく」
スタイルとはかなり相性が良いです。
raw と curated の役割分担はそのまま活かせる
今回の拡張でも、前回までの設計思想はそのまま残しています。
raw 層
raw は HDFS にそのまま保存するログ本体 です。
特徴:
- オリジナルのログを保持
- 取り込み失敗時の再処理元になる
- フォレンジックや検証にも使える
- 保持期間を短めに設定しやすい
例:
/data/kafka/syslog/YYYY/MM/DD/HH/*.json
/data/kafka/authlog/YYYY/MM/DD/HH/*.json
curated 層
curated は 分析しやすい形へ正規化したテーブル層 です。
例として、syslog なら以下のような列を持たせています。
tshostseverityprogrammsgdthr
これまで Hive 外部テーブルとして扱っていた curated を、
今後は Iceberg テーブルとして扱う ようにしました。
つまり設計思想は変わらず、
- raw = 保存 / 再処理
- curated = 分析 / 可視化
という役割分担です。
Iceberg 化で何が変わったか
1. 分析対象を「ファイル」ではなく「テーブル」として扱いやすくなった
従来の curated では、
「Parquet があるから読める」という感覚が強かったのですが、Iceberg 化すると、
- どのファイルが有効か
- どのパーティションに何があるか
- いつの状態を参照しているか
を、テーブル側のメタデータで持てる ようになります。
これは運用していくと地味に効きます。
2. compaction がしやすくなった
ログ系データは、小さなファイルが大量にできがちです。
これを放置すると、分析クエリの効率が落ちやすくなります。
Iceberg を使うと、
小さいファイルを定期的にまとめる（compaction）
という運用を入れやすくなります。
例えば日次・週次で compaction を回すことで、
- クエリ性能の改善
- メタデータ肥大化の抑制
- スキャン効率の改善
が期待できます。
3. 将来的な更新・再投入にも強くなる
今回のログ基盤は基本的に append 中心ですが、
今後もし
- 再生成
- 再投入
- 一部期間の再計算
- 集計済みテーブルの差し替え
などをやりたくなった場合、Iceberg のほうが拡張しやすいです。
自宅ラボでも、最初は append-only でも、後からやりたいことが増えがちなので、この柔軟性は大きいです。
Trino を入れた理由
Hive だけでも SQL はできるが、BI 連携では Trino がかなり便利
従来は Hive / Beeline でクエリしていました。
これはこれで十分便利です。
ただし、可視化や日常的な参照を考えると、Trino の導入メリットがかなり大きいです。
Trino の良かった点
1. SQL 実行が軽快
日々の確認で欲しいのは、たとえばこういうクエリです。
- 直近24時間の syslog 件数
- authlog の失敗ログ推移
- ホスト別の件数
- 時間帯別のピーク確認
こうした 「ダッシュボード向けの参照系クエリ」 は、Trino と相性が良いです。
2. Grafana との接続がしやすい
Grafana 側から見ると、Trino はかなり扱いやすいです。
つまり、
- HDFS / Iceberg に保存
- Trino で SQL
- Grafana で可視化
という流れがきれいに作れます。
この形にしておくと、
「データレイク上のログを BI 的に見る」
という使い方がかなり現実的になります。
3. “運用で使う画面”を作りやすい
CLI や SQL だけでなく、
Grafana ダッシュボードとして可視化される と、一気に運用基盤らしくなります。
たとえば以下のような可視化がしやすくなります。
- syslog / authlog の時間別件数
- ホスト別のログ量
- severity 別の分布
- 異常増加日の検出
- 認証失敗の推移
これが「見たい時にすぐ見える」状態になるのはかなり大きいです。
Grafana をつないで何が良くなったか
“見える化”はやはり強い
ログ基盤は、保存できているだけでも価値があります。
ただ、見える化されて初めて「運用で使っている感」が出る と感じました。
たとえば以下のようなパネルを作るだけでもかなり便利です。
- 直近24時間の syslog 件数
- 直近24時間の authlog 件数
- ホスト別ログ件数ランキング
- 時間帯ごとの推移
- 認証失敗イベントの推移
特に便利だった観点
1. “増え方”がすぐ分かる
テーブルで件数を見るより、グラフのほうが異常を見つけやすいです。
- 特定時間帯だけ急増していないか
- ある日だけ authlog が跳ねていないか
- 取り込み停止で急にゼロになっていないか
こうした変化は、Grafana にすると一気に分かりやすくなります。
2. SQL の使い回しがしやすい
一度 Trino 用に SQL を整えてしまえば、Grafana 側でかなり再利用できます。
例えば、
- 日別集計
- 時間別集計
- ホスト別集計
- severity 別集計
などをテンプレ化しておけば、パネルの追加も楽です。
3. “監視”と“分析”の中間が作れる
Prometheus / Alertmanager のような厳密監視とは別に、
Grafana は 「見て判断するための監視」 に向いています。
つまり今回の基盤では、
- Prometheus / node_exporter → サービス・ホスト監視
- Grafana + Trino → ログ傾向・分析監視
という住み分けができます。
これはかなり実運用向きです。
実際に便利だった分析例
syslog 件数の時間別推移
SELECT
CAST(date_trunc('hour', at_timezone(ts, 'Asia/Tokyo')) AS timestamp) AS time,
COUNT(*) AS syslogcnt
FROM iceberg.logs.syslog_iceberg
WHERE dt BETWEEN CAST(from_iso8601_timestamp('${__from:date:iso}') AS date)
AND CAST(from_iso8601_timestamp('${__to:date:iso}') AS date)
AND ts BETWEEN from_iso8601_timestamp('${__from:date:iso}')
AND from_iso8601_timestamp('${__to:date:iso}')
GROUP BY 1
ORDER BY 1
これで「いつログが増えているか」が見えます。
authlog の認証失敗件数
SELECT
CAST(date_trunc('hour', at_timezone(ts, 'Asia/Tokyo')) AS timestamp) AS time,
COUNT(*) AS fail_cnt
FROM iceberg.logs.authlog_iceberg
WHERE msg LIKE '%Failed password%'
AND dt BETWEEN CAST(from_iso8601_timestamp('${__from:date:iso}') AS date)
AND CAST(from_iso8601_timestamp('${__to:date:iso}') AS date)
AND ts BETWEEN from_iso8601_timestamp('${__from:date:iso}')
AND from_iso8601_timestamp('${__to:date:iso}')
GROUP BY 1
ORDER BY 1
認証失敗の増減を見るだけでも、かなり“運用してる感”が出ます。
ホスト別ログ件数
SELECT
host,
COUNT(*) AS cnt
FROM iceberg.logs.syslog_iceberg
WHERE dt BETWEEN CAST(from_iso8601_timestamp('${__from:date:iso}') AS date)
AND CAST(from_iso8601_timestamp('${__to:date:iso}') AS date)
AND ts BETWEEN from_iso8601_timestamp('${__from:date:iso}')
AND from_iso8601_timestamp('${__to:date:iso}')
GROUP BY host
ORDER BY cnt DESC
LIMIT 10
どのホストが多くログを出しているか、ざっくり把握できます。
運用してみて感じたこと
今回の拡張で大きかったのは、
「保存できる」から「分析・可視化して使える」へ進んだこと です。
前回までの構成は、ログ基盤としてすでにかなり有用でした。
ただ、Iceberg / Trino / Grafana を入れることで、次のような価値が出てきました。
- SQL で見やすい
- ダッシュボードで見やすい
- データレイクとして整理しやすい
- 将来拡張しやすい
特に自宅ラボでは、
「とりあえず保存する」→「あとでちゃんと使えるようにする」
という流れが非常に大事だと思っています。
その意味で、今回の拡張はかなり満足度が高かったです。
まとめ
今回、既存の syslog / authlog 収集基盤に対して
- Iceberg
- Trino
- Grafana
を追加することで、単なるログ保存基盤から、
“分析・可視化までできるログデータレイク” に近い形まで持っていけました。
今回の構成で、次の流れがかなりきれいに実現できています。
- ログを集める
- 失わず保存する
- 分析しやすく整える
- SQL で参照する
- ダッシュボードで見る
「自宅ラボでここまでやるのはやりすぎでは？」と思いつつも、
やってみるとかなり学びが多く、実用性も高い構成になりました。
同じように、
- ログをちゃんと溜めたい
- Hadoop / Kafka / Hive を触ってみたい
- データレイクっぽい構成を自宅で試したい
- Grafana までつないで運用っぽくしたい
という人には、かなりおすすめできる構成です。
おわりに
ここまで構築した内容について以下にまとめています。
興味があればぜひ挑戦してみてください。