{ “author”: “SRE_DevOps_Assistant”, “version”: “1.1.0”, “context”: “multi-line_log_processing_awk_rs_getline”, “safety_level”: “production_ready” }
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
awkによるスタックトレース等の複数行ログ解析とJSON構造化の自動化
【導入と前提】
アプリケーションのスタックトレース等、複数行にまたがる非構造化ログを特定パターンで集約・抽出し、後続の分析基盤へ渡すための構造化処理を自動化します。
OS: GNU/Linux (Ubuntu 22.04+, RHEL 8+)
Tools: GNU awk (gawk) 4.1+, jq 1.6+, bash 4.4+
【処理フローと設計】
graph TD
A["非構造化ログファイル"] --> B{"awkによるレコード分割"}
B -->|RS: レコードセパレータ| C["パターンマッチング/抽出"]
C -->|getline: 動的行読み込み| D["一時オブジェクト生成"]
D --> E["jqによるJSON整形"]
E --> F["構造化ログ出力/転送"]
awkの標準動作（1行1レコード）をRS（Record Separator）変数の定義によって変更し、論理的な1ブロック（エラー単位など）を一つのレコードとして扱います。
【実装：堅牢な自動化スクリプト】
以下のスクリプトは、タイムスタンプで始まる行を区切りとして、複数行のエラー内容を一つのJSONオブジェクトに変換する実戦的な例です。
#!/bin/bash
# set -e: エラー発生時に即座に終了
# -u: 未定義変数の参照をエラーとする
# -o pipefail: パイプライン途中のエラーを伝播させる
set -euo pipefail
# 一時ファイルのクリーンアップを保証
TMP_FILE=$(mktemp)
trap 'rm -f "$TMP_FILE"' EXIT
LOG_FILE="${1:-/var/log/app/error.log}"
if [[ ! -f "$LOG_FILE" ]]; then
echo "Error: Log file not found: $LOG_FILE" >&2
exit 1
fi
# awkによる複数行処理
# RS="^([0-9]{4}-[0-9]{2}-[0-9]{2})" : 日付形式をレコードの区切りに設定(GNU awk)
# getline : 条件に応じた動的な次行読み込み
awk '
BEGIN {
# レコード区切りを「行頭のタイムスタンプ」に設定（正規表現）
# ※gawk固有の動作: RSに複数文字/正規表現を許容
RS = "\n(?=[0-9]{4}-[0-9]{2}-[0-9]{2})";
OFS = ",";
}
{
# 現在のレコードからメッセージを抽出
msg = $0;
gsub(/\n/, " ", msg); # 改行をスペースに置換して1行化
sub(/^ +/, "", msg); # 先頭の余白削除
# 最初の行（ヘッダー）からタイムスタンプとレベルを抽出
if (match(msg, /^([0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}) ([A-Z]+)/, arr)) {
printf "{\"timestamp\":\"%s\",\"level\":\"%s\",\"message\":\"%s\"}\n", arr[1], arr[2], msg;
}
}' "$LOG_FILE" | \
jq -c '.' # 各行をコンパクトなJSONとして検証・出力
# システムユニットとしての実行例 (systemd)
# [Service]
# ExecStart=/usr/local/bin/log-processor.sh /path/to/app.log
# StandardOutput=append:/var/log/app/structured_error.json
【検証と運用】
正常系の確認
スクリプトを実行し、各スタックトレースが1つのJSONオブジェクトに収まっているかを確認します。
# JSON形式の正当性確認 ./log-processor.sh | jq -r '.message' | head -n 5 # journalctlでの実行ログ確認（systemd化している場合） journalctl -u log-processor.service -f
運用監視
レコードの分割に失敗した場合、awkのRS正規表現を見直す必要があります。特にログフォーマットが変更された際に注意が必要です。
【トラブルシューティングと落とし穴】
GNU awkの差異:
RSに正規表現を使用できるのはgawkです。一部の軽量ディストリビューション（Alpine等）のmawkやbusybox awkでは動作が異なるため、awk --versionで確認してください。getlineの戻り値: スクリプト内で
getlineを直接使う場合、ファイルの終端（EOF）で0、エラーで-1を返すため、while (getline > 0)のようなループ制御が必須です。メモリ消費: 非常に巨大な1レコード（巨大なダンプログ等）が流れてきた場合、
RSでメモリに読み込む際にバッファオーバーフローが発生する可能性があります。その場合は、getlineを使い、条件一致するまでバッファをフラッシュする逐次処理を検討してください。
【まとめ】
運用の冪等性と堅牢性を維持するためのポイント：
区切り文字の厳密化:
RSにはログの開始パターン（Timestamp等）を正規表現で厳密に指定する。パイプラインの安全確保:
set -o pipefailを使用し、awkやjqの失敗を無視せず検知する。後続処理への配慮: 抽出した複数行データは、必ず
jq等でJSONエスケープ処理を行い、ログ基盤のパースエラーを防止する。
