Trafik Log Ayarları
Log Kayıt Bölgeleri
Apinizer üzerinde tanımlanan API Proxy'e gelen ve giden mesaj bilgileri mesaj ögelerine (başlık, parametre, gövde) göre Elasticsearch veri tabanında loglanmaktadır.
Bu log kaydı tutulan bölgeler:
İstemciden API Proxy'e gelen istek bilgileri
API Proxy'den Backend API'ye iletilen istek bilgileri
Backend API'den API Proxy'e verilen yanıt bilgileri
API Proxy'den istemciye gönderilen yanıt bilgileri
Varsayılan olarak, projenin tüm mesaj bölgelerindeki alanların loglanması aktiftir. Loglanan alanlar ihtiyaca göre veya log sunucusunun kaynak tüketimi baz alınarak kısıtlanabilir.
Bu ekran üzerinden proje ve ortam (environment) bazlı log ayarı yönetilmektedir.
Üretim ortamı için aşağıdaki ortamlara ait ögeleri loglama işleminin devre dışı bırakılması tavsiye edilmektedir.
- API Proxy'den Backend API'ye (Request to Target)
- Backend API'den API Proxy'e (Response from Target)
Eğer bir API Proxy üretim ortamında çalışıyorsa, API Proxy'deki tüm poliçelerin ayarları ve testleri tamamlandığı ve artık geliştirme yapılmayacağı anlamına gelmektedir.
Bu yüzden veri tabanında verilerinin aşırı büyümemesi bu iki bölgedeki başlık, parametre ve gövde verilerinin yazılmaması tavsiye edilir.
Tüm loglama alanları kapalı olsa dahi istekte de bir hata oluştuysa log alanlarının tümü hatanın tespit edilebilmesi için kayıt edilir. Bu özellik genel ayarlarda açılıp, kapatılabilir.
Formdata istekleri değişken veri büyüklükleri ve veri formatları nedeniyle dosya kısımları hiçbir şekilde loglanmamaktadır. Sadece diğer metadata alanları loglanmaktadır.
Websocket ve gRPC istekleri Apinizer'a gelen ve Apinizer'dan çıkan veriler şeklinde tutulmakta olduğundan bu tip API Proxylerde sadece 2 bölge vardır.
Bu ekranda API Proxy bazlı trafik log ayarlarını yönetebilirsiniz. Ortam üzerinde tanımlı konnektör entegrasyonları varsa, her proxy için trafik kayıtlarının bu hedeflere gönderilip gönderilmeyeceğini buradan ayarlarsınız.
Düzenleme penceresi (Edit API Traffic Proxy Log Settings)
Satırda Düzenle ile açılan pencerede solda CONNECTORS menüsünde Logback, Webhook, Kafka, RabbitMQ, veritabanı, Syslog, Elasticsearch gibi log hedefleri listelenir; bir öğeye tıkladığınızda sağda yalnızca o hedefe özel form görüntülenir. Üstte ortam seçimi ve Save and Deploy bulunur; her konnektör kartında Active for this environment anahtarı ile seçili ortamda gönderimin açılıp kapatılmasını yönetirsiniz. Menüdeki renkli durum göstergesi, ilgili konnektör için yapılandırmanın özet durumunu yansıtır. Method Overrides ile metot bazlı ek yapılandırmaya geçebilirsiniz.
Method Overrides bölümünde metotlar, yolun önünde HTTP metodu ile listelenir (örneğin GET /pet/{petId}); böylece aynı yolu paylaşan ancak metodu farklı olan uç noktalar birbirinden ayırt edilebilir. SOAP operasyonları gibi HTTP metodu bulunmayan kayıtlar yalnızca adıyla listelenir.
Seçtiğiniz konnektör için Log içeriği bölümünde HTTP istek üst bilgileri, performans metrikleri, yanıt durumu ve yönlendirme adresi gibi üst düzey grupları ayrı ayrı işaretleyebilirsiniz; bu gruplar birbirinden bağımsızdır. Request from Client, Request to Target, Response from Target ve Response to Client kutularında her mesaj bölgesi için Parametre, Başlık ve Gövde (ve varsa Partial Size / kısmi boyut) ayarlarını düzenlersiniz. Altta Privacy ile gizlilik işleme seçeneğini açıp kapatabilirsiniz.
Veritabanı konnektörü log hedefi olarak seçildiğinde, log tablolarının şema ön eki veya özel tablo adı bağlantı (Connection) tanımında ayarlanır. Detay için Veritabanı Bağlantısı sayfasına bakın.
Log Ayarları Alanları
Log ayarları için kullanılan başlıca alanlar aşağıdaki tabloda özetlenmektedir.
| Alan | Açıklama |
|---|---|
| Active for this environment | Seçili ortamda bu log hedefine trafik kaydı gönderilip gönderilmeyeceğini açar veya kapatır. |
| HTTP istek ayrıntıları | İstemci IP, HTTP metodu, URI, port gibi üst bilgilerin loga dahil edilmesini yönetir. |
| Performans metrikleri | Süre, iletişim boyutu, önbellek ile ilişkili metriklerin loga yazılıp yazılmayacağını yönetir. |
| Yanıt durumu bilgisi | HTTP durum kodu ve hata tipi gibi alanların loga dahil edilmesini yönetir. |
| Yönlendirme adresi | Yönlendirme veya hedef adres bilgisinin loga yazılıp yazılmayacağını yönetir. |
| Başlık (Header) | İlgili mesaj bölgesinde başlık bilgilerinin loglanıp loglanmadığını yönetir. |
| Gövde (Body) | İlgili mesaj bölgesinde gövde bilgilerinin loglanıp loglanmadığını yönetir. |
| Parametre (Parameter) | İlgili mesaj bölgesinde parametre bilgilerinin loglanıp loglanmadığını yönetir. |
| Kısmi boyut (Partial size) | Uzun metin alanlarında kayıt boyutunun sınırlandırılıp sınırlandırılmayacağını ilgili mesaj bölgesi için yönetir. |
| Politika çalışma süreleri | İstekte çalışan her politikanın sırasını, tipini ve milisaniye cinsinden süresini loga ekler. Varsayılan olarak kapalıdır; bkz. aşağıdaki bölüm. |
| Gizlilik (Privacy) | Ortamda tanımlı gizlilik kurallarının bu konnektör çıkışındaki log akışına uygulanıp uygulanmayacağını yönetir. |
HTTP istek ayrıntıları kapalıyken çağıranın kullanıcı adı ve çağıranın atıf bilgisi o konnektörün trafik logundan çıkarılır: tipli istemci atıf kimlikleri (ack, cot, coi, coo) ve abonelik kimlikleri (subi, subp, subpl, subo). AI kiracı kimlik bilgisi (aivk) yazılmaya devam eder. Bu kimliklere göre sayan kullanım raporları ve AI alarmları o konnektörün trafiğini görmez; kota ve limit uygulaması etkilenmez.
Politika Çalışma Süreleri
Bir istek beklenenden yavaş olduğunda sıradaki soru genellikle hangi politikanın süreyi yediğidir. Bugüne kadar bu sorunun cevabı için API Proxy üzerinde Trace açmak gerekiyordu; Trace her politikanın gövdesini, başlıklarını ve parametrelerini öncesi/sonrasıyla kaydettiği için production ortamında sürekli açık tutulamaz.
Politika çalışma süreleri aynı soruyu hiçbir içerik yakalamadan cevaplar. Ayar açıldığında her trafik log kaydı, o istekte çalışan politikaların kısa bir listesini taşır:
| Değer | Anlamı |
|---|---|
| Sıra | Çalışma sırası. Değer aynı zamanda hattı da taşır: 0-9999 istek, 10000-19999 yanıt, 20000 ve üzeri hata. API Trafiği detay ekranı hem hattı hem hat içindeki sırayı gösterir. |
| Politika tipi | Politikanın tipi; örneğin jwt-auth veya content-filter. Politika adı bilinçli olarak tutulmaz — genellikle otomatik üretilmiş bir tanımlayıcıdır ve ekranda bir anlam taşımaz. |
| Süre | Politikanın çalışma süresi (milisaniye). |
Akış (streaming) yanıtının sonunda çalışan kayıtlar, koşulu karşılanmadığı için atlanan politikalar ve alışılmadık sayıda politika çalıştığında eklenen kesme işareti, politika tipinin yanında küçük bir rozetle gösterilir.
Ölçümün kendisi yeni bir iş değildir: gateway her politikanın süresini zaten her istekte hesaplıyor ve Trace kapalıyken bu değeri atıyordu. Bu ayar yalnızca değerin saklanmasını sağlar.
Ayarın açılması
Ayar diğer log içerik seçenekleriyle birlikte durur ve log hedefi başına verilir; böylece süreleri Elasticsearch'e yazarken ilişkisel veritabanı hedefinin dışında bırakabilirsiniz. Metot bazlı geçersiz kılmalar da geçerlidir.
Değişiklikten sonra API Proxy'yi yeniden dağıtın — trafik log ayarları gateway'e proxy dağıtımıyla birlikte ulaşır.
Verinin yazıldığı yer
| Hedef | Temsil |
|---|---|
| Elasticsearch | pxt alanı, nested obje dizisi olarak. nested, tip ile süreyi ilişkili tuttuğu için "X politikasının süresi 100 ms'den büyük olan istekler" gibi bir sorgu doğru satırları döndürür. |
| MongoDB | Alt doküman dizisi. |
| İlişkisel veritabanı (SQL/JDBC) | policy_exec_times kolonu; karakter sınırlı tek bir CSV: sıra:tip:süre, dikey çizgiyle ayrılmış. |
| Graylog | İlişkisel hedefle aynı CSV. |
Ayar varsayılan olarak kapalıdır. Elasticsearch tarafında nested alan, listedeki her öğeyi ayrı bir
iç doküman olarak indeksler; dolayısıyla 10-20 politikalı bir kayıt o indeksin doküman sayısını buna
göre artırır. Yalnızca veriye gerçekten ihtiyaç duyduğunuz hedeflerde açın.
Yeni alan yükseltme sırasında indeks şablonuna eklenir ve indeks otomatik olarak rollover edilir. Trafik logları bir data stream'e yazıldığı için alan yalnızca rollover sonrası oluşan backing indekslerde bulunur; eski kayıtlar olduğu gibi kalır.
Trafik loglarını ilişkisel bir veritabanına yazıyorsanız policy_exec_times kolonunun her ortam
veritabanına bir kez eklenmesi gerekir. ALTER betiği için 2026.09.1 — Log Tablosu ALTER Scriptleri
sayfasına bakın; yeni kurulumlarda kolon
Apinizer Logları için Tablo Oluşturma Komutları
scriptiyle zaten oluşur.