はじめに
前回の記事で構築した syslog / authlog 収集・分析基盤は、
Kafka / HDFS / Hive / Iceberg / Trino / Grafana を組み合わせることで、
ログの蓄積・集計・可視化 を行える状態になっています。
ここに LLM（大規模言語モデル）を組み合わせることで、
今後は 「自然文でログ分析する」 方向に発展させることができます。
たとえば以下のような問い合わせが可能になります。
- 「昨日の SSH 失敗が多いホストを出して」
- 「直近1時間で sudo 失敗が増えているサーバある？」
- 「Kafka Lag が増えた時間帯と authlog の異常を突き合わせて」
- 「worker2 の異常ログだけ要約して」
従来は SQL を直接書いて分析していたものを、
自然文 → SQL → 実行 → 要約 という流れに変換するイメージです。
目指す構成
今回の構想では、以下のような構成を想定しています。
各コンポーネントの役割
1. Open WebUI（チャットUI）
利用者が自然文で問い合わせるためのフロントエンドです。
例:
- 「昨日の authlog 失敗上位5ホスト」
- 「直近24時間の syslog 件数推移」
- 「sshd の失敗ログを20件だけ見せて」
この問い合わせをそのままバックエンドへ渡します。
2. LLM連携API（制御層）
ここが一番重要な部分です。
役割は以下です。
- ユーザーの質問を分類
- 質問に応じて SQL テンプレートを選択
- パラメータ（日付、host、program など）を埋め込む
- SQL を安全化する
- Trino へ実行
- 結果を LLM で要約して返す
つまり、LLM を直接 DB に触らせないための安全弁 です。
3. ローカルLLM(ollma)
ここでは LLM を以下の用途に使います。
- 自然文の意図解釈
- SQL生成補助
- 結果の日本語要約
- 異常傾向の説明
特に authlog や syslog には内部情報が多く含まれるため、
外部APIではなく ローカルLLM の方が相性が良いケースがあります。
4. Trino（既存）
既存の Iceberg / Hive テーブルを自然文問い合わせの検索先として使います。
Trino は対話型クエリに向いているため、
この用途ではかなり相性が良いです。
対象の主テーブルは以下です。
logs.syslog_iceberglogs.authlog_iceberg
必要に応じて curated / raw を参照する構成も可能です。
5. Kafka / HDFS / Iceberg（既存基盤）
既存のログ収集基盤はそのまま利用します。
つまり LLM は「新たな収集処理」を行うのではなく、
既に蓄積されたログを人間が扱いやすくするレイヤー として追加されます。
期待できること
自然文でログ検索できる
SQL を毎回手で書かなくても、
- 期間
- ログ種別
- 条件
- 集計粒度
を自然文で指定できるようになります。
一次障害解析を自動化できる
たとえば以下のような使い方ができます。
- 「昨日の夜に何が起きていた？」
- 「worker1 の異常傾向を要約して」
- 「Kafka Lag 増加と同時刻の authlog 異常を見たい」
このとき、単にログを返すだけでなく、
結果を要約して日本語で説明する ことができます。
アラートを人間向けに説明できる
Prometheus / Grafana のアラートをトリガーにして、
- 関連ログ抽出
- 直近の傾向分析
- 原因候補の要約
を自動で行えば、
単なる閾値アラートではなく、読めるアラート にできます。
まず実装するべき最小機能
いきなり何でも聞ける自由入力にすると危険なので、
最初は 対応パターンを限定 するのが現実的です。
1. 件数系
- 「昨日の authlog 件数」
- 「今日の syslog 件数」
2. 上位系
- 「昨日の SSH 失敗上位5ホスト」
- 「sudo 失敗が多いホスト」
3. 時系列系
- 「直近24時間の host別件数推移」
- 「1時間ごとの authlog 件数」
4. 抽出系
- 「sshd の失敗ログを20件」
- 「sudo failure を最新50件」
5. 異常傾向系
- 「昨日比で急増した host」
- 「普段より多い program」
安全のために必要な制限
自然文から SQL を作る以上、
LLM に好き勝手な SQL を打たせないこと が非常に重要です。
最低限、以下の制限は必要です。
-
SELECTのみ許可 -
INSERT / UPDATE / DELETE / DROP / ALTER / CALL禁止 -
LIMIT強制 - 対象テーブル限定
- 実行時間制限
- デフォルト期間を短くする（例: 直近1日）
- 最大取得件数制限（例: 200件）
また、Trino 側も read-only ユーザー にしておくのが望ましいです。
処理の流れ
実際の流れは以下のようになります。
実際の問い合わせイメージ
たとえばユーザーが以下のように質問したとします。
昨日の SSH 失敗が多いホストを出して
このとき内部では、たとえば以下のような SQL を生成するイメージです。
SELECT host, COUNT(*) AS cnt
FROM iceberg.logs.authlog_iceberg
WHERE dt = current_date - INTERVAL '1' DAY
AND (
msg LIKE '%Failed password%'
OR msg LIKE '%Invalid user%'
OR msg LIKE '%Connection closed by authenticating user%'
)
GROUP BY host
ORDER BY cnt DESC
LIMIT 10;
この結果をそのまま返すのではなく、
LLM が以下のように整形します。
- 失敗が多かったホスト
- 件数の偏り
- 時間帯の偏り
- 調査候補
といった説明に変換できます。
今後の拡張案
1. 手順書 / 障害メモのRAG化
過去の構築メモ、障害対応手順、Ansible メモなどを取り込むことで、
「過去の知見を引ける運用アシスタント」にできます。
例:
- 「Hive Metastore が上がらない時の確認手順」
- 「Pgpool failover の確認方法」
- 「Iceberg compaction の手順」
2. Grafana / Alertmanager 連携
アラート発報時に LLM が補足説明をつける構成も考えられます。
例:
- 関連ログ抽出
- 発生時刻の傾向分析
- 影響範囲の要約
- 原因候補の提示
3. 定期サマリ
毎朝・毎時で以下のようなサマリを生成できます。
- 前日の authlog 失敗傾向
- syslog 件数の急増ホスト
- Kafka Lag とログ異常の相関
まとめ
今回構築してきたログ分析基盤は、
単なる「蓄積・可視化」だけでなく、
LLM と組み合わせることで自然文分析基盤へ拡張できる 土台になっています。
最初の実装としては、
- Open WebUI
- LLM連携API
- Trino（read only）
- Iceberg テーブル
をつなぐだけでも十分価値があります。
特に以下のような用途に向いています。
- 自然文ログ検索
- 一次障害解析
- 異常傾向の要約
- アラートの説明強化
まずは 件数系 / 上位系 / 抽出系 の限定機能から始めて、
徐々に RAG やアラート連携へ広げていくのが現実的です。
構築手順
ここまで構築した内容について以下にまとめています。
興味があればぜひ挑戦してみてください。