Bölüm 26: Analytics, Cost ve Performance¶
Bu bölüm, Arceris kullanımının operasyonel görünürlüğünü sağlayan üç yüzeyi kapsar: Kullanım Analizi (kullanım analitiği ve maliyet), Maliyet Limiti Kuralları (yeniden kullanılabilir limit ön ayarları) ve Performans (ağ geçidi sağlığı ve gecikme izleme).
Kullanım Analizi Sayfası¶
Kullanım Analizi sayfası, Arceris üzerinden geçen trafiğin hacmini, güvenlik eylemlerini, token tüketimini ve maliyet dağılımını gösterir. Sayfanın üst kısmında dönem seçimi yapılır: Bugün, 7 Gün veya 30 Gün. Güvenlik kartları seçili döneme göre filtrelenir; token ve maliyet sayaçları ise dönen (rolling) sayaçlardır ve döneme göre filtrelenmez.
Güvenlik Etkinliği — döneme göre filtrelenen 5 KPI kartı:
- API İstekleri: Dönem içindeki toplam istek sayısı.
- Engellenen İstekler: Engellenen istek sayısı ve engelleme oranı (%). Oran %10'ün üzerindeyse kırmızı, %2–10 arası turuncu, %2 altında normal gösterilir.
- PII Maskelendi: PII maskelenen istek sayısı.
- Ort. Gecikme: Ağ geçidi gidiş-dönüş ortalama gecikme (ms).
- Aktif Kullanıcılar: Dönem içinde aktif kullanıcı sayısı ve toplam kullanıcı sayısı.
Token & İstek Kullanımı — döneme göre filtrelenmeyen dönen sayaçlar:
- Günlük Token: Bugünkü toplam token tüketimi (UTC sıfırlamalı).
- Aylık Token: Bu takvim ayının toplam token tüketimi.
- Günlük İstek: Bugünkü toplam istem (prompt) sayısı.
- Aylık İstek: Bu ayın toplam istem sayısı.
- Toplam Token: Kullanıcılar genelinde aylık token toplamı.
- Toplam Maliyet: Kullanıcılar genelinde aylık maliyet (USD).
Toplam Maliyet artık her kanalı sayar: kodlama ajanları (Claude Code, Codex — explicit proxy üzerinden), yerel LLM proxy'si (/local/), tarayıcı proxy'si, birleşik ağ geçidi ve /v1. Daha önce kodlama ajanı ve /local/ çağrıları 0 token, 0 istem ve $0 olarak kaydediliyordu; şimdi sağlayıcının gerçek token kullanımı kaydedilir ve Model Fiyatlandırma'dan fiyatlanır (Bölüm 8).
Maliyet gösterimi (v1.3.1):
- Bir sentin üzerindeki tutarlar iki haneyle, altındakiler dört haneyle gösterilir (ör.
$0.0014);$0.0001altındaki tutarlar<$0.0001olarak gösterilir. Böylece kaydedilmiş küçük bir maliyet, "hiç fiyatlanmadı"dan ayırt edilebilir. - Ay içinde fiyatlanamayan istem varsa Total Cost kartında turuncu bir "N prompt fiyatlanamadı" notu belirir. İmleç notun üzerine getirildiğinde ayrım görülür: sağlayıcının token kullanımı bildirmediği istemler (tarayıcı AI arayüzleri — chatgpt.com, claude.ai, gemini.google.com — yapısal olarak hiç bildirmez) ve modelin Model Fiyatlandırma'da fiyatı olmadığı istemler. İkincisi, fiyat Bölüm 8'deki Model Fiyatlandırma sekmesinden eklenerek giderilir; self-hosted bir model
$0girişiyle "fiyatlı ama ücretsiz" işaretlenebilir.
Olay Dağılımı:
Dönem içindeki olayların kategori bazında dağılımı:
- İzin Verilen: İzin verilen ve passthrough istekler.
- ACL Reddedildi: Model erişim kontrolü tarafından reddedilenler.
- Prompt Enjeksiyonu: Prompt injection engellenenler.
- PII Engellendi: PII nedeniyle tamamen engellenenler.
- PII Maskelendi: PII tespit edilen ama maskelenerek iletilenler.
- Gölge AI: Bilinmeyen/kaydedilmemiş kaynaklardan gelen istekler (varsa).
Bir promptu birden fazla kontrol engelleyecekse, artık en erken karar katmanı adlandırılır (ör. Prompt Guard deseni sınıflandırıcı yerine, PII DLP yerine). Bu yüzden bu dağılım ve rapor sayımları sürüme geçerken katman bazlı kayabilir (Bölüm 27).
Ayrıca Kapsam bölümü ile trafiğin hangi kapsamdan geldiği (API, Browser Proxy, All) gösterilir.
Günlük Trend:
Seçilen dönem içinde günlük istek hacmini gösteren yığılmış çubuk grafik:
- Mavi: Toplam istek.
- Kırmızı: Engellenen istekler.
- Turuncu: Maskelenen istekler.
Fare ile çubuğun üzerine gelindiğinde tooltip'te gün, toplam, engellenen ve maskelenen değerler gösterilir.
Model Dağılımı:
Hangi modellerin ne sıklıkta kullanıldığını gösteren yatay çubuk grafik. Her model için toplam istek sayısı ve varsa engelleme oranı (%) gösterilir. Bu bilgi, kurumun AI tercihlerini ve maliyet davranışını anlamak için kullanılır.
Kullanıcı Bazında Etkinlik:
Her kullanıcının ayrıntılı kullanım tablosu (25'er kullanıcı başına sayfalanır):
| Sütun | Açıklama |
|---|---|
| Kullanıcı | Sıra numarası, baş harf avatarı, kullanıcı adı ve rolü |
| İstekler | Dönem içindeki toplam istek sayısı |
| Engellenen | Engellenen istek sayısı (kırmızı) |
| Engelleme Oranı | Engelleme oranı; %25 üzeri kırmızı, %0 üzerinde turuncu |
| Maskelenen | PII maskelenen istek sayısı (turuncu) |
| Aylık Token | Aylık token tüketimi; toplam içindeki payı mini çubukla |
| Tahmini (web UI) | Yalnızca tahmin özelliği açıkken görünen sütun (aşağıya bakın) |
| Maliyet (ay) | Aylık maliyet (USD); fiyatlanamayan istem varsa altında turuncu "+N fiyatsız" notu (aynı no_usage/no_price ayrımı tooltip'te) |
| Yapılandırılmış Limitler | Kullanıcıya tanımlı limitler ve doluluk oranları; limit yoksa "Limit yok" |
"Yalnızca aktif kullanıcıları göster" onay kutusu ile yalnızca dönem içinde etkinliği olan kullanıcılar listelenir.
Tahmini (web UI) sütunu: Tarayıcı AI arayüzleri hiçbir zaman token kullanımı bildirmediği için, "Web UI Token Estimation" ayarı (Ayarlar → Çalışma Zamanı, Bölüm 6) açıkken Arceris kendi tahminini üretir ve bu sütunda ≈ girdi / ≈ çıktı olarak iki ayrı sayı gösterilir. Bu bir Arceris tahminidir: sohbet geçmişi sağlayıcının sunucusunda kaldığı için girdi tarafı bir alt sınırdır; tahminler asla gerçek sütunlarla toplanmaz ve hiçbir limite bağlanmaz.
Yapılandırılmış Limitler:
Kullanıcı tablosundaki son sütun, her kullanıcı için tanımlı limitleri ve doluluk oranlarını gösterir. Her limit için bir ilerleme çubuğu bulunur:
- Mavi çubuk: Limit altında.
- Turuncu çubuk: Soft limite ulaşılmış (uyarı).
- Kırmızı çubuk: Hard limite ulaşılmış (aşıldı).
Gösterilen limit türleri: Günlük token, Aylık token, Aylık maliyet (USD), Günlük istek, Aylık istek.
Önemli: bir limit atandığı anda saymaya başlar — atama anından önceki kullanım geriye doğru harcanmaz. Bu sayfadaki, kullanıcının kendi profilindeki ve Erişim Yönetimi'ndeki tüketim çubukları bu net değeri gösterir; sınır atandığı andan itibaren 0'a yakın görünmesi normaldir.
Neler sayılır, neler sayılmaz:
- Her giriş kanalı sayılır (#1574): Kodlama ajanları (explicit proxy),
/local/, tarayıcı proxy'si, birleşik ağ geçidi ve/v1— hepsi gerçek kullanımı aynı sayaçlara yazar. Bu kullanıcılara atanmış maliyet/token/istek limitleri de artık bu kanallarda uygulanır (aşağıya bakın). - Tarayıcı yolunda bayt sayımı yok: Aktarılan baytlar artık token olarak sayılmaz; kullanım bildirmeyen bir arayüzde istem 0 tokenla kaydedilir (tahmin sütununa bakın).
- Eşzamanlı isteklerde limit tutarlıdır (#812): Limit kontrolü, kararı ve kullanım artışını tek atomik adımda yapar (birden çok ağ geçidi örneğinde bile geçerli). 3 istem/gün limitinde aynı anda gelen 12 istekten yalnızca 3'ü karşılanır, kalanı alışılmış "limit doldu" yanıtını alır. Başka bir kontrole takılan veya sağlayıcıya hiç ulaşmayan istek, ayırdığı payı geri verir. Tarayıcıda üretim durdurulsa bile kullanım kaydı yazılır.
- Token sayma probları sayılmaz (#1217): Claude Desktop'ın açılışta gönderdiği ~25 paralel
count_tokensisteği güvenlik taramasından geçer (Model ACL, injection, DLP, moderation, PII) ama istem/token/maliyet olarak sayılmaz — izleyen gerçek istem iki kez sayılmaz. Bir kontrol probu engellerse kayıt yine yazılır. /local/satırları kullanıcı adını taşır (#1660): Yerel LLM proxy trafiği artık diğer kanallar gibi düz kullanıcı kimliğiyle kaydedilir; kullanıcıya göre arama ve rapor sayımları aynı kişiyi iki kez saymaz.
Maliyet Yönetimi¶
Maliyet Uygulama Varsayılanları¶
Genel varsayılanlar Ayarlar → Çalışma Zamanı → Maliyet Uygulama Varsayılanları bölümünde tanımlanır (Bölüm 6). Bölüm başlığındaki anahtar maliyet/limit uygulamasını topluca açar-kapar; kapalıyken altındaki alanlar soluklaşır. Ayarlar anında uygulanır.
- Sert Kota Kısıtlamaları:
- Günlük Token Limiti: Kullanıcı başına günlük maksimum token sayısı.
- Aylık Token Limiti: Kullanıcı başına aylık maksimum token sayısı.
- Aylık Maliyet Limiti (USD): Kullanıcı başına aylık maksimum maliyet.
- Varsayılan Yumuşak Limit %: Hard limite ulaşmadan önce uyarı tetiklenecek yüzde (ör. %80). 0 = devre dışı.
Boş bırakılan veya 0 girilen alanlar sınırsız demektir. İstek (prompt) limitleri bu varsayılanlarda bulunmaz; istek limitleri yalnızca kullanıcı bazlı atanır — aşağıdaki ön ayarlar veya doğrudan Erişim Yönetimi üzerinden (Bölüm 11).
Limit aşımında ne olur¶
- Hard limite ulaşan kullanıcının isteği sağlayıcıyla görüşmeden önce reddedilir: 429 yanıtı,
Retry-Afteriçinde gerçek reset zamanı (gün/ay sınırının ne zaman devrileceği) ve hangi limitin dolduğu bilgisiyle birlikte döner. Red, bir Request Events satırı ve bir denetim kaydı olarak yazılır (Bölüm 25). - v1.3.1'de bu koruma kodlama ajanı ve
/local/kanallarını da kapsar (#1574): bu kanallardan gelen istekler de limit denetiminden geçer; aşım durumunda aynı 429 + reset bilgisi uygulanır. - Soft limite ulaşan kullanıcı ilk aşta turuncu uyarıyla karşılaşır; kullanıcı panelinde "limitinize yaklaşıyorsunuz" bandı belirir, hard limitten sonra kırmızı "limit doldu" bandı ve geri sayım gösterilir.
- Kullanıcı, kullanıcı panelinden limit artışı isteyebilir; istek onay akışından geçer (Bölüm 28).
Maliyet Limiti Kuralları (Maliyet Limiti Ön Ayar Kütüphanesi)¶
Maliyet Uygulama Varsayılanları genel sınırları tanımlarken; bazen operatör farklı kullanıcı grupları için farklı limit setleri ister (ör. "yöneticiler yüksek limit", "stajyerler düşük limit"). İşte bu noktada Maliyet Limitleri sayfası devreye girer.
Sayfa yolu: Kenar çubuğu → Erişim bölümü → Maliyet Limitleri (/admin/cost-rules). cost_limits lisans özelliği gerektirir.
Bu sayfa, yeniden kullanılabilir maliyet-limiti ön ayarları tanımlamayı sağlar. Tanımlanan ön ayarlar daha sonra Erişim Yönetimi üzerinden kullanıcılara atanır; atama sırasında değerler kullanıcının kaydına kopyalanır (snapshot) — ön ayar sonradan değişse bile atanmış kullanıcı etkilenmez.
Ön ayar formu:
- Ad: Ön ayarın görünen adı (ör. "Temel Seviye").
- Limit Modu: İki moddan biri seçilir ve yalnızca o modun alanları doldurulur:
- Token Bazlı: Günlük Token, Aylık Token, Aylık Maliyet (USD).
- İstek Bazlı: Günlük İstek, Aylık İstek.
- Yumuşak Limit %: Yumuşak-limit uyarısının tetiklendiği yüzde (0–100; varsayılan 80).
İstenmeyen alan boş bırakılır. Liste tablosu Ada, Günlük/Aylık Token, Aylık Maliyet, Günlük/Aylık İstek, Yumuşak % ve İşlemler sütunlarını gösterir; ada göre arama yapılabilir ve tablo 10'arlı sayfalara bölünür. Salt-okunur oturumlarda ekleme/düzenleme/silme gizlenir.
Doğrulama kuralları: Günlük limit aylık limiti aşamaz; Yumuşak Limit % 0–100 arası olmalıdır; negatif değerler reddedilir.
Not: Ön ayar ataması yalnızca kullanıcı hedefine yapılır ve Erişim Yönetimi'nden yürütülür (Bölüm 11) — atama akışındaki "Existing Rule" seçici bu listeden beslenir. Yani ön ayarları buradan tanımlayın, atamayı Erişim Yönetimi'nden yapın. Bir kullanıcı aynı anda tek bir limit kaydı taşıdığı için el ile atanmış bir limit, kural seti fan-out'u tarafından asla üzerine yazılmaz.
Performans Sayfası¶
Performans sayfası, ağ geçidinin sağlık ve gecikme görünürlüğünü sağlar: analitik destekli 24 saatlik bir sağlık özeti, işleme özel Go çalışma zamanı istatistikleri ve ara katman (middleware) işlem süreleri. Başlıkta son güncelleme saati ve bu örneğin çalışma süresi gösterilir; Yenile düğmesi verileri tazeler.
Ağ Geçidi Sağlığı (son 24 saat · analitik destekli):
Restart'ta sıfırlanmayan, analitik verisine dayanan 4 kart:
- İstekler (24s): Son 24 saatteki toplam etkileşim.
- Ret Oranı: Engellenen/toplam oranı. %5 altı yeşil, %5–15 arası turuncu, %15 üzeri kırmızı gösterilir.
- Ort. Gecikme: İstek başına ortalama gecikme (aşağıdaki gecikme rehberine göre renklenir).
- Aktif Uyarılar: Şu anda tetiklenen uyarı sayısı; 0'dan büyükse kırmızı gösterilir ve "tetikleniyor" rozeti eklenir.
Çalışma Zamanı (işleme özel · yeniden başlatmada sıfırlanır):
6 KPI kartı:
- Goroutine'ler: Aktif goroutine sayısı. Yüksek değerler (ör. >10.000) bellek sızıntısına işaret edebilir.
- Heap Ayrılan: Kullanım için ayrılmış heap belleği (MB).
- Heap Kullanımda: Kullanımda olan heap belleği (MB) — aktif span'lar.
- GC Duraklamaları: Son GC (Garbage Collection) duraklama süresi; 10 ms üzerinde kırmızı gösterilir. Altında toplam GC sayısı belirtilir.
- GC Toplam Duraklama: Başlangıçtan beri toplam GC duraklaması ("dünya durdu" toplamı); 1 saniye üzerinde turuncu gösterilir.
- Sistem Belleği: İşletim sisteminden alınan toplam bellek (MB).
Ara Katman tablosu:
Kimlik doğrulama, captive portal gibi ara katman alt işlemlerinin işlem süreleri tek bir tabloda gösterilir:
| Sütun | Açıklama |
|---|---|
| İşlem | Alt işlem adı (monospace kod stili) |
| Sayı | Toplam çağrı sayısı |
| Ort. | Ortalama gecikme |
| P50 | Medyan gecikme (50. persentil) |
| P95 | 95. persentil gecikme |
| P99 | 99. persentil gecikme — tablodaki en yüksek P99'e göre oransal çubukla |
Ortalama ve persentiller son 1.000 örneği yansıtır; sayım ömür boyudur. Henüz istek geçmemiş bir ağ geçidinde tablo "Henüz Veri Yok" durumu gösterir.
Gecikme rehberi (tüm gecikme hücrelerinde geçerlidir):
- Normal: < 100 ms
- Yavaş: 100 ms – 1 s
- Kritik: > 1 s
Kullanım Senaryoları:
- Yavaş yanıtlar: P99 gecikmesi yüksek ara katman işlemleri tespit edilir.
- GC baskısı: GC Duraklamaları veya GC Toplam Duraklama sürekli yüksekse bellek kullanımı incelenmelidir.
- Ret oranı izleme: Ağ Geçidi Sağlığı'ndaki Ret Oranı kartı, güvenlik kurallarının aşırı keskinleşip keskinleşmediğini gösterir; %15 üzeri kalıcı değer incelenmelidir.
- Örnek karşılaştırması: Çalışma Zamanı kartları yeniden başlatmada sıfırlanır; Ağ Geçidi Sağlığı kartları analitik verisine dayandığı için restart sonrası da 24 saatlik gerçekleri korur. İkisinin ayrımı, "süreç yeni mi başladı yoksa trafik mi azaldı" sorusunu yanıtlar.
Sağlık denetimleri ve uyarılar:
/readyz derin sağlık kontrolleri paralel yürütülür — DNS'siz bir kurulumda ~2 saniye (eskiden 14–24 saniye) — ve iptal edilen bir istek artık yanıltıcı bir "degraded" sonucu önbelleklemez (#1193, #1334, #1335). Performans sayfasındaki Aktif Uyarılar kartı, P95/P99 gecikme ve ret oranı eşiklerine göre değerlenen uyarıların anlık sayısını gösterir; paneldeki Sentinel Insights bileşeni aynı uyarıları ayrıntısıyla listeler (Bölüm 5). Bildirimler yapılandırılan webhook'a yalnızca durum değişiminde gönderilir, böylece uyarı sürekli tetiklenip sönmez (flap yapmaz); uyarı değerlendirmesi ve dışa bildirim akışının denetim izleri Bölüm 25'te ele alınır.