ログ収集・解析システムのテーブル設計/運用をまとめてみた。

Last updated at 2026-08-06Posted at 2026-04-07

ログ収集・解析システムのテーブル運用をまとめてみた。

概要

これまでまとめてきた、syslog/suthlog収集/解析システムの運用をまとめる。

本環境では、syslog / authlog のログ分析用テーブルを以下の 3層に分けて運用する。

リアルタイム明細層
リアルタイム集計層
長期履歴分析層

この構成により、以下を両立する。

Grafana で軽量に可視化
Zeppelin / Trino で詳細調査
長期保持データで履歴分析
Flink によるリアルタイム集計
Iceberg による高速分析・履歴管理

リアルタイムテーブルとバッチテーブルの分離設計

本構成では、Flink によるリアルタイム処理と、バッチ処理による長期履歴データ生成を同一テーブルに集約せず、用途ごとに別テーブルへ分離している。

役割分担は以下の通りである。

Flink(リアルタイム)

Kafka から当日分をリアルタイム取得
即時可視化向けの集計テーブルを更新

Batch(長期履歴)

HDFS RAW / curated データを元に再処理
正確性を重視した確定テーブルを生成

このように分離することで、リアルタイム性と正確性を両立しやすくなる。

この設計の意図

Flink はリアルタイム可視化に強い一方で、障害時や再起動時には一時的な欠損や遅延が発生する可能性がある。
一方、バッチ処理は即時性には劣るが、蓄積済みデータをもとに再計算できるため、最終的な正確性を担保しやすい。

そのため、本構成では以下のように割り切る。

Flink テーブル = 速報値
Batch テーブル = 確定値

つまり、Flink 側のテーブルには一部欠損や遅延があり得るが、これは速報用途として許容する。
最終的な集計結果や長期保存用途では、Batch 側のテーブルを参照する。

この分離設計のメリット

この方式には次の利点がある。

Flink と Batch が同一テーブルを更新しない
二重書き込みによる重複や競合を避けられる
Flink 障害時でも、Batch 側の正本テーブルには影響しない
リアルタイム用途と確定用途を明確に分けられる

特に重要なのは、リアルタイム処理の不安定さを正本テーブルに持ち込まない点である。
これにより、運用上の切り分けもしやすくなる。

利用時の考え方

この構成では、参照先テーブルを用途に応じて使い分ける。

Grafana などのリアルタイム監視
Flink 側テーブルを参照
日次長期集計、レポート、検証用途
Batch 側テーブルを参照

このルールを明確にしておくことで、利用者が速報値と確定値を混同しにくくなる。

まとめ

本構成では、Flink と Batch を競合させず、役割ごとに別テーブルへ分離する設計を採用している。

これにより、

Flink はリアルタイム性を担当
Batch は正確性を担当

という責務分離が明確になり、運用性・拡張性ともに高い構成にしやすい。

テーブル設計方針

命名ルール

テーブル名は 技術方式ではなく用途 が分かる名前とする。

基本ルール

*_events
→ 明細ログ
*_<dimension>_<grain>
→ 集計テーブル
*_iceberg
→ 長期履歴分析用テーブル
→ 用途が分かる名前でないため、*_historyへ将来的に変更する。

例

syslog_events
authlog_events
syslog_host_1m
authlog_host_1m
syslog_iceberg
authlog_iceberg

テーブル一覧

1. リアルタイム明細層

役割

実際のログ本文を確認する
障害調査時の深掘りに使う
LIKE 検索や直近ログ確認に使う

テーブル

logs.syslog_events
logs.authlog_events

主な利用先

Zeppelin
Trino
障害調査用 SQL
LLM / API（具体ログ例を返す用途）

主な列（例）

列名	内容
`host`	ホスト名
`ts`	ログ時刻
`program`	出力プログラム
`msg`	ログ本文
`dt`	日付パーティション用
`dh`	時間解析用

代表クエリ例

SELECT host, ts, program, msg
FROM iceberg.logs.syslog_events
ORDER BY ts DESC
LIMIT 100;

SELECT host, ts, msg
FROM iceberg.logs.authlog_events
WHERE msg LIKE '%Accepted publickey%'
ORDER BY ts DESC
LIMIT 100;

2. リアルタイム集計層

役割

Grafana の時系列可視化
ホスト別件数ランキング
リアルタイム異常検知
API / LLM での件数回答

テーブル

logs.syslog_host_1m
logs.authlog_host_1m

主な利用先

Grafana
Zeppelin
Trino
LLM / API

主な列（例）

列名	内容
`window_start`	集計開始時刻
`window_end`	集計終了時刻
`host`	ホスト名
`cnt`	件数
`dt`	日付パーティション用
`dt`	時間解析用

代表クエリ例

時系列表示

SELECT
  CAST(window_start AS timestamp) AS time,
  host AS metric,
  cnt AS value
FROM iceberg.logs.syslog_host_1m
WHERE window_start BETWEEN from_iso8601_timestamp('${__from:date:iso}')
                      AND from_iso8601_timestamp('${__to:date:iso}')
ORDER BY 1, 2;

ホスト別ランキング

SELECT
  host,
  SUM(cnt) AS total_cnt
FROM iceberg.logs.syslog_host_1m
WHERE window_start BETWEEN from_iso8601_timestamp('${__from:date:iso}')
                      AND from_iso8601_timestamp('${__to:date:iso}')
GROUP BY host
ORDER BY total_cnt DESC
LIMIT 10;

3. 長期履歴分析層

役割

長期分析
日次 / 週次 / 月次の傾向確認
過去比較
安定した履歴分析基盤

テーブル

logs.syslog_iceberg
logs.authlog_iceberg

主な利用先

Zeppelin
Trino
長期レポート
過去傾向分析

主な列（例）

列名	内容
`host`	ホスト名
`ts`	ログ時刻
`program`	出力プログラム
`severity`	severity
`msg`	ログ本文
`dt`	日付
`hr`	時間

代表クエリ例

日次件数

SELECT
  dt,
  COUNT(*) AS cnt
FROM iceberg.logs.syslog_iceberg
WHERE dt >= date_sub(current_date(), 14)
GROUP BY dt
ORDER BY dt;

ホスト別件数

SELECT
  host,
  COUNT(*) AS cnt
FROM iceberg.logs.syslog_iceberg
WHERE dt BETWEEN DATE '2026-04-01' AND DATE '2026-04-07'
GROUP BY host
ORDER BY cnt DESC;

運用上の使い分け

基本方針

`*_events`

実際のログ本文を確認するためのテーブル

用途:

「何のログが出ているか」を見る
メッセージ本文の確認
直近障害の深掘り

`*_host_1m`

件数や傾向を可視化するためのテーブル

用途:

Grafana の時系列表示
ホスト別ランキング
急増検知
API / LLM での件数応答

`*_iceberg`

長期履歴分析のためのテーブル

用途:

日次 / 週次 / 月次の傾向確認
過去比較
安定分析用

調査時の基本フロー

障害調査や異常検知時は、以下の順で確認する。

Step 1. 集計テーブルで異常箇所を特定

まず *_host_1m を見て、

いつ増えたか
どのホストが増えたか
何分単位で増えたか

を確認する。

例

10:32〜10:37 に急増
gateway1 だけ急増
authlog のみ増加

Step 2. 明細テーブルで実ログ確認

次に *_events を見て、

実際に何のログだったか
失敗なのか成功なのか
どのプロセス由来か

を確認する。

例

SELECT host, ts, program, msg
FROM iceberg.logs.authlog_events
WHERE host = 'gateway1'
  AND ts BETWEEN TIMESTAMP '2026-04-05 10:32:00'
             AND TIMESTAMP '2026-04-05 10:37:00'
ORDER BY ts DESC
LIMIT 200;

Step 3. 必要に応じて履歴テーブルで過去比較

異常が一時的か恒常的かを確認するため、*_iceberg で過去比較を行う。

例

昨日だけ増えたのか
毎週同じ時間に増えるのか
先週比でどれくらい違うか

各ツールでの推奨利用先

Grafana

推奨

syslog_host_1m
authlog_host_1m

理由

集計済みで軽い
毎回 GROUP BY しなくてよい
時系列パネルとの相性が良い

非推奨

*_events をそのまま件数可視化に使うこと

理由:

明細件数を毎回再集計するため重くなりやすい

Zeppelin

推奨

まず *_host_1m
次に *_events

理由

傾向把握 → 詳細確認の流れに向いている

Trino

推奨

集計系は *_host_1m
詳細分析は *_events / *_iceberg

理由

用途に応じて適切な粒度のテーブルを選べる

LLM / API

件数系質問

例:

昨日の syslog 件数
過去1週間の日毎件数
ホスト別件数 top5

→ *_host_1m を優先

実ログ例質問

例:

直近の SSH 成功ログ
失敗ログを見せて
特定メッセージを含むログ

→ *_events を優先

列指向データの扱いについて

どこから列指向か

バッチ経路

Kafka raw JSON
  ↓
Hive raw / parsed view
  ↓
curated Parquet
  ↓
Iceberg

→ curated Parquet から列指向

Flink 経路

Kafka / Stream
  ↓
Flink SQL
  ↓
Iceberg

→ Iceberg に sink した時点から列指向

補足

Flink 自体が列指向なのではなく、
Flink が書き込んだ先（Iceberg / Parquet）が列指向 である。

今後の拡張ルール

今後テーブルを増やす場合は、以下ルールに従う。

明細系

{source}_events

例:

syslog_events
authlog_events

集計系

{source}_{dimension}_{grain}

例:

syslog_host_1m
syslog_program_1m
authlog_user_1m
authlog_result_5m

履歴系

{source}_iceberg

例:

syslog_iceberg
authlog_iceberg

現時点での推奨整理

そのまま維持してよい

syslog_events
authlog_events
syslog_host_1m
authlog_host_1m

将来的に見直し推奨

syslog_iceberg → syslog_history
authlog_iceberg → authlog_history

最終まとめ

本環境では以下の考え方で運用する。

events = 明細
host_1m = 集計
iceberg = 長期履歴
将来的に技術名（iceberg）ではなく用途名で管理する

これにより、

どのテーブルをどの用途で使うかが明確になる
Grafana / Zeppelin / Trino / API の役割分担が整理される
今後の拡張時も命名ルールが崩れにくい

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up