失敗は、見た層のログにしか残らない — アプリ・nginx・外からの3か所で数える

環境は nginx 1.30.4(nginx:1.30.4-alpine)、Python 3.14.7(python:3.14-slim、http.server.ThreadingHTTPServer)、curl 8.16.0(curlimages/curl:8.16.0)、Docker Engine 28.4.0(Docker Desktop、aarch64)、2026-09-28 です。nginx は upstream にアプリ1台を置き、proxy_connect_timeout 2s と proxy_read_timeout 2s に縮めました(既定はどちらも 60s)。prober は 60 秒間、約1秒ごとに nginx へ GET を送ります。

その1分間に、10秒目からアプリのプロセスを10秒止め、30秒目からアプリを10秒間「応答前に5秒寝る」状態にし、45秒目から nginx を10秒止めました。良い = 5xx でも 000 でもない件数、として3つのログを数えた結果です。

window (prober start..end, UTC): 14:12:40 .. 14:13:40  (60s)
where        total  good  bad    avail  breakdown
prober(外)       52    28   24    53.8%  {'000': 10, '200': 28, '502': 10, '504': 4}
nginx           42    28   14    66.7%  {'200': 28, '502': 10, '504': 4}
app             32    32    0   100.0%  {'200': 32}

件数はつながっています。prober 52 = nginx 42 + nginx 停止中の 000 が10。nginx 42 = アプリ 32 + アプリ停止中の 502 が10。アプリの 32 は nginx の 200(28)に、nginx が 504 と書いた4件を足した数です。同じ手順の再実行(r3)でも nginx 66.7%・アプリ 100.0% で、prober は 51 件中 28 件の 54.9% でした。

1分間の外で、1回ずつ2つの壊し方も試しました。まとめると、1つの要求に3つの判定が付きます。

壊し方                          外(curl)      nginx の行                アプリの行
(a) アプリのプロセスを止める    502           502(接続拒否)            なし
(a') アプリのコンテナごと止める 504           504(接続タイムアウト)    なし
(b) アプリが5秒寝る             504           504(読み取りタイムアウト)200(約3秒後)
(c) nginx を止める              000(exit 7)   なし                      なし
(d) クライアントが1秒で打ち切る 000(exit 28)  499                       200(約4秒後)

(a') と (d) は1分間の外で各1回、prober とは別のクライアントコンテナから curl で送りました。「アプリを止めると 502」は止め方次第でした。接続を拒まれれば 502(error_log は connect() failed (111: Connection refused))、接続先が消えると 504 です。接続拒否で 502 になる理由も、読み取りタイムアウトで 504 になることも、nginx の文書には書かれていません(確認範囲: proxy・upstream モジュールの文書全文)。どちらもこの版での実測です。

(c) で nginx を止めた10秒間、prober は 000(curl の終了コード 7、Failed to connect to host.)を10件記録し、nginx とアプリのログは空でした。Workbook 第2章はロードバランサで数える例を選んだ理由を closer to the user’s experience than those from the application server’s logs と書き、付録A は同じ方式に may fail to accurately measure cases where user requests didn’t reach the load balancer と注意書きを付けています。(c) はその注意書きの実物です。

prober で数えても、000 を「応答が無いので判定できない」として分母から外すと、次のようになります。

数え方                          良い / 分母  可用性
prober(000 も悪いに数える)       28 / 52      53.8%
prober(000 を分母から外す)       28 / 42      66.7%
nginx                            28 / 42      66.7%
アプリ                           32 / 32     100.0%

外で数えているのに、nginx と同じ数になりました。nginx 停止の失敗は、どのサーバのログにも無いうえに、外の数字からも消えています。SRE Book 第4章も not measuring behavior at the client can miss a range of problems that affect users but don’t affect server-side metrics と書いています。ただし prober も全部を見るわけではなく、第15期で読んだとおり may miss issues that affect only a subset of users です。