この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。curl公式マニュアルとjq公式マニュアルを確認し、旧版の監視スクリプトを失敗原因ごとに切り分ける構成へ見直しました。検証ステータス：📘 curl・jq公式情報確認済み／実APIでの監視運用は未検証
APIヘルスチェックでは「curlが終わった」だけでは不十分です。少なくとも、通信・HTTP・JSON・業務値を別々に判定します。
4層で確認する
| 層 | 失敗例 |
|---|---|
| 通信 | DNS、接続、TLS、タイムアウト |
| HTTP | 4xx、5xx |
| JSON | 壊れたJSON、想定外の型 |
| 業務値 | statusがokでない、version不一致 |
HTTPエラー時も本文を調べたいなら
curlの --fail-with-body はHTTP 400以上でエラーを返しつつ、レスポンス本文を保持できます。単純な --fail より障害解析に使いやすい場面があります。
jqは終了コードも使う
jq -e '.status == "ok" and (.version | type == "string")' response.json-e を使うとフィルタ結果に応じた終了コードを利用でき、シェル側で成功・失敗を判定しやすくなります。
リトライは慎重に
curlにはリトライ機能がありますが、すべてのエラーを無条件に再試行する設定は、操作によっては重複送信につながります。ヘルスチェックのような読み取り処理でも、対象APIとHTTPメソッドを確認して使います。
まとめ
API監視は、通信、HTTP、JSON、値検証を分けると原因を特定しやすくなります。失敗時に何層で止まったかを終了コードとログへ残すことが重要です。
公式情報・一次情報
この記事の更新履歴
- 2026-09-13 追加：通信・HTTP・JSON・業務値の4層、–fail-with-body、jq -eを追加。
- 2026-09-13 変更：単一スクリプト例中心から失敗原因の切り分け中心へ変更。
- 2026-09-13 削除：内部メタ情報、本文H1、リトライを一律推奨する表現を削除。
