Port izleme, web sitenizin arkasındaki hizmetleri, yani veritabanlarını, önbellekleri, kuyrukları, e-posta aktarıcılarını ve dosya aktarım uç noktalarını doğrudan kontrol ederek sessiz arızaları tespit eder. HTTP kontrolleri yalnızca ön yüzün döndürdüğünü görür; bir ön yüz ise bir bağımlılık çöktükten çok sonra bile önbelleğe alınmış sayfaları veya yüzeysel bir sağlık uç noktasını sunmaya devam edebilir. TCP ve UDP portlarını bağlantı süreleriyle birlikte izlemek, bu arızaları kullanıcılar veya HTTP izleyicileri fark etmeden dakikalar ya da saatler önce ortaya çıkarır.
Gerçek Kesintiler Sırasında HTTP Kontrolleri Neden Yeşil Kalır?
Bir HTTP izleyicisi tek bir soru sorar: Bu URL beklenen yanıtı zamanında döndürdü mü? Sistem zaten bozulmuşken bile bu sorunun yanıtı “evet” olabilir:
- Önbelleğe alınmış yanıtlar. Kaynak sunucunun arkasındaki PostgreSQL veya Redis portu bağlantıları reddederken bir CDN veya ters proxy eski sayfaları sunar.
- Yüzeysel sağlık uç noktaları. Veritabanına hiç dokunmadan 200 döndüren bir
/healthrotası, yalnızca web sürecinin ayakta olduğunu kanıtlar. - HTTP yüzeyi olmayan hizmetler. Arka plan işçileri, mesaj aracıları, SMTP aktarıcıları ve SFTP sunucuları herhangi bir web yanıtını değiştirmeden tamamen çökebilir.
- Yedekli düğümler. Birincil düğüm trafiğe hizmet vermeye devam ederken bir replika veya yedek (failover) düğüm çökebilir ve güvenlik payınızı sessizce ortadan kaldırabilir.
Her durumda kullanıcıya dönük katman sorunsuz görünür; bu nedenle önbelleğin süresi dolana veya birincil düğüm hazırda bekleyen bir yedek olmadan çökene kadar kimse uyarılmaz.
Port İzlemenin Daha Erken Yakaladığı Sinyaller
Bağımlılık portlarının karanlığa gömülmesi
5432, 6379, 5672 veya 25 numaralı portlara yönelik bir TCP kontrolü, web katmanından bağımsız olarak hizmetin bağlantı kabul ettiğini doğrular. Bir veritabanı veya mesaj aracısı dinlemeyi bıraktığında port kontrolü bir sonraki çalışmasında, genellikle 30 ila 60 saniyelik bir aralık içinde başarısız olur.
Artan TCP bağlantı süresi
Bir sunucunun kabul (accept) birikimi veya SYN kuyruğu dolduğunda TCP el sıkışması başarısız olmadan önce yavaşlar. 5 ms'lik bir temel çizgiden 200 ms veya daha fazlasına kayan bir bağlantı süresi, çoğu zaman HTTP zaman aşımlarından birkaç dakika önce gelir. Kalıcı sapmalarda uyarı vermek, örneğin art arda üç kontrolün temel çizginin üç katının üzerinde olması durumunda, ölçeklendirme veya yük azaltma için hâlâ zaman varken doygunluğu yakalar.
Yapılandırma ve güvenlik duvarı sapmaları
Bir güvenlik grubu veya güvenlik duvarı değişikliği, iş ortaklarının ya da dahili sistemlerin dayandığı HTTP dışı bir portu kapatabilir. Port durumunu bilinen bir temel çizgiyle karşılaştırmak, kapanmayı anında işaretler ve kapalı olması gereken portlarda beklenmedik hizmetlerin ortaya çıkmasını da gün yüzüne çıkarır.
Gerçekçi Bir Sessiz Arıza Zaman Çizelgesi
Önünde bir CDN, bir uygulama katmanı, PostgreSQL ve Redis destekli bir iş kuyruğu bulunan bir e-ticaret yığınını düşünün.
| Zaman | Olay | HTTP izleyicisi | Port izleyicisi |
|---|---|---|---|
| 09:00 | Redis bellek baskısı başlar | 200 OK | Bağlantı süresi 4 ms'den 90 ms'ye çıkar |
| 09:12 | Redis bağlantı kabul etmeyi bırakır | 200 OK (önbellekteki sayfalar) | 6379 numaralı port başarısız olur, uyarı gönderilir |
| 09:15 | Sipariş onay işleri birikir | 200 OK | Hâlâ başarısız |
| 09:40 | Önbellek TTL süresi dolar, ödeme hataları başlar | 502 hataları | Zaten inceleniyor |
Port izleyicisi ekibe yaklaşık 28 dakikalık bir uyarı süresi sağladı ve doğrudan Redis'i işaret etti.
Port Kontrollerinin Size Söyleyemeyecekleri
Açık bir port, hizmetin bağlantı kabul ettiği anlamına gelir; sorguların doğru veri döndürdüğü, girişlerin çalıştığı veya ödemenin tamamlandığı anlamına gelmez. Bir veritabanı, her sorgu bir kilit nedeniyle zaman aşımına uğrarken TCP bağlantılarını kabul edebilir. Protokole özgü doğrulama ve hizmet parmak izi çıkarma bu boşluğu daraltır, ancak uygulama düzeyindeki kontrollerin yerini tutmaz.
Pratik yaklaşım katmanlamadır:
- Replikalar ve HTTP dışı hizmetler dahil olmak üzere her kritik bağımlılıkta port kontrolleri.
- Kullanıcıya dönük yollar için içerik veya durum doğrulamalı HTTP ve API kontrolleri.
- Veritabanı ve önbellek bağlantılarını gerçekten çalıştıran derin sağlık uç noktaları.
- Tek seferlik sıçramalarda değil, kalıcı sapmalarda uyarı veren bağlantı süresi temel çizgileri.
Kontrol mekanizmalarına daha ayrıntılı bir bakış için port izlemenin nasıl çalıştığına dair rehberimize göz atın.
Uyarı Gürültüsü Olmadan Kurulum
UpScanX port izleme; 15'ten fazla küresel konumdan TCP ve UDP kontrolleri çalıştırır, bağlantı süresini ve yanıt gecikmesini takip eder, sürüm tespitiyle hizmetleri tanımlar ve durum değişikliklerini yapılandırma temel çizgilerinize göre işaretler. Uyarılar e-posta, Slack, Telegram, Microsoft Teams veya bir webhook'a gönderilir.
Uyarıların güvenilir kalması için uyarı vermeden önce arızaları en az iki konumdan doğrulayın ve herkese açık portları yalnızca ağınızın içinden erişilebilir olması gereken dahili portlardan ayırın.
Önemli Çıkarımlar
- HTTP kontrolleri ön yüzü görür; port kontrolleri ise ilk önce sessizce çöken bağımlılıkları görür.
- Artan TCP bağlantı süresi, birikim doygunluğunun erken bir uyarı işaretidir.
- Yalnızca birincil web hizmetini değil, replikaları, işçileri, e-posta ve SFTP portlarını da izleyin.
- Port kontrolleri doğruluğu değil erişilebilirliği doğrular; bu nedenle onları HTTP ve derin sağlık kontrolleriyle katmanlayın.