[META] STYLE: SRE_ENGINEER_TECHNICAL_DRAFT FOCUS: SHELL_AUTOMATION_ERROR_HANDLING TOOLS: CURL, JQ, SYSTEMD, BASH [/META]
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
REST API 監視の堅牢化：curl と jq による高度な自動検証スクリプトの構築
【導入と前提】
マイクロサービスのヘルスチェックとデータ整合性検証を自動化し、異常検知時の即時復旧を支える堅牢なシェルスクリプトの構築手法を解説します。
前提環境: GNU/Linux (Ubuntu 22.04+ / RHEL 9+),
curl7.70+,jq1.6+対象: APIの死活監視および特定フィールドの値に基づく条件分岐が必要な運用環境。
【処理フローと設計】
graph TD
A["Start: Script Execution"] --> B["Environment Check"]
B --> C["HTTP Request: curl"]
C --> D{"HTTP Status Code"}
D -->|200 OK| E["JSON Validation: jq"]
D -->|Error/Timeout| H["Error Handler: Trap/Log"]
E --> F{"Logic: Expected Value?"}
F -->|Match| G["Success: Output Result"]
F -->|Mismatch| H
G --> I["Cleanup: Remove Temp Files"]
H --> I
I --> J[End]
このフローでは、単なる接続確認に留まらず、レスポンスボディに含まれる特定のJSONフィールドが期待値（例：status: "UP" や version）を満たしているかを厳密に検証します。
【実装：堅牢な自動化スクリプト】
#!/usr/bin/env bash
# ==============================================================================
# API Validation Script
# 堅牢なシェル記述（set -euo pipefail）により、途中のエラーで停止させ、
# 不正な状態で後続処理が実行されるのを防ぐ。
# ==============================================================================
set -euo pipefail
IFS=$'\n\t'
# 設定
API_URL="${API_URL:-https://api.example.com/v1/health}"
EXPECTED_STATUS="UP"
TIMEOUT_SEC=10
TMP_RESPONSE=$(mktemp)
# クリーンアップ処理の定義
# 異常終了時でも一時ファイルを確実に削除する
cleanup() {
rm -f "$TMP_RESPONSE"
}
trap cleanup EXIT
echo "Starting API validation for: $API_URL"
# APIリクエストの実行
# -s: 進捗非表示, -S: エラー表示, -f: 4xx/5xxで失敗, -L: リダイレクト追従, --retry: 失敗時の再試行
RESPONSE_CODE=$(curl -s -S -L -f \
--max-time "$TIMEOUT_SEC" \
--retry 3 \
--retry-delay 2 \
--write-out "%{http_code}" \
-o "$TMP_RESPONSE" \
"$API_URL")
# ステータスコードの検証（curl -f で既に2xx以外はエラーになるが、念のため）
if [[ "$RESPONSE_CODE" -ne 200 ]]; then
echo "Error: API returned HTTP $RESPONSE_CODE" >&2
exit 1
fi
# jqを用いたJSON検証
# -e: 抽出結果がnullまたはfalseの場合に終了ステータス1を返す
# -r: クォートなしの生出力
ACTUAL_STATUS=$(jq -e -r '.status' "$TMP_RESPONSE")
if [[ "$ACTUAL_STATUS" != "$EXPECTED_STATUS" ]]; then
echo "Validation Failed: Expected $EXPECTED_STATUS but got $ACTUAL_STATUS" >&2
# エラー詳細をログ出力
jq '.' "$TMP_RESPONSE" >&2
exit 1
fi
echo "Success: API is $ACTUAL_STATUS"
補足：Systemdによる定期実行（Timer）
Cronの代替として、実行履歴が journalctl で管理しやすい systemd timer の利用を推奨します。
# /etc/systemd/system/api-health-check.service [Unit] Description=API Health Check Job [Service] Type=oneshot ExecStart=/usr/local/bin/api-check.sh User=monitor-user # 環境変数の漏洩防止 EnvironmentFile=/etc/default/api-check-env
【検証と運用】
正常系の確認
スクリプトを実行し、終了ステータス $? が 0 であることを確認します。
./api-check.sh echo $? # 0が表示されれば成功
エラー時のログ確認
systemd を利用している場合、以下のコマンドでエラーログの履歴を詳細に追跡可能です。
# 失敗した直近のログを抽出 journalctl -u api-health-check.service -n 50 --no-pager
【トラブルシューティングと落とし穴】
jqのバージョン差異:
jq -eオプションは古いバージョンでは挙動が異なる場合があります。環境導入前にjq --versionで 1.6 以上であることを確認してください。一時ファイルの権限:
mktempで作成されるファイルは実行ユーザーのみ読み書き可能ですが、umask設定が緩い環境では注意が必要です。環境変数の秘匿: APIキーをスクリプト内にハードコードせず、
EnvironmentFile（systemd）や CI/CD の Secret 変数から注入してください。
【まとめ】
運用の冪等性と堅牢性を維持するための3つの重要ポイント：
Fail-Fast設計:
set -euo pipefailを用い、予期せぬエラーが発生した瞬間に処理を停止させる。リソースの自動クリーンアップ:
trapコマンドで一時ファイルやロックファイルを確実に処理する。詳細な診断情報の出力: 失敗時には
jqを活用してレスポンスボディ全体を標準エラー出力(stderr)へ流し、デバッグを容易にする。
