0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@naritomo08(nari tomo)

Kafka・Iceberg・Flinkで作るsyslog/authlog分析基盤まとめ

0
Last updated at Posted at 2026-04-07

Kafka・Iceberg・Flinkで作るsyslog/authlog分析基盤まとめ

はじめに

syslog / authlog を対象に、
検索・集計・可視化できるログ分析基盤を構築しました。

本記事では、これまで構築してきた内容をベースに

  • 全体アーキテクチャ
  • 設計思想
  • データフロー
  • パフォーマンス改善ポイント
  • 実運用でのハマりどころ

をまとめます。

※個別の設計は末尾の関連記事を参照してください

全体アーキテクチャ

log-platform-index.png

アーキテクチャの考え方

この基盤は以下の思想で設計しています。

バッチ + リアルタイムの両立

  • バッチ（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へ保管します

  • 1分単位集計
  • window処理
  • 即時反映

例テーブル：

  • syslog_host_1m
  • authlog_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 の追加については以下にまとめています。

AWS S3 / Glue / Athena（分析用コピー）

自宅側の Iceberg を Source of Truth として残しつつ、AWS 側に Athena 分析用コピーを作る構成も追加で整理しました。

役割：

  • S3 に Iceberg warehouse を配置
  • Glue Data Catalog に Iceberg テーブルを登録
  • Athena からサーバーレスに SQL 分析
  • QuickSight / Amazon Quick で可視化
  • 自宅側障害時も、同期済み範囲は AWS 側で参照可能

ポイントは、HDFS 上の Iceberg ディレクトリを S3 へ単純コピーしないことです。

AWS 側は分析用コピーであり、自宅 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を書かなくても分析可能

Elixirによるログ検索アプリ(発展)

ブラウザからログを検索できる軽量なWebアプリも追加で作成しました。

Kibanaでの全文検索、Grafanaでの可視化、LLMによる自然文分析に加えて、用途を絞ったWeb検索画面も用意することで、運用時のログ確認手段を増やせます。

この構成でできること

  • リアルタイム監視
  • 過去分析
  • ホスト別ランキング
  • 異常検知の基盤
  • Kibana による全文検索
  • Athena によるクラウド側SQL分析
  • QuickSight / Amazon Quick によるAWS側ダッシュボード
  • 障害発生時のログ調査

まとめ

  • バッチとリアルタイムを分離
  • Icebergを中心に統合
  • SQLで全て分析可能
  • Elasticsearch / Kibana によりログ検索も可能
  • S3 / Glue / Athena によりAWS側の分析用コピーも構成可能
  • QuickSight / Amazon Quick によりAWS側の可視化基盤も追加可能

👉 実用レベルのログ分析基盤が構築できる

2025/12月末辺りからhadoopへのauthlog/syslog溜め込み検証からスタートして、収集/解析/検証まで一通りのデータレイクに関する自前設計/構築ができました。
ここまで自前構築できればこれらの基盤がクラウドに変わっても戸惑わずに対応できると思います。
これからこれらで得た知見を生かしていければと思います。

ログ解析基盤構築に使用したハードについて

ログ解析基盤について、基本的にはProxmoxで仮想マシンを構築する前提であるため、
以下のスペックのPCを用意すれば構築できると思います。
(特にメモリについてはVMを30台近く立ち上げるため、基本はメモリ2Gで割り振りますが、
余裕を持ってこのぐらい欲しいです。)

Proxmox VE 上に検証用 VM をまとめて作成する場合は、Terraform で Cloud-init 対応 VM を作成する以下の記事も参照ください。

・CPU Corei7 10700
・メモリ DDR4 96GB
・SSD 1.5TB(1TB & 500GBで分散させてもよい。)
・RTX5060(LLMまで構築する場合のみ)

使用していないゲーミングPCなどあれば挑戦してみてもいいかもしれません。

VMスペック(特に手順書指定がない場合、以下のスペックで各種構築できます。)

  • 2 vCPU
  • 2GB RAM
  • 30GB 記憶容量
  • Ubuntu24.04

参考記事（詳細設計）

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?