Yönetim > Sistem Ayarları yolunu izleyerek birleşik Sistem Ayarları ekranına erişilir. Bu ekran, platformun tüm yapılandırma parametrelerini, varsayılan limitlerini ve sistem kısıtlarını 8 sekmede gruplayarak sunar.
uyarı
Bu ekrana sadece Yönetici (Admin) rolü olan kullanıcılar erişebilir. Ayarlar platform genelinde etkili olduğundan dikkatli yapılandırılmalıdır.
Birleşik Sistem Ayarları sayfası, daha önce ayrı ekranlarda yönetilen Genel Ayarlar, Sistem Özellikleri ile belgelenmemiş olan runtime parametreleri ve sistem kısıtlarını tek bir arayüzde birleştirmektedir. Her ayarın yanında kapsam etiketi (scope badge) bulunur:
Kapsam
Renk
Açıklama
Deploy Gerekli
Turuncu
Veritabanında saklanır, değişikliğin geçerli olması için API Proxy'lerin yeniden deploy edilmesi gerekir
Restart Gerekli
Mavi
Ortam değişkeni olarak tanımlanır, değişiklik için pod yeniden başlatılmalıdır
Sabit
Gri
Değiştirilemez altyapı sınırı
Düzenlenebilir ayarlar ilgili giriş bileşenlerini (sayı, metin, açma/kapama, renk seçici vb.) kullanarak doğrudan ekrandan değiştirilebilir. Salt okunur parametreler kilit simgesiyle gösterilir.
Sekme 1: Yönlendirme ve Trafik Yönetimi (Routing & Traffic Management)
Bu sekme, API isteklerinin arka uç sunuculara nasıl yönlendirileceğini ve bağlantı yapılandırmasını kontrol eden ayarları içerir.
Göreli yönlendirme izni kapalıyken, arka uçtan gelen Location başlığı göreli bir adres taşıyorsa yönlendirme takip edilmez ve istek açık bir yönlendirme hatasıyla sonlanır. Mutlak adresler (http→https geçişleri dâhil) bu ayardan etkilenmez.
Maksimum yönlendirme değeri HTTP/2, streaming (SSE) ve sunucu-akışı taşımalarında min(ayar, 20) olarak uygulanır: bu taşımalar OkHttp kullanır ve OkHttp'nin kendi takip üst sınırı 20'dir, değiştirilemez. 20'nin üzerinde bir değer girildiğinde fiilen 20 geçerli olur. HTTP/1.1 taşımasında ayarın tamamı uygulanır.
Başarısız giriş denemeleri sunucuda kullanıcı başına sayılır; ardışık başarısızlık captcha için izin verilen ve kilitleme için izin verilen sayıların toplamına ulaşınca (varsayılan 3 + 7 = 10) hesap kilitlenir, kilit Kullanıcılar → Kilitli alanından görülür ve açılır. Captcha eşiğini giriş sayfasının kendisi uygular: aynı tarayıcı sayfasında art arda o kadar başarısız denemeden sonra CAPTCHA görünür. Bu, gelişigüzel tekrar denemelere karşı istemci tarafı bir caydırıcıdır, güvenlik kontrolü değildir; kontrol kilitlemedir. Giriş ekranı hangi durumun geçerli olduğunu hiçbir zaman söylemez: bilinmeyen kullanıcı adı, yanlış parola, kilitli ya da pasif hesap ve başarısız LDAP kontrolü aynı Kullanıcı adı veya parola hatalı yanıtını alır; kalan deneme sayısı gösterilmez. Bu bilgilerden herhangi birinin giriş yapmamış bir çağırana açıklanması, hangi hesapların var olduğunun keşfedilmesine (user enumeration) yol açar. Kesin neden, yöneticiler için Giriş Kayıtları ekranında kaydedilmeye devam eder.
JDK TLS/SSL Ayarları (Restart Gerekli, Salt Okunur)
Parametre
Açıklama
Kapsam
Devre Dışı Bırakılan Algoritmalar
TLS'de kullanımı engellenen algoritma listesi
Restart Gerekli
Sertifika Yolu Devre Dışı Bırakılan Algoritmalar
Sertifika doğrulama yolunda engellenen algoritmalar
Log saklama ayarları, farklı log tiplerine göre saklama sürelerini ve maksimum kayıt sayılarını belirler. Tüm log tipleri (trafik, uygulama, token, audit, login, güvenlik olayları) için ayrı ayrı yapılandırılabilir — Kimlik Bilgisi Senkronizasyonu sayfasında anlatılan koşu-bazlı Kimlik Senkronizasyon Geçmişi dahil; bu ayar varsayılan olarak kapalıdır ve yönetici açıkça etkinleştirmedikçe hiçbir koşu kaydı silinmez. Güvenlik Olayları sayfasında anlatılan, bir politika tarafından engellenen ya da hatayla sonuçlanan Gateway isteklerinin gövdesiz kaydı olan API Security Events (API Güvenlik Olayları) temizleme görevi de aynı şekilde varsayılan olarak kapalıdır. Bitmiş Veri Yaşam Döngüsü Temizleme koşularının kaydı olan Lifecycle Purge Run History (Temizleme Koşusu Geçmişi) de aynı şekilde varsayılan olarak kapalıdır (etkinleştirildiğinde 365 gün); devam eden bir koşu bu ayardan bağımsız olarak asla temizlemeye uygun değildir.
Yukarıdaki Log Saklama ayarı log kayıtlarının ne kadar süre tutulacağın ı belirlerken, Veri Saklama Profili farklı bir soruyu yanıtlar: bir isteğin gövdesi/header'ları hiç kaydediliyor mu. Katılık sırasına göre artan üç profil vardır:
Profil
Ekrandaki adı
Davranış
STANDARD
Standart
Bugünkü davranış — gövde/header yakalama, kalıcı kayıt ve iz kaydı (trace) mevcut ayarlarınıza göre normal çalışır
NO_PAYLOAD
Gövde Yok
İstek/yanıt header'ları, query string ve gövde hiç yakalanmaz — sonradan temizlenmez, baştan hiç doldurulmaz. Canlı İzleme (trace) başlatma bu profildeyken kilitlenir; yetkili bir kullanıcı bile açamaz
NO_PERSIST
Kalıcı Kayıt Yok
Gövde Yok'un tüm kısıtlarına ek olarak connector'lara, Mongo trace deposuna veya OTel span'lerine hiçbir kayıt gönderilmez. İz kaydı burada da kilitlidir
Sayaç ve metrik akışları (Prometheus, kota sayaçları) her üç profilde de etkilenmez — bu profiller yalnızca kalıcı kayıt üretimini durdurur, sayma işlemini değil.
Bellekteki geçici veriyle karıştırmayın
Bu profiller kalıcı/harici kayıt üretimini engeller. Bir istek işlenirken veri (örneğin backend'e iletilirken) JVM belleğinde yine de geçici olarak bulunur — "bellekte bile hiçbir iz kalmaz" iddiası bu profillerle kurulmaz, yalnızca "kalıcı/harici kayıt üretilmez" iddiası kurulur.
Profil üç seviyede ayarlanabilir: bu sayfadaki global seviye, proje ayarları seviyesi ve API proxy'nin trafik log ayarları seviyesi. Etkin (effective) profil üç seviyeden en katı olanıdır — bir alt seviye üst seviyeden daha gevşek bir profil seçemez: proje, global profille aynı veya ondan daha katı bir profil seçebilir; proxy da kendi devraldığı (global + proje) etkin profille aynı veya ondan daha katı olmalıdır. Daha gevşek bir seçim ekranda kayıt sırasında reddedilir.
Bu kademeleme yalnızca bir arayüz kolaylığı değildir — gateway çalışma zamanında da aynı en-katı-kazanır mantığıyla etkin profili hesaplar; bir üst seviyeyi arayüz dışından (örn. APIops ile proxy ayarını doğrudan güncelleyerek) atlatmaya çalışmak etkisizdir.
Kafka, RabbitMQ, ActiveMQ, Graylog, Webhook ve veritabanı (DB) bağlantılarının log gönderimi için kullandığı devre kesicinin kurulum genelindeki varsayılan değerleridir. Bu bölüm, Sekme 1'deki Yönlendirme (Routing) devre kesicisinden bağımsızdır — o, backend'e giden isteklerin devre kesicisidir; buradaki yalnızca connector'ların log gönderimini kapsar.
Parametre
Varsayılan
Yapılandırma Aralığı
Kapsam
Devre Kesici Etkin
Kapalı
-
Deploy Gerekli
Hata Penceresi
10 sn
1 - 3.600 sn
Deploy Gerekli
Hata Eşiği
5
1 - 10.000
Deploy Gerekli
Uyku Penceresi
30 sn
1 - 3.600 sn
Deploy Gerekli
Yarı Açık Deneme Etkin
Açık
-
Deploy Gerekli
bilgi
Bu beş değer kurulum genelindeki varsayılanlardır. Kafka, RabbitMQ, ActiveMQ, Graylog, Webhook ve veritabanı bağlantı ekranlarındaki Dayanıklılık (Resilience) bölümünden, her bağlantı için Devre Kesiciyi Etkinleştir, Hata Eşiği ve Bekleme Penceresi ayrı ayrı geçersiz kılınabilir (override); boş bırakılan alanlar buradaki varsayılanı kullanır. Hata Penceresi ve Yarı Açık Deneme Etkin yalnızca burada, kurulum genelinde yapılandırılır.
Sekme 5: Veri İşleme ve Sınırlar (Data Processing & Limits)
Sekme 6: Gateway Çalışma Zamanı (Gateway Runtime)
Bu sekmedeki tüm parametreler Restart Gerekli kapsamındadır ve salt okunurdur. Değiştirmek için ortam değişkeni olarak tanımlanmalı ve pod yeniden başlatılmalıdır.
Korelasyon kimliği başlık adı şu anda sabit olarak tanımlıdır ve değiştirilemez. Bu değer istekler arasında iz sürme (distributed tracing) için kullanılır.
Ekranın sağ üst köşesindeki Değişiklikleri Uygula butonu ile değişiklikler kaydedilir. Sistem farklı veri kaynaklarına ait değişiklikleri ayrı ayrı kaydeder:
Deploy Gerekli (DB) ayarlar anında tüm node'lara dağıtılır
Restart Gerekli ayarlar için ilgili pod'un yeniden başlatılması gerekir
Sabit değerler salt okunurdur ve değiştirilemez
uyarı
Bazı ayarların (örneğin API Root Context) değiştirilmesi platformun yeniden başlatılmasını gerektirebilir.