[ROLE:SRE_DEV_OPS_ENGINEER] [TECH:GNU_AWK,JQ,SHELL_STRICT_MODE] [CONTEXT:LOG_ANALYSIS_AUTOMATION] [METHOD:RS_GETLINE_PATTERN_EXTRACTION]
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
awkによる複数行ログの高度な解析：RSとgetlineを用いたスタックトレース整形自動化
【導入と前提】 JavaやPythonのスタックトレース等の複数行に渡るログを、RS(レコードセパレータ)操作で1イベントとして正確に捕捉・整形します。
- 実行環境：GNU/Linux (bash, gawk 4.x+, jq 1.6+)
【処理フローと設計】
graph TD
A["非構造化ログ/スタックトレース"] --> B{"awk: RS/FSの再定義"}
B --> C["1レコードとしての読み込み"]
C --> D["getlineによる条件付抽出"]
D --> E["jqによるJSON構造化"]
E --> F["分析基盤/標準出力へ"]
awkにおいてデフォルトで改行となっているRS（Record Separator）を、「空行」や「特定のパターン（日付など）」に変更することで、複数行にまたがるログを単一のエンティティとして処理可能にします。
【実装：堅牢な自動化スクリプト】
#!/bin/bash
# ==============================================================================
# Script: log_summarizer.sh
# Description: RSとgetlineを駆使し、複数行スタックトレースを抽出しJSON化する
# ==============================================================================
set -euo pipefail
# -e: エラー発生時に即座に終了
# -u: 未定義変数の参照時にエラー
# -o pipefail: パイプライン途中のエラーも検知
# 作業用一時ディレクトリの作成
TMP_DIR=$(mktemp -d)
trap 'rm -rf "$TMP_DIR"' EXIT # 終了時に確実に削除
readonly LOG_FILE="${1:-/var/log/application.log}"
readonly OUTPUT_JSON="formatted_logs.json"
if [[ ! -f "$LOG_FILE" ]]; then
echo "Error: File $LOG_FILE not found." >&2
exit 1
fi
echo "Processing $LOG_FILE..."
# awkによる複数行抽出処理
# RS="^20[0-9]{2}": 20XXで始まる行をレコードの区切りとする (gawk特有の正規表現RS)
# getlineで特定のキーワード(Error)を含む行を探索
gawk '
BEGIN {
RS = "(^|\n)20[0-9]{2}-[0-9]{2}-[0-9]{2}" # 日付でレコードを分割
ORS = ""
}
{
# レコード内に "ERROR" または "Exception" が含まれるか確認
if ($0 ~ /ERROR/ || $0 ~ /Exception/) {
# 整形処理: 連続する空白を1つにし、改行をリテラルとして扱う
content = $0
gsub(/\n/, " ", content)
gsub(/"/, "\\\"", content)
# タイムスタンプの抽出（レコードの先頭部分を再利用）
# RTはgawkがマッチしたセパレータを保持する変数
print content "\n"
}
}
' "$LOG_FILE" | \
jq -R -s '
split("\n") |
map(select(length > 0)) |
map({
severity: (if . | contains("ERROR") then "ERROR" else "INFO" end),
message: .
})
' > "$OUTPUT_JSON"
echo "Process completed. Output saved to $OUTPUT_JSON"
【検証と運用】
正常系の確認 スクリプトを実行し、生成されたJSONが正しいか確認します。
cat formatted_logs.json | jq '.[0]'
ログ監視との連携 systemdのタイマー機能で定期実行する場合のユニットファイル例：
[Unit] Description=Log Aggregator Timer [Timer] OnCalendar=hourly Persistent=true [Install] WantedBy=timers.target
journalctlでの確認 スクリプトの標準エラー出力はjournalctlで追跡可能です。
journalctl -u log-aggregator.service
【トラブルシューティングと落とし穴】
メモリ消費の増大:
RSを空行や大きなパターンに設定すると、1レコードが数MBになる可能性があります。awkのバッファ上限に注意が必要です。正規表現の互換性: 上記の
RSに正規表現を使う手法はgawk(GNU awk) 特有です。ポータブルなmawk等では動作が異なるため、RS="\n\n"（空行区切り）などの代替案を検討してください。ファイルロック: 書き込み中のログファイルを読み込む際、不完全なレコードが生成される可能性があります。運用上は
logrotate後のファイルを対象にするのが安全です。権限の最小化:
/var/log以下の読み取りには通常sudoが必要ですが、スクリプト自体をrootで動かすのではなく、特定のログ読み取りグループに属するユーザーで実行することを推奨します。
【まとめ】
運用の冪等性を維持するための3つのポイント：
入力の不変性: 元のログファイルを変更せず、フィルタ結果のみを別ファイルに出力する。
原子的な書き出し:
jq等で一時ファイルに書き出してからmvで置換し、中途半端な状態のファイルを作らない。環境の独立性:
set -euo pipefailとgawkのバージョンチェックを冒頭に入れ、予期せぬ挙動を未然に防ぐ。
