はじめに

前回の記事で構築した 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_iceberg
logs.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 やアラート連携へ広げていくのが現実的です。

構築手順

ここまで構築した内容について以下にまとめています。
興味があればぜひ挑戦してみてください。