webアプリケーションの異常時の問題の切り分け
通信処理の流れ
以下のように通信処理は流れる
ブラウザ
プロキシ
DNS
Webサーバ
APサーバ
App
DB
この流れの中で問題が発生している場所を特定することが重要(切り分け)
外側から内側に向かって順番に確認する
1. ブラウザ → サーバ間
curlのレスポンスヘッダでどのレイヤーが返しているか
curl使い方
アクセス処理を順に確認してどこまで処理が進んでいるか
レスポンスヘッダの内容からどこまで処理が到達しているか判断する
2. ブラウザ → Webサーバ間
ブラウザでのアクセス時にWebサーバのログが出力されるか
ログ出力有り: Webサーバまで処理が到達できている → Webサーバ以降に問題がある
ログ出力無し: Webサーバまで処理が到達できていない → Webサーバ以前に問題がある
nginx: /var/log/nginx/access.log
Apache: /etc/httpd/logs/access.log
3. ブラウザ → APサーバ間
ブラウザでのアクセス時にAPサーバ(mongrel、unicorn、Puma等)のログが出力されるか
ログ出力有り: APサーバまで到達できている → APサーバ以降に問題がある
ログ出力無し: APサーバまで到達できていない → APサーバ以前に問題がある
Puma: log/puma.log
mongrel: log/mongrel.300*.log
unicorn: log/unicorn.log
4. ブラウザ → App間
ブラウザでのアクセス時のログ、処理の動きを確認する
production.log等のアプリケーションのログでエラーが無いか確認
可能ならデバッグログで確認
Rails: log/production.log
5. DB
以下の3つをログから確認する
接続可否
クエリが遅い/タイムアウト
データの有無
DBに直接接続して確認(psql等)
PostgreSQL: /var/log/postgresql/postgresql-*.log
MySQL: /var/log/mysql/error.log
調査時の注意点
ブラウザからのアクセス時に意図しないプロキシ(ifilter等)が挟まっている場合はIPやアクセス処理に影響が出る可能性がある → 極力offにして検証する
APサーバとAppのログが別々に存在する/しない場合がある
mongrel: AP、Appが同じログ
Puma+Rails: AP、Appが別ファイル
外側から内側に向かって調査することで無駄な調査が不要になる
Appのソースコードの調査が一番時間が掛かる
ログのディレクト入りはデフォルトから変更されている場合もあるので以下も確認すると確実
Rails: config/environments/production.rb
nginx: /etc/nginx/nginx.conf
Apache: /etc/httpd/conf/httpd.conf の CustomLog を確認