ログ・監視分析
GB 級ログから目的のハリを見つける——異常検知は目視では無理
ログ分析の痛み、やった人にしかわからない
ログが多すぎて読めない、トラブルが起きたら全部推測頼み
サーバーは 1 日で何 GB もログを生成する、目で見れって言う？重要な 500 エラーが数百万行の正常リクエストに埋もれちゃって、30 分掘ってても問題の行が見つからない。
さらにひどいのは：多くの問題は事後に発見される。ユーザーからクレームが来て、上司に言われて、やっとログを開く。その時点で手遅れ——本番環境が 2 時間も落ちてた。もし何か常に監視できるものがあれば、さっさと防げたのに。
OpenClaw：ログを読む、パターンを見つける、異常を捕まえる、一貫して
ログファイルを OpenClaw に放り込むと、ローカルでスクリプトを実行して分析してくれる。サードパーティのプラットフォームにアップロードしなくていいから、センシティブなログは漏れない。
できることはいろいろ：GB 級のログから異常パターンを抽出、高頻度エラーを判別、時間帯別のエラー率の変動をグラフ化、さらに監視アラートルールまで書いてくれる。昔なら ELK スタックを構築してやってた作業が、今や 1 つのプロンプトで起動する。
ログ分析 Prompt 3 本、そのまま使える
異常検知からビジュアル化から根因特定まで、運用の必須アイテム。
Nginx ログ異常検知：高頻度 IP + 異常ステータスコード
ゴールデンコマンド
~/logs/nginx_access.log を分析（約 500 万行）、以下をしてほしい：
1. 各 IP のリクエスト数をカウントして、トップ 20 の高頻度 IP を見つける
2. 異常行動をマーク：単一 IP が 1 分間に 100 回以上リクエストする期間
3. ステータスコード別にグループ化、全ての 4xx と 5xx の数と割合を列記
4. 連続で 5xx が出てる期間を見つける（サーバーダウンのサイン）
5. 異常報告を出力、疑わしい IP リストとブロック提案付き
ログフォーマットは標準的な combined format ね。これは運用が最もよくやるシーン。昔のやり方は awk + sort + uniq でコマンドを一行ずつ組み立てる、抜けやすい。AI に完全な分析スクリプトを書かせれば、カバー面が広くて、気づかなかった異常パターンも見つかる。Opus モデルを使うことをすすめるよ、分析ロジックが厳密だから。
エラー率ビジュアル化：時間別にカウントしてグラフ化
上級テク
~/logs/ ディレクトリの過去 7 日間のアプリログ（app-2025-03-*.log）を読み込んで、以下をしてほしい：
1. 各行のタイムスタンプとログレベル（INFO/WARN/ERROR/FATAL）をパース
2. 時間別に各レベルのログ数をカウント
3. 各時間のエラー率（ERROR+FATAL / 合計）を計算
4. matplotlib で 7 日間のエラー率トレンドグラフを描く、5% 超える時間をマーク
5. グラフは error_trend.png で保存、データは error_stats.csv で保存
ログフォーマット：[2025-03-14 08:23:15] ERROR: xxxビジュアル化は問題発見の最強の武器。数字を目で見るだけではトレンドが分かりにくいけど、グラフにすれば一目で、どの時間帯に問題が出たかすぐわかる。こういうスクリプトは一度書いたら何度も使い回せるから、簡易的な監視ダッシュボードみたいに使える。
エラーログ根因特定：エラーを見て原因を探す
ビギナー向け
以下はうちのアプリが直近 1 時間に出したエラーログ（下に貼り付け）、以下をしてほしい：
1. エラーをタイプ別に分類（データベース接続、タイムアウト、ヌルポ、権限など）
2. 最頻度なエラータイプと出現回数を見つける
3. エラー同士に関連があるか分析（例：データベース接続失敗が後続リクエストを全部引っ張り倒す）
4. 最有力な根本原因と調査提案を出す
[あなたのエラーログを貼り付け]ビギナー最適な使い方：トラブルが出ても原因がわからなくて、エラーログをぺたっと貼り付ければ、AI が分類整理して、原因の連鎖を見つけてくれる。一画面の stack trace を前に呆然とするより、遥かにマシ。
ログ分析：OpenClaw vs ELK Stack
一つはタダで即使える、もう一つは重厚長大インフラ。シーン次第で選ぼう。
OpenClaw
- デプロイ不要、Elasticsearch・Logstash・Kibana をインストール不要
- ローカル分析だから、ログのアップロード不要、セキュリティ問題ゼロ
- 自然言語で要件を言えば OK、KQL クエリ言語を勉強不要
- 柔軟性が高い：分析のやり方は自由自在、プリセットダッシュボードの制約なし
- 一時的なトラブル対応、ワンショット分析、中小チーム向け
VS
ELK Stack
- 3 つのコンポーネントをデプロイする必要がある、セットアップだけで半日～1 日かかる
- Elasticsearch はメモリ食い、最低 4GB は必要
- 継続監視向きだけど、初期投資コストが高い
- クエリ言語に学習曲線がある、Kibana ダッシュボードの設定も手間
- 大規模本番環境の標準装備だけど、小さいチームにはオーバーキル
リアルシーン
運用エンジニア：真夜中の値番でトラブル対応
真夜中の 3 時にアラート通知、本番サービスの応答が遅い、エラー率が爆上がり。寝ぼけまなこでパソコン開く、何 GB ものログを前に途方に暮れる。
OpenClaw 方案
直近 1 時間のログを OpenClaw に放り込む：「この期間の異常パターンを見つけて、エラーの根因を特定してよ」。2 分で結果が出る：データベース接続プール満杯、後続のクエリが全部タイムアウト。修復提案も、一時的な対症療法もくれる。ローカルで実行だから、本番ログをどこにもアップロードしなくて OK。
全手動プラン
grep ERROR で一杯翻す、エラーが何百件も、どれが原因でどれが結果なのか不明。行ったり来たり 40 分掘ってやっと問題チェーンを推測できた。上司からもう 3 本の催促電話が来た。
ログ分析の実用テク
ログファイルがでかすぎ？プロンプトで「直近 1 時間のログだけ分析してね」か「tail -n 10000 で最後の 1 万行だけ抽出して」と言う、スコープを絞って詳しく分析、効率アップ。
AI に分析スクリプトを保存させる。次のトラブルはスクリプト直実行、プロンプト不要。自分専用の運用ツールボックスができる感じ。
ログ分析時はタイムゾーン問題に気をつけて。サーバーログは UTC かもしれないけど、アラートに見えるのは地元時間。プロンプトでタイムゾーン明記、時間のズレを避けよう。