Nginx + Haproxy + Thin + Rails-503 ServiceUnavailable-
これをトラブルシューティングする方法がわかりません。 6つのThinサーバー（127.0.0.1：127.0.0.1： 3000 .. 3005）。/blogのような静的ファイルは現在問題ありません。フォールダウンは次のとおりです。ポート80のnginx-3100および3200のhaproxy-3000 .. 3005のthin、次にRails。ここに/etc/nginx/nginx.confがあります：
user nginx;
worker_processes 2;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
sendfile on;
tcp_nopush on;
keepalive_timeout 65;
tcp_nodelay on;
include /etc/nginx/conf.d/*.conf;
}
次に/etc/nginx/conf.d/default.conf
upstream fast_thin {
server 127.0.0.1:3100;
}
upstream slow_thin {
server 127.0.0.1:3200;
}
server {
listen 80;
server_name www.gitwatcher.com;
rewrite ^/(.*) http://gitwatcher.com/$1 permanent;
}
server {
listen 80;
server_name gitwatcher.com;
access_log /var/www/gitwatcher/log/access.log;
error_log /var/www/gitwatcher/log/error.log;
root /var/www/gitwatcher/public;
# index index.html;
location /about {
proxy_pass http://fast_thin;
break;
}
location /trends {
proxy_pass http://slow_thin;
break;
}
location /categories {
proxy_pass http://slow_thin;
break;
}
location /signout {
proxy_pass http://slow_thin;
break;
}
location /auth/github {
proxy_pass http://slow_thin;
break;
}
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_Host;
proxy_redirect off;
if (-f $request_filename/index.html) {
rewrite (.*) $1/index.html break;
}
if (-f $request_filename.html) {
rewrite (.*) $1.html break;
}
if (!-f $request_filename) {
proxy_pass http://slow_thin;
break;
}
}
}
次に、haproxy構成ファイル/etc/haproxy/haproxy.cfg：
global
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
#log loghost local0 info
maxconn 4096
#chroot /usr/share/haproxy
user haproxy
group haproxy
daemon
#debug
#quiet
nbproc 1 # number of processing cores
defaults
log global
retries 3
maxconn 2000
contimeout 5000
mode http
clitimeout 60000 # maximum inactivity time on the client side
srvtimeout 30000 # maximum inactivity time on the server side
timeout connect 4000 # maximum time to wait for a connection attempt to a server to succeed
option httplog
option dontlognull
option redispatch
option httpclose # disable keepalive (HAProxy does not yet support the HTTP keep-alive mode)
option abortonclose # enable early dropping of aborted requests from pending queue
option httpchk # enable HTTP protocol to check on servers health
option forwardfor # enable insert of X-Forwarded-For headers
balance roundrobin # each server is used in turns, according to assigned weight
stats enable # enable web-stats at /haproxy?stats
stats auth haproxy:pr0xystats # force HTTP Auth to view stats
stats refresh 5s # refresh rate of stats page
listen Rails_proxy 127.0.0.1:3100
# - equal weights on all servers
# - maxconn will queue requests at HAProxy if limit is reached
# - minconn dynamically scales the connection concurrency (bound my maxconn) depending on size of HAProxy queue
# - check health every 20000 microseconds
server web1 127.0.0.1:3000 weight 1 minconn 3 maxconn 6 check inter 20000
server web1 127.0.0.1:3001 weight 1 minconn 3 maxconn 6 check inter 20000
server web1 127.0.0.1:3002 weight 1 minconn 3 maxconn 6 check inter 20000
listen slow_proxy 127.0.0.1:3200
# cluster for slow requests, lower the queues, check less frequently
server slow1 127.0.0.1:3003 weight 1 minconn 1 maxconn 3 check inter 40000
server slow2 127.0.0.1:3004 weight 1 minconn 1 maxconn 3 check inter 40000
server slow3 127.0.0.1:3005 weight 1 minconn 1 maxconn 3 check inter 40000
およびThin構成ファイル/etc/thin/gitwatcher.yml：
---
chdir: /var/www/gitwatcher
environment: production
address: 0.0.0.0
port: 3000
timeout: 300
log: log/thin.log
pid: tmp/pids/thin.pid
max_conns: 1024
max_persistent_conns: 100
require: []
wait: 30
servers: 3
daemonize: true
開いているリッスンポートを調べると、次のようになります。
root@fullness:/var/www/gitwatcher# lsof | grep TCP | egrep "nginx|haproxy|thin"
nginx 834 root 8u IPv4 921 0t0 TCP *:http (LISTEN)
nginx 835 nginx 8u IPv4 921 0t0 TCP *:http (LISTEN)
nginx 837 nginx 8u IPv4 921 0t0 TCP *:http (LISTEN)
haproxy 1908 haproxy 4u IPv4 11699 0t0 TCP localhost:3100 (LISTEN)
haproxy 1908 haproxy 6u IPv4 11701 0t0 TCP localhost:3200 (LISTEN)
root@fullness:/var/www/gitwatcher#
iptables -Lは私に次のことを教えてくれます：
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:22222
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT all -- anywhere anywhere
DROP all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
何か助けはありますか？
更新：提案された方法でトラブルシューティングを試みても、「接続できませんでした」というエラーが表示されるだけなので、役に立ちません。
root@fullness:/var/www/gitwatcher/log# ps -ef | grep thin
root 3740 1 4 15:20 ? 00:00:19 thin server (0.0.0.0:3000)
root 3809 1 5 15:20 ? 00:00:22 thin server (0.0.0.0:3001)
root 3834 1 6 15:20 ? 00:00:26 thin server (0.0.0.0:3002)
root 4166 2274 2 15:27 pts/1 00:00:00 grep --color=auto thin
root@fullness:/var/www/gitwatcher/log# curl http://localhost:3000/trends
curl: (7) couldn't connect to Host
root@fullness:/var/www/gitwatcher/log# curl http://localhost:3001/trends
curl: (7) couldn't connect to Host
root@fullness:/var/www/gitwatcher/log# curl http://localhost:3002/trends
curl: (7) couldn't connect to Host
root@fullness:/var/www/gitwatcher/log#
更新：
root@fullness:/var/www/gitwatcher# netstat -a | egrep "3000|3001|3002"
tcp 0 0 *:3000 *:* LISTEN
tcp 0 0 *:3001 *:* LISTEN
tcp 0 0 *:3002 *:* LISTEN
root@fullness:/var/www/gitwatcher#
アップストリームで503を診断しようとしている場合は、次のいずれかを実行します。
ローカルボックスで、curlを使用して、アップストリームの1つで有効なURLを直接要求し、そこで結果を確認します。
curl http://localhost:3000/example
これができない場合は、構成を一時的に更新して、アップストリームが外部IPをリッスンし、ブラウザーでIP：ポートにアクセスするようにします。
次に、リクエストのログを確認します。これにより、サーバーエラーが存在する場所を特定できます。