502, 503 ve 504 Hataları: Web Sunucusunda Teşhis Rehberi için üretim ortamında izlenecek en doğru yol; ölçüm, log analizi, kontrollü değişiklik ve doğrulama sırasıdır. Özellikle silme, disk veya servis yeniden başlatma işlemlerinde geri dönüş yolu önceden hazırlanmalıdır.
502, 503 ve 504 Hataları: Web Sunucusunda Teşhis Rehberi için doğru başlangıç
Sunucu tarafında ilk adım değişiklik yapmak değil ölçüm almaktır. Servis durumu, disk/inode, RAM, load ve ilgili error log aynı zaman aralığında kaydedildiğinde semptomun gerçek kaynağı daha hızlı ayrılır.
1. upstream erişimi
upstream erişimi aşamasında önce mevcut servis durumunu, kaynak kullanımını ve ilgili log zaman aralığını kaydedin. Bir servisi yeniden başlatmadan veya konfigürasyon değiştirmeden önce hatanın tekrar üretilebilir olup olmadığını doğrulamak teşhisi kolaylaştırır.
- upstream erişimi: mevcut değer ile hedef sonucu yan yana kaydedin.
- Disk, inode, RAM ve process durumunu ölçün.
- Değişiklikten önce konfigürasyon/yedek alın.
- Düzeltme sonrası web, cron ve bağımlılık testlerini yapın.
2. kapasite
kapasite için panel arayüzü tek başına yeterli değildir. İşletim sistemi ve servis seviyesindeki loglar, disk/inode kullanımı, process durumu ve port dinleme bilgisi birlikte incelendiğinde sorunun gerçek katmanı ortaya çıkar.
- Servis ve sistem loglarını aynı zaman aralığında inceleyin.
- kapasite: mevcut değer ile hedef sonucu yan yana kaydedin.
- Değişiklikten önce konfigürasyon/yedek alın.
- Düzeltme sonrası web, cron ve bağımlılık testlerini yapın.
3. timeout
timeout üzerinde düzeltme yaparken önce düşük riskli adımı uygulayın. Dosya silme, paket yükseltme veya servis konfigürasyonu değiştirme gibi geri dönüşü zor işlemlerden önce yedek alın ve önceki yapılandırmayı ayrı dosyada saklayın.
- Servis ve sistem loglarını aynı zaman aralığında inceleyin.
- Disk, inode, RAM ve process durumunu ölçün.
- timeout: mevcut değer ile hedef sonucu yan yana kaydedin.
- Düzeltme sonrası web, cron ve bağımlılık testlerini yapın.
4. reverse proxy logları
reverse proxy logları sonrasında yalnız ana sayfayı açmakla yetinmeyin. PHP çalışması, cron, SSL, mail/API bağlantıları ve gerekiyorsa panel işlemleri ayrı ayrı test edilmelidir; çünkü servis ayağa kalksa bile uygulama bağımlılıklarından biri bozuk kalabilir.
- Servis ve sistem loglarını aynı zaman aralığında inceleyin.
- Disk, inode, RAM ve process durumunu ölçün.
- Değişiklikten önce konfigürasyon/yedek alın.
- reverse proxy logları: mevcut değer ile hedef sonucu yan yana kaydedin.
Önerilen uygulama sırası
- Mevcut yapı ve bağımlılıkları kaydedin.
- Değişikliği mümkün olan en dar kapsamda uygulayın.
- upstream erişimi: ilk doğrulama noktasını tamamlamadan sonraki adıma geçmeyin.
- Kullanıcı akışını ve bağlı servisleri ayrıca test edin.
- Sonuç beklenen gibi değilse önceki yapılandırmaya dönün ve kök nedeni yeniden ölçün.
Sık yapılan hatalar
Sunucu sorunlarında en riskli yaklaşım, nedeni doğrulamadan log, cache veya yedek dosyalarını topluca silmek ya da servisleri art arda yeniden başlatmaktır. Bu davranış belirtinin kaynağını gizleyebilir. Önce ölçüm alın, sonra tek değişiklik yapın ve sonucu aynı metriklerle karşılaştırın.
Doğrulama ve geri alma
Düzeltme sonrası servis yalnız 'active' görünmemeli; gerçek istek altında doğru cevap vermelidir. HTTP yanıtı, error log, kaynak tüketimi ve arka plan görevlerini birkaç dakika izleyin. Sorun tekrar ederse son değişikliği geri alabilecek dosya/yedek yolunu hazır tutun.
Kaynak ve ilgili hizmet
Teknik ayrıntılarda ürün veya standardın güncel resmî dokümantasyonunu esas alın: resmî teknik kaynak. UST Bilişim tarafında ilgili altyapı veya web projesi için hizmetlerimizi inceleyebilir, mevcut sisteminizin analizi için iletişim sayfasından bize ulaşabilirsiniz.
Bu konuyla birlikte okuyun
Bilgiyi uygulanabilir projeye dönüştürelim.
İhtiyacınızı teknik, operasyonel ve ticari açıdan değerlendirip doğru çözüm yol haritasını birlikte oluşturalım.
Projenizi Anlatın
