Proxy havuzu gözlemlenebilirliği: metrikler, loglar, alarmlar ve bir dakikada bozulma teşhisi

Giriş: metrikler olmadan sorun "her şey yavaş" gibi görünür

Tanıdık bir sahne. Ekip sohbetine bir mesaj düşer: "Proxyler yavaş." Beş dakika sonra ikincisi: "bir de çok hata var." Sonra mühendislerin aralarında arkeoloji dediği şey başlar. Biri konsolu açar ve rastgele üç adres üzerinden elle curl çalıştırır. Biri proxyle alakası olmayan CPU yük grafiğine bakar. Biri elinde tek bir sayı olmadan sağlayıcı desteğine "bir şeyler ters" diye yazar. Bir saat geçer. Ortaya çıkar ki sadece havuzun bir kesiti, sadece tek bir ülkede bozulmuş ve bu "şimdi" değil, iki gün önce başlamış, kimse fark etmemiş.

Böyle bir hikâyeye bir saat harcayan ekiple bir dakika harcayan ekip arasındaki fark deneyim ya da yetenek değil. Fark, ikinci ekibin önceden neyi ölçeceğine, loglara neyi yazacağına ve neye alarm kuracağına karar vermiş olmasında. Ülke ve operatör bazında başarılı istek oranı grafiğiniz olduğunda "her şey yavaş" cümlesi somut bir iddiaya dönüşür: "14:32'den itibaren B bölgesindeki A operatörünün mobil proxylerinde ilk bayta kadar geçen sürenin p95'i 1,8 saniyeden 6,4 saniyeye çıktı, hata oranı değişmedi, yeniden deneme oranı üç katına çıktı." Böyle bir iddiayla çalışabilirsiniz: yükü yeniden dağıtırsınız, sağlayıcıya duyguyla değil veriyle bilet açarsınız ya da sorunun aslında proxylerde değil hedef kaynakta olduğunu anlarsınız.

Bu kılavuzda proxy havuzu etrafındaki gözlemlenebilirliği baştan sona ele alacağız. Neredeyse tüm faydalı bilgiyi veren dört sinyalin hangileri olduğunu, her log satırında hangi alanların bulunması gerektiğini ve hangilerinin asla bulunmaması gerektiğini, ortalama yanıt süresinin neden yalan söylediğini ve yüzdeliklerin nasıl doğru hesaplanacağını, tek bir kesitin bozulmasını görmek için verilerin boyutlara göre nasıl etiketleneceğini, nadiren ama yerinde tetiklenen alarmların nasıl kurulacağını ve panodan bir dakikada üç tipik sorun tablosunun nasıl ayırt edileceğini göreceksiniz. Sonda minimum teknoloji yığınını, sayılarla gerçek vakaları inceleyip sık sorulan soruları yanıtlayacağız.

Sınırları hemen çizelim. Havuzdan belirli bir IP seçimi, proxy sağlık kontrolleri ve sorunlu adreslerin karantinaya alınmasını burada ayrıntılı olarak tartışmıyoruz: buna ayrı bir materyal ayrıldı. Burada yalnızca iki şeyden söz ediyoruz: ölçüm ve uyarı. Aşağıda anlatılan her şey meşru mühendislik senaryolarına uygulanabilir: halka açık platformlarda fiyat izleme, farklı bölgelerde reklam gösterimini doğrulama, kendi servislerinizin coğrafyaya bağlı içeriğini test etme, kaynak kurallarına uyarak açık veri toplama.

Biraz temel: proxy özelinde gözlemlenebilirlik nedir

Klasik tanım der ki gözlemlenebilirlik (observability), bir sistemin iç durumunu dış çıktılarından anlamayı sağlayan özelliğidir. Mühendislik diline çevirirsek: sisteme önceden öngörmediğiniz yeni bir soru sorabilir ve yeni kod dağıtmadan yanıt alabilirsiniz. İzleme önceden bilinen soruları yanıtlar ("servis ayakta mı?"), gözlemlenebilirlik bilinmeyenleri ("bu alana giden istekler neden özellikle salı günleri mobil adresler üzerinden yavaşladı?").

Gözlemlenebilirliğin üç dayanağı iyi bilinir: metrikler (sayısal zaman serileri, saklaması ucuz, toplaması kolay), loglar (bağlamlı olaylar, saklaması pahalı ama ayrıntı içerir) ve izlemeler (tek bir isteğin bileşenler arasındaki yolu). Proxy havuzu için tablo biraz kendine özgü. Kodunuzla hedef site arasında, kontrol etmediğiniz bir dış altyapı durur: çıkış adresi, operatör, hedefe giden rota. Mobil bir baz istasyonuna ajan kuramazsınız. Dolayısıyla her şeyi ölçtüğünüz tek nokta, isteği proxy üzerinden gönderen kendi istemcinizdir. Havuz üzerinden geçen her istek arkasında iki iz bırakmalı: metrik artışı ve yapılandırılmış bir log satırı. İzlemeler faydalıdır ama çoğu ekip için gereksizdir; onlara yalnızca SSS bölümünde döneceğiz.

Bu neden özellikle proxy için önemli? Çünkü proxy bozulması neredeyse hiç çökme gibi görünmez. Sunucu yanıt vermiyor — bu basit. Proxy ise "biraz daha yavaş", "biraz daha sık bağlantı hatası veriyor", "bazen indirmeyi ortasında koparıyor". Bu belirtilerin her biri tek başına insanın dikkat eşiğinin altındadır. Toplamda ise veri toplama maliyetini ikiye katlar ve teslim tarihlerini bozar. Yavaş bozulmayı ancak ölçümle fark edersiniz.

Proxy için dört sinyal: başarı, gecikme, yeniden deneme, trafik

Güvenilirlik mühendisliğinde "altın sinyaller" diye bir kavram vardır: gecikme, trafik, hatalar ve doygunluk. Proxy havuzu için bu fikri uyarlar ve durumların %90'ı için yeterli olan dört sinyal elde ederiz. Neden yirmi değil de dört? Çünkü panodaki her ek grafik, nöbetçinin doğru olana bakma şansını azaltır. Dört sinyal, tek bir ekran satırına sığan ve on saniyede okunabilen şeydir.

Sinyal 1: başarılı istek oranı

Başarılı istek oranı (success rate), zaman penceresi içinde faydalı sonuçla biten isteklerin toplam istek sayısına oranıdır. Anahtar kelime "faydalı"dır. Proxy için başarı sadece HTTP 200 değildir. Başarı, hedef kaynağın beklediğiniz yanıtı verdiği ve yanıtın tamamen geldiği durumdur. Gövdenin ortasında kopan bir bağlantı başarı değildir, başlıklar 200 kodlu olsa bile. Hedef siteden gelen 403 kodu da başarı değildir, ama bu muhtemelen proxy'nin suçu değildir; bunu sonuç sınıflandırmasıyla ayırt ederiz.

Pratik kural: her isteğin sonucunu az sayıda kategoriye sınıflandırın. Örneğin: ok (beklenen yanıt alındı), proxy_connect_error (proxy'ye bağlantı kurulamadı), proxy_auth_error (proxy yetkilendirmeyi reddetti), upstream_timeout (proxy yanıt verdi ama hedef kaynak zamanında yanıt vermedi), upstream_4xx, upstream_5xx, truncated (gövde bitmeden bağlantı koptu). Bu sınıflandırma, sonraki tüm analizin temelidir. Başarı oranı ok'un tümüne oranı olarak hesaplanır, ama hata kategorilerinin her birinin oranına ayrı ayrı bakılır çünkü bunlar farklı sorumlulara işaret eder.

Sinyal 2: yüzdelik bazında gecikme

Proxy için gecikmeyi üç noktada ölçmek anlamlıdır: proxy ile bağlantı kurma süresi, hedef kaynağın yanıtının ilk baytına kadar süre (TTFB, time to first byte) ve toplam istek süresi. Birincisi proxy düğümünün erişilebilirliği hakkında konuşur. İkincisi proxy'den hedefe giden rotanın kalitesi ve hedefin yanıt hızı hakkında. Üçüncüsü kanalın bant genişliği hakkında. Sadece üçüncüsü artıyorsa ilk ikisi sabitken sorun bant genişliğinde, erişilebilirlikte değil. Birincisi artıyorsa sorun sizinle proxy arasında. Gecikme ortalamayla değil yüzdeliklerle hesaplanmalıdır; buna aşağıda ayrı bir bölüm ayırdık.

Sinyal 3: yeniden deneme oranı

Yeniden deneme oranı (retry rate) en az değer verilen sinyaldir. Çoğu istemci, hata durumunda isteği başka bir adres üzerinden otomatik yineleyecek şekilde yazılmıştır. Güvenilirlik açısından doğru, gözlemlenebilirlik açısından korkunçtur: başarılı istek oranı %99 kalır ama kaputun altında her istek üç kez yapılır. Trafiği üç katına ödersiniz, hedef kaynak üç kat yük alır, panoda her şey yeşildir. Yeniden deneme oranı gizli bozulmayı, görünür bozulmaya dönüşmeden önce açığa çıkarır. Deneme sayısının mantıksal istek sayısına oranı olarak hesaplanır: 1,0 değeri yeniden deneme olmadığı, 1,5 ise her ikinci isteğin tekrarlandığı anlamına gelir.

Sinyal 4: trafik tüketimi

Trafik tüketimi doğrudan parayla ilgili bir sinyaldir, çünkü Proxeon tarifeleri de dahil birçok tarife aktarılan veri hacmini hesaba katar. Ama teşhis rolü de vardır. Başarılı istek başına baytın ani artışı, hedef kaynağın farklı sayfalar göndermeye başladığı anlamına gelir: ağır dolgu sayfaları, başka bölümlere yönlendirmeler, değişmiş düzen. Ani düşüş ise tam sayfalar yerine kısa hata yanıtları aldığınız anlamına gelir. Trafiği iki yönde de sayın ve mutlaka başarılı istek sayısına göre normalize edin: "başarılı istek başına kilobayt", "saatte gigabayt"tan çok daha bilgilendirici bir metriktir.

Kodda nasıl görünür

Aşağıda Python'da Prometheus için asgari metrik seti var. Etiket setine dikkat edin: havuz, ülke, operatör, proxy tipi. Belirli proxy adresi etiketlerde bilinçli olarak yok; bunu boyutlar bölümünde açıklayacağız.

from prometheus_client import Counter, Histogram

LABELS = ["pool", "country", "operator", "proxy_type"]

REQUESTS = Counter("proxy_requests_total", "Логические запросы через пул", LABELS + ["outcome"])
ATTEMPTS = Counter("proxy_attempts_total", "Попытки, включая ретраи", LABELS + ["attempt_kind"])
TTFB = Histogram("proxy_ttfb_seconds", "Время до первого байта", LABELS, buckets=(0.1, 0.25, 0.5, 1, 2, 4, 8, 16, 30))
CONNECT = Histogram("proxy_connect_seconds", "Установление соединения с прокси", LABELS, buckets=(0.05, 0.1, 0.25, 0.5, 1, 2, 5))
BYTES = Counter("proxy_bytes_total", "Байты через пул", LABELS + ["direction"])

def observe(ctx, outcome, ttfb, connect, bytes_in, bytes_out, attempt):
base = dict(pool=ctx.pool, country=ctx.country, operator=ctx.operator, proxy_type=ctx.proxy_type)
kind = "first" if attempt == 1 else "retry"
ATTEMPTS.labels(**base, attempt_kind=kind).inc()
if outcome in ("ok", "upstream_4xx", "upstream_5xx", "truncated", "upstream_timeout"):
TTFB.labels(**base).observe(ttfb)
CONNECT.labels(**base).observe(connect)
BYTES.labels(**base, direction="in").inc(bytes_in)
BYTES.labels(**base, direction="out").inc(bytes_out)
if outcome == "ok" or attempt == ctx.max_attempts:
REQUESTS.labels(**base, outcome=outcome).inc()

Şu ayrıntıya dikkat edin: mantıksal istek sayacı yalnızca başarıda ya da denemeler tükendiğinde artar. Böylece başarı oranı kodunuzun kullanıcısı için sonucu, deneme sayacı ise havuzun gerçek işini yansıtır. İkisi arasındaki fark da yeniden deneme oranıdır.

Tablo: metrik, artışının anlamı, ilk eylem

Her istek için loglara ne yazmalı — ve ne yazmamalı

Metrikler "ne oluyor" sorusunu yanıtlar, loglar "tam olarak neyle". Pano "X ülkesi, Y operatörü" kesitinde hata artışı gösterdiğinde, bu kesitteki tüm adreslerin mi yoksa otuzdan ikisinin mi suçlu olduğunu anlamanız gerekir. Adres etiketli metrikler depoyu havaya uçurur, loglar uçurmaz, çünkü logları sürekli toplamaz, sorguyla filtreler ve ararsınız.

Log satırının zorunlu alanları

Proxy havuzu üzerinden her istek denemesi, tercihen JSON formatında, yapılandırılmış tek bir kayıt üretmelidir. Asgari yeterli saydığımız alan seti şu:

• ts — milisaniyeli UTC zaman damgası. Yerel saat değil. Asla.
• request_id — mantıksal isteğin kimliği, tüm denemeleri için ortak. Tek komutla bir isteğin tüm geçmişini toplamanızı sağlar.
• attempt ve max_attempts — deneme numarası ve limit. Deneme numarası olmadan ilk hatayı üçüncüden ayırt edemezsiniz.
• proxy_id — proxy'nin iç kimliği. Portlu adres değil, bağlantı dizesi değil. Ayrı bir korumalı tablo üzerinden gerçek adrese eşleyebileceğiniz iç kimlik.
• proxy_type, country, operator, pool — metriklerdeki aynı boyutlar. Bu, yeniden hesap yapmadan pano ile loglar arasında geçiş yapmanızı sağlar.
• target_host — hedefin alan adı. Tam URL değil: sorgu dizelerinde token ve kişisel veri olabilir.
• method — HTTP metodu.
• status — alındıysa HTTP yanıt kodu, aksi halde null.
• outcome — yukarıda sözü geçen sonuç sınıflandırması.
• error_class — sonuç ok değilse istisna sınıfı ya da kısa taşıma hata kodu.
• connect_ms, ttfb_ms, total_ms — üç gecikme milisaniye cinsinden.
• bytes_in, bytes_out — yanıt gövdesi ve istek boyutu.
• session_id — yapışkan oturum kullanıyorsanız oturum kimliği; hataların uzun oturumlarda yoğunlaştığını bu sayede görürsünüz.
• retry_reason — ikinci ve sonraki denemeler için: önceki denemenin sonucu.

Örnek satır:

{"ts":"2026-03-14T11:32:07.412Z","request_id":"7f3a9c1e","attempt":2,"max_attempts":3,"retry_reason":"upstream_timeout","proxy_id":"px-2841","proxy_type":"mobile","country":"RU","operator":"op_a","pool":"pricing","target_host":"shop.example","method":"GET","status":200,"outcome":"ok","error_class":null,"connect_ms":184,"ttfb_ms":1420,"total_ms":2310,"bytes_in":48211,"bytes_out":612,"session_id":"s-19b"}

Böyle bir satır yaklaşık 400 bayt. Saniyede 50 istekte bu, sıkıştırmasız günde yaklaşık 1,7 gigabayt, sıkıştırmayla 200–300 megabayt eder. Mütevazı bir bütçe için bile gayet yapılabilir.

Loglarda bulunmaması gerekenler

Burada mühendislikten sorumluluğa geçiyoruz. Liste kısa ama her madde önemli:

1. Proxy erişim bilgileri. En sık sızıntı, geliştiricinin "hata ayıklama için" tüm yapılandırmayı logladığı için http://kullanıcı:parola@host:port biçiminde bağlantı dizesinin tam olarak loga düşmesidir. Loglar kopyalanır, biletlere gider, meslektaşlara iletilir, yıllarca saklanır. İçlerindeki erişim bilgileri, logu bir kez gören herkesin erişebildiği erişim bilgileridir.
2. Proxy-Authorization başlığı ve hedef kaynağa giden başlıklar dahil diğer tüm yetkilendirme başlıkları.
3. Yanıt gövdesi. Kocaman, üçüncü kişilere ait kişisel veri içerebilir ve proxy teşhisi için neredeyse hiç gerekli değildir. Hedefin ne verdiğini anlamanız gerekiyorsa gövdenin hash'ini ve uzunluğunu saklayın, yanıtın kendisini ise kısa ömürlü ve yalnızca örneklemle sınırlı ayrı bir depoya koyun.
4. Cookies, iki yönde de.
5. Sorgu parametreli tam URL. Host ve gerekirse parametresiz yol yeterlidir.
6. Proxy'nin gerçek adresi açık biçimde, log ortak depoya gidiyorsa. İç kimlik yeterlidir.

Önerdiğimiz uygulama: her proxy ile ilgili kaydın geçtiği tek bir fonksiyon düzeyinde düzenlemeyi (redaction) uygulayın. Geliştiricilerin disiplinine güvenmeyin.

import re

CRED_IN_URL = re.compile(r"(https?|socks5h?)://[^/@:]+:[^/@]+@")
SENSITIVE_HEADERS = {"proxy-authorization", "authorization", "cookie", "set-cookie"}

def redact(record: dict) -> dict:
for key, value in list(record.items()):
if key.lower() in SENSITIVE_HEADERS:
record[key] = "[redacted]"
elif isinstance(value, str):
record[key] = CRED_IN_URL.sub(lambda m: m.group(1) + "://[redacted]@", value)
record.pop("body", None)
return record

Örnekleme ve saklama

Her denemeyi yazmak gerekli mi? Hataları — evet, hepsini. Başarılı denemeleri örnekleyebilirsiniz: saniyede yüzün üzerinde istek yoğunluğunda, gecikmeleri değerlendirmek için başarılı satırların %5–10'u yeterlidir, çünkü metrikler zaten tam resmi içerir. Önemli olan örnekleme kararının request_id bazında verilmesidir, her denemede rastgele değil: aksi halde ikinci denemeyi birincisi olmadan alırsınız. Ayrıntılı logların saklama süresi genelde 7–14 gündür; toplamlar ve metrikler daha uzun yaşar.

Ortalama yerine yüzdelikler: neden ortalama sorunu saklar

Yüz adresli bir havuz düşünün. Doksanı 0,8 saniyede yanıt veriyor. Onu 9 saniyede, çünkü aşırı yüklü bir baz istasyonuna denk geldiler. Ortalama yanıt süresi 1,62 saniye. Bir hafta önce, her şey iyiyken ortalama 1,4'tü. Yüzde 15 artış. Buna kim tepki verir? Kimse. Oysa her on isteğinizden biri dokuz saniye bekliyor ve sekiz saniyelik bir zaman aşımınız varsa her on istekten biri hatayla düşüyor.

Aritmetik ortalama, çana benzeyen dağılımları iyi tanımlar. Proxy üzerinden gecikmeler hiçbir zaman çana benzemez. Uzun sağ kuyruklu bir dağılımdır: isteklerin çoğu hızlıdır ama bazıları çok yavaştır ve kullanıcı deneyimini ve maliyeti tam da onlar belirler. Dahası, havuz üzerinden gecikmeler sıklıkla bimodaldır: "normal" bir tümsek ve "sorunlu adresler" tümseği vardır. Ortalama tam aralarına, gerçekte neredeyse hiç istek olmayan bir noktaya düşer.

p50, p95, p99 nedir

Yüzdelik, gözlemlerin belirli bir bölümünün altında kaldığı değerdir. p50 (medyan) — isteklerin yarısı bu değerden hızlıdır. p95 — %95 daha hızlı, %5 daha yavaş. p99 — yalnızca yüzde biri daha yavaş. Proxy havuzu için farklı amaçlarla üç yüzdelik izlemenizi öneririz:

• p50 "tipik" isteği gösterir. p50 artıyorsa çoğunluk bozulmuştur. Bu nadir ve ciddi bir sinyaldir.
• p95 — alarmlar için çalışma metriği. Sorunlu kesitlere duyarlıdır (yukarıdaki örnekte p95 anında 9 saniyeyi gösterir), ama tek tek aykırı değerlere karşı dayanıklıdır.
• p99 — zaman aşımları ve planlama metriği. Zaman aşımınız "sağlıklı" p99'un biraz üzerinde olmalıdır, aksi halde normal istekleri kesip onları yeniden denemeye dönüştürürsünüz.

Doğru nasıl hesaplanır

Veri azsa (pencerede binlerce değer) doğru hesaplayın: sıralayıp dizideki öğeyi alın.

def percentile(values, p):
if not values:
return None
ordered = sorted(values)
k = (len(ordered) - 1) * p / 100.0
lo = int(k)
hi = min(lo + 1, len(ordered) - 1)
return ordered[lo] + (ordered[hi] - ordered[lo]) * (k - lo)

ttfb_window = [0.8, 0.9, 0.7, 9.1, 0.85, 8.7, 0.78, 0.92, 0.81, 0.79]
print(percentile(ttfb_window, 50), percentile(ttfb_window, 95))

Doğru hesap ölçeklenmez: milyonlarca istek üzerinden bir haftalık p95 hesaplamak için tüm değerleri saklamanız gerekir. Bu yüzden endüstriyel sistemler yaklaşık yapılar kullanır.

Ölçekte nasıl hesaplanır: histogramlar

Prometheus ve uyumlu sistemler histogramı kova sayaçları kümesi olarak saklar: 0,1 s'den küçük, 0,25 s'den küçük, 0,5 s'den küçük kaç gözlem vardı vs. Yüzdelik kova içinde doğrusal interpolasyonla geri kazanılır. Doğruluk, kova sınırlarının ne kadar iyi seçildiğine bağlıdır. Proxy üzerinden gecikmeler için 100 milisaniyeden 30 saniyeye logaritmik ölçek iyi çalışır: 0,1; 0,25; 0,5; 1; 2; 4; 8; 16; 30. Sağlıklı p95'iniz 2 saniye civarında ve zaman aşımınız 15 ise bu ızgara kuyrukta %20–30 aralığında hata verir, bu alarm ve teşhis için yeterlidir.

histogram_quantile(0.95,
 sum by (le, country, operator) (
rate(proxy_ttfb_seconds_bucket{pool="pricing"}[5m])
 )
)

İçerideki sum by (le, ...) ifadesine dikkat edin. Bu kritik bir ayrıntıdır: farklı istemci örneklerinizin histogramları önce toplanmalı, sonra yüzdelik hesaplanmalıdır. Ters işlem — her örnekte p95 hesaplayıp ortalamak — matematiksel olarak anlamsızdır. Yüzdeliklerin ortalaması yüzdelik değildir. Bu en yaygın hatalardan biridir ve sorunu sıradan ortalama kadar güvenilir biçimde saklayabilir.

Kuyrukta yüksek doğruluk gerekiyorsa (örneğin iç müşterilere gecikme SLA'sı satıyorsanız) sabit bellek hacminde yüzde birin altında hata veren t-digest veya HDR histogram gibi yapılar kullanın. Çoğu ekip için standart histogramlar yeterlidir.

Boyutlara göre etiketleme: ülke, operatör, proxy tipi

İşte boyutların neden gerekli olduğunu gösteren bir senaryo. 400 adresli bir havuzunuz var, %5'i bir bölgede tek bir operatörün mobil adresleri. Bu kesit tamamen bozuldu: başarı oranı %10'a düştü. Havuz genelindeki başarı oranı grafiği ne gösterir? %99'dan %94,5'e düşüş. Fark edilir ama kritik değil. Nöbetçi "ağ dalgalanıyor" diye düşünüp geçer. Oysa bu bölgeden veri alan müşteri eli boş kalır.

Boyutlara göre etiketleme (Prometheus terminolojisinde label'lar) tam da bu sorunu çözer: toplamı kesitlere ayırıp sorunun yerelleştiğini görmenizi sağlar. Ama etiketlemenin bir bedeli vardır ve bunu anlamak gerekir.

Hangi boyutları seçmeli

İyi bir boyutun iki özelliği vardır: sınırlı sayıda değeri olmalı ve ona göre bölme gerçek bir teşhis sorusunu yanıtlamalı. Proxy havuzu için metriklerde dört boyut öneririz:

• proxy_type — mobil, rezidenşıl, veri merkezi. Farklı tipler farklı bozulur ve farklı maliyettedir.
• country — çıkış adresinin ülkesi. Genelde 1 ila 30 değer.
• operator — adresin çıktığı operatör ya da özerk sistem. Sorunlar sıklıkla tam da burada yerelleşir: aşırı yüklü bir baz istasyonu ya da operatörde kötü bir peering.
• pool — mantıksal amaç: bu kesiti hangi ürün ya da görev kullanıyor. Olayları iş etkisine göre ayırmanızı sağlar.

Düşünülmesi gereken beşinci boyut target_host, hedef host. Proxy sorunlarını hedef sorunlarından ayırmak için gerekir. Ama binlerce farklı alan adına gidiyorsanız kardinalite patlar. Ödün: metrik etiketinde yalnızca hacimce ilk 20 hostu bırakın, gerisini other değerine düzleştirin.

Kardinalite aritmetiği

Her benzersiz etiket değeri kombinasyonu ayrı bir zaman serisidir. Hesaplayalım: 3 tip × 10 ülke × 15 operatör × 4 havuz × 7 sonuç = yalnızca istek sayacı için 12.600 seri. 9 kovacıklı bir histogram kendi seri sayısını 10 ile çarpar. Toplamda 50–60 bin seri civarı. Bu Prometheus için rahat. Şimdi proxy adresli bir etiket eklediğinizi düşünün (400 değer). Seri sayısı 400 katına çıkar — 20 milyona. Bu artık "rahat" değil, depolamanın ölümü.

Buradan şu kural çıkar: belirli proxy adresi loglarda yaşar, metriklerde değil. Metrikler "hangi kesit bozuldu", loglar "kesit içindeki hangi adresler" sorusunu yanıtlar. Bu iş bölümü hem hızı hem ayrıntıyı, maliyeti patlatmadan verir.

Kesiti bulan sorgular

Teşhisin ana sorusu: "en kötü nerede?" Bunu kesitleri başarı oranına göre sıralamak yanıtlar:

bottomk(5,
 sum by (country, operator, proxy_type) (rate(proxy_requests_total{outcome="ok"}[10m]))
 /
 sum by (country, operator, proxy_type) (rate(proxy_requests_total[10m]))
)

İkinci soru: "bu yeni bir sorun mu yoksa hep mi böyleydi?" Bunu geçmişle karşılaştırma yanıtlar:

(
 sum by (operator) (rate(proxy_requests_total{outcome="ok"}[10m])) / sum by (operator) (rate(proxy_requests_total[10m]))
)
-
(
 sum by (operator) (rate(proxy_requests_total{outcome="ok"}[10m] offset 1d)) / sum by (operator) (rate(proxy_requests_total[10m] offset 1d))
)

Negatif değer, kesitin bir gün önceye göre ne kadar kötüleştiğini gösterir. Panodaki böyle bir grafik "bir yerde bir şeyler ters" ifadesini "C ülkesindeki B operatörü düne göre eksi 12 puan"a dönüştürür.

Boyut değerleri nereden gelir

Ülke ve proxy tipi genelde havuz yapılandırmasından bilinir. Operatörü sağlayıcının meta verilerinden elde edebilirsiniz: örneğin Proxeon panelinde ve API'sinde adresler, havuzu başlatırken çekip proxy'nin iç kimliğinin yanında önbelleğe aldığınız coğrafya ve operatör bilgisiyle donatılmıştır. Operatörü istek anında dış veritabanları üzerinden belirlemek doğru değildir: gecikme ekler ve gereksiz bir bağımlılık yaratır.

Gürültü yapmayan alarmlar: eşikler, pencereler, histerezis

Uyarı sistemiyle başa gelebilecek en kötü şey kaçırılan bir olay değildir. En kötüsü, nöbetçinin günde 40 bildirim alması ve bunların 39'unun hiçbir anlam taşımaması, kırkıncıyı da okumayı bırakmasıdır. Görmezden gelinen uyarı, hiç uyarı olmamasından kötüdür, çünkü kontrol illüzyonu yaratır.

İlke 1: alarm nedene değil belirtiye

"px-2841 proxy hata verdi" alarmını kurmayın. Tek bir adresin hasta olma hakkı vardır; bununla havuz içindeki karantina mekanizması ilgilenir ki burada tartışmıyoruz. Alarmı verinizin kullanıcısının hissettiği şeye kurun: havuz başarı oranı hedefin altında, p95 hedefin üstünde, yeniden denemeler hedefin üstünde. Boyutları doğru yaptıysanız nedeni panodan bir dakikada bulursunuz. Alarmın görevi uyandırmak, açıklamak değil.

İlke 2: asgari trafik hacmi

Beş dakikada iki istek üzerinden %50 başarı oranı, bir olay değil, bir başarısız istektir. Oranla ilgili her kural pencere içinde asgari istek sayısı koşulu içermelidir. Aksi halde gece trafik düştüğünde yanlış tetiklenmelere boğulursunuz.

İlke 3: pencereler ve hata bütçesi tükenme hızı

Hedef güvenilirlik seviyesi tanımladıysanız (örneğin aylık %98 başarılı istek), bir hata bütçeniz vardır: %2 istek. İyi bir alarm anlık değere değil bütçenin tükenme hızına tepki verir. Güvenilirlik alanında standart hâline gelen uygulama çok pencereli alarmlardır: kısa pencere (5 dakika) ani düşüşleri yakalar, uzun pencere (1 saat) yavaş bozulmayı yakalar ve kısa süreli sıçramaları dışlamak için ikisi aynı anda aşılmalıdır.

İlke 4: histerezis

Histerezis, tetikleme ve sönme uyarısı için farklı eşiklerdir. Alarm başarı oranı %95'in altına düştüğünde tetiklenip %95'in üstüne çıktığında sönüyorsa, %95 civarında salınan metrik birkaç dakikada bir "tetiklendi — söndü — tetiklendi" bildirim serisi üretir. Çözüm: %95'te tetikle, %97'de söndür. Ya da daha basitçe, koşulun belirli bir süre kesintisiz sürmesini isteyin (Prometheus'ta for anahtar kelimesi) ve sönme için de bir gecikme tanımlayın.

İlke 5: önem düzeyleri ve yönlendirme

Her şeyi telefonla ulaştırmak gerekmez. Uyarıları iki-üç düzeye ayırın: kritik (veri tüketenleri şu anda etkiliyor — nöbetçiye arama ya da push), uyarı (kesitte bozulma, yeniden deneme artışı, trafik anomalisi — kanala mesaj, mesai saatinde ilgilenilir), bilgilendirici (örnektan veri gelmemesi, trafik limitine yaklaşma — günlük özet).

Örnek kural seti

groups:
- name: proxy-pool
 rules:
 - record: pool:success_ratio:5m
expr: sum by (pool) (rate(proxy_requests_total{outcome="ok"}[5m])) / sum by (pool) (rate(proxy_requests_total[5m]))
 - record: pool:success_ratio:1h
expr: sum by (pool) (rate(proxy_requests_total{outcome="ok"}[1h])) / sum by (pool) (rate(proxy_requests_total[1h]))
 - record: pool:request_rate:5m
expr: sum by (pool) (rate(proxy_requests_total[5m]))

 - alert: ProxyPoolSuccessLow
expr: pool:success_ratio:5m < 0.95 and pool:success_ratio:1h < 0.97 and pool:request_rate:5m > 0.5
for: 5m
labels: { severity: critical }
annotations:
 summary: "Доля успеха по пулу {{ $labels.pool }} ниже цели"

 - alert: ProxyPoolLatencyHigh
expr: histogram_quantile(0.95, sum by (le, pool) (rate(proxy_ttfb_seconds_bucket[10m]))) > 4 and pool:request_rate:5m > 0.5
for: 10m
labels: { severity: warning }

 - alert: ProxyPoolRetryRateHigh
expr: sum by (pool) (rate(proxy_attempts_total[15m])) / sum by (pool) (rate(proxy_requests_total[15m])) > 1.4
for: 15m
labels: { severity: warning }

 - alert: ProxyPoolSliceDegraded
expr: (sum by (pool, country, operator) (rate(proxy_requests_total{outcome="ok"}[15m])) / sum by (pool, country, operator) (rate(proxy_requests_total[15m]))) < 0.85 and sum by (pool, country, operator) (rate(proxy_requests_total[15m])) > 0.2
for: 15m
labels: { severity: warning }

 - alert: ProxyPoolNoData
expr: absent(proxy_requests_total) or pool:request_rate:5m == 0
for: 10m
labels: { severity: warning }

Son kurala dikkat edin. Veri yokluğu en sinsi arızadır: istemci çöker, metrik yok, grafikler düz ve yeşil, herkes rahat. Sessizliğe alarm zorunludur.

Her yeni alarm için kontrol listesi

1. Alıcının ne yapacağı açıklamada yazıyor mu? Hayırsa kural hazır değil.
2. Asgari trafik koşulu var mı?
3. for gecikmesi ya da histerezis var mı?
4. Kural son bir ayın geçmişinde test edildi mi: kaç kez tetiklenirdi ve kaçı gerçek olaydı?
5. Hangi önem düzeyine ait olduğu ve nereye yönlendirileceği belli mi?
6. Ters süreç var mı: alarm tetiklendi ve yanlış çıktıysa kim, ne zaman gözden geçirecek?

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

Pano grafik galerisi değil, karar aracıdır. İyi bir proxy havuzu panosu bir huni gibi kurgulanır. Üst satır: tüm havuz için son 6 saatin dört sinyali, dünün ince çizgiyle üst üste bindirilmiş hâli. İkinci satır: aynı sinyaller ülke, operatör ve tipe göre bölünmüş — kötü değere göre sıralı tablo ya da ısı haritası. Üçüncü satır: ilk 10 hedef host için başarı oranı ve TTFB. Dördüncü: bağlantı, TTFB ve toplam süre oranı. Artı, dağıtım ve havuz yapılandırma değişikliklerinin dikey işaretleri.

Böyle bir panoyla teşhis üç soruyu yanıtlamaya indirgenir: "tüm havuz mu yoksa bir kesit mi bozuldu?", "tüm hedefler mi yoksa bir tanesi mi bozuldu?", "üç gecikmeden hangisi arttı?". Yanıt kombinasyonları üç tipik tabloyu verir.

Tablo 1: tüm kesitler aynı anda bozuldu

Tüm ülkeler, tüm operatörler, tüm proxy tipleri hata ya da gecikme artışını dakika farkıyla eşzamanlı gösteriyor. Dış sağlayıcılar ve operatörler böyle bozulmaz: onların sizin tarafınızda ortak bir arıza noktası yoktur. Yani sorun sizde: çıkış kanalınız, DNS'iniz, dosya tanıtıcılarının ya da yerel portların tükenmesi, zaman aşımlarını veya bağlantı havuzu boyutunu değiştiren yakın tarihli bir dağıtım, aynı makinede başka bir süreçle CPU rekabeti. İlk eylem: dağıtım işaretine ve proxy ile bağlantı süresine bakın. Bağlantı süresi artmış ve (bağlantı düşülünce) TTFB sabitse sorun sizinle proxy düğümleri arasındadır ve neredeyse kesinlikle sizin tarafınızda ya da ağ sağlayıcınızdadır.

Tablo 2: tek kesit bozuldu

Bir ülkede tek bir operatör ya da bir proxy tipi düşüş gösteriyor, diğer kesitler sabit. Bu en sık görülen tablo. Nedeni operatör tarafında (ağ segmentinde aşırı yüklenme, bakım) ya da proxy sağlayıcısının altyapı segmentinde. İlk eylem: bu kesitin yük dağıtımındaki ağırlığını geçici olarak düşürün (mekanizma bu makalenin dışında) ve sağlayıcının desteğine somut verilerle yazın: kesit, başlangıç zamanı, öncesi ve sonrası metrikler, örnek request_id'ler. Proxeon desteği, "sizde her şey kötü" mesajına kıyasla böyle başvurulara daha hızlı yanıt verir, çünkü hazır bir yerelleştirme almış olur. İkinci eylem: kesitteki loglara bakıp kesit içindeki tüm adreslerin mi bozulduğunu yoksa birkaçının mı olduğunu anlayın.

Tablo 3: tek hedef host için başarı oranı düştü, gecikmeler normal

Havuzun tüm kesitleri hâlâ bir host hariç diğer tüm hostlara iyi gidiyor. O host için upstream_4xx oranı artıyor ya da istek başına bayt hacmi değişiyor. Burada proxy'lerin hiçbir suçu yok. Hedef kaynak davranışını değiştirdi: hız sınırı getirdi, sayfa yapısını değiştirdi, isteklerin bir kısmına farklı içerik göndermeye başladı. İlk eylem: bu kaynağa istek yoğunluğunu düşürün ve toplamanızın kullanım kurallarına uyup uymadığını kontrol edin. İkinci: örneklemde içeriği doğrulayın ve yanıt doğrulamasını güncelleyin. Bu durumda kesinlikle yeniden deneme sayısını artırmak ya da adresleri daha sık değiştirmek doğru değildir — bu yalnızca kaynağa yükü ve trafik maliyetinizi artırır.

Tablo 4 (bonus): yeniden denemeler artıyor, başarı sabit

Başarı oranı %99, gecikmeler katlanılabilir, ama yeniden deneme oranı 1,1'den 1,8'e çıktı. Bu gizli bozulma. Şu anda bile size para kaybettiriyor ve deneme stoku tükenir tükenmez görünür bozulmaya dönüşecek. İlk eylem: tekrarlara hangi sonucun yol açtığına bakın (loglarda retry_reason alanı) ve sonra ilk üç tablodan birine göre ilerleyin.

60 saniyede teşhis kontrol listesi

1. Saniye 0–10: üst satır. Dört sinyalden hangisi dünün çizgisinden ayrıldı? Tam olarak ne zaman?
2. Saniye 10–25: kesit tablosu. Tek kesit mi kırmızı, hepsi mi? Hepsiyse tablo 1, dağıtım işaretlerine ve kendi altyapınıza gidin.
3. Saniye 25–40: hedef host tablosu. Tek host mu, hepsi mi? Tekse tablo 3, proxy'ler ilgisiz.
4. Saniye 40–50: gecikme oranı. Bağlantı mı, TTFB mi, toplam süre mi arttı?
5. Saniye 50–60: tek cümleyle ifade edin: "[zaman]da [kesit] kesitinde [hedef] için [metrik] [önceki]den [şimdi]ye çıktı, muhtemelen [hipotez] nedeniyle". Bu cümle olay kanalına ve sağlayıcı biletine gider.

Gözlemlenebilirliğin faydasını sıfırlayan tipik hatalar

Proxy etrafında onlarca izleme kurulumu gördük. Hatalar şaşırtıcı bir istikrarla tekrarlanıyor.

• Ana metrik olarak ortalama yanıt süresi. Zaten tartıştık: ortalama kuyruğu saklar, kuyruk da sorunun kendisidir.
• Örnekler arası yüzdeliklerin ortalanması. Hazır p95'leri değil histogramları toplayın.
• Metrik etiketi olarak proxy adresi. Kardinalite patlaması ve bir ay içinde depolamanın çöküşü.
• Loglarda erişim bilgileri. Tek bir "hata ayıklama için" satırı — ve parola bir yıl boyunca ortak log deposunda.
• Yeniden denemelerin başarı sayılması. Yalnızca nihai sonucu sayarsanız havuzun gereğinden üç kat yoğun çalıştığını asla göremezsiniz.
• Hedef kaynaktan gelen 429 ve 403 kodlarının proxy hatası olarak kaydedilmesi. Bu bir sınıflandırma hatasıdır; soruşturmayı yanlış yöne çeker ve sağlayıcıyla ilişkileri bozar.
• Üç yerine tek gecikme. Bağlantı, TTFB ve toplam süreyi ayrı ölçmezseniz erişilebilirlik sorununu bant genişliği sorunundan ayırt edemezsiniz.
• Asgari trafiksiz alarm. Gece gürültüsü ve uyarılara güven kaybı.
• Her bir adrese ayrı alarm. Bu karantinanın görevi, insan uyarımının değil.
• Veri yokluğuna alarm olmaması. İstemci çöktü — grafikler yeşil.
• Loglarda yerel saat. Sağlayıcı ve başka saat dilimindeki meslektaşlarla veri eşleştirmek işkenceye dönüşür.
• Dağıtım işareti olmayan pano. Olayların yarısı kod ya da yapılandırma değişikliğiyle çakışır. İşaret olmadan neden dışarıda ararken içeridedir.
• Ayrıntılı logları sonsuza saklamak. Pahalı ve anlamsız: iki hafta sonra ayrıntılar gerekmez, toplamlar zaten metriklerde vardır.

Aşırı karmaşıklaştırmadan minimum yığın

Gözlemlenebilirliği proje olsun diye projeye çevirmek kolaydır. Üç kişilik bir ekip, saniyede 20 istek yapan bir istemci için dağıtık mesaj kuyruğu, sütunsal veritabanı kümesi ve izleme sistemi kurar. Yapmayın. Yığın ölçeğe uygun olmalı.

Seviye 1: tek servis, saniyede 50 isteğe kadar

Dosyaya ya da standart çıktıya yapılandırılmış JSON loglar ve dakikada bir bunları toplayıp dört sinyali basit bir tabana ya da aynı loga yazan tek bir betik yeter. Pano — tablodan grafik üretebilen herhangi bir araç. Alarmlar — toplamları eşiklerle karşılaştırıp mesajlaşma uygulamasına mesaj atan cron betiği. Bu yığın bir günde kurulur ve ihtiyaçların %80'ini kapatır.

Seviye 2: birkaç servis, saniyede 50–1000 istek

Standart set: metrikler için Prometheus, panolar için Grafana, uyarı yönlendirmesi için Alertmanager, etiketle indekslenen loglar için Loki ya da benzeri depolama. İstemciler metrikleri yerleşik HTTP uç noktası üzerinden dışa aktarır ve JSON logları standart çıktıya yazar; ajan bunları toplar. Kayıt kuralları (recording rules) başarı oranlarını önceden hesaplar, böylece panolar anında açılır. Bu, yukarıdaki örneklerde anlatılan konfigürasyondur ve ekiplerin büyük çoğunluğunu kapsar.

Seviye 3: onlarca servis, saniyede binlerce istek

Burada tek toplama katmanı olarak OpenTelemetry, loglar için milyarlarca satır üzerinde serbest analitik sorgu yapabilen sütunsal depolama ve belki karmaşık zincirler için izlemeler anlam kazanır. Ama bu düzeyde bile dört sinyal ve log yapısı değişmez. Yalnızca taşıma ve depolama değişir.

Tamamlayıcı olarak sağlayıcı verileri

Proxy sağlayıcısı kendi tarafını görür: her port için trafik tüketimi, aktif bağlantı sayısı, son rotasyon zamanı. Proxeon paneli ve API'si bu istatistikleri verir; bunları kendi metriklerinizin yanına çekmek faydalıdır — en azından trafik tüketimini dengelemek için: bayt sayacınızla sağlayıcının sayacı %10–15'ten fazla farklıysa ölçümünüzde bir sorun var (çoğunlukla başlıklar, TLS el sıkışmaları ya da kopan yanıtlar hesaba katılmıyordur). Ama sağlayıcı verileri sizinkinin yerini almaz: hangi isteğin görev açısından başarılı olduğunu yalnızca siz bilirsiniz.

Tek ölçüm noktası olarak istemci sarmalayıcısı

Yığın düzeyi ne olursa olsun, tüm ölçümler HTTP istemcisinin üzerindeki tek bir sarmalayıcıdan geçmelidir. "Burada ölçelim, burada unutmuşuz" olmaz. Şematik olarak:

import time, json, sys, requests

def fetch_via_proxy(ctx, url, timeout=(5, 20)):
t0 = time.perf_counter()
outcome, status, err = "ok", None, None
ttfb = connect = total = 0.0
bytes_in = 0
try:
session = ctx.session # уже настроена на прокси по внутреннему proxy_id
resp = session.get(url, timeout=timeout, stream=True)
ttfb = time.perf_counter() - t0
status = resp.status_code
body = resp.content
bytes_in = len(body)
total = time.perf_counter() - t0
if status >= 500: outcome = "upstream_5xx"
elif status >= 400: outcome = "upstream_4xx"
elif not ctx.validate(body): outcome = "invalid_content"
except requests.exceptions.ProxyError as e:
outcome, err = "proxy_connect_error", type(e).__name__
except requests.exceptions.ReadTimeout as e:
outcome, err = "upstream_timeout", type(e).__name__
except requests.exceptions.ChunkedEncodingError as e:
outcome, err = "truncated", type(e).__name__
finally:
total = total or (time.perf_counter() - t0)
observe(ctx, outcome, ttfb, connect, bytes_in, len(url), ctx.attempt)
record = redact({"ts": ctx.now_utc(), "request_id": ctx.request_id, "attempt": ctx.attempt,
"proxy_id": ctx.proxy_id, "proxy_type": ctx.proxy_type, "country": ctx.country,
"operator": ctx.operator, "pool": ctx.pool, "target_host": ctx.host(url),
"status": status, "outcome": outcome, "error_class": err,
"ttfb_ms": int(ttfb * 1000), "total_ms": int(total * 1000), "bytes_in": bytes_in})
sys.stdout.write(json.dumps(record, ensure_ascii=False) + chr(10))
return outcome, status

invalid_content sonucuna dikkat edin: doğrulamanızı geçmeyen 200 kodlu yanıt (örneğin beklenen veri bloğu olmayan sayfa) başarı değildir. Çoğunlukla hedef kaynağın davranış değişikliğini maskeleyen tam da bu yanıtlardır.

Vakalar: gözlemlenebilirliğin iş başındaki hâli

Vaka 1: tek operatör, tek ülke, haftada iki saat kayıp

Halka açık ticaret platformlarında fiyat izleyen bir ekip, yaklaşık 300 mobil ve rezidenşıl adresli bir havuz üzerinden saniyede yaklaşık 40 istek yoğunluğuyla çalışıyordu. Operatör etiketlemesini uygulamadan önce tek bir şey görüyorlardı: genel p95 TTFB zaman zaman 1,6'dan 3–4 saniyeye sıçrıyor, birkaç saat sürüyor, başarı oranı 3–5 puan düşüyordu. Her böyle olayın soruşturması bir ila iki saat sürüyor ve çoğunlukla "kendiliğinden geçti" cümlesiyle bitiyordu. country ve operator etiketleri eklenince ilk olay iki dakikada yerelleşti: tek bir bölgede tek bir operatörün mobil adresleri, p95 orada normal 2 saniyeye karşı 11 saniyeydi. Havuzun kalan %85'i tümüyle sorunsuzdu. Ekip bu kesitin yük dağıtımındaki ağırlığını düşürdü, sağlayıcıya zaman aralıkları ve metriklerle bir rapor gönderdi ve birkaç saat içinde operatörde planlı bakım onayını aldı. Çeyrek sonunda sonuç: teşhis süresi 90 dakikadan 5 dakikaya düştü, olay sayısı değişmedi ama genel p95 üzerindeki etkileri ayırt edilemez hâle geldi.

Vaka 2: gizli yeniden denemeler ve trafik faturasına +%38

Başka bir ekip, görev sayısı sabit ve başarı oranı %98,5 stabilken bir ayda trafik tüketiminin %38 arttığını fark etti. İlk hipotez — hedef sayfalar ağırlaştı. Başarılı istek başına bayt metriği bunu çürüttü: 46 kilobayt, eskisi gibi. Ama o güne kadar kimsenin bakmadığı yeniden deneme oranı 1,08'den 1,52'ye çıkmıştı. Loglarda retry_reason alanının incelenmesi gösterdi ki: tekrarların neredeyse tamamına, yavaş yanıt vermeye başlayan ama ikinci denemede zaman aşımına sığan bir hedef host için upstream_timeout sonucu yol açıyordu. Proxy'ler hiçbir şekilde sebep değildi. Ekip bu host için okuma zaman aşımını 8'den 15 saniyeye çıkardı (sağlıklı p99 11'di), ona yapılan istek yoğunluğunu düşürdü ve trafik tüketimini üç günde eski seviyesine getirdi. Ders: yeniden deneme oranı para metriğidir.

Vaka 3: haftada 200 bildirimden altıya

Üçüncü ekip, "herhangi bir kesitte 1 dakikada başarı oranı %90'ın altına" kuralıyla, trafik koşulu olmayan bir uyarı sistemi devraldı. Geceleri bazı kesitlerden dakikada iki-üç istek geçerken kural onlarca kez tetikleniyordu. Nöbetçiler sesi kapattı. Gerçek bir olay — bütün bir segmentin erişilebilirliğinin dört saat düşmesi — sabah şikâyetlerle fark edildi. Kuralların yeniden düzenlenmesi bir gün sürdü: asgari trafik koşulu eklendi, iki pencere getirildi (5 dakika ve 1 saat), 10 dakikalık for gecikmesi eklendi, kesitler warning düzeyine alındı ve havuz düzeyinde tek bir critical bırakıldı. Sonuç: haftada yaklaşık altı bildirim, bunların dört-beşi gerçek eylem gerektiriyor. Nöbetçiler sesi yeniden açtı.

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

Metrikler ve loglar varsa izlemelere gerek var mı?

Çoğu ekip için yok. Proxy üzerinden bir istek on mikros travmadan geçmez; tek geçişi vardır. Burada izlemenin rolünü loglardaki request_id oynar: onunla bir isteğin tüm denemelerini toplarsınız. İzlemeler, proxy istemcisi uzun bir zincirin (görev kuyruğu, parser, doğrulayıcı, veritabanı yükleyici) sadece bir parçası olduğunda ve zamanın tam olarak nerede kaybolduğunu anlamanız gerektiğinde faydalı hâle gelir.

HTTP istemcisi doğrudan vermiyorsa TTFB nasıl ölçülür?

Çoğu istemci, akış okuma (stream=True veya benzeri) istendiğinde başlıklar alındıktan sonra kontrolü döndürür. Dönüş anı TTFB'nin yaklaşık değeridir. Bağlantı süresi taşıma katmanında daha doğru ölçülür: birçok kütüphanenin bağlantı olaylarına kancaları, bazılarının istek aşamaları hakkında hazır bilgisi vardır. Kanca yoksa isteğin ilk baytını gönderme süresini ayrı bir alt düzey ölçümle ölçebilirsiniz, ama pratik amaçlar için akış okuma yaklaşımı yeterlidir.

Proxy hatasını hedef kaynak hatasından nasıl ayırt ederim?

Oluştuğu yere göre. Proxy ile bağlantı kurulamadıysa ya da proxy kendi kodunu döndürdüyse (örneğin yetkilendirme sorunlarında 407 ya da ağ geçidinin kendine özgü yanıtı), bu proxy hatasıdır. Proxy isteği kabul edip de sonrasında hedef sunucudan kod geldiyse ya da yanıt beklemede zaman aşımı olduysa, bu proxy ile hedef arasındaki ya da hedefin kendisindeki hatadır. Sınıflandırmayı bu sınırda yapın, sonra kesitlere göre karşılaştırın: hedef hataları tüm kesitlerde aynı anda görünür, proxy hataları belirli kesitlerde.

Sağlıklı yeniden deneme oranı ne olmalı?

Hedeflere ve proxy tipine bağlı. Mobil adresler için 1,05–1,15 normal sayılabilir: kablosuz ağ doğası gereği daha az öngörülebilir. Veri merkezi için 1,01–1,05. Mutlak değerden çok istikrarı önemlidir: haftalık temel seviyeye göre %30 artış, mutlak değer hâlâ mütevazı görünse bile incelemeye değerdir.

Geçmiş yoksa alarm eşikleri nasıl seçilir?

Uyarısız gözlemle başlayın: iki hafta veri toplayın, başarı oranının ve p95'in günlere ve saatlere göre dağılımına bakın. critical eşiğini, bu iki haftada en fazla bir-iki kez tetiklenecek ve her ikisinde de olay olduğunu kabul edeceğiniz şekilde koyun. warning eşiğini — haftada birkaç kez tetiklenecek şekilde. Sonra her ay gözden geçirin: hiç eyleme yol açmayan alarm ya sıkılaştırılır ya silinir.

Hata durumlarında bile yanıt gövdesini saklamak gerekli mi?

Taşıma hatalarında gövde yoktur. Beklenmeyen içerikli yanıtlar için (invalid_content) ilk birkaç yüz baytı ya da hash'i ve uzunluğu, bir-iki gün ömürlü, kişisel verilerden arındırması zorunlu ayrı bir depoda saklamak faydalıdır. Tam gövdeleri saklamak gerekmez: ağırdır, üçüncü kişilere ait veri içerebilir ve proxy teşhisi için neredeyse her zaman hangi tür sayfanın geldiğini anlamak yeterlidir.

Kendi trafik muhasebemi sağlayıcının verileriyle nasıl karşılaştırırım?

Başlıklar dahil iki yöndeki baytları sayın ve port ya da oturum bazında günlük toplamları sağlayıcının panelinde gösterdiğiyle karşılaştırın. %5–10 fark normaldir: TLS ek yükü ve kopan bağlantılar sizde hesaba katılmıyordur. %20'nin üzerindeki fark, yalnızca gövdeyi sayıp saymadığınızı ve gövdeyi okumadan istisnayla biten denemeleri kaybedip kaybetmediğinizi kontrol etmek için bir sebeptir.

Anlatılan yaklaşımın sıfırdan uygulanması ne kadar sürer?

HTTP üzerine hâlihazırda sarmalayıcısı olan tek bir istemci için: metrikler ve log yapısı bir gün, pano bir gün, alarm kuralları bir gün ve critical alarmları açmadan önce iki hafta gözlem. Farklı dillerde birden fazla istemciniz varsa asıl süre, ortak sonuç ve etiket seti üzerinde anlaşmaya gider — burada acele etmemek önemli, çünkü bir yıl geçmiş biriktikten sonra metriği yeniden adlandırmak çok acı verir.

Sağlayıcıda adreslerin bir kısmı için operatör verisi yoksa ne yapmalı?

unknown değeri tanımlayın ve oranını izleyin. Havuzun %10–15'inden fazlası unknown ise operatör bazlı kesitleriniz anlamını yitirir — sağlayıcıdan tam meta veri isteyin ya da adresleri havuza eklerken bir kez elle etiketleyin.

Sonuç: bir saat yerine bir dakika

Başlangıçtaki sahneye dönelim. "Proxyler yavaş" — bilgi içermeyen bir cümle. Bu kılavuzda anlatılan her şey tek bir amaca hizmet ediyor: onu sayısı, kesiti, zamanı ve hipotezi olan bir cümleye dönüştürmek. Dört sinyal — başarı oranı, yüzdelik bazında gecikme, yeniden deneme oranı, trafik tüketimi — havuzun durumunun resmini verir. İstek kimliği, proxy kimliği, deneme numarası, kod, üç gecikme ve boyut içeren yapılandırılmış log — soruşturma ayrıntıları. Ortalama yerine yüzdelikler, gerçek sorunların yaşadığı kuyruğu gösterir. Ülke, operatör ve tipe göre etiketleme, bozulmayı kesite kadar yerelleştirir. Asgari trafik, iki pencere ve histerezisli alarmlar nadiren ve yerinde tetiklenir. Huni biçimli pano üç soruyu bir dakikada yanıtlar.

Yarın nereden başlamalı? İlk adım — tek bir sonuç sınıflandırması ve tek bir kayıt fonksiyonu olan bir istemci sarmalayıcısı. İkinci — ülke, operatör ve tipe göre etiketli TTFB histogramı ve deneme sayacı. Üçüncü — her şeyin istisnasız geçtiği log düzenleme fonksiyonu. Dördüncü — dört grafik ve kesit tablosundan oluşan bir pano. Beşinci — iki hafta gözlem, ancak ondan sonra alarmlar. Bir ay sonra yeniden deneme oranı grafiğine bakıp, muhtemelen şaşıracaksınız: havuz size göründüğünden belirgin biçimde daha yoğun çalışıyormuş. Bir çeyrek sonra ise "bizde her şey yavaş" cümlesi sohbetinizden kaybolacak — sorunlar biteceği için değil, her birini adıyla çağırabileceğiniz için.