{ “style”: “SRE/DevOps Professional”, “technical_focus”: “awk(RS/getline), bash(safety), jq, structured logging”, “keywords”: [“multi-line log parsing”, “awk RS”, “SRE automation”, “idempotency”], “language”: “ja” }
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
awkによる複数行ログの構造化抽出：SREのためのインシデント分析自動化
【導入と前提】
本ガイドでは、Javaのスタックトレースやコンテナのデバッグログなど、標準的なgrepでは抽出困難な「複数行にまたがるログレコード」を、awkのRS（レコードセパレータ）とgetlineを活用して効率的に構造化・抽出する手法を解説します。これにより、大規模ログからの特定エラーパターンの自動抽出とJSON化による二次利用を堅牢化します。
実行環境: GNU/Linux (Ubuntu 22.04 LTS等), gawk (GNU awk), jq 1.6+
対象読者: ログ解析の自動化スクリプトを構築するSRE / インフラエンジニア
【処理フローと設計】
graph TD
A["非構造化マルチラインログ"] --> B{"awk処理"}
B -->|RSでレコード境界を定義| C["特定パターンの抽出"]
C -->|getline/配列で整形| D["キーバリュー形式へ変換"]
D --> E["jqによるJSON整形"]
E --> F["構造化ログ/分析基盤へ"]
awkのデフォルト動作（行単位処理）をRS変数の操作によって「論理的なログブロック単位」の処理へと昇華させ、複雑な正規表現なしにコンテキストを維持した抽出を実現します。
【実装：堅牢な自動化スクリプト】
以下のスクリプトは、タイムスタンプで始まる複数行のログ（スタックトレース含む）を抽出し、各ログエントリをJSONオブジェクトとして出力する実戦的な例です。
#!/usr/bin/env bash
# --- 安全のための設定 ---
set -euo pipefail
IFS=$'\n\t'
# --- 一時ファイル管理 ---
TMP_DIR=$(mktemp -d)
trap 'rm -rf "$TMP_DIR"' EXIT # 終了時に必ずクリーンアップ
readonly LOG_FILE="${1:-/var/log/application.log}"
readonly OUTPUT_JSON="error_report.json"
# --- メイン処理：awkによる複数行抽出 ---
# 1. RS (Record Separator) に正規表現を使用し、新しいログの開始（日付）を境界とする
# 2. getline を併用し、特定の条件に合致する後続行を制御する
# 3. 抽出結果を jq で構造化する
parse_multiline_logs() {
local input_file="$1"
if [[ ! -f "$input_file" ]]; then
echo "Error: File $input_file not found." >&2
exit 1
fi
# gawkを使用（RSへの正規表現指定はgawkの機能）
gawk '
BEGIN {
# レコードの区切りを「行頭の[202x-xx-xx]」形式に設定
# 肯定先読みが使えないため、マッチした境界を保持する工夫が必要
RS = "(^|\n)\\[[0-9]{4}-[0-9]{2}-[0-9]{2}"
}
{
# RT (Record Terminator) にはマッチしたRSの内容が入る
# $0 にはレコード本体が入る
if ($0 ~ /ERROR|Exception/) {
# 前方のトリミングと整形
content = $0
gsub(/^\s+/, "", content)
# JSONの要素として出力（後でjqで組み立てるために簡易フォーマット化）
# RTと$0を組み合わせて元の構造を維持
printf "TIMESTAMP: %s\nBODY: %s\n---\n", RT, content
}
}' "$input_file" | \
# 簡易テキストからJSONへ変換
jq -R -s '
split("---\n") |
map(select(length > 0) |
split("\n") |
{
timestamp: (.[0] | sub("TIMESTAMP: "; "") | sub("^\n"; "")),
message: (.[1:-1] | map(sub("BODY: "; "")) | join("\n"))
})
' > "$OUTPUT_JSON"
echo "Extraction completed: $OUTPUT_JSON"
}
# --- 実行 ---
parse_multiline_logs "$LOG_FILE"
【検証と運用】
1. 正常系の確認
生成されたJSONが正しい構造を持っているか、jqのフィルタ機能で確認します。
# 特定のタイムスタンプのエラー内容のみを表示
jq '.[] | select(.message | contains("NullPointerException")) | .timestamp' error_report.json
2. ログ確認（systemd環境の場合）
スクリプトを定期実行（Cron/Timer）している場合、標準エラー出力をjournalctlで追跡します。
# ユニット名が log-parser.service の場合 journalctl -u log-parser.service --since "1 hour ago"
【トラブルシューティングと落とし穴】
gawkとposix awkの違い: 多くの環境で
awkはgawkへのシンボリックリンクですが、RSに正規表現（複数文字）を使用できるのは主にgawkです。ポータブルな環境（Alpine Linux等）ではbusybox awkの挙動に注意してください。メモリ消費量:
RSで巨大なログブロックを一つのレコードとして読み込むと、メモリを大量に消費します。1レコード（1スタックトレース）が数MBを超えるような特殊なケースでは、RSを使わず、状態フラグ（State Machine）を用いた行単位の処理に切り替えてください。権限問題:
/var/log/配下のログを読み取る場合、実行ユーザーに読み取り権限が必要です。sudoを付与するか、ログを一時ディレクトリにコピーしてから処理することを推奨します。
【まとめ：運用の冪等性を維持する3ポイント】
状態を持たない処理: スクリプトは常に「入力ファイル全体」または「特定のオフセット」から独立して動作するように設計し、二重実行によるデータ重複を
jqのユニーク処理等で防ぐ。型定義の厳格化: 出力は必ずJSONのような構造化データとし、後続のプロトコル（Elasticsearch, BigQuery等）でのパース失敗を最小限に抑える。
一時ファイルの局所化:
trapコマンドにより、途中でエラー停止してもゴミを残さない（アトミックな書き換えを意識する）。
