feat(pl24): günlük HTTP bütçesi, kullanıcı rezervi ve proxy_logs telemetrisi #262

Merged
root merged 1 commits from dev into main 2026-09-17 13:37:51 +03:00
Owner

Faz 1 / adım 2: PL24 hacim freni + görünürlük. Analiz /home/s/ss/plv2.md (bulgular consumers_jobs-03/06/07, deploy_ops-13).

Sorun

İki hesap banı da günde 5-7 bin kategori yazan (≈10 bin+ istek) otomatik drill dalgalarının ardından geldi; gerçek kullanıcı decode'u ≤14/gün. Mevcut korumaların hepsi iş-seviyesinde (iş/dk, iş/gün) — HTTP isteği sayan hiçbir tavan yoktu. Üstelik PL24 çağrıları proxy_logs'a hiç yazılmıyordu (yalnız pcat/emex), bu yüzden hacim ancak ban'dan sonra, DB satır sayılarından geriye dönük çıkarılabildi. Kill switch de yalnız decodeVin'i kapatıyordu; drill, backfill ve katalog gezinmesi "kapalı" kaynağa istek atmaya devam ediyordu.

Değişiklik

Yeni PL24BudgetService — tüm PL24 upstream trafiği için tek geçit:

  • Günlük sayaç pl24:http:<gün> (Redis, 8 gün TTL), tavan PL24_HTTP_DAILY_MAX (varsayılan 1200).
  • Kullanıcı rezervi PL24_HTTP_USER_RESERVE (varsayılan %40): backfill tavanın %60'ında durur, kullanıcı decode'u sonuna kadar akar. Kaçak bir backfill müşteriyi aç bırakamaz. Lane ayrımı mevcut isBackfillContext() ile.
  • Reddedilen çağrı ağa hiç çıkmaz, telemetriye de yazılmaz.
  • Redis düşerse fail-open.

Telemetri: ProxyServiceLeg += pl24_http, pl24_auth. Login, authorize ve tüm katalog fetch'leri artık proxy_logs'a yazıyor (provider, hesap, status, süre, 403/429 → banned, taşıma hatası sınıflandırma). "Hangi gün kaç istek attık, ilk 401/403 ne zaman başladı" sorusu artık ban'dan önce yanıtlanabilir.

Kill switch yayıldı: kill-source-pl24 artık budgetedFetch içinde — decode + drill + backfill + browse + görsel indirme dahil tüm katalog trafiğini kapatıyor.

Doğrulama

  • Yeni pl24-budget.service.spec.ts: 9 test (tavan, kullanıcı rezervi, reddedilen çağrının ağa çıkmaması, Redis fail-open, telemetri biçimi ve leg ayrımı, ban sinyali, taşıma hatası sınıflandırma).
  • Etkilenen paketler: 197 test geçti, tsc + biome temiz.

Adım 1'in prod ölçümü (bu PR'ın öncülü, PR #261)

Oturum modeli 10:06 UTC'de prod'a indi. 25 dakikalık pencere:

ölçüm değer
login denemesi 2 (kibar + squeezeOut = tek olay)
başarılı login 1
authorize 2
oturum düşme / 401 0
decode 2

Eski modelde aynı pencerede en az 2-3 yeniden login olurdu. Oturum kalıcı, servis anahtarı yalnız kullanıldığında yenileniyor.

Öneri

Merge sonrası prod env: PL24_HTTP_DAILY_MAX=1200 açıkça ayarlanabilir (varsayılan da 1200). Birkaç gün telemetri toplandıktan sonra tavan bilinçli olarak yükseltilir — Faz 3'te backfill açılışının ön koşulu bu.

🤖 Generated with Claude Code

Faz 1 / adım 2: PL24 hacim freni + görünürlük. Analiz `/home/s/ss/plv2.md` (bulgular consumers_jobs-03/06/07, deploy_ops-13). ## Sorun İki hesap banı da günde **5-7 bin kategori** yazan (≈10 bin+ istek) otomatik drill dalgalarının ardından geldi; gerçek kullanıcı decode'u **≤14/gün**. Mevcut korumaların hepsi iş-seviyesinde (iş/dk, iş/gün) — **HTTP isteği sayan hiçbir tavan yoktu**. Üstelik PL24 çağrıları `proxy_logs`'a hiç yazılmıyordu (yalnız pcat/emex), bu yüzden hacim ancak ban'dan *sonra*, DB satır sayılarından geriye dönük çıkarılabildi. Kill switch de yalnız `decodeVin`'i kapatıyordu; drill, backfill ve katalog gezinmesi "kapalı" kaynağa istek atmaya devam ediyordu. ## Değişiklik **Yeni `PL24BudgetService`** — tüm PL24 upstream trafiği için tek geçit: - Günlük sayaç `pl24:http:<gün>` (Redis, 8 gün TTL), tavan `PL24_HTTP_DAILY_MAX` (varsayılan **1200**). - **Kullanıcı rezervi** `PL24_HTTP_USER_RESERVE` (varsayılan %40): backfill tavanın %60'ında durur, kullanıcı decode'u sonuna kadar akar. Kaçak bir backfill müşteriyi aç bırakamaz. Lane ayrımı mevcut `isBackfillContext()` ile. - Reddedilen çağrı ağa hiç çıkmaz, telemetriye de yazılmaz. - Redis düşerse fail-open. **Telemetri**: `ProxyServiceLeg` += `pl24_http`, `pl24_auth`. Login, authorize ve tüm katalog fetch'leri artık `proxy_logs`'a yazıyor (provider, hesap, status, süre, 403/429 → `banned`, taşıma hatası sınıflandırma). "Hangi gün kaç istek attık, ilk 401/403 ne zaman başladı" sorusu artık ban'dan **önce** yanıtlanabilir. **Kill switch yayıldı**: `kill-source-pl24` artık `budgetedFetch` içinde — decode + drill + backfill + browse + görsel indirme dahil tüm katalog trafiğini kapatıyor. ## Doğrulama - Yeni `pl24-budget.service.spec.ts`: 9 test (tavan, kullanıcı rezervi, reddedilen çağrının ağa çıkmaması, Redis fail-open, telemetri biçimi ve leg ayrımı, ban sinyali, taşıma hatası sınıflandırma). - Etkilenen paketler: **197 test geçti**, `tsc` + `biome` temiz. ## Adım 1'in prod ölçümü (bu PR'ın öncülü, PR #261) Oturum modeli 10:06 UTC'de prod'a indi. 25 dakikalık pencere: | ölçüm | değer | |---|---| | login denemesi | 2 (kibar + squeezeOut = tek olay) | | başarılı login | 1 | | authorize | 2 | | oturum düşme / 401 | 0 | | decode | 2 | Eski modelde aynı pencerede en az 2-3 yeniden login olurdu. Oturum kalıcı, servis anahtarı yalnız kullanıldığında yenileniyor. ## Öneri Merge sonrası prod env: `PL24_HTTP_DAILY_MAX=1200` açıkça ayarlanabilir (varsayılan da 1200). Birkaç gün telemetri toplandıktan sonra tavan bilinçli olarak yükseltilir — Faz 3'te backfill açılışının ön koşulu bu. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
root added 1 commit 2026-09-17 13:13:54 +03:00
feat(pl24): günlük HTTP bütçesi, kullanıcı rezervi ve proxy_logs telemetrisi
Some checks are pending
QA Gate (P0/P1) / Test affected app (pull_request) Waiting to run
56a8ea09be
Faz 1 / adım 2 (analiz: /home/s/ss/plv2.md, bulgular consumers_jobs-03/06/07,
deploy_ops-13).

SORUN: İki PL24 hesap banı da günde 5-7 bin kategori yazan (≈10 bin+ istek)
otomatik drill dalgalarının ardından geldi; gerçek kullanıcı decode'u ≤14/gün.
Mevcut korumaların hepsi iş-seviyesinde (iş/dk, iş/gün) — HTTP isteği sayan
hiçbir tavan yoktu. Üstelik PL24 çağrıları `proxy_logs`'a hiç yazılmıyordu
(yalnız pcat/emex), bu yüzden hacim ancak ban'dan SONRA, DB satır sayılarından
geriye dönük çıkarılabildi. Kill switch de yalnız decodeVin'i kapatıyordu; drill,
backfill ve katalog gezinmesi "kapalı" kaynağa istek atmaya devam ediyordu.

DEĞİŞİKLİK:
- Yeni `PL24BudgetService`: tüm PL24 upstream trafiği için tek geçit.
  - Günlük sayaç `pl24:http:<gün>` (Redis, 8 gün TTL); tavan `PL24_HTTP_DAILY_MAX`
    (varsayılan 1200).
  - Kullanıcı rezervi `PL24_HTTP_USER_RESERVE` (varsayılan %40): backfill tavanın
    %60'ında durur, kullanıcı decode'u sonuna kadar akar — kaçak bir backfill
    müşteriyi asla aç bırakamaz. Lane ayrımı mevcut `isBackfillContext()` ile.
  - Reddedilen çağrı ağa hiç çıkmaz ve telemetriye yazılmaz.
  - Redis düşerse fail-open (auth/katalog telemetri yüzünden bloklanmaz).
- Telemetri: `ProxyServiceLeg` += `pl24_http`, `pl24_auth`. Login, authorize ve
  tüm katalog fetch'leri `proxy_logs`'a yazıyor (provider dataimpulse/none,
  sessionKey=hesap, status, süre, 403/429 → banned, taşıma hatası sınıflandırma).
  Artık "hangi gün kaç istek attık, ilk 401/403 ne zaman başladı" sorusu
  ban'dan ÖNCE yanıtlanabilir.
- Kill switch yayıldı: `kill-source-pl24` artık `budgetedFetch` içinde, yani
  decode + drill + backfill + browse + görsel indirme dahil TÜM katalog trafiğini
  kapatıyor (eskiden yalnız decodeVin).
- `fetchWithRetry` 401 çaresi netleşti: yalnız servis token'ı tazelenir; oturumun
  kendisi gerekirse auth katmanında düşürülür.

Test: yeni `pl24-budget.service.spec.ts` (9 test: tavan, kullanıcı rezervi,
reddedilen çağrının ağa çıkmaması, Redis fail-open, telemetri biçimi/leg ayrımı,
ban sinyali, taşıma hatası sınıflandırma). Etkilenen paketler: 197 test geçti.
tsc + biome temiz.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
root merged commit 2add2b253a into main 2026-09-17 13:37:51 +03:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: root/sase.tr#262