Makale içeriği

Tipik bir nöbetçi mühendisin sabahını hayal edin. Sohbete bir mesaj düşüyor: "Her şey yavaşladı". Tam olarak ne yavaşladı? Tüm havuz mu, yoksa tek bir kesit mi? Belirli bir ülkedeki proxy mi yoksa belirli bir operatör mü? Hedef site mi yavaş yanıt veriyor, yoksa yeniden deneme kuyruğu mu büyüyor? Rakamlar olmadan bu bir olay değil, kahve falı bakmaktır. Ve ekip tahmin yürütürken zaman geçiyor, para akıyor.

Bu makale, belirsiz "yavaşladı" hissini bir dakika içinde kesin bir teşhise dönüştürmekle ilgili. Proxy havuzu etrafında hangi metriklerin toplanacağını, her istek için loglara ne yazılması gerektiğini ve neyin kesinlikle yazılmaması gerektiğini, neden persentillerin ortalamadan daha önemli olduğunu, verilerin boyutlara göre nasıl etiketleneceğini ve sizi yanlış nedenlerle uyandırmayan alarmların nasıl kurulacağını ele alacağız. Sonunda sizi hızlı müdahale tablosu ve pratik bir SSS bekliyor.

Konunun sınırları hakkında önemli bir not. Burada sadece ölçüm ve uyarı konuşuyoruz. İstek için belirli bir IP seçimi, düğüm sağlık kontrolü ve havuz içi karantina mantığı ayrı ve büyük bir konudur, ona ayrı bir materyal ayrılmıştır. Buradaki görevimiz daha dar: bozulmayı görmek, yerini belirlemek ve zamanında alarmı çalmak. Örneklerde Proxeon altyapısı kullanılıyor, ancak ilkeler evrenseldir.

Temeller: gözlemlenebilirlik nedir ve proxy'ler neden buna özellikle ihtiyaç duyar

Temelden başlayalım. Gözlemlenebilirlik (observability), bir sistemin dış çıktı verilerine bakarak iç durumunu hata ayıklayıcıyla içine girmeden anlayabilme özelliğidir. Klasik gözlemlenebilirlik üçlüsü: metrikler, loglar ve izler (trace). Metrikler toplamda "ne oluyor" sorusunu yanıtlar, loglar "belirli bir isteğe tam olarak ne oldu" sorusunu, izler ise "istek tüm zincirden nasıl geçti" sorusunu.

Proxy'lerin normal bir web servisinden farkı nedir? Tam olarak kontrol edemediğiniz bir üçüncü tarafın olması: proxy düğümünün kendisi, ona giden kanal ve arkasındaki hedef kaynak. Normal bir uygulama son fonksiyonuna kadar profillenebilir. Ancak proxy, bozulmanın her yerden gelebileceği bir ağ belirsizliği katmanı ekler: telekom operatöründen, yönlendirmeden, belirli bir düğümün aşırı yüklenmesinden, hedef sitenin değişen davranışından.

Bu yüzden proxy havuzu etrafındaki gözlemlenebilirlik lüks değil, hijyendir. Onsuz kör çalışırsınız. Onunla, sorunun yapısını görürsünüz: "her şey kötü" değil, "bir bölgedeki bir operatörün mobil proxy kesiti bozuldu, geri kalanı normal". Bu, panik ile cerrahi hassasiyet arasındaki farktır.

Sorunların yaşadığı üç katman

Baştan itibaren bozulmanın doğduğu üç katmanı akılda tutmak faydalıdır:

  • Taşıma katmanı: proxy'ye giden kanal, paket kayıpları, bağlantı kurma süresi. Burada zaman aşımları ve yavaş TTFB yaşar.
  • Proxy düğümü katmanı: belirli bir IP'nin aşırı yüklenmesi, limitlerin tükenmesi, operatördeki sorunlar. Burada belirli bir kesitteki hata oranı artışı yaşar.
  • Hedef kaynak katmanı: site daha yavaş yanıt vermeye başladı, standart dışı kodlar döndürdü, limitleri değiştirdi. Burada site sorununu havuz sorunuyla karıştırmamak önemlidir.

İyi bir gözlemlenebilirlik sistemi, sorunun bu üç katmandan hangisinde olduğunu tek bakışta anlamanızı sağlar. İşte bu, tüm bunları başlatmamızın nedeni olan o "teşhise bir dakika"dır.

Proxy için dört sinyal: neden tam olarak bunlar

Her şeyi toplama cazibesi vardır. Yüzlerce metrik, onlarca pano, kilometrelerce grafik. Bu bir tuzaktır. Çok fazla metrik gürültü demektir, gürültü ise olay anında ihtiyacınız olanı bulamayacağınız anlamına gelir. Deneyimli mühendislik pratiği tam tersini söyler: sorunların çoğunu kapsayan minimum sinyal setiyle başlayın. Bir proxy havuzu için bu tür dört sinyal vardır.

Birinci sinyal: başarılı istek oranı

Başarılı istek oranı (success rate), beklenen şekilde tamamlanan isteklerin toplam sayıya yüzdesidir. Bu, sağlığın ana göstergesidir. Başarı oranı düşerse, bir şey tam şu anda ve tam kullanıcının yanında bozulmuştur.

Kilit soru: başarı olarak ne sayılmalı? Naif "200 kodu" yanıtı yanlıştır. Başarıyı kullanım sözleşmeniz üzerinden tanımlamak daha doğrudur. Genellikle tüm 2xx ve 3xx kodları ile hedef kaynağın geçerli yanıtı olan, proxy sorunu olmayan anlamlı 4xx kodları başarı sayılır. Ancak zaman aşımları, bağlantı kopmaları, proxy düzeyindeki hatalar ve toplu 5xx kodları başarısızlıktır.

Biçimsel olarak başarı oranı, SLI (Service Level Indicator) modelindeki "kullanılabilirlik" metrik ailesine aittir. Bu, daha sonra SLO (hizmet seviyesi hedefleri) ve hata bütçesinin üzerine inşa edildiği o göstergedir.

İkinci sinyal: persentillere göre gecikme

Gecikme (latency), isteğin gönderilmesinden yanıtın alınmasına kadar geçen süredir. Ancak tek bir gecikme sayısı anlamsızdır. Persentiller gerekir: p50, p95, p99. Neden ortalama yerine persentiller sorusunu ayrı bir bölümde ayrıntılı olarak ele alacağız, çünkü bu tüm izlemedeki en hafife alınan konulardan biridir.

Proxy için özellikle değerli olan TTFB'dir (Time To First Byte, ilk bayta kadar geçen süre). Bu, ağ gecikmesini ve sunucu yanıt süresini, yanıt gövdesinin iletilme süresinden ayırır. TTFB artıyorsa bu ağ veya düğüm sorunudur. Toplam süre artıyor ama TTFB sabitse, belki yanıtlar büyümüştür veya kanalın bant genişliği düşmüştür.

Üçüncü sinyal: yeniden deneme oranı

Yeniden deneme oranı (retry rate), yeniden deneme gerektiren isteklerin yüzdesidir. Bu, sorunun erken habercisidir. Genellikle başarı oranı hâlâ normaldir çünkü yeniden denemeler durumu kurtarır, ancak yeniden deneme oranı çoktan yukarı tırmanmaya başlamıştır. Bu, 37,2 derece ateş gibidir: biçimsel olarak hâlâ çalışıyorsunuz ama organizma çoktan savaşıyor.

Yeniden denemeler son kullanıcı için bozulmayı maskeler ama kaynakları yer: zamanı, trafiği, havuz kapasitesini. Bu sinyali görmezden gelmek iki kat tehlikelidir, çünkü yeniden deneme artışı, yeniden deneme istekleri zaten aşırı yüklenmiş düğümlere yük eklediğinde sistemi çığ gibi çökertebilir.

Dördüncü sinyal: trafik tüketimi

Trafik tüketimi (bandwidth), iletilen veri hacmidir. Neden dört ana sinyalden biri? Birincisi, bu doğrudan paradır çünkü trafik ücretlendirilir. İkincisi, anormal tüketim bir sinyaldir: ani artış, birinin fazladan bir şey çektiği, yanıtların şiştiği veya yeniden denemelerin aynı verileri döngüde döndürdüğü anlamına gelebilir. Normalde aktivite olan bir kesitte sıfıra ani düşüş, o kesitin tamamen çalışmayı durdurduğu anlamına gelir.

Bu dört sinyal tesadüfi değildir. Güvenilirlik mühendislerinin popülerleştirdiği "altın sinyaller" gözlemlenebilirlik metodolojisiyle örtüşürler: gecikme, trafik, hatalar, doygunluk. Bunu proxy'nin özelliklerine uyarladık; burada yeniden denemeler, bu alana özgü bir erken haberci olarak ayrı bir yer hak ediyor.

Derinlemesine: her istek için loglara ne yazılmalı

Metrikler eğilimleri gösterir. Ancak belirli bir isteğe ne olduğunu anlamanız gerektiğinde loglar kurtarır. Doğru tasarlanmış bir istek logu, olay incelemesinde başvurduğunuz kara kutunuzdur. Zorunlu olarak ne yazılması gerektiğini ve neyin asla yazılmaması gerektiğini ele alalım.

Zorunlu olarak yazılması gerekenler

  • Proxy tanımlayıcısı: açık haldeki IP değil, düğüm veya havuzun kararlı bir tanımlayıcısı. Bu, isteği belirli bir kaynakla ilişkilendirmenize ve hangi düğümlerin sorun çıkardığını görmenize olanak tanır.
  • Yanıt kodu: HTTP durumu veya taşıma hatası kodu (zaman aşımı, bağlantı reddi, kopma). Bu, başarı oranını hesaplamanın temelidir.
  • İlk bayta kadar geçen süre (TTFB): milisaniye cinsinden. Ağ sorunlarını yerelleştirmek için en bilgilendirici göstergelerden biri.
  • Toplam istek süresi: başlangıçtan bitişe, yine milisaniye cinsinden.
  • Yanıt boyutu: bayt cinsinden. Trafik metriğini besler ve anormal büyük veya boş yanıtları fark etmeye yardımcı olur.
  • Deneme numarası: ilk deneme mi yoksa zaten yeniden deneme mi, kaçıncı sırada. Bu alan olmadan yeniden deneme oranını hesaplamak imkânsızdır.
  • Etiketleme boyutları: ülke, operatör, proxy türü. Bunlara ayrı bir bölüm var, ancak loglarda bulunmalıdırlar.
  • Zaman damgası ve izleme tanımlayıcısı: kayıtları birbirleriyle ve harici sistemlerle ilişkilendirmek için.

İşte JSON formatındaki yapılandırılmış bir log kaydının nasıl görünebileceği. Dikkat edin: makine tarafından okunabilir, bu sonraki analiz için kritiktir.

{"ts":"2026-02-14T08:12:33Z","trace_id":"a1b2c3","proxy_id":"pool7-node042","country":"RU","carrier":"op-a","proxy_type":"mobile","status":200,"ttfb_ms":187,"total_ms":342,"bytes":20481,"attempt":1,"outcome":"success"}

Asla yazılmaması gerekenler

Bu, ne yazmanız gerektiğinden daha az önemli değildir. Loglar sızma, analitik sistemlere kopyalanma, yedeklere girme eğilimindedir. Oraya koyduğunuz her şey uzun süre ve beklenmedik yerlerde yaşar.

  • Kimlik bilgileri (kredler): proxy'ye kullanıcı adları, parolalar, yetkilendirme token'ları, API anahtarları. Asla. Kısmen bile. "Hata ayıklama süresince" bile.
  • Yanıt gövdesinin tamamı: birincisi, bu devasa bir hacimdir, ikincisi, kişisel ve hassas veriler içerebilir. Sadece boyutu ve gerekirse bir hash veya kısa bir imza yazın.
  • Sır içeren başlıklar: Authorization, Cookie, Set-Cookie ve benzerleri. Kayıttan önce temizlenmelidirler.
  • Hassas parametreler içeren tam URL'ler: sorgu dizesinde token veya kişisel tanımlayıcılar varsa, bunlar maskelenmelidir.
  • Kullanıcıların kişisel verileri: kişisel veri mevzuatı kapsamına giren her şey ya loglara girmemeli ya da anonimleştirilmelidir.

Log oluşturma aşamasında pratik maskeleme yöntemi:

def sanitize(entry):  secret_keys = {"authorization", "cookie", "set-cookie", "proxy-authorization"}  headers = {k: ("***" if k.lower() in secret_keys else v) for k, v in entry.get("headers", {}).items()}  entry["headers"] = headers  entry.pop("body", None)  entry.pop("proxy_credentials", None)  return entry

Altın kural: log, sorunu teşhis etmeye izin vermeli ancak sızdırılmış sırlar veritabanına dönüşmemelidir. Bir alanı yazıp yazmama konusunda şüpheniz varsa, yazmayın. Teşhis değeri neredeyse her zaman güvenli vekiller aracılığıyla elde edilebilir: hash'ler, boyutlar, bayraklar, kategoriler.

Ortalama yerine persentiller: ortalama neden sorunu gizler

Bu, iki kez okunmaya değer bir bölümdür. Çünkü burada performans izlemedeki en yaygın ve en sinsi hata yatmaktadır.

Ortalama neden yalan söyler

Hayal edin: yüz isteğiniz var. Doksan dokuzu 100 milisaniyede tamamlandı, biri 10 saniyede. Ortalama süre yaklaşık 199 milisaniye olacaktır. Harika görünüyor, neredeyse hiçbir şey değişmedi. Oysa bir kullanıcınız on saniye bekledi ve muhtemelen söverek çoktan gitti.

Ortalama, aykırı değerleri tüm örnekleme yayan bir aparattır. Uç değerlere duyarlıdır ancak dağılımın yapısına duyarsızdır. Ağ sistemlerinin performansı neredeyse her zaman uzun kuyruklu bir dağılıma sahiptir: çoğu istek hızlıdır ancak çok yavaş bir azınlık vardır. Ve tam da bu kuyruk, gerçek kullanıcı deneyimini ve sorunların varlığını belirler.

Persentil nedir ve nasıl okunur

Persentil, gözlemlerin belirli bir yüzdesinin altında kaldığı değerdir. Üç ana tanesini ele alalım:

  • p50 (medyan): isteklerin yarısı bu değerden hızlı, yarısı yavaş. Bu "tipik" deneyimdir.
  • p95: isteklerin yüzde 95'i bu süreye sığdı. Bu, kayda değer bir kullanıcı kesimini etkileyen "neredeyse en kötü durum" deneyimidir.
  • p99: isteklerin yüzde 99'u daha hızlı. Bu, zaman aşımlarının, yeniden denemelerin ve öfkeli kullanıcıların yaşadığı o uzun kuyruktur.

Yüz istekli örneğimizde p50 ve p95 yaklaşık 100 milisaniyede kalacak, ancak p99 10 saniyeye fırlayacaktır. Persentil, ortalamanın sakladığı sorunu dürüstçe gösterdi. İşte bu yüzden deneyimli mühendisler öncelikle p95 ve p99'a bakar, ortalamayı ise gecikme değerlendirmesi için neredeyse hiç kullanmaz.

Persentiller nasıl doğru hesaplanır

Naif yöntem tüm değerleri toplamak, sıralamak ve istenen konumu almaktır. Bu doğrudur ancak ölçeklenmez: milyonlarca istekte tüm diziyi saklamak imkânsızdır. Pratikte yaklaşık hesaplama yapıları kullanılır: sabit kovalı histogramlar veya t-digest ve HDR histogramları gibi özel algoritmalar.

Histogram fikri basittir: önceden zaman aralıklarını (kovaları) tanımlarsınız ve basitçe her birine kaç isteğin düştüğünü sayarsınız. Birikmiş sayaçlardan kabul edilebilir doğrulukla herhangi bir persentili geri kazanmak kolaydır ve bellek sabit harcanır.

import bisectclass PercentileTracker:  def __init__(self):    self.buckets = [10, 25, 50, 100, 200, 500, 1000, 2000, 5000]    self.counts = [0] * (len(self.buckets) + 1)  def add(self, ms):    i = bisect.bisect_left(self.buckets, ms)    self.counts[i] += 1  def percentile(self, p):    total = sum(self.counts)    if total == 0:      return None    target = total * p / 100    acc = 0    for i, c in enumerate(self.counts):      acc += c      if acc >= target:        return self.buckets[min(i, len(self.buckets) - 1)]    return self.buckets[-1]

Toplama konusunda önemli bir uyarı. Persentiller ortalanamaz. On düğümde p95'iniz varsa, bu p95'lerin ortalamasını alıp sonucu genel p95 olarak adlandıramazsınız. Bu matematiksel olarak yanlıştır. Doğru toplama için histogramları toplamanız ve persentili toplam histogramdan hesaplamanız gerekir. İşte bu yüzden modern izleme sistemleri hazır persentilleri değil histogramları saklar.

Boyutlara göre etiketleme: tüm havuzu değil, kesiti görmek

İşte gözlemlenebilirliğin bir grafikten teşhis aracına dönüştüğü an. Tüm havuz için tek bir başarı oranı sayısı size az şey söyler. Yüzde 97 olabilir ve normal görünebilir, bir kesitin yüzde 40'a düştüğünü gizlerken geri kalanlar ortalamayı yukarı çeker.

Proxy için üç kilit boyut

  • Ülke (country): proxy coğrafyası. Bozulma genellikle coğrafi olarak yerelleşmiştir: bir bölgede yönlendirme sorunu, belirli ülkeler için hedef kaynak tarafında değişiklikler.
  • Operatör (carrier): Proxeon mobil proxy'leri için bu kritik önemde bir boyuttur. Belirli bir telekom operatöründeki sorun tam burada ortaya çıkar ve ölçeğini hemen anlarsınız.
  • Proxy türü (proxy_type): mobil, sunucu, rezidenSİYAL. Farklı türler farklı davranır ve bir türün bozulması genel yığın içinde kaybolmamalıdır.

Kardinalite: nerede durmalı

Verileri her şeye göre etiketleme cazibesi vardır: her IP'ye, her hedef alan adına, her kullanıcıya göre. Bu, kardinalite patlamasına yol açar; yani benzersiz etiket kombinasyonlarının sayısının patlamasına. Yüksek kardinalite izleme sistemlerini öldürür: depolama hacmi büyür, sorgular yavaşlar, altyapı pahalanır.

Pratik kural: sınırlı ve istikrarlı bir değer kümesine sahip boyutlara göre etiketleyin. Ülkeler onlarca, operatörler bir veya onlarca, proxy türleri birkaç tanedir. Bu güvenlidir. Ancak bireysel IP veya tam URL metriklerde etiket olarak kullanılamaz; bunlar muazzam miktarlarda benzersizdir. Bu tür ayrıntıların yeri loglardır; orada satır satır saklanırlar, metriklerde veri satırlarını çoğaltmazlar.

from prometheus_client import Counter, Histogramrequests_total = Counter(  "proxy_requests_total",  "Total proxy requests",  ["country", "carrier", "proxy_type", "outcome"])latency_ms = Histogram(  "proxy_latency_ms",  "Request latency",  ["country", "carrier", "proxy_type"],  buckets=[10, 25, 50, 100, 200, 500, 1000, 2000, 5000])def record(country, carrier, ptype, outcome, ms):  requests_total.labels(country, carrier, ptype, outcome).inc()  latency_ms.labels(country, carrier, ptype).observe(ms)

Bu tür bir etiketlemeyle saniyeler içinde bir sorgu oluşturabilirsiniz: son bir saatte operatörlere göre başarı oranını göster. Ve hemen tüm havuzun değil, bir kesitin bozulduğunu görürsünüz. İşte bu yerelleştirmedir. Bu yaklaşımın güzelliği, "her şey bozuldu" panikini sakin bir "Y operatörünün X kesiti dikkat gerektiriyor"a dönüştürmesidir.

Gürültü yapmayan alarmlar

Ekiplerin izlemeye güvenmeyi bırakmasının en yaygın nedeni gürültülü alarmlardır. Sistem sizi bir gecede beş kez yanlış nedenlerle uyandırdığında, çok yakında onu görmezden gelmeye başlarsınız. Sonra da gerçek bir olayı kaçırırsınız. Buna alarm yorgunluğu denir ve gözlemlenebilirliği tamamen izleme eksikliğinden daha etkili bir şekilde öldürür.

Sessiz alarmların üç ilkesi

Birinci ilke: eşikler nedenlere değil, semptomlara. Kullanıcının hissettiği şeye alarm vermelisiniz: başarı oranı düşüşü, p99 gecikme artışı. Kendi başına sorun anlamına gelmeyen ara teknik dalgalanmalara değil.

İkinci ilke: gözlem pencereleri. Tek bir sıçramaya tepki vermeyin. Tek bir yavaş istek gürültüdür. Belirli bir zaman dilimi boyunca sürekli sapma sinyaldir. Alarmı, koşul örneğin beş dakika boyunca üst üste devam ettiğinde tetiklenecek şekilde ayarlayın, tek bir anda değil.

Üçüncü ilke: histerezis. Mühendislikten ödünç alınan bu terim, tetikleme ve sıfırlama için farklı eşikler anlamına gelir. Alarm, başarı oranı yüzde 90'ın altına düştüğünde yanar, ancak yalnızca yüzde 95'in üzerine çıktığında söner. Eşikler arasındaki boşluk, metrik tek bir değer etrafında dalgalandığında ve alarmın yanıp sönmesi durumunda "titremeyi" önler.

Örnek alarm yapılandırması

İşte çoğu izleme sisteminin anlayacağı tarzda bir kural örneği. Herhangi bir operatör kesitinde başarılı istek oranı gözlem penceresi boyunca eşiğin altında kalırsa tetiklenir.

groups:- name: proxy-health  rules:  - alert: LowSuccessRateByCarrier    expr: |      sum by (carrier) (rate(proxy_requests_total{outcome="success"}[5m]))      /      sum by (carrier) (rate(proxy_requests_total[5m]))      < 0.90    for: 5m    labels:      severity: warning    annotations:      summary: "Success rate below 90 percent for carrier"

Önem düzeyleri ve yönlendirme

Tüm alarmlar eşit değildir. Onları önem düzeyine göre ayırın:

  • Warning: bir şey sapmış, çalışma saatlerinde bakmaya değer. Gece uyandırmaz.
  • Critical: kullanıcılar şu anda acı çekiyor, acil müdahale gerekiyor. Nöbetçiyi uyandırır.

Başlamak için makul set tam anlamıyla birkaç alarm içerir: genel başarı oranında kritik düşüş, kesite göre başarı oranı bozulması, p99 gecikmesinde keskin artış, yeniden deneme oranında anormal sıçrama. Daha fazlası değil. Her yeni alarm, ona yanıt verileceğine dair bir vaattir. Tutamayacağınız vaatler vermeyin.

Çerçeve olarak hata bütçesi

Anlık değerlere katı eşikler yerine hata bütçesi kullanmak ileri düzey bir tekniktir. Aylık yüzde 99 başarılı istek hedefiniz varsa, hata bütçesi "harcayabileceğiniz" o yüzde birdir. Bütçe tüketim hızına (burn rate) yönelik alarm, tek bir hata olgusuna değil, izin verilen hata limitini çok hızlı harcadığınıza tepki verir. Bu tür alarmlar çok daha sakindir ve SLO için gerçek tehdidi daha doğru yansıtır.

Panodan hızlı teşhis: üç tipik tablo

Şimdi en ilginç kısım. Bozulmanın nerede olduğunu bir dakikada nasıl anlarsınız? Yanıt, gözünüzü birkaç tipik desene alıştırmaktır. İyi bir pano, grafik çöplüğü değil, bir desen tanıma aracıdır. Üç klasik tabloyu ele alalım.

Birinci tablo: bir kesit düştü, geri kalanı normal

Operatörlere göre bölünmüş başarı oranına bakıyorsunuz. Genel gösterge biraz düşmüş, ancak ayrıntıya bakınca görüyorsunuz: bir operatör yüzde 50'ye çökmüş, geri kalanlar yüzde 98'i tutuyor. Sorunlu kesitte gecikme artmış, diğerlerinde sabit.

Bu ne anlama gelir: düğüm veya operatör düzeyinde yerelleşmiş sorun. Neden sizin sisteminizde veya genel olarak hedef kaynakta değil, havuzun belirli bir kesitinde. Taşıma veya düğümün kendisinde sorun.

İlk eylem: sorunlu kesiti aktif rotasyondan çıkarın (bu zaten karantina alanı, ayrı bir konu) ve izlemeye devam edin. Bozulmanın operatör içindeki belirli bir bölgeyle ilgili olup olmadığını kontrol edin.

İkinci tablo: her yerde gecikme arttı, ancak hata yok

Başarı oranı sabit, yüzde yüze yakın. Ancak p95 ve p99 gecikmesi tüm kesitlerde aynı anda ve eşit şekilde arttı. Yeniden deneme oranı önemsiz miktarda arttı.

Bu ne anlama gelir: her şey aynı anda ve eşit şekilde bozulduğunda, ortak bir faktör arayın. Çoğu zaman bu ya kendi altyapınızdır (aşırı yüklenme, kaynak yetersizliği, kodunuzdaki darboğaz) ya da hedef kaynak herkes için yavaşlamıştır. Proxy düğümleri burada devrede değildir, aksi halde bozulma dengesiz olurdu.

İlk eylem: TTFB'ye ayrıca bakın. TTFB artmışsa ağ veya sunucu. TTFB sabitse ve toplam süre artıyorsa sorun iletimde veya gövde işlemesinde. Kendi tarafınızdaki yükü ve hedef kaynağın metriklerini kontrol edin.

Üçüncü tablo: başarı oranı sabitken yeniden deneme oranı artıyor

Başarı oranı normal görünüyor, yaklaşık yüzde 97. Ancak yeniden deneme oranı yukarı tırmanıyor: yüzde 3'ten yüzde 15'e çıktı. Gecikme de arttı çünkü yeniden denemeler zaman ekler.

Bu ne anlama gelir: bu en sinsi desendir çünkü nihai sonuç hâlâ normaldir. Ancak sistem sınırda çalışıyor: başarı oranını tutmak için giderek daha fazla yeniden deneme harcıyor. Bu bir çöküş habercisidir. Eğilim devam ederse, yeniden denemeler kurtarmayı bırakacak ve başarı oranı çökecektir.

İlk eylem: başarı oranı çökene kadar beklemeyin. Yeniden denemelerin hangi kesitte arttığını bulun (yine boyutlara göre bölme) ve çok geç olmadan kök nedeni araştırın. Yeniden denemelerin kendilerinin bir kısır döngüyü hızlandıran ek yük yaratıp yaratmadığını kontrol edin.

Dakikalık teşhis için pano düzeni

Bu desenlerin bir dakikada okunması için ana ekrana dört sinyale karşılık gelen sadece dört panel yerleştirin ve her biri boyutlara göre hızlı bölme özelliğine sahip olsun:

  1. Başarı oranı: genel ve operatörlere ve ülkelere göre bölünmüş.
  2. Gecikme: p50, p95, p99 tek bir grafikte, kuyruk sapmasını görmek için.
  3. Yeniden deneme oranı: son saatlerdeki eğilim.
  4. Trafik tüketimi: kesitlere göre, anormallikleri yakalamak için.

Geri kalan her şey ikincildir ve ayrı ekranlarda yaşar. Ana ekran tek bir soruyu yanıtlamalı: her şey yolunda mı, değilse tam olarak nerede? Fazlalık yok.

Hızlı müdahale tablosu: metrik, artışı ve ilk eylem

Bu tabloyu yazdırıp nöbetçinin çalışma alanının yanına asmaya değer. Gözlemi gereksiz düşünmeden eyleme dönüştürür.

Metrik: başarılı istek oranında düşüş (tüm havuz)

Ne anlama gelir: isteklerin çoğunu etkileyen toplu arıza. Sistem düzeyinde sorun.
İlk eylem: kendi altyapınızı ve hedef kaynağı kontrol edin, çünkü eşit düşüş nadiren tek düğümlerden gelir.

Metrik: başarılı istek oranında düşüş (tek kesitte)

Ne anlama gelir: operatör, ülke veya proxy türünün yerelleşmiş bozulması.
İlk eylem: kesiti bölmeyle yerelleştirin ve dinamikleri izleyerek rotasyondan çıkarın.

Metrik: p50 sabitken p99 gecikmesinde artış

Ne anlama gelir: kuyruk uzadı, bazı istekler çok yavaşladı, tipik istek ise normal.
İlk eylem: kuyruğu büyüyen kesiti bulun, zaman aşımlarını ve sıçrama yapan düğümleri kontrol edin.

Metrik: p50 ve p95'te aynı anda ve eşit artış

Ne anlama gelir: genel performans bozulması, muhtemelen altyapı veya hedef kaynak.
İlk eylem: TTFB ve gövde iletim süresini ayırın, kendi tarafınızdaki yükü kontrol edin.

Metrik: başarı oranı sabitken yeniden deneme oranında artış

Ne anlama gelir: sistem bozulmayı tekrarlarla maskeliyor, çöküş habercisi.
İlk eylem: yeniden deneme artışı olan kesiti bulun ve başarı oranı çökmeden kök nedeni ortadan kaldırın.

Metrik: trafik tüketiminde anormal artış

Ne anlama gelir: şişmiş yanıtlar, gereksiz tekrarlar veya planlanmamış aktivite.
İlk eylem: trafik artışını istek sayısı ve yanıt boyutuyla karşılaştırın, kaynağı bulun.

Metrik: aktif kesitte trafik tüketiminin sıfıra düşmesi

Ne anlama gelir: kesit istekleri tamamen sunmayı bıraktı.
İlk eylem: kesit düğümlerinin kullanılabilirliğini ve bağlantıyı kontrol edin, doğrulanırsa yükseltin.

Proxy gözlemlenebilirliğinin tipik hataları

Onlarca olay incelemesi deneyimi, en sık basılan tırmıkların bir koleksiyonunu toplamayı sağlar. Bu hataları bilmek aylarca acı tasarrufu sağlar.

Hata 1: persentiller yerine ortalamaya bakmak

Bunu zaten ele aldık, ancak tekrarlayalım çünkü hata o kadar yaygın. Ortalama yanıt süresi uzun kuyruk sorunlarını göstermez. Ekip istikrarlı bir ortalama görür ve kullanıcılar takılmalardan şikayet edene kadar her şeyin yolunda olduğundan emindir. Her zaman p95 ve p99.

Hata 2: "hata ayıklama süresince" sırları loglamak

Geçicinin kalıcı olma eğilimi vardır. "Kontrol için beş dakikalığına" loglanan bir token, log depolama sisteminde aylarca kalır ve yedeklere girer. Sırların maskelenmesi, her geliştiricinin anlık kararı değil, loglama kitaplığı düzeyinde katı bir kural olmalıdır.

Hata 3: etiket kardinalitesi patlaması

Metrikleri her IP veya URL'ye göre etiketlemek, izleme sistemi boğulmaya ve giderek daha fazla kaynak talep etmeye başlayana kadar uygun görünür. Etiketler yalnızca sınırlı bir değer kümesine sahip boyutlar için. Ayrıntılar loglarda.

Hata 4: çok fazla alarm

İzlemesiyle gurur duyan bir ekip kırk alarm kurar. Bir ay sonra bunların yarısı gürültü yapar, nöbetçiler bildirimlerde onları kapatır ve bir gün gerçek bir olayı kaçırırlar çünkü akışta kaybolmuştur. Daha az alarm, ama daha doğru.

Hata 5: pencere ve histerezis olmayan alarmlar

Alarm anlık değerle tetiklenir ve hemen söner, sonra tekrar tetiklenir. Bildirim titremesi sinir bozucudur ve sistemi değersizleştirir. Gözlem pencereleri ve histerezis zorunludur.

Hata 6: başarı olarak yalnızca 200 kodunu saymak

Böylece ya geçerli yanıtları başarısızlık sayarak başarı oranını düşürürsünüz ya da tam tersine sorunları kaçırırsınız. Başarıyı mekanik olarak tek bir koda göre değil, kullanım sözleşmesi üzerinden anlamlı bir şekilde tanımlayın.

Hata 7: boyutlara göre bölümlemenin olmaması

Tek bir genel başarı oranı grafiği yerel sorunları gizler. Bölümleme olmadan "genel olarak normal" görürsünüz ve düşmüş bir kesiti kaçırırsınız. Etiketleme seçenek değil, gerekliliktir.

Hata 8: yeniden denemeleri görmezden gelmek

Birçoğu yalnızca nihai başarı oranına güvenerek yeniden deneme oranını hiç saymaz. Ve en erken habercisini kaybeder. Başarı oranı düştüğünde, yeniden denemeler çoktan sorunu haykırıyordu.

Hata 9: histogram yerine persentil saklamak

Kesitler için hazır p95 saklarsanız, genel p95'i doğru şekilde hesaplayamazsınız çünkü persentiller toplanmaz. Histogramları saklayın, persentilleri sorguda hesaplayın.

Hata 10: çöplük olarak pano

Tek bir ekranda elli panel gözlemlenebilirlik değil, bilgi gürültüsüdür. Olay anında göz kaybolur. Ana ekran minimalist, ayrıntılar tıklamayla.

Araçlar ve kaynaklar

İyi haber: proxy havuzu etrafında kaliteli gözlemlenebilirlik için pahalı ve karmaşık bir yığına ihtiyaç yok. Minimum yeterli seti ve seçim mantığını ele alalım.

Metrik toplama ve depolama

Metrikler için etiket ve histogram desteği olan zaman serisi modeline dayalı sistemler mükemmel uygundur. Kilit gereksinim, persentillerin doğru hesaplanması için histogram desteği ve kardinalite patlaması olmadan boyutlara göre etiketlemedir. Bu tür sistemler "bir saatte operatörlere göre başarı oranı" gibi sorguları anında yapmanıza olanak tanır.

Görselleştirme

Panolar için zaman serisi grafikleri oluşturabilen, tek bir grafikte birden fazla persentili üst üste koyabilen ve boyutlara göre bölümlemeyi hızlıca değiştirebilen bir araç gerekir. Değişken filtreler yapabilme önemlidir: operatörü seçtiniz ve tüm paneller ona göre yeniden düzenlendi. Bu teşhisi kat kat hızlandırır.

Log toplama ve depolama

İstek logları yapılandırılmış (JSON) olmalı ve alanlara göre filtrelemeye izin veren bir sisteme düşmelidir: proxy tanımlayıcısı, yanıt kodu, kesit. Zorunlu gereksinim, hassas verilerin sonsuza kadar birikmemesi için otomatik silme ile saklama politikasıdır.

Alarm

Alarm sistemi gözlem pencerelerini (koşul N dakika devam eder), önem düzeylerini ve kanallara göre yönlendirmeyi desteklemelidir. Ayrıca, sakin ama doğru tetiklemeler için hata bütçesi tüketim hızına yönelik alarm desteği değerlidir.

Kod enstrümantasyonu için kitaplıklar

Proxy istemci kodunda etiketli sayaçları ve histogramları destekleyen metrik kitaplıkları kullanın. Her isteği bir ölçüme sarın: başlangıç zamanını kaydedin, tamamlandığında sonucu, gecikmeyi ve trafiği kaydedin. Enstrümantasyon merkezi olmalı, tek bir yerde, yeni bir geliştiricinin yanlışlıkla atlayamayacağı şekilde.

import timedef instrumented_request(client, url, meta):  start = time.monotonic()  attempt = meta["attempt"]  try:    resp = client.get(url)    elapsed = (time.monotonic() - start) * 1000    outcome = "success" if resp.status_code < 500 else "server_error"    record(meta["country"], meta["carrier"], meta["type"], outcome, elapsed)    log_request(meta, resp.status_code, elapsed, len(resp.content), attempt, outcome)    return resp  except TimeoutError:    elapsed = (time.monotonic() - start) * 1000    record(meta["country"], meta["carrier"], meta["type"], "timeout", elapsed)    log_request(meta, None, elapsed, 0, attempt, "timeout")    raise

2026 trendleri

Gözlemlenebilirlik endüstrisi 2026'da birkaç belirgin yöne doğru ilerliyor. Birincisi, metriklerin, logların ve izlerin tek bir resme entegrasyonunu kolaylaştıran açık protokollere dayalı telemetri standardizasyonu. İkincisi, minimum bellek harcamasıyla doğru persentiller veren üstel histogramlara artan ilgi. Üçüncüsü, eşik alarmlarını tamamlayan, önceden eşik belirlenemeyen olağandışı desenleri fark eden istatistiksel modellere dayalı otomatik anomali tespitinin uygulanması. Ve dördüncüsü, toplanan veri miktarından anlamlılığına odak kayması: daha az metrik, ama doğru olanlar. Bu tam olarak bu makalede konuştuğumuz şeydir.

Vaka çalışmaları ve sonuçlar

İlkelerin et ve kemik kazanması için, proxy havuzlarının tipik işletim pratiği üzerine kurulu birkaç genelleştirilmiş senaryoyu ele alalım. Rakamlar örnekleyicidir ancak desenler gerçektir.

Vaka 1: bir operatörün görünmez bozulması

Ekip Proxeon mobil proxy havuzuyla çalışıyor ve genel başarı oranına güveniyordu. Gösterge yaklaşık yüzde 96'da kalıyordu, alarma gerek yoktu. Aynı zamanda yönlerden birinin kullanıcıları arızalardan şikayet ediyordu. Operatörlere göre bölümleme uygulandıktan sonra tablo anında netleşti: bir operatör yüzde 62 başarı oranı veriyordu, geri kalanlar yaklaşık yüzde 99. Genel rakam tüm bir kesitin çöküşünü maskeliyordu.

Sonuç: operatörlere göre etiketleme ve kesit bozulmasına yönelik alarm eklendikten sonra, bu tür sorunların tespit süresi birkaç saatten (şikayetlerle) birkaç dakikaya (alarmla) düştü. Sorunlu kesit zamanında rotasyondan çıkarılmaya başlandı ve yön için genel başarı oranı yüzde 98'e yükseldi.

Vaka 2: ortalamanın arkasına saklanan uzun kuyruk

Başka bir ekip, rahat 240 milisaniyede kalan ortalama gecikmeyi izliyordu. Periyodik "takılma" şikayetleri kaprislere bağlanıyordu. Persentillere geçiş gözleri açtı: p50 gerçekten yaklaşık 190 milisaniyeydi ancak p99 8 saniyeye ulaşıyordu. Her yüzüncü istek acı verici derecede yavaştı.

Sonuç: ekip p99'u izlemeye ve artışına alarm kurmaya başladıktan sonra, kuyruğun yoğun saatlerde belirli bir düğüm grubuna yapılan istekler tarafından üretildiğini keşfettiler. Sorun bölümlemeyle yerelleştirildi. p99'u 1,2 saniyeye düşürmeyi başardılar ve takılma şikayetlerinin sayısı neredeyse sıfıra düştü.

Vaka 3: yeniden deneme sarmalı

Üçüncü senaryo tehlikesiyle dikkat çekicidir. Agresif tekrar politikasına sahip sistem, başarı oranını yaklaşık yüzde 97'de tutuyordu ve her şey istikrarlı görünüyordu. Ancak kimse yeniden deneme oranını izlemiyordu. Bir gün küçük bir yük artışında yeniden deneme oranı yarım saat içinde yüzde 5'ten yüzde 40'a çıktı. Yeniden deneme istekleri yük ekledi, düğümler daha fazla aşırı yüklendi, yeniden denemeler daha da arttı - klasik bir sarmal. Bir saat içinde başarı oranı yüzde 60'a çöktü.

Sonuç: olay incelemesi, ayrı bir yeniden deneme oranı metriği ve artışına yönelik erken alarm getirilmesine yol açtı. Artık yeniden deneme eşiğine ulaşıldığında ekip, başarı oranı çökmeden çok önce uyarı alıyor. Benzer durumlar erken haberci aşamasında yakalanmaya başlandı, kazaya yol açmadan. Bu, yeniden denemelerin neden dört ana sinyal arasında yer hak ettiğinin açık bir örneğidir.

Vakalardan genel çıkarım

Üç hikaye, üç farklı sorun, ancak tek bir düzenlilik. Her durumda, tespit için veriler sistemde fiziksel olarak mevcuttu, ancak sorunun görünür hale gelmesi için sunulmamıştı. Boyutlara göre bölümleme, ortalama yerine persentiller ve yeniden denemelere dikkat - bunlar soyut öneriler değil. Her biri kendi sorun sınıfını görünür kılan somut merceklerdir.

SSS: proxy gözlemlenebilirliği hakkında sık sorulan sorular

Şu anda hiçbir şey yoksa nereden başlamalı?

Her isteği zorunlu alanlarla yapılandırılmış biçimde loglamakla başlayın: proxy tanımlayıcısı, yanıt kodu, TTFB, boyut, deneme numarası, boyutlar. Metrikler ve panolar olmadan bile bu, olayları inceleme yeteneği verir. Sonraki adımda dört metrik ve bir-iki kritik alarm ekleyin. Her şeyi bir kerede inşa etmeye çalışmayın - minimum çalışan set, ideal yarım kalmıştan daha değerlidir.

Metrikler ne sıklıkla alınmalı?