API Proxy Trafik Log Ayarları
Log Kaydı Tutulan Bölgeler
API Proxy mesajları şu bölgelerde loglanabilir:
İstemciden API Proxy'e gelen istek mesajları
API Proxy'den Backend API'ye iletilen istek mesajları
Backend API'den API Proxy'e verilen yanıt mesajları
API Proxy'den istemciye gönderilen yanıt mesajları
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.
Üretim Ortamı Önerileri
Üretim Ortamı İçin Öneriler: Üretim ortamında aşağıdaki bölgelerin loglanmasının devre dışı bırakılması tavsiye edilir.
Üretim ortamında çalışan API Proxy'lerde tüm poliçelerin ayarları ve testleri tamamlandığı için geliştirme yapılmayacaktır. Veritabanında verilerin aşırı büyümemesi için şu bölgelerin loglanması devre dışı bırakılabilir:
- Request to Target: API Proxy'den Backend API'ye iletilen istekler
- Response from Target: Backend API'den API Proxy'e verilen yanıtlar
Bu iki bölgedeki başlık, parametre ve gövde verilerinin yazılmaması veritabanı boyutunu kontrol altında tutmaya yardımcı olur.
Hata veya Engellenme Durumunda Loglama
Hata Durumunda Otomatik Loglama: Belirli loglama alanları kapalı olsa dahi, istek bir politika tarafından engellendiğinde veya hata aldığında, sorunun tespit edilebilmesi için kapalı tutulan alanların yine de loglanması istenebilir. Bu davranış konnektör bazında "Engellenme durumunda devre dışı alanları logla" ve "Hata durumunda devre dışı alanları logla" anahtarları ile yönetilir; ayar konnektörün ortama eklenmesi sırasında yapılır. Bkz.
Formdata İstekleri
Formdata İstekleri: 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 İstekleri
WebSocket ve gRPC: WebSocket ve gRPC istekleri Apinizer'a gelen ve Apinizer'dan çıkan veriler şeklinde tutulduğundan bu tip API Proxy'lerde sadece 2 bölge bulunur:
- Request from Client / Response to Client
- Request to Target / Response from Target
Streaming (SSE) Yanıtları
Sunucu tarafı akış (Server-Sent Events) kullanan API Proxy'lerde yanıt gövdesi daha önce trafik kaydında <<Server Side Streaming Operation Enabled>> yer tutucusu olarak görünüyordu. Artık istemciye gerçekten yazılan olay akışı kaydedilir:
- Akış boyunca tek bir trafik kaydı üretilir; kayıt bağlantı kapandığında tamamlanır. Her chunk için ayrı kayıt oluşturulmaz — böylece korelasyon bozulmaz ve uzun bağlantılar log hacmini sınırsız büyütmez.
- Akış yalnızca, o istek için istemciye giden yanıt gövdesini (Response to Client body) gerçekten kaydedecek en az bir etkin log connector'ı varsa yakalanır — istek için çözülen connector ayarlarına (metot bazlı override'lar dahil) ya da connector üzerindeki blok/hata durumunda kapalı alanları logla seçeneğine göre. İstek için gövde loglama kapalıysa veya saklama profili yük (payload) içeriğine izin vermiyorsa yer tutucu korunur ve yakalama tamponu hiç oluşturulmaz.
- Kaydedilen gövde Maksimum gövde boyutu (
LOGGING_TRAFFIC_MAX_BODY_SIZE) ayarıyla sınırlıdır. Sınır aşılırsa kopyalama durur ve kaydın sonuna<<Streaming Body Truncated>>işareti eklenir; kesilmiş bir gövdenin tam sanılması böylece engellenir. - AI Gateway proxy'leri de kapsam dahilindedir: AI Proxy Routing ekranındaki Streaming ayarı açıkken LLM sağlayıcısından akan yanıt, aynı kapı (yanıt gövdesi loglaması ve saklama profili), aynı gövde sınırı ve aynı kesme işaretiyle kaydedilir. Kaydedilen içerik istemciye gerçekten gönderilen akıştır — yanıt üzerinde çalışan maskeleme/DLP politikalarının çıktısı, sağlayıcının ham yanıtı değil.
- İstemci bağlantıyı kesse veya arka uçta hata oluşsa da o ana kadar yazılmış gövde aynı tek kayda işlenir.
Streaming gövde logu açıkken her akış, worker belleğinde en fazla Maksimum gövde boyutu (LOGGING_TRAFFIC_MAX_BODY_SIZE, varsayılan 25 MB) kadar bir yakalama tamponu tutar; akış kapanınca bu tampon aynı boyda bir kayıt metnine dönüşür ve kayıt yazılana kadar bellekte kalır. Kaba hesap: eşzamanlı akış sayısı × min(akış gövdesi, gövde sınırı) — 100 eşzamanlı uzun AI yanıtı ile varsayılan sınırda 2,5 GB'a kadar heap gerekebilir. Uzun akışların yaygın olduğu ortamlarda genel sınırı düşürmek yerine ilgili log connector'ının Response to Client bölgesindeki Kısmi boyut (sizeBodyToClient) ayarıyla kaydedilecek gövdeyi küçük tutun; gövdeye ihtiyaç yoksa o istekler için gövde loglamasını kapatın (tampon hiç oluşmaz). Sınır aşımı yalnız kaydı kısaltır, istemciye giden akışı asla etkilemez.
Sıkıştırılmış SSE (Content-Encoding taşıyan akışlar) gateway tarafından şeffaf biçimde aktarılır; güvenle açılıp mevcut gizlilik/maskeleme zincirinden geçirilemediği için bu akışlarda yer tutucu korunur. İkili (binary) akışlar da kaydedilmez.
Saklama profili gövde kaydına izin vermiyorsa (NO_PAYLOAD / NO_PERSIST) hiç tampon oluşturulmaz. Gizlilik (PII) maskeleme, kayıt kalıcılaştırılmadan önce mevcut mekanizma üzerinden uygulanır.
Log Ayarları Sekmesi
API Proxy detay sayfasında Log Ayarları (Log Settings) sekmesi, trafik log konfigürasyonunu yönetmek için ayrılmış özel bir sekmedir. Eskiden Settings sekmesinin en altında yer alan log ayarları bölümü, artık bu ayrı sekmeden yönetilir.
Üç Seviyeli Yapılandırma: Log ayarlarını üç seviyede yapılandırabilirsiniz:
- API Proxy bazında: Her API Proxy için genel log ayarları
- Ortam bazında: Seçilen ortama özel log ayarları (ayarlar ortam bazlı saklanır)
- Metod bazında: Belirli API metodları için özel log ayarları (Method Overrides)
Log Ayarları Ekranı
Log Ayarları sekmesinde API Proxy bazlı ve ortam bazlı log ayarları yapılabilir. Eğer entegrasyon ayarları yapılmışsa, hangi API Proxy'lerin trafik kayıtlarının bu entegrasyon hedeflerine gönderilebileceği de ayarlanabilir.
Bu ayarlar sadece Elasticsearch için değil, Kafka, RabbitMQ, Veritabanı, ActiveMQ, Syslog, Webhook, Logback, Graylog gibi tüm konnektör tipleri için geçerlidir. Konnektör listesi ortamda tanımlı olan konnektör nesnelerine göre dinamik olarak oluşturulur; aynı tipte birden fazla konnektör yapılandırılabilir ve her biri bağımsız olarak ayarlanır.
Ekran yapısı
API Proxy üst menü: Overview, Settings, Design, Develop, Upstream / Routing, Tracing, Log Ayarları (Log Settings) (aktif sekme), API Traffic, API Analytics, Audit Records, Application Logs vb.
Üst çubuk:
- Ortam (Environment): Log ayarlarının uygulanacağı ortamı seçersiniz; ayarlar ortam bazında saklanır.
- Kaydet ve Yayınla (Save and Deploy): Değişiklikleri kaydeder ve ilgili ortama dağıtımı tetikler.
Sol panel — CONNECTORS:
- Seçilen ortamda tanımlı konnektörler listelenir (örnek ekranda Elasticsearch, Database, Graylog). Liste ortamdaki gerçek konnektör kayıtlarına göre dinamiktir.
- Aynı tipte birden fazla konnektör varsa her biri ayırt edici adla gösterilebilir; tek örnekte yalnızca tip adı görünebilir.
- Metod Geçersiz Kılmaları (Method Overrides): Belirli API metodları için varsayılanlardan farklı log kuralları tanımlanır; tanım sayısı rozetle gösterilir.
Ana alan — seçilen konnektör (ör. Elasticsearch):
- Konnektör için Etkin (Enabled) durumu (ör. yeşil rozet) ve Bu ortam için etkin (Active for this environment) anahtarı ile bu ortamda log gönderiminin açılıp kapatılması.
- Log içeriği seçimi (Log Content Selection) — birbirinden bağımsız gruplar (birini kapatmak diğerlerini etkilemez):
- HTTP İstek Detayları (HTTP Request Details) — IP, metot, URI, port vb.
- Performans Metrikleri (Performance Metrics) — süre, boyut, önbellek vb.
- Yanıt Durum Bilgisi (Response Status Info) — durum kodu, hata tipi vb.
- Yönlendirme Adresi (Routing Address)
- İstek ve yanıt akışı: Dört mesaj bölgesi üzerinden Parametre, Başlık (Header) ve Gövde (Body) loglaması ayrı ayrı açılıp kapatılır; istek taraflarında üç alan, yanıt taraflarında tipik olarak Başlık ve Gövde kullanılır. Her bölgede Kısmi boyut (Partial Size) ile gövde/başlık için kısmi kayıt modu yönetilebilir.
- Gizlilik (Privacy): Açıkken, öğe adı ve işlem tipine göre maskeleme vb. kuralları tanımlayan tablo kullanılır; + Ekle ile ortama özel gizlilik tanımları eklenir. Tanım yoksa tabloda bilgi mesajı görünür.
Platform genelinde geçerli log ayarlarını Genel Ayarlar ekranından yapılandırabilirsiniz.
Konnektör Ayarları
Her konnektör nesnesi için aşağıdaki alanlar bağımsız olarak yapılandırılabilir:
| Alan | Açıklama |
|---|---|
| Etkin (Enabled) | Konnektörün bu ortamda kullanılabilir olup olmadığını gösterir (ör. yeşil rozet). |
| Bu ortam için etkin (Active for this environment) | Seçilen ortamda bu konnektöre log gönderiminin açık/kapalı olmasını belirler. |
| Log içeriği seçimi (Log Content Selection) | HTTP istek detayları, performans metrikleri, yanıt durum bilgisi, yönlendirme adresi gibi üst düzey alan gruplarının loglanıp loglanmayacağını ayrı ayrı seçersiniz. |
| Kısmi boyut (Partial Size) | İlgili mesaj bölgesinde başlık/gövde için tam kayıt yerine kısmi (boyut sınırlı) kayıt modunu açar veya kapatır. |
| Başlık (Header) | İlgili bölgedeki mesajın Başlık alanındaki değerlerin loglanmasını sağlar. Mesajdaki başlık bilgilerinin loglanıp loglanmadığını yönetir. |
| Gövde (Body) | İlgili bölgedeki mesajın Gövde alanındaki değerin loglanmasını sağlar. Mesajdaki gövde bilgilerinin loglanıp loglanmadığını yönetir. |
| Parametre (Parameter) | İlgili bölgedeki mesajın Parametre alanındaki değerlerin loglanmasını sağlar. Mesajdaki parametre bilgilerinin loglanıp loglanmadığını yönetir. |
Metod Geçersiz Kılmaları
Belirli API metodları için varsayılan konnektör ayarlarından farklı log ayarları tanımlayabilirsiniz. Örneğin hassas bir metot için gövde loglamasını kapatabilir, diğer metodlar için açık bırakabilirsiniz.
- Metod Geçersiz Kılması Ekle (Add Method Override): Metod ve konnektör seçerek özel ayar tanımlarsınız.
- Metodlar, 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. - Her geçersiz kılma için başlık, parametre ve gövde loglaması ayrı ayrı yapılandırılabilir.
- Mevcut geçersiz kılmalar düzenlenebilir veya silinebilir.
Daha önce yapılmış log ayarları otomatik olarak korunur. Mevcut ayarlar yeni konnektör bazlı sisteme sorunsuz geçiş yapar; ek bir işlem gerekmez.
Gizlilik Ayarları
API Proxy trafik loglarında hassas verilerin korunması için gizlilik ayarları yapılabilir. Bu ayarlar connector'ler environment'a eklenirken yapılandırılır. Hangi alanların loglanacağı ve hangi alanlarda gizlilik işlemleri (maskeleme, silme, hashleme, şifreleme) uygulanacağı belirlenebilir.
Bir Gizlilik Kuralı Veriyi Nasıl Bulur
Her kural önce neyi arayacağına, sonra onunla ne yapacağına karar verir. Bunu tanım eklerken Kural tipi ile seçersiniz. Veriyi bulmanın üç yolu vardır:
| Kural Tipi | Neyi Eşler | Ne Zaman Kullanılır |
|---|---|---|
| Öğe adı | Verilen ada sahip alan, header veya query parametresi — değeri ne olursa olsun | Hassas veri her zaman bilinen bir alanda duruyorsa (password, cardNumber gibi). Ada göre eşleyen tek tip budur; loglanan header'ları, parametreleri ve loglanan URL'in query string'ini kapsar |
| Düzenli ifade | Kalıbınıza uyan her metin — gövdede, istek yolunda, query string'de, loglanan header listelerinde ve loglanan parametre listelerinde | Format API'lerinize özgüyse — sipariş kodu, iç referans numarası |
| Hazır PII tipi | Bilinen bir kişisel veri formatı — gövde, adres, loglanan header listeleri ve loglanan parametre listeleri dahil, nerede geçerse geçsin | Değer herhangi bir alana, /user/12345678901 gibi bir yol parçasına ya da AI prompt'u gibi serbest metne düşebiliyorsa |
Hazır tipler TC Kimlik No (TCKN), Türkiye IBAN, Türkiye telefon numarası, e-posta adresi ve kredi kartı numarasını kapsar; katalogda IP Adresi ve URL dahil ek hazır tipler de bulunur.
İşlemler
- Maskeleme — değeri, seçtiğiniz maskeleme biçimine göre değiştirir (aşağıya bakın)
- Silme — değeri kaldırır
- Hashleme — tek yönlü hash saklar; orijinal değer geri alınamaz
- Şifreleme — geri çözülebilir şifreli değer saklar
- Tespit Et — kaydı değiştirmez; kural tipi ne olursa olsun (öğe adı, düzenli ifade, hazır PII tipi) yalnızca eşleşmeyi not eder, veriyi maskelemez, silmez, hash'lemez veya şifrelemez. Trafik log tarafında bu tespitler için ayrı bir rapor ekranı yoktur
Öğe adı kural tipiyle birlikte Tespit Et işlemi seçili bir kural, yükseltmeden sonra da veriyi maskelemez. Bu alanın loglarda gizlenmesini istiyorsanız kuralın işlemini Maskele olarak değiştirin.
Maskeleme Biçimi
Maskeleme her kural için ayrı yapılandırılır ve üç kural tipinin (öğe adı, düzenli ifade, hazır PII tipi) hepsinde aynı şekilde çalışır:
| Biçim | Girdi | Çıktı |
|---|---|---|
| Tamamını değiştir (varsayılan) | 05321234567 | *** |
| İlk N karakteri koru (N=4) | 05321234567 | 0532******* |
| Son N karakteri koru (N=4) | 05321234567 | *******4567 |
| İlk N karakteri maskele (N=4) | 05321234567 | ****1234567 |
Varsayılan biçim değerin tamamını *** ile değiştirir ve hiçbir şey sızdırmaz. Kısmî biçimler çıktının uzunluğunu korur ve değerin bir bölümünü bilerek açıkta bırakır; destek ekibinin kaydı eşleştirebilmesi gerektiğinde kullanışlıdır, ama kalan parça tek başına bile kişiyi tanımlayabileceği için bilinçli seçilmelidir. Değiştirme metni de yapılandırılabilir; kısmî biçimlerde metnin ilk karakteri maskeleme karakteri olarak kullanılır.
Korunacak karakter sayısı değerin uzunluğuna eşit ya da büyükse hiçbir şey maskelenmemiş olurdu; böyle bir durumda güvenli tarafa düşülür ve değerin tamamı değiştirilir.
Şifrelenen değerin nasıl geri okunacağı Gelişmiş Korumalar sayfasında anlatılır — aynı şifreleme ve anahtar bu ekran için de geçerlidir.
Bilinmesi Gerekenler
URL de kapsama girer, ama farklı kural tipleriyle. Loglanan query string hem ada göre (bir id kuralı, parametre listesindeki id değerini nasıl gizliyorsa ?id=... içindekini de aynı şekilde gizler) hem de desene göre maskelenir. İstek yolu ise yalnızca düzenli ifade ya da hazır PII tipiyle maskelenir; çünkü bir yol parçasının eşleşecek bir adı yoktur. /user/12345678901 içindeki numarayı gizlemek için hazır TCKN kuralı ya da [0-9]{5,} gibi bir desen tanımlayın. Backend'e fiilen gönderilen adres (Gönderilen Adres / routing address) de aynı kurallara tabidir. Adresin yalnız yol ve query string bölümü, httpRequestQueryString ve httpRequestPathInfo ile birebir aynı kurallarla maskelenir; şema, host ve port (https://host:8443 kısmı) hiçbir zaman değiştirilmez — bu bölüm PII taşımaz ve trafik listeleriyle raporların backend'e göre gruplandığı anahtardır. URL'e yüzde-kodlu gelen değerler (user%40example.com) desen uygulanmadan önce çözülür; böylece hazır e-posta kuralı orada da yakalar. Hiçbir kural eşleşmezse loglanan URL geldiği gibi yazılır.
Hazır tipler değerin yalnız biçimini değil, kendisini de doğrular. TCKN, IBAN ve kredi kartı numaraları kalıp eşleştikten sonra doğrulanır (kontrol hanesi, mod-97, Luhn). Biçimi doğru olup doğrulamayı geçemeyen bir değer bilinçli olarak maskelenmeden bırakılır; böylece sıradan 11 haneli sayılar, tutarlar ve referans kodları loglarınızda bozulmaz. Maskelenmesini beklediğiniz bir değer görünmeye devam ediyorsa, önce gerçekten geçerli bir numara olduğunu doğrulayın.
Bu kurallar yalnızca trafik loglarına uygulanır. Elasticsearch, Kafka ve diğer log connector'lerine yazılanı değiştirir; gateway'in istemciye döndürdüğünü veya backend'e gönderdiğini değiştirmez. Trafiğin kendisinde maskeleme için AI PII Mask politikasını ya da bir dönüşüm politikasını kullanın.
Düzenli ifade ve Hazır PII tipi kuralları artık ayrıştırılmış header ve parametre listelerini de tarar. Bu iki kural tipi, hem istemciden gelen hem hedefe giden istekteki, hem de yanıt tarafındaki (hedeften gelen, istemciye giden) loglanan header listelerinde ve istek tarafındaki loglanan parametre listelerinde çalışır — yalnızca gövde ve adres alanlarıyla sınırlı değildir. Aynı kapsam, ilgili proxy'nin izleme (trace) kaydındaki öncesi/sonrası header ve parametre alanları için de geçerlidir. Örneğin hazır TCKN kuralı tanımlıysa, geçerli bir TCKN değeri hem adreste hem de ayrıştırılmış parametre listesinde maskelenir. Bu tarama yalnızca ilgili kural tanımlıysa çalışır; hiçbir Düzenli ifade veya Hazır PII tipi kuralı tanımlı değilse ek bir maliyeti yoktur.
Hazır PII tipi olarak IP Adresi veya URL kuralı tanımlarsanız X-Forwarded-For, Referer, Location gibi header değerleri de trafik kaydında maskelenir. Gerçek istek ve yanıt hiçbir zaman değişmez; yalnızca log kaydındaki kopya maskelenir.
Detaylı bilgi için Log Konnektörü Eklenmesi sayfasına bakabilirsiniz.
Log Ayarları bölümünde, log ayarları API Proxy bazlı olarak yönetilir.
Ortam Kısıtlarını Ezme
Bu sekmedeki konnektör ayarları son sözü söylemez. Bir konnektör Gateway Runtime ortamına eklenirken yönetici ona bir detay filtresi ve boyut limitleri iliştirebilir; bu, hangi proxy ne isterse istesin loglanabilecekleri daraltan, ortam geneline ait bir kuraldır.
Bu sekmenin üst çubuğundaki Ortam kısıtlarını ez seçeneği, yalnızca bu API Proxy'yi o kuraldan muaf tutar. Sık karşılaşılan bir duruma verilen cevaptır: ortam, log hacmini kontrol etmek için yanıt gövdelerini kapalı tutar, ama bir entegrasyon incelemededir ve bir süre tam kayıt gerekir.
Anahtar tek başına çalışır; konnektörden ayrıca bir izin beklenmez. Karar tümüyle proxy sahibine aittir ve ortamdaki log konnektörünün tipinden bağımsız olarak geçerlidir.
Ezmenin atladığı şeyler: ortam konnektörünün detay filtresi (hangi alanlara izin verdiği) ve gövde boyut sınırları. Anahtar etkinken bu proxy'nin kendi log ayarları tek başına karar verir; ortamın keseceği bir gövde tam olarak kaydedilir.
Gizlilik ayarları bu anahtarın dışındadır. Maskeleme, hash'leme, silme ve şifreleme kuralları ezmeden bağımsız olarak her kayda uygulanır — bunlar bir görüntüleme tercihi değil, veri koruma yükümlülüğüdür ve proxy seviyesindeki bir anahtar onları kaldıramaz.
Veri saklama profili de etkilenmez. No Payload veya No Persist yürürlükteyken gövde hiç toplanmaz, dolayısıyla ezmenin yeniden açacağı bir şey yoktur.
Ayar varsayılan olarak kapalıdır ve proxy'nin kendi log ayarı kaydında tutulur; bu kaydın gateway'e giden kendi dağıtım kanalı vardır. Kaydetmek yeterlidir — API Proxy yeniden dağıtımı (redeploy) GEREKMEZ, değişiklik bir sonraki istekte geçerlidir.
Veri Saklama Profili
Bu sekmedeki başlık/gövde/parametre ayarları, proje ve global seviyeden devralınan veri saklama profili çerçevesinde çalışır — proxy seviyesinde profili daha da katılaştırabilirsiniz, ama devraldığınızdan daha gevşek bir profil seçmeniz kayıt sırasında reddedilir.
Gövde Yok veya Kalıcı Kayıt Yok profili etkinken, yukarıdaki Log İçeriği Seçimi ve Konnektör Ayarları'nda başlık/gövde/parametre alanları açık görünse bile bu veriler hiç yakalanmaz — Gizlilik kuralları da (aşağıda) böyle bir durumda üzerinde çalışacak veri bulamaz.
İlgili Sayfalar
- Analitik (Admin)
- API Trafiği Log Kaydı Veri Yapısı
- Gönderilmemiş API Trafik Loglarını Taşı
- API Trafik Loglarını Yönetmek
- API Trafik Logu Hacim Yönetimi