HTTP ve Ters Proksiler

Neden önemli

Kullanıcılar 502 Bad Gateway görür, proksi ekibi çağrılır; oysa proksi sağlıklıdır: arkasındaki bir şeyin düştüğünü sadakatle raporluyordur. Proksiyi yeniden başlatmakla geçen her dakika gerçek neden, 30 saniyelik zaman aşımından 40 saniyede yanıt veren uygulama, zaman aşımlarına devam eder. Proksi hataları tanık beyanıdır. Öyle oku ve yukarı yürü.

Kavramlar

HTTP üç teşhis hediyesi verir: yöntem, durum ve yol; üçü de varsayılan olarak loglanır. 5xx ailesi temiz ayrılır. 502 proksinin geçersiz yanıt aldığı demektir: bağlantı reddi, sıfırlama veya bozuk bayt; genelde dinleyen yok ya da uygulama yanıt ortasında öldü. 503 upstream'e ulaşılabiliyor ama kapasite yok demektir: kuyruk dolu, havuz tükenmiş veya açık bakım sinyali. 504 upstream'in proksi zaman aşımından uzun sürdüğü demektir: yaşıyor ama yavaş. Kullanıcıya görünen aynı kesinti, üç farklı ekip, üç farklı düzeltme. Durum kodu sevk pusulasıdır.

Ters proksi istemci bağlantısını sonlandırıp upstream'e kendisininkini açar; böylece iki bağımsız loglu iki bağımsız arıza alanı doğar. Proksi logu istemcinin ne gördüğünü ve upstream'in ne kadar sürdüğünü kaydeder; upstream logu uygulamanın ne yaptığını kaydeder. Zaman uyuşmazlığında (proksi 30.0 saniye loglamış, uygulama 41) fark teşhistir: çökme değil zaman aşımı. M01

1. dersin istediği gibi eşleşmiş zaman damgalarıyla ikisini de çek; uygulamanın

sağlıklılığını asla yalnızca proksi logundan ilan etme.

Konfigürasyon hataları üç yerde yaşar: hangi bloğun yanıtlayacağına karar veren listen ve server_name, upstream'i adlandıran proxy_pass ve proksinin ne kadar sabırlı olduğuna karar veren zaman aşımları ile tampon boyları. Yanlış porta giden proxy_pass, 2. dersin hayaletinin yeni giysisidir; uygulamanın en yavaş meşru yanıtının altına konmuş upstream zaman aşımları yılın en yoğun gününde 504 üretir. Sürüm kontroldeki değil aktif konfigürasyonu oku: yeniden yüklenen dosyayla çalışan süreç, itiraf edilenden sık ayrışır.

Uygulamalı örnek

Ödeme 14:05'ten beri 502 dönüyor. Sırayla iki taraf:

$ tail -5 /var/log/proxy/access.log | grep 14:05 10.0.0.8 "POST /checkout HTTP/1.1" 502 154 "-" 0.003 $ tail -20 /var/log/app/server.log | grep -iE "error|listen|bind" | head -3 14:04:58 FATAL: bind 127.0.0.1:3000: address already in use

Beklenen okuma: proksi 3 milisaniyede 502 yanıtladı; yavaşlık elendi, reddedilen veya bozuk upstream kaldı. Uygulama logu belirtiden bir dakika önce port çakışması gösteriyor: eskisni durdurmadan yenisini başlatan dağıtımdan kalma uygulamanın ikinci kopyası portu tutuyor, asıl örnek çıkıyor. Düzeltme: yineleneni durdur, ss -tlnp ile tek dinleyiciyi doğrula, 200'lerin dönüşünü izle. Proksinin hiçbir şeye ihtiyacı yoktu; dokunmak yineleneni bir gün daha saklardı. L05 labı proksi-upstream çiftine karşı 502/503 canlandırır; üç kodlu ayrım otomatikleşene kadar sürer.

Yaygın yanlış hamle

504'ler dursun diye proksi zaman aşımlarını yükseltmek. Kırığa ağrı kesici gibi işe yarar: paneller yeşillenir, kullanıcı sayfa başına 90 saniye bekler, upstream kuyrukları tüm katman birlikte düşene kadar büyür. Zaman aşımları kabul edilebilir gecikme sözleşmesini kodlar; sözleşmeyi prokside bozmak ihlali, düzeltebilecek tek kişilerden saklar. Yavaş yanıtlar uygulamada düzeltilir ya da sözleşme yeni sayıyla açıkça yeniden müzakere edilir; yeni sayı yazılır ve izlenir.

Lab ve sonraki adım

L05 labı proksi ve upstream'i tek bozuk bağlantıyla verir; düzeltmeden önce iki taraflı okuma ister. Sırada 4. ders: kanalın kendisini güvenceye alır; TLS zincirleri, makine adları ve her yıl ekipleri çağıran süre dolumu.