Syslog
Genel Bakış
Amacı Nedir?
Connection (Bağlantı) üzerinden Apinizer loglarını merkezi bir syslog kolektörüne düşük gecikmeli olarak aktarır.
TCP/UDP, TLS ve mesaj formatı seçenekleriyle farklı kurum standartlarına uyumlu log taşıma esnekliği sunar.
Ortam bazlı yapılandırma ile Development/Test/Production ayrımını korurken ortak isimlendirme ve versiyonlama sağlar.
UDP modunda iletilen loglar için teslim garantisi yoktur; kritik akışlar için TCP + SSL/TLS tercih edin.
Çalışma Prensibi
Integration Flow veya Connector içerisinden Syslog bağlantısı talep edildiğinde, sistem yapılandırılmış connection parametrelerini okur.
TCP modunda her ortam için bir veya daha fazla kalıcı soket açılır (Bağlantı Sayısı); log mesajları asenkron olarak kuyruğa alınır ve sırayla gönderilir — bu bir connection pool değil, kalıcı soket(ler) üzerinden çalışan kuyruklama modelidir. Kuyruk (mesaj adedi veya bellek tavanından hangisi önce dolarsa) dolduğunda yeni mesajlar, Syslog Connector tanımında failover connector etkinleştirilmişse oraya yönlendirilir; etkin değilse (varsayılan) düşürülür. Aktif bağlantı kapandığında veya yazma zamanaşımı aşıldığında otomatik yeniden bağlanma uygulanır; UDP modunda stateless gönderim yapılır.
TLS kullanılıyorsa sertifika tabanlı Authentication uygulanır, aksi durumda syslog sunucusunun IP tabanlı güvenlik politikaları devreye girer.
Seçilen protokol üzerinden RFC 3164/5424/5425 formatında log mesajları, hostname ve facility/severity alanları iletilir.
İşlem tamamlandıktan sonra TCP bağlantısı açık kalır ve kuyruktaki bir sonraki mesaj için yeniden kullanılır; UDP paketleri stateless olduğu için ek yönetim gerekmez.
Bağlantı hatası, timeout veya authentication hatası durumunda deployment-result diyaloğunda detaylar gösterilir; hata metric'leri Apinizer Event Manager üzerinden yayılır.
Kullanım Alanları
API Gateway loglarının SIEM veya SOC platformlarına gerçek zamanlı aktarılması
Güvenlik olaylarının (ör. WS-Security, Authentication hataları) merkezi alarm sistemine bildirilmesi
İşletim sistemleri, firewall ve Apinizer servisleri arasındaki log korelasyonu için tekil log akışının sağlanması
Test ortamında yeni kural/dönüşüm geliştirmelerini prod ortamındaki syslog altyapısını etkilemeden doğrulama
Teknik Özellikler ve Yetenekler
Temel Özellikler
TCP/UDP: Düşük gecikmeli UDP veya güvenilir TCP modları arasında seçim yapılabilir.
RFC 3164, RFC 5424 veya RFC 5425 formatları; hostname, facility ve severity alanlarıyla uyumlu log şablonu oluşturulur.
environmentId listesi üzerinden her Connection için hedef Ortam seçilerek farklı syslog uçlarına yönlendirme yapılır.
Her ortam (Development, Test, Production) için ayrı connection parametreleri tanımlama imkanı.
Connection'ı aktif veya pasif hale getirme (enable/disable toggle). Pasif durumda bağlantı kullanılamaz ancak yapılandırması saklanır.
OCTET_COUNTING modunda mesajlar uzunluk önekiyle çerçevelenir; büyük veya çok satırlı gövdelerde satır sonları çerçeveyi bölmez.
Birden fazla TCP soketiyle paralel gönderim yapılabilir; gönderim kuyruğu artık bayt cinsinden bir bellek tavanıyla da sınırlandırılabilir.
İleri Düzey Özellikler
Kaydetme ve test sonrası IDeploymentResult çıktıları kullanıcıya gösterilir, log akışının gerçek durumu anında izlenir.
Admin kullanıcıları connection'ı proje bağlamından çıkarıp global alana taşıyabilir, böylece tekrar kullanım kolaylaşır.
ExportFile yapısı ile JSON + metadata paketlenerek başka ortamlara aktarılabilir.
"Test Connection" butonu ile bağlantı parametrelerini kaydetmeden önce doğrulama imkanı.
Connection yapılandırmasını ZIP dosyası olarak export etme. Farklı ortamlara (Development, Test, Production) import etme. Versiyon kontrolü ve yedekleme imkanı.
Bağlantı sağlığı, kuyruk durumu ve performans metriklerini izleme.
Connection Parametreleri
Zorunlu Parametreler
Parametre: Name
Örnek Değer: Production_Syslog
Connection adı (benzersiz olmalı). Boşlukla başlamaz, özel karakterler kullanılmamalı.
Parametre: Environment (Ortam)
Örnek Değer: prod-env-id
Logların hedefleneceği yayınlanmış ortamın kimliği. Ortam listesi Environment Service üzerinden gelir, seçim yapılmazsa test edilemez.
Parametre: Syslog Protocol Type
Örnek Değer: TCP
TCP veya UDP seçimi. TCP seçildiğinde timeout ve SSL ayarları zorunlu olur.
Parametre: Syslog Server Hostname
Örnek Değer: syslog.corp.local
Logların gönderileceği syslog sunucu adı veya IP'si. FQDN önerilir, DNS çözümlemesi gateway tarafından yapılır.
Parametre: Syslog Port
Örnek Değer: 514
Syslog dinleme portu. UDP için 514, TLS için 6514 yaygın kullanılabilir.
Parametre: Syslog Message Format
Örnek Değer: RFC_5424 (yeni bağlantıda önerilen varsayılan; bu varsayılan değişmeden önce oluşturulmuş bir bağlantı, siz değiştirene kadar RFC_3164'ü korur)
Mesaj gövdesi şablonu (RFC 3164/5424/5425). SIEM beklentisine göre seçilmelidir.
Parametre: Syslog App Name
Örnek Değer: ApinizerGateway
Mesajlarda görünecek uygulama adı. 48 karakteri aşmaması önerilir.
Parametre: Syslog Facility
Örnek Değer: AUDIT
Log sınıflandırma değeri; standart syslog facility listesinden seçilir (örneğin AUDIT, USER, DAEMON, AUTH ya da LOCAL0-LOCAL7).
Parametre: Syslog Severity
Örnek Değer: INFORMATIONAL
Log önem seviyesi; standart syslog severity listesinden seçilir (Emergency, Alert, Critical, Error, Warning, Notice, Informational, Debug).
Parametre: Syslog Timeout (TCP)
Örnek Değer: 500
TCP el sıkışması + ACK için milisaniye cinsinden bekleme. UDP modunda gösterilmez, TCP modunda zorunludur.
İsteğe Bağlı Parametreler
Parametre: Description
Varsayılan Değer: -
Önerilen Değer: Kullanım amacı ve hedef syslog kümesini belirtin
Connection hakkında açıklama
Parametre: Syslog Message Hostname
Varsayılan Değer: gateway01
Önerilen Değer: Her ortam için farklı hostname kullanarak korelasyonu kolaylaştırın
Log içindeki HOSTNAME alanını override eder.
Parametre: Syslog SSL Enabled
Varsayılan Değer: false
Önerilen Değer: Production'da true, Test/Dev'de gerekirse self-signed
TCP üzerinden TLS kapsülleme sağlar.
Parametre: Keystore (Key Store)
Varsayılan Değer: Boş
Önerilen Değer: Yalnızca syslog sunucusu istemci sertifikası istiyorsa doldurun
Karşılıklı TLS (mTLS) için syslog sunucusuna sunulan istemci sertifikası. Boş bırakılırsa istemci sertifikası sunulmaz ve bağlantı yalnız sunucu TLS'i ile kurulur. Liste Yönetim → Gizlilik Yönetimi → Key Stores ekranındaki kayıtlardan gelir; kayıttaki tek parola hem depo hem de anahtar parolası olarak kullanıldığı için PKCS12 paketini tek parolayla hazırlayınız. Yalnızca Syslog SSL Enabled açıkken dikkate alınır.
Parametre: Truststore (Trust Store)
Varsayılan Değer: Boş
Önerilen Değer: Syslog sunucusu kurum içi bir sertifika otoritesinden imzalıysa o otoritenin kök sertifikasını taşıyan depoyu seçin
Syslog sunucusunun sertifika zincirini doğrulayan güven deposu. Boş bırakılırsa Java çalışma ortamının varsayılan güven deposu kullanılır; bu, sürüm yükseltmesi öncesindeki davranıştır. Bir güven deposu seçildiğinde yalnızca o depo geçerli olur: varsayılan kök sertifikalar bu depoya eklenmez, dolayısıyla genel bir sertifika otoritesinden alınmış sunucu sertifikası yalnız kurum kökünü taşıyan bir depoyla doğrulanmaz. Yalnızca Syslog SSL Enabled açıkken dikkate alınır.
Parametre: Sunucu Adı (Hostname) Doğrulaması (Hostname Verification)
Varsayılan Değer: Ekrandan oluşturulan yeni kayıtlarda açık; alanın hiç ayarlanmadığı kayıtlarda kapalı
Önerilen Değer: Sunucu sertifikasındaki ad hedef adresle eşleşiyorsa açık bırakın
Sunucu sertifikasındaki adın bağlantıdaki hedef ana bilgisayar adıyla eşleşmesini şart koşar. Kapalıyken yalnızca sertifika zinciri doğrulanır, sunucunun kimliği doğrulanmaz. Alanın hiç ayarlanmadığı kayıtlarda — sürüm yükseltmesinden gelenler ve alanı göndermeyen APIops istekleriyle oluşturulanlar dahil — doğrulama kapalıdır; açmak için değeri açıkça belirtmeniz gerekir. Hedef bir IP adresi olarak girildiyse doğrulamanın çalışması için o IP'nin sunucu sertifikasının alternatif ad (SAN) alanında bulunması gerekir. Yalnızca Syslog SSL Enabled açıkken dikkate alınır.
Parametre: RFC 5424 Yapılandırılmış Veri (SD) Yaz (Structured Data)
Varsayılan Değer: false
Önerilen Değer: SIEM tarafı mesaj gövdesine düzenli ifade yazmadan olay üstverisini okuyacaksa açın
Çerçevenin RFC 5424 yapılandırılmış veri alanını doldurur. Yalnızca RFC 5424 ve RFC 5425 mesaj formatlarında ve TCP protokolünde etkilidir; RFC 3164 seçiliyken ve UDP yolunda sessizce yok sayılır. Açıldığında bu bağlantı üzerinden geçen tüm RFC 5424/5425 çerçeveleri — SIEM olaylarının yanı sıra bu bağlantıyı kullanan trafik ve uygulama logları da — yapılandırılmış veri taşır.
Parametre: Kurum Numarası (PEN) (Enterprise ID)
Varsayılan Değer: Boş
Önerilen Değer: Kurumunuzun IANA numarası varsa girin; yoksa boş bırakın
IANA Private Enterprise Number; 1 ile 10 arasında rakam kabul edilir, başka karakter içeren değer kaydedilemez. Boş bırakılırsa yapılandırılmış veride yalnızca origin ve timeQuality elemanları yazılır, kuruma özel apinizer@<numara> elemanı hiç üretilmez. Numara başvurusu Apinizer dışında, IANA başvuru formu üzerinden yapılır. Yalnızca yapılandırılmış veri açıkken dikkate alınır.
Parametre: Deploy To Worker
Varsayılan Değer: true
Önerilen Değer: Ağ izolasyonu varsa true bırakın
Bağlantının worker node'lara dağıtılıp dağıtılmayacağı.
Parametre: Syslog Framing Type
Varsayılan Değer: AUTO (boş bırakılabilir)
Önerilen Değer: Ortalama mesaj boyutu büyükse veya SIEM tarafında satır bütünlüğü önemliyse OCTET_COUNTING
Çerçeveleme biçimini belirler: AUTO / NON_TRANSPARENT / OCTET_COUNTING. Boş bırakılır veya AUTO seçilirse değer seçili mesaj formatından türetilir — RFC 5425 seçiliyse OCTET_COUNTING, diğer formatlarda NON_TRANSPARENT (bugünkü davranış, mesaj sonuna CR LF eklenir). OCTET_COUNTING seçildiğinde her çerçeve <uzunluk> <mesaj> biçiminde uzunluk önekiyle gönderilir (RFC 6587 §3.4.1).
TLS Bağlantısını Doğrulama ve Sertifika Yenileme
TLS ile ilgili alanların hiçbiri zorunlu değildir. TLS kullanmayan kurumlar Syslog SSL Enabled kapalı kalacak şekilde düz TCP ya da UDP ile çalışmaya devam eder; bu yolda çerçeveler ve davranış değişmemiştir.
Test Connection butonu TLS açıkken sonuç kutusuna bir tanılama satırı yazar. Satır, el sıkışmanın gerçekten hangi koşullarda tamamlandığını gösterir:
ok: tls: TLSv1.3 / TLS_AES_256_GCM_SHA384 / peer=CN=siem.kurum.local / clientCert=CN=apinizer-gw (expires 2036-08-31)
peersunucunun sunduğu sertifikanın adıdır;clientCertApinizer'ın sunduğu istemci sertifikasıdır. İstemci sertifikası seçilmemişse bu bölümclientCert=noneolarak görünür.- Seçilen keystore veya truststore çözülemezse test açık bir hata mesajıyla başarısız olur; bağlantı sessizce düz TLS'e ya da düz TCP'ye düşmez.
- Test çerçevesi yapılandırılmış veri taşımaz. Yapılandırılmış verinin sunucuda nasıl göründüğünü doğrulamak için gerçek bir olay gönderiniz.
Aynı davranış üretimde de geçerlidir: seçilen depo çözülemediğinde o hedefe hiçbir olay gönderilmez ve yaklaşık 30 saniyede bir açıklayıcı bir hata kaydı düşer. Bağlantıda bir yedek (failover) connector tanımlıysa kayıtlar oraya yönlendirilir; tanımlı değilse düşürülür.
Syslog SSL Enabled kapatıldığında üç TLS alanı silinmez. Keystore, Truststore ve Sunucu Adı (Hostname) Doğrulaması alanları form üzerinde görünmez olur ancak kayıtta korunur; SSL bir sonraki açılışında aynı değerlerle yeniden geçerli olur.
Sertifika yenilendikten sonra bağlantıyı yeniden kaydediniz. Aynı keystore kaydının içeriği güncellendiğinde çalışan gönderici havuzu eski sertifika materyaliyle bağlantısını sürdürür. Syslog bağlantısını yeniden kaydetmek (ya da ortamı yeniden dağıtmak) havuzu yeni materyalle yeniden kurar.
Timeout ve Kuyruk Parametreleri
Açıklama: TCP modunda syslogTimeout değeri (el sıkışması + ACK bekleme)
Varsayılan: 500
Birim: milisaniye
Notlar: UI'da yalnızca zorunluluk kontrolü var; min/max yok.
Açıklama: TCP asenkron gönderim kuyruğundaki maksimum log mesajı adedi. Artık Bellek Tavanı ile birlikte çalışan ikincil bir sınırdır — ikisinden hangisi önce dolarsa kuyruk o noktada dolu kabul edilir. Bu durumda mesaj, failover connector etkinse oraya yönlendirilir; etkin değilse düşürülür.
Varsayılan: 10000
Min: 100 | Max: 1000000
Birim: mesaj
Açıklama: Syslog sunucusuna bir mesajın yazılması bu süreyi aşarsa bağlantı zorla kapatılır ve yeniden kurulur.
Varsayılan: 5
Min: 1 | Max: 60
Birim: saniye
Açıklama: TCP modunda eşzamanlı açılan syslog soket sayısı. Birden fazla soket açıldığında mesajlar bu soketler arasında dağıtılarak gönderilir; bu bir connection pool değildir.
Varsayılan: 1
Min: 1
Birim: adet
Notlar: Varsayılan değer (1) bilinçli seçilmiştir — 1'den büyük bir değer mesaj sırasını bozabilir ve mevcut kurulumların büyük çoğunluğu tek-soket, tam-sıralı davranışa bağımlıdır. Değiştirmeden önce aşağıdaki "Paralel Bağlantılarda Sıra" bölümünü inceleyin.
Açıklama: Gönderim kuyruğunun bayt cinsinden üst sınırı. Kuyruk Kapasitesi ile birlikte çalışır, ikisinden önce dolan sınır bağlayıcıyı dolu duruma getirir.
Varsayılan: 64 MB
Min: 1 MB (1.048.576 bayt)
Birim: bayt
Notlar: Bu değerin dörtte birinden büyük tek bir kayıt kuyruğa hiç alınmaz, beklemeden reddedilir — kuyruğa asla sığmayacak bir kayıt admission'ı kilitlemesin diye. Varsayılan 64 MB'da bu tavan 16 MB'dır; daha büyük tekil kayıtlar gönderilecekse Bellek Tavanını buna göre yükseltin.
Açıklama: Kuyruk doluyken gönderen tarafın bekleyeceği en fazla süre. Süre dolduğunda mesaj, failover connector etkinse oraya yönlendirilir; etkin değilse düşürülür.
Varsayılan: 100
Min: 0 | Max: 2000
Birim: milisaniye
Notlar: Bu süre yalnızca sanal thread (virtual thread) üzerinde tam olarak uygulanır. Gönderim bir platform thread'i üzerinde çalışıyorsa istek thread'ini uzun süre tutmamak için etkin bekleme 50 ms'e sınırlanır.
Açıklama: Bir yazma turunda kaç çerçevenin gönderilip tek seferde flush edileceği.
Varsayılan: 8
Min: 1
Birim: adet
Mesaj Bölme Parametresi
Açıklama: Bu connection'ın gönderdiği tek bir syslog mesajının alabileceği en büyük boyut; bu değer aşıldığında kayıt tek mesaj yerine birden fazla syslog mesajı olarak gönderilir. Ölçülen miktar çerçevenin başlığı, yapılandırılmış verisi ve gövdesiyle birlikte bütün syslog mesajıdır — yalnızca serbest metin gövdesi değil; bu, rsyslog'un `global(maxMessageSize=...)` (eski `$MaxMessageSize`) ile ölçtüğü miktarla aynıdır. Mesajın etrafındaki RFC 6587 çerçevelemesi — OCTET_COUNTING modundaki uzunluk öneki veya NON_TRANSPARENT modundaki satır sonu — bu ölçüme dahil değildir.
Varsayılan: 0 — bölme yok. Bu alan hiç ayarlanmasa da her kayıt, bu ayar var olmadan önceki gibi bayt düzeyinde tek bir mesaj olarak gönderilmeye devam eder.
Birim: bayt (UTF-8)
Notlar: UDP'de bu değeri ağ yolunuzun gerçek datagram boyutunun belirgin biçimde altında tutun; RFC 5426, eski relay ve ara cihazlarla uyumluluk için 2048 baytın altında kalınmasını önerir. Bölünmüş bir mesajın telde nasıl göründüğü ve SIEM & Log Yönlendirme sayfasındaki boyut politikasıyla ilişkisi için aşağıdaki Büyük Mesajları Bölme bölümüne bakınız.
Büyük Kayıtlar ve Yüksek Hacim
Yeni parametrelerin tamamı opsiyoneldir ve boş bırakılabilir. Çerçeveleme, paralel bağlantı sayısı ve kuyruk adedi tarafında boş bırakıldığında bugünkü davranış korunur. Tek istisna Bellek Tavanıdır: bu alan hiç doldurulmasa da 64 MB'lık üst sınır varsayılan olarak uygulanır — ortalama kayıt boyutu büyük olan kurulumlarda kuyruk, eskisine göre daha erken dolu duruma gelir (200 KB'lık kayıtlarda 64 MB ≈ 327 mesaj, eski adet sınırı ise 10.000 idi). Bu kurulumlarda Bellek Tavanını bilinçli olarak yükseltin.
Neden Tampon Bellek Tavanı Var
Önceki sürümlerde gönderim kuyruğu yalnızca mesaj sayısıyla sınırlıydı (Kuyruk Kapasitesi, varsayılan 10.000). Ortalama 200 KB büyüklüğündeki API trafik kayıtlarında dolu bir kuyruk bu durumda yaklaşık 2 GB bellek anlamına gelir; ayrıca kuyrukta uzun süre bekleyen kayıtlar JVM'de daha uzun ömürlü bir bellek kuşağına terfi ederek yoğun çöp toplamayı (garbage collection) tetikler. Bellek Tavanı parametresi aynı kuyruğa bayt cinsinden bir üst sınır getirerek (varsayılan 64 MB) bu riski öngörülebilir bir seviyede tutar. Kuyruk Kapasitesi ve Bellek Tavanı birlikte çalışır: ikisinden hangisi önce dolarsa kuyruk o noktada dolu kabul edilir.
Uzunluk Önekli Çerçeveleme (OCTET_COUNTING)
Çerçeveleme tipi OCTET_COUNTING seçildiğinde her mesaj, sunucunun önceden bileceği bir uzunluk değeriyle çerçevelenir; bu sayede mesaj gövdesi içindeki satır sonları artık çerçeveyi bölmez. NON_TRANSPARENT modda (bugünkü varsayılan davranış) gövdedeki her satır sonu syslog sunucusu için bir çerçeve sonu anlamına geldiğinden, JSON/XML gibi çok satırlı gövdeler gönderim öncesinde tek satıra indirilir. OCTET_COUNTING modda bu indirgeme yapılmaz, kayıt orijinal biçimiyle sunucuya ulaşır.
Bu davranış rsyslog 8.2504.0 ile doğrulanmıştır: 200 KB'lık bir mesaj OCTET_COUNTING modda tek bir olay olarak sunucuya ulaşırken, aynı gövde NON_TRANSPARENT modda birden fazla olaya bölünmüştür.
Paralel Bağlantılarda Sıra
Paralel Bağlantı Sayısı 1'den büyük seçildiğinde mesajlar farklı soketlere dağıtılır ve sunucuya varış sırası değişebilir. RFC 5424 formatı mikrosaniye hassasiyetinde zaman damgası taşıdığı ve her soket kendi artan mesaj kimliğini ürettiği için, sıralamayı yeniden kurmak isteyen taraf için bu iki alan ayırt edici bilgi sağlar. RFC 3164 seçildiğinde Paralel Bağlantı Sayısı otomatik olarak 1'e sabitlenir; bu formatta saniye altı hassasiyet bulunmadığından paralel gönderimde sıralama garantisi verilemez.
rsyslog Sunucu Tarafı Gereksinimleri
Uzunluk önekli çerçevelemenin (OCTET_COUNTING) beklenen kazancı sağlaması için rsyslog tarafında da aşağıdaki noktaların gözden geçirilmesi gerekir:
imtcpgirişindekimaxFrameSizevarsayılanı 200000 bayttır. Ortalama mesaj boyutu bunun üzerindeyse (örneğin 200 KB ≈ 204800 bayt) rsyslog uzunluk önekli moddan çıkar ve OCTET_COUNTING kazancı kaybolur.global(maxMessageSize="...")ayrı bir ayardır vemaxFrameSizeile birlikte yükseltilmelidir.maxFrameSizeparametresi rsyslog 8.1905 ve sonraki sürümlerde bulunur; daha eski sürümler bu parametreyi tanımaz ve hata döner (parameter maxFrameSize not known). Ayarı uygulamadan önce sunucu sürümünün doğrulanması önerilir.global(oversizemsg.report="on")açıldığında, boyutu aşan kayıtlar sessizce kaybolmak yerine raporlanır.- rsyslog, mesaj gövdesindeki satır sonlarını varsayılan olarak kendi kaçış dizisiyle yazar; SIEM tarafında bu karakterler örneğin
#012olarak görünür. Kaydın ham haliyle görünmesi isteniyorsaglobal(parser.escapeControlCharactersOnReceive="off")ayarlanmalıdır.
Örnek bir rsyslog girişi:
input(type="imtcp" port="514" maxFrameSize="2000000" SupportOctetCountedFraming="on")
global(maxMessageSize="2097152" oversizemsg.report="on")
Syslog Connector tanımında bir yedek (failover) connector belirlemeniz önerilir. Failover varsayılan olarak kapalıdır; etkinleştirilmediğinde kuyruk dolduğunda veya rsyslog sunucusuna erişilemediğinde kayıtlar düşürülür ve yaklaşık 30 saniyede bir toplu uyarı loglanır. Failover etkinleştirildiğinde bu kayıtlar yedek bağlayıcı üzerinden aktarılmaya devam eder.
Boşta Kalan Bağlantılar ve Yeniden Bağlanma
Syslog sunucusu, güvenlik duvarı veya aradaki yük dengeleyici, bir süre boşta kalan TCP oturumunu genellikle kapatır ve bunu gönderen tarafa bildirmez. Apinizer bu durumu ancak bir sonraki yazma denemesinde fark eder. Trafiğin seyrek olduğu bir bağlantıda bu, her yazma kümesinin önce başarısız olması, taze bir soket üzerinde yeniden denenmesi ve ardından başarılı olması anlamına geliyordu: kayıt kaybı yoktu, ancak her küme için bir hata satırı yazılıyor ve log, aktarım başarısız oluyormuş gibi görünüyordu.
Apinizer artık bir soket üzerinden 30 saniye boyunca hiçbir şey gönderilmediyse, yazmadan önce soketi yeniler; böylece kapanmış oturuma hiç yazılmaz. Log tarafında bunun iki sonucu vardır:
- Bir kez başarısız olup taze sokette başarılı olan küme artık hata olarak raporlanmaz. Bir dakika içindeki ilk kurtarma, veri kaybı olmadığını belirten bir bilgi satırı olarak yazılır; kalanlar sayılır ve aşağıdaki periyodik özette bildirilir.
- Raporlayacak bir hareketi olduğu sürece her soket, dakikada en fazla bir kez bilgi düzeyinde özet yazar: gönderilen küme ve kayıt sayısı, boşta kaldığı için yenilenen soketler, kurtarılan kümeler, kaybedilen kayıtlar, o anki kuyruk doluluğu ve kuyruğun reddettiği kayıt sayısı. Raporlayacak bir şeyi olmayan soket sessiz kalır.
Tek bir yazmanın bir saniyeden uzun sürmesi ayrıca uyarı olarak, hedef ve geçen süre ile birlikte raporlanır. "Syslog sunucusu gerçekten yetişemiyor mu, yoksa yalnızca boştaki oturumları mı kapatıyor" sorusunda bakılması gereken satır budur.
Gateway tanılama çıktısı bağlantı başına aynı iki sayacı taşır: idleReconnectCount, boşta kaldığı için yazmadan önce yenilenen soket sayısı; recoveredBatchCount ise bir kez başarısız olup taze sokette başarılı olan küme sayısıdır. Sürekli artan bir recoveredBatchCount, karşı tarafın oturumları otuz saniyeden daha erken kapattığı anlamına gelir.
Otuz saniyelik eşik bağlantı üzerinde ayar gerektirmez ve ekranda gösterilmez. Karşı taraf veya güvenlik duvarı oturumları çok daha erken kapatıyorsa, Gateway -Dapinizer.syslog.socketIdleReconnectMillis=<milisaniye> parametresiyle başlatılarak eşik düğ üm genelinde kısaltılabilir; 0 değeri proaktif yenilemeyi kapatır ve önceki davranışa döner.
Bağlantıyı Kabul Eder Etmez Kapatan Alıcılar
Yukarıdaki boşta-yenileme mekanizması yalnızca bağlantıyı boşta bırakan tarafın Apinizer olduğu durumlarda yardımcı olur. Bazı alıcılar farklı davranır: TCP el sıkışmasını tamamlar ve tek bir bayt bile alışverişi yapılmadan oturumu hemen kapatır — bunu genellikle bir oturum sayısı sınırı veya kaynak-IP reddi tetikler. Apinizer bunu bağlantı anında göremez; bir kontrol olmadan taze sokete yapılan ilk yazma başarısız olur, başka bir taze sokette yapılan yeniden deneme de yine hemen kapatan bir alıcıya denk gelir ve bu, her küme için yeni bir TCP bağlantısı açılacak kadar hızlı tekrarlanabilir; bu arada kayıtlar sessizce kaybolur.
Apinizer artık bağlandıktan hemen sonra (TLS kullanılıyorsa TLS el sıkışmasından sonra da) ve herhangi bir şey yazmadan önce soketten kısa bir süre okuma yapar. Alıcı oturumu zaten kapatmışsa bu okuma bunu anında bildirir ve bağlantı normal bir bağlantı hatası olarak değerlendirilir — trafiği yedek connector'a taşıyan üç-ardışık-hata eşiğine dahil edilir ve tıpkı diğer bağlantı hatalarında olduğu gibi beş saniye sonra yeni bir deneme yapılır. Alıcı sessiz kalıyorsa, sıradan bir syslog alıcısında olduğu gibi, kontrol yalnızca zaman aşımına uğrar ve soket hemen kullanılır; bağlantı kurulup sonraki kümeler için yeniden kullanılmaya başladıktan sonra ekstra G/Ç veya ölçülebilir bir gecikme eklenmez.
Bir alıcı bağlantıyı temiz şekilde kabul edip her kümeden sonra tekrar kapatıyorsa, her başarısız yazmadan sonra yeniden bağlanmak yine de çok yüksek bir hızda bağlantı açılmasına yol açabilir. Apinizer, bir yazma hatasından sonraki yeniden bağlanmaları soket başına saniyede en fazla yaklaşık on ile sınırlar; bir özet penceresinde en az on küme gönderilmiş ve bunların yarısından fazlası bu şekilde kurtarılmış olduğunda, dakikada bir kez ayrı bir uyarı loglanır:
Syslog receiver drops the connection after nearly every batch (recovered X of Y batches, reconnects N, peerClosedAtAccept M); delivery may be silently lost - check receiver session limits (connectionId=..., target=...)
Bu satır, alıcı tarafın kendi oturum sınırlarının veya bağlantı politikasının kontrol edilmesi gerektiğinin işaretidir — gönderen doğru şekilde yeniden deniyordur, ama bu şekilde davranan bir alıcıda, kümenin çekirdek gönderme tamponuna kabul edildiği an ile alıcının bir sonraki kapatmasının fark edildiği an arasında yine de kayıt kaybı olabilir.
İki JVM sistem özelliği bu davranışı düğüm genelinde ayarlar; ikisi de yalnızca Apinizer'ın TCP syslog gönderici için geçerlidir, başka bir connector'ı etkilemez.
-Dapinizer.syslog.connectLivenessMillis=<milisaniye>— bağlantı-anı canlılık okumasının, alıcının sessiz ve sağlıklı olduğuna karar vermeden önce ne kadar bekleyeceği. Varsayılan 100 ms, üst sınır 2000 ms;0kontrolü tamamen kapatır ve APNZ-6839 öncesi davranışa döner: oturumu kabul anında kapatan bir alıcı ancak bir sonraki yazmada fark edilir.-Dapinizer.syslog.minReconnectIntervalMillis=<milisaniye>— aynı soket üzerinde bir yazma hatasını izleyen iki yeniden bağlanma arasındaki en kısa süre. Varsayılan 100 ms, üst sınır 5000 ms;0bu hız sınırlamasını kaldırır. Bu ayar ilk bağlantıyı, yukarıdaki proaktif boşta-yenilemeyi veya yarı-açık sağlık probunu etkilemez — onların zaten kendi, daha uzun aralıkları vardır.
Aralık dışı veya ayrıştırılamayan bir değer, bağlantıyı başarısız kılmak yerine varsayılana düşer ve uyarı olarak loglanır.
Yukarıda açıklanan periyodik soket-başı özet artık iki sayaç daha raporlar: reconnects, o soket üzerinde açılan taze TCP bağlantısı sayısı (ilk bağlantı da sayılır, yani hiç kopmamış bir soket bile 1 gösterir) ve peerClosedAtAccept, bu bağlantılardan kaçının bağlantı-anı canlılık kontrolü tarafından açıldıktan hemen sonra kapalı bulunduğu. Sıfırdan büyük bir peerClosedAtAccept sayısı, arızanın ağ yolunda veya Apinizer tarafında değil, alıcı tarafta olduğu anlamına gelir — bir oturum sınırı, bir kaynak-IP reddi ya da aradaki bir yük dengeleyici.
Büyük Mesajları Bölme
Bu, yukarıdaki çerçeveleme ayarlarından farklı bir araçtır. Çerçeveleme büyük bir kaydı tek syslog olayı olarak bütün tutar. Bölme ise bir kaydı, çerçevelemenin çözemediği durumlarda — alıcı sunucunun kendi mesaj boyutu sınırı yükseltilemediğinde veya bağlantı UDP olup zaten uzatılacak bir çerçeveleme bulunmadığında — bilinçli olarak birden fazla syslog mesajına böler.
Maksimum Mesaj Boyutu, bu connection'ın gönderdiği tek bir syslog mesajının boyutunu sınırlar — tam olarak neyin ölçüldüğü için yukarıdaki parametre kartına bakınız. İsteğe bağlıdır ve varsayılanı 0'dır; bu, bölme yapılmayacağı anlamına gelir: connection her kayıt için tek mesaj göndermeye, bu ayar var olmadan önceki gibi bayt düzeyinde aynen devam eder. Pozitif bir bayt değeri girildiğinde, mesajı bu boyutu aşacak her kayıt tek mesaj yerine birden fazla syslog mesajı olarak, her biri ayrı ayrı gönderilir.
Bölünmüş bir mesaj nasıl görünür
Bölünmüş bir mesajın her parçası orijinal içeriğin bir dilimini taşır; tek ekleme, her parçanın mesaj gövdesinin başındaki kısa bir önektir:
[chunk 1/3 a1b2c3d4] orijinal mesajın ilk parçası...
`[chunk i/N <id>]` öneki parçanın sırasını (i), toplam parça sayısını (N) ve o tek orijinal mesajın tüm parçalarında aynı, başka bir bölünmüş mesajınkinden farklı bir kimliği taşır. Bu önek her protokolde (TCP ve UDP) ve her mesaj formatında yazılır; böylece alıcı, RFC 3164 ve düz TCP veya UDP kullanan bir hedefte bile bölünmüş bir mesajı tanıyıp yeniden birleştirebilir.
Connection'da RFC 5424 veya RFC 5425 seçiliyken ve hem RFC 5424 Yapılandırılmış Veri (SD) Yaz hem de geçerli bir Kurum Numarası (PEN) ayarlıyken — yani Connection Parametreleri bölümündeki `apinizer@<numara>` elemanını da açan aynı iki koşul sağlandığında — bölünmüş bir mesaj her parçada ek olarak `apinizerChunk@<PEN>` yapılandırılmış veri elemanı taşır; bu eleman önekle aynı sıra, toplam ve kimlik bilgisini içerir. Önek, yapılandırılmış veri desteği olmayan bir alıcının bile yeniden birleştirebileceği bilgidir; eleman ise yapılandırılmış veriyi zaten okuyan bir ayrıştırıcı için bir kolaylıktır. Eleman üç parametre taşır: `id` (bir mesajın bütün parçalarının paylaştığı kimlik), `seq` (bu parçanın 1'den başlayan sırası) ve `total` (mesajın kaç parçaya bölündüğü) — örneğin `[apinizerChunk@32473 id="3f2a19cc" seq="2" total="7"]`.
Kimlik, RFC 5424 MSGID alanında taşınmaz. Bu alan protokol gereği 32 karakterle sınırlıdır ve bu, güvenle benzersiz kalmak için her zaman yeterli değildir; bu nedenle kimlik mesaj önekinde — ve uygunsa yapılandırılmış veri elemanında — taşınır.
Bölünmüş bir JSON kaydı, tek bir parça hâlinde geçerli JSON değildir. Bölünen şey JSON biçimli bir yük ise — bir SIEM Apinizer JSON v2 olayı, bir Legacy Raw trafik log kaydı veya başka bir JSON gövdesi — önek dahil her syslog mesajı, kendi başına ayrıştırılabilir bir belge değil, bir parçadır. JSON ayrıştırma kurallarını çalıştırmadan önce alıcı tarafta parçaları yeniden birleştirin (bkz. Bölünmüş Mesajları Birleştirme); doğrudan tek bir parçaya uygulanan bir ayrıştırıcı hata verir ya da daha kötüsü, kaydı sessizce yanlış okur.
SIEM Boyut Politikası ile İlişkisi
SIEM & Log Yönlendirme sayfasının kendi Boyut Politikası vardır ve bu iki ayar farklı sorunları çözer. SIEM boyut politikası önce, hedef (destination) seviyesinde çalışır: bir Apinizer JSON v2, CEF 0 veya LEEF 2.0 yükünün data nesnesini olay hedeflenen boyuta sığana kadar kısaltır, düşürür veya hash ile değiştirir — Legacy Raw profilinde kullanılamaz ve SIEM & Log Yönlendirme sayfasından hiç geçmeyen trafik loglarına asla uygulanmaz. Maksimum Mesaj Boyutu ise bunun ardından, Syslog connection'ın kendisinde, ona ulaşan nihai mesaj her ne ise onun üzerinde çalışır — boyut politikasından zaten geçmiş bir SIEM yükü, değişmemiş bir Legacy Raw olayı veya SIEM sayfasının tamamen dışında bir Syslog Connector tarafından iletilen bir trafik log kaydı olabilir. SIEM boyut politikası içeriği sığdırmak için küçültür veya düşürürken, Maksimum Mesaj Boyutu içeriğin tamamını korur ve bunun yerine birden fazla mesaj olarak iletir.
TCP üzerinde bölme, Bellek Tavanı'nın gönderim kuyruğuna kabul ettiği miktarı da büyütmez: bölünmüş bir mesajın parçaları kuyrukta tek bir kayıt olarak birlikte tutulur ve birlikte sayılır; bu nedenle toplam boyutu bu tavana sığmayan bir mesaj yine bir bütün olarak reddedilir. Maksimum Mesaj Boyutu, bir alıcının veya tel protokolünün mesaj boyutu sınırını çözer — connection'ın kendi kuyruk bütçesini aşmanın bir yolu değildir.
UDP üzerinde ise gönderim kuyruğu ve bu ya-hep-ya-hiç kabul yoktur: her parça kendi datagramı olarak gönderilir. Gönderim ortasında hata oluşursa daha önce gönderilmiş parçalar tel üzerinde kalır ve kayıt failover yolundan bütün olarak yeniden denenir; bu durumda alıcı mükerrer parça görebilir. Bu, UDP'nin doğasından gelir ve büyük kayıtlarda TCP'yi tercih etmek için bir neden daha oluşturur.
Kullanım Senaryoları
Durum: SOC platformu TCP + TLS ile log kabul ediyor
Çözüm: Protocol: TCP, SSL Enabled: true, Port: 6514
Beklenen Davranış: Loglar TLS üzerinden güvenli biçimde iletilir, facility/severity alanları SIEM kurallarına düşer
Durum: Firewall loglarıyla korelasyon için hızlı UDP gerekiyor
Çözüm: Protocol: UDP, Port: 514, Message Format: RFC_3164
Beklenen Davranış: Düşük gecikme ile log akışı yapılır, paket kaybı toleranslıdır
Durum: Test ortamında ayrıntılı debug logu isteniyor
Çözüm: Severity: DEBUG, Facility: LOCAL0, Message Hostname: test-gw
Beklenen Davranış: Test syslog sunucusu ayrıntılı debug olaylarını alır
Durum: Denetim ekipleri audit trail talep ediyor
Çözüm: Facility: AUDIT, Severity: NOTICE, App Name: ComplianceGW
Beklenen Davranış: Denetim raporları için ayrıştırılmış log akışı sağlanır
Durum: Birden fazla proje aynı global syslog'u kullanacak
Çözüm: Move to Global, Environment ID: admin project, Name prefix: Global_
Beklenen Davranış: Tek connection tüm projelerde paylaşılır, değişiklikler merkezi yönetilir
Durum: Production logları ikincil veri merkezine kopyalanacak (opsiyonel)
Çözüm: Export ZIP, Farklı ortama import, Port/Hostname DR adresine güncellenir
Beklenen Davranış: DR syslog sunucusu aynı formatta log almaya başlar
Connection Yapılandırma
Bu adımda, yeni bir connection oluşturabilir ya da mevcut connection parametrelerini yapılandırarak bağlantı kurallarını belirleyebilirsiniz. Tanımlanan parametreler, connection'ın çalışma şeklini doğrudan etkiler ve Integration Flow veya Connector adımlarında kullanılabilir hale gelir.
Yeni Syslog Bağlantısı Oluşturma
- Sol menüden Connection → Syslog Bağlantısı bölümüne gidin.
- Sağ üstteki [+ Create] butonuna tıklayın.
Enable Status (Aktif Durumu): Toggle ile aktif/pasif durumu ayarlayın. Yeni connection'lar varsayılan olarak aktiftir.
Name (İsim) Zorunlu:
- Örnek:
Production_Syslog - Benzersiz isim girin, boşlukla başlamaz.
- Sistem otomatik kontrol eder. Yeşil tik: kullanılabilir. Kırmızı çarpı: mevcut isim.
Description (Açıklama):
- Örnek: "Gateway prod log akışı"
- Maks. 1000 karakter.
- Connection'ın amacını açıklayın.
Sayfanın üst kısmındaki işlem butonları alanında, [<> Variable] butonunu kullanarak dinamik değer seçebilir, Global variable ifadeleri sayesinde connection parametrelerini sabit değer yerine değişken tabanlı yönetebilirsiniz. Detaylı bilgi için Dinamik Değişkenler sayfasını inceleyebilirsiniz.
- Dropdown menüden ortam seçin: Development, Test, veya Production.
- Her ortam için farklı connection parametreleri tanımlanabilir.
- Syslog Protocol Type alanından TCP veya UDP seçin.
- Syslog Server Hostname ve Syslog Port değerlerini girin.
- Yanlış port, log kaybına yol açar; network firewall açılışlarını doğrulayın.
- Syslog Message Format seçin (RFC 3164/5424/5425).
- Syslog Message Hostname, Syslog App Name, Facility ve Severity alanlarını log politikanıza göre doldurun.
- TCP seçildiğinde Syslog Timeout değeri milisaniye cinsinden girilir (varsayılan 500).
- UDP modunda timeout alanı gizlenir.
- TCP modunda Syslog SSL Enabled seçeneğini true yaparak TLS kapsüllemesini açın.
- Anahtar açıldığında Keystore, Truststore ve Sunucu Adı (Hostname) Doğrulaması alanları görünür. Hiçbiri zorunlu değildir: sunucu istemci sertifikası istiyorsa Keystore, sunucu kurum içi bir sertifika otoritesinden imzalıysa Truststore seçilir.
- Mesaj formatı RFC 5424 veya RFC 5425 ise RFC 5424 Yapılandırılmış Veri (SD) Yaz anahtarı ve açıkken Kurum Numarası (PEN) alanı görünür.
- Sunucu tarafı dahil adım adım karşılıklı TLS kurulumu için bkz. Syslog Entegrasyonu.
- [Test Connection] butonuna tıklayın.
- Bağlantı parametrelerinin doğru olup olmadığını test edin.
- Başarılı: Yeşil onay mesajı, Başarısız: Hata detayları gösterilir.
- TLS açıkken sonuç kutusunda protokol, şifre takımı, sunucu sertifikası ve sunulan istemci sertifikasını gösteren bir tanılama satırı da yer alır; bkz. TLS Bağlantısını Doğrulama ve Sertifika Yenileme.
- Sağ üstteki [Save and Deploy] butonuna tıklayın.
Kontrol Listesi: Benzersiz isim. Zorunlu alanlar dolu. Test connection başarılı (önerilir)
Sonuç:
- Connection listeye eklenir.
- Integration Flow ve Connector adımlarında kullanılabilir hale gelir.
- Ortama göre aktif olur.
Connection başarıyla oluşturuldu! Artık Integration Flow ve Connector adımlarında kullanabilirsiniz.
Connection'ı Silme
Connection'ı silmek için:
- Connection'ın view ekranına gidin.
- Sağ üstteki [Delete] butonuna tıklayın.
- Onay dialogunda silme işlemini onaylayın.
- Connection listesinde satır sonundaki ⋮ menüsünden Delete seçeneğini tıklayın.
- Onay dialogunda silme işlemini onaylayın.
Silmeden Önce Kontrol Edin:
- Integration Flow veya Connector adımlarında kullanılıyor olabilir.
- Gerekirse alternatif bir connection atayın.
- Silmeden önce Export ile yedek alın.
- Silmek yerine connection'ın aktif durumunu pasif hale getirin.
- Connection pasif olur ancak silinmez.
- Gerektiğinde aktif hale getirerek yeniden kullanabilirsiniz.
Connection'ı Dışa/İçe Aktarma
Bu adımda, mevcut connection'ları yedekleme, farklı ortamlara taşıma veya paylaşma amacıyla dışa aktarabilir (export) ya da daha önce dışa aktarılmış bir connection'ı tekrar içe aktarabilirsiniz (import). Bu işlem, sürüm yönetimi, test ve üretim ortamları arasında geçiş veya ekipler arası paylaşım süreçlerinde veri bütünlüğünü korumak için kullanılır.
Dışa Aktarma (Export)
- Connection'ın view ekranına gidin.
- Sağ üstteki [Export] butonuna tıklayın.
- ZIP dosyası otomatik olarak indirilir.
Satır sonundaki ⋮ menüsünde artık iki kalem vardır: birincil Export, bu connection ön-seçili olarak Dışa/İçe Aktarma Sihirbazı'nı açar — sertifika/key store'u ve varsa ${DEĞİŞKEN} referansları bağımlılık adımında otomatik yüzeye çıkar; ikincil Export as File (Dosya Olarak Dışa Aktar) ise sihirbaza girmeden aşağıda anlatılan ZIP dosyasını doğrudan indirir.
Format: {Date}-syslog-integration-{ConnectionName}-export.zip
Örnek: 13 Nov 2025-syslog-integration-Production_Syslog-export.zip
- Connection JSON dosyası
- Metadata bilgileri
- Bağımlılık bilgileri (örneğin sertifikalar, key store)
- Yedekleme
- Ortamlar arası taşıma (Test → Prod)
- Versiyonlama
- Ekip veya proje bazlı paylaşım
İçe Aktarma (Import)
- Ana listedeki [Import Syslog Bağlantısı] butonuna tıklayın — bu buton artık tip Bağlantı (Connection) ön-seçili olarak Dışa/İçe Aktarma Sihirbazı'nın içe aktarma adımını açar (Administration'dan açıldığında Admin kapsamında); eski yükleme diyaloğu kaldırıldı.
- Dışa aktarılan paketi seçin ve sihirbazın adımlarını izleyin.
- Sihirbaz, siz onaylamadan önce formatı, isim çakışmasını ve bağımlılıkların durumunu kontrol eder.
Senaryo 1: İsim Çakışması → Eski connection'ın üzerine yazın veya yeni bir isimle oluşturun.
Senaryo 2: Eksik Bağımlılıklar → Eksik sertifikaları veya key store'ları önce oluşturun veya import sırasında çıkarın.
Connection'ın Kullanım Alanları
Bu adımda, oluşturduğunuz Syslog Bağlantısı connection'ını sistemin farklı bileşenlerinde kullanabilirsiniz. Connection'lar Integration Flow, Connector adımları veya Scheduled Job'larda seçilerek kullanılır.
Adımlar:
- Connection'ı oluşturun.
- Test Connection ile bağlantıyı doğrulayın.
- Save and Deploy ile kaydedin ve etkinleştirin.
- Connection'ın Enabled durumda olduğundan emin olun.
Syslog mesajları gönderme gerektiren adımlarda connection seçilir. Örnek: "Send Syslog Message", "Syslog Notify", "Log Forward" gibi adımlar. Bağlantı seçimi bu adımların yapılandırmasında yer alan Connection alanından yapılır.
Zamanlanmış görevlerde (ör. belirli aralıklarla log toplama, sağlık kontrolü bildirimleri vb.) bağlantı seçilerek syslog sunucularına erişim sağlanır. Connection değiştiğinde, job çalışma davranışı da buna göre güncellenir.
Connection Test özelliği ile bağlantının doğruluğu Integration Flow'dan bağımsız olarak kontrol edilebilir. Bu test hata ayıklama sürecinde kritik önem taşır.
Best Practices
Yapılması Gerekenler ve En İyi Uygulamalar
Kötü: Tüm ortamlarda varsayılan RFC 3164 kullanmak.
İyi: SIEM gereksinimine göre format seçmek.
En İyi: Ortam bazlı farklı formatları Export/Import ile versiyonlayıp belgelemek.
Kötü: Tüm logları aynı severity ile göndermek.
İyi: Uyarı ve hata loglarını farklı severity'lere ayırmak.
En İyi: Incident sınıflandırmasına göre facility/severity matrisini dokümante etmek.
Kötü: Varsayılan hostname değerini bırakmak.
İyi: Ortam bazlı hostname kullanmak.
En İyi: EnvironmentCode-gatewayId formatında isimlendirip CMDB ile eşlemek.
Kötü: Name alanında boşluklu ve belirsiz ifadeler.
İyi: Ortam prefix'i kullanmak (Test_Syslog).
En İyi: {Environment}_{Purpose}_{Region} şablonunu zorunlu kılmak.
Kötü: Tüm ortamlarda aynı connection parametrelerini kullanmak.
İyi: Her ortam için ayrı connection oluşturmak.
En İyi: Environment seçeneğini kullanarak tek connection'da tüm ortamları yönetmek, ortamlar arası geçişte sadece environment değiştirmek.
Kötü: Connection'ı test etmeden kaydetmek ve deploy etmek.
İyi: Kaydetmeden önce Test Connection ile doğrulamak.
En İyi: Her parametre değişikliğinden sonra test etmek, production'a geçmeden önce test ortamında tam entegrasyon testi yapmak.
Güvenlik En İyi Uygulamaları
Syslog sunucusunu sadece ilgili gateway subnet'lerinden erişilebilir kılın. Firewall'da UDP/TCP 514/6514 portlarını kısıtlayın.
TLS kullanıyorsanız sertifika zincirini düzenli yenileyin; self-signed sertifikaları yalnızca Development ortamında kullanın.
Kritik loglar için RFC 5425 formatında TLS + mesaj imza mekanizması kullanarak bütünlüğü koruyun.
Kullanıcı adı ve şifre gibi hassas bilgileri environment variable veya secret manager kullanarak saklayın. Kimlik bilgilerini kod veya konfigürasyon dosyalarına hardcode etmeyin. Periyodik olarak şifreleri güncelleyin.
Production ortamında mutlaka SSL/TLS aktif edin. Self-signed sertifikalar sadece development ortamında kullanın. Sertifika expiration tarihlerini takip edin ve zamanında yenileyin.
Connection yapılandırmasını sadece yetkili kullanıcıların değiştirmesine izin verin. Connection değişiklik loglarını saklayın. Kritik connection'lar için değişiklik approval süreci uygulayın.
Kaçınılması Gerekenler
Neden kaçınılmalı: UDP teslim garantisi vermez, paket kaybı denetlenemez.
Alternatif: TCP + SSL/TLS modu kullanın.
Neden kaçınılmalı: SIEM kuralları tetiklenmez, uyarılar gözden kaçar.
Alternatif: Facility/severity haritasını operasyon ekibiyle doğrulayın.
Neden kaçınılmalı: SIEM tarafında kaynak ayırt edilemez.
Alternatif: Ortam + bölge + node kimliğini içeren hostname kullanın.
Neden kaçınılmalı: Test verileri production sistemine yazılabilir, gerçek kullanıcılar etkilenebilir, güvenlik riski oluşur.
Alternatif: Her ortam için ayrı connection oluşturun, environment parametresini kullanın, connection isimlerini ortama göre prefix ekleyerek ayırın (Test_, Prod_).
Neden kaçınılmalı: Ağ gecikmelerinde connection sürekli timeout olur, Entegrasyon adımları başarısız olur.
Alternatif: Gerçek kullanım senaryolarına göre timeout değerlerini ayarlayın, network latency'yi ölçün ve timeout'ları buna göre belirleyin.
Performans İpuçları
Öneri: UDP modunda gateway tarafında rate limiting uygulayın.
Etki: Hedef syslog sunucusunun buffer taşması önlenir.
Öneri: Timeout değerlerini 5-10 sn aralığında tutun, network kesintilerinde otomatik reconnect davranışını doğrulayın.
Etki: Log teslim sürekliliği korunur.
Öneri: RFC 5424 yalnızca zorunluysa kullanın, aksi halde RFC 3164 ile mesaj boyutunu küçültün.
Etki: Bant genişliği ve depolama maliyetleri azalır.
Öneri: Gerçek network latency'yi ölçün, timeout değerlerini buna göre ayarlayın, çok düşük veya çok yüksek timeout'lardan kaçının.
Etki: Gereksiz beklemeler önlenir, hızlı fail-over sağlanır, kullanıcı deneyimi iyileşir.
Öneri: Kuyruk doluluğunu ve Bellek Tavanı kullanımını izleyin, timeout oranlarını takip edin, connection health check yapın, alerting kurun.
Etki: Sorunlar proaktif tespit edilir, performans darboğazları erken belirlenir, kesinti süresi azalır.
Teslim Sağlığı
Bir Syslog bağlantısı SIEM ve Log Yönlendirme sayfasında hedef olarak kullanıldığında, Hedefler sekmesi hedef listesinin üzerinde o hedef için salt okunur bir sağlık kartı gösterir.
Kart bir durum taşır — Sağlıklı, Bozulmuş, Başarısız ya da Boşta — son başarı ve son başarısızlık zamanını, ardışık başarısızlık sayısını ve son hata mesajını gösterir. Hedef bir Syslog bağlantısı olduğu için kart ayrıca göndericinin kendi durumunu da gösterir: çalışıp çalışmadığını, o an kuyrukta kaç mesaj olduğunu ve kaç mesajın reddedildiğini, kaybedildiğini ya da yazma zaman aşımından uzun süre bloke olduğunu — yukarıda Büyük Kayıtlar ve Yüksek Hacim bölümünde anlatılan aynı durumlar.
Kart yalnızca bu Yönetim Konsolu düğümünü anlatır. Sayaçlar bellekte tutulur ve düğüm yeniden başladığında sıfırlanır; her Gateway kendi sayaçlarını tutar ve bunları Manager'ınkilere eklemeden kendi tanılamasında raporlar. Sekme açıkken kart her on saniyede bir kendini yeniler.
Tam durum referansı, uygulanan yapılandırma sürümü ve düğümler arası teslim karşılaştırması için kullanılan Gateway tanılama JSON'u için SIEM ve Log Yönlendirme sayfasındaki Teslim Sağlığı bölümüne bakınız.
Sorun Giderme (Troubleshooting)
TLS El Sıkışması Başarısız
Yanlış port (6514 yerine 514), sertifika chain eksik veya syslog sunucusu TLS beklemiyor olabilir.
Port ve protokol eşleşmesini doğrulayın.
Sertifika depolarını güncelleyin.
Syslog tarafında TLS listener'ını açın.
UDP Logları Eksik
Network paket kaybı, firewall throttling veya fazla burst oranı olabilir.
Paket capture yaparak kaybı ölçün.
Gateway tarafında rate limiting uygulayın.
Gerekirse TCP moduna geçin.
Connection Timeout
Network gecikmesi, hedef sistem yavaş yanıt veriyor veya timeout değeri çok düşük olabilir.
Network connectivity kontrol edin.
Hedef sistem sağlığını kontrol edin.
Timeout değerlerini artırın.
Connection loglarını inceleyin.
Authentication Failed
Yanlış kullanıcı adı/şifre, expired credentials veya yetki problemi olabilir.
Kimlik bilgilerini doğrulayın.
Hedef sistemde kullanıcının aktif olduğunu kontrol edin.
Gerekli yetkilerin verildiğini kontrol edin.
SSL/TLS sertifikalarını kontrol edin.
Connection Test Başarılı Ama Entegrasyon Akışı Hata Veriyor
Integration/Connector adımında farklı connection seçili olabilir, adım yanlış yapılandırılmış olabilir veya Flow/Job redeploy edilmemiş olabilir.
Connection'ın enable toggle'ının aktif olduğunu kontrol edin.
Integration Flow'da doğru connection'ın seçildiğini doğrulayın.
Connection'ı tekrar deploy edin.
Integration Flow veya Job'ı redeploy edin.
Gateway loglarını kontrol edin.
Büyük Kayıtlar Bölünerek veya Kırpılarak Geliyor
Çok satırlı bir JSON veya stack trace kaydı syslog tarafında birden fazla olaya bölünüyor ya da uzun kayıtlar hiç görünmüyor.
Satır sonu içeren kayıtlar için Çerçeveleme (Framing) Tipi değerinin OCTET_COUNTING olduğunu (veya AUTO ile birlikte mesaj formatının RFC_5425 seçildiğini) doğrulayın. Çerçeveleme yalnızca TCP modunda geçerlidir; UDP'de bu ayar dikkate alınmaz.
Syslog sunucusunda maxFrameSize ve global(maxMessageSize=...) değerlerini en büyük kaydınızı rahatça aşacak şekilde yükseltin.
Syslog sunucusunun rsyslog 8.1905 veya sonraki bir sürümü çalıştırdığını doğrulayın; maxFrameSize daha eski sürümlerde tanınmaz.
Yoğun yük altında Bellek Tavanı veya Kuyruk Kapasitesi sınırına ulaşılıp ulaşılmadığını kontrol edin. Sığmayan mesajlar, failover connector etkinse oraya yönlendirilir; etkin değilse düşürülür.
Sık Sorulan Sorular (SSS)
Syslog connection'ı tek seferde birden fazla syslog sunucusuna gönderebilir miyim?
Hayır, her connection tek hedefe yöneliktir; çoklu hedef için connection'ı çoğaltın veya load balancer kullanın.
UDP'den TCP'ye geçişte yeni connection oluşturmak zorunda mıyım?
Aynı connection üzerinde protokolü güncelleyebilirsiniz ancak değişiklikten önce export ile yedek almanız önerilir.
RFC 5425 seçmek için ek yapılandırma gerekir mi?
Evet, TLS dinleyen bir syslog sunucusu ve Syslog SSL Enabled değerinin true olması gerekir.
Timeout değeri hangi bileşeni etkiler?
Sadece TCP el sıkışması ve ACK bekleme süresini etkiler; syslog bağlantısı için ayrı bir istek zaman aşımı alanı bulunmaz.
Connection'ı farklı projelerde paylaşabilir miyim?
Admin kullanıcıları Move to Global eylemiyle connection'ı global alana taşıyabilir; diğer projelerde kullanılabilir.
Aynı connection'ı birden fazla Integration Flow'da kullanabilir miyim?
Evet, aynı connection birden fazla Integration Flow veya Connector adımında kullanılabilir. Bu merkezi yönetim sağlar ve konfigürasyon tutarlılığını garanti eder. Ancak connection'da yapılan değişiklikler tüm kullanım yerlerini etkileyeceği için dikkatli olunmalıdır.
Test ve Production için farklı connection'lar mı oluşturmalıyım?
Evet, her ortam için ayrı connection oluşturmanız önerilir. Alternatif olarak environment parametresini kullanarak tek connection içinde tüm ortamları yönetebilirsiniz. Bu yaklaşım daha kolay yönetim ve daha az hata riski sağlar.
Test Connection başarılı ama Integration Flow'da çalışmıyor, neden?
Birkaç neden olabilir:
- Connection enable toggle'ı pasif olabilir
- Integration adımında farklı bir connection seçili olabilir
- Connection deploy edilmemiş olabilir
- Integration Flow henüz redeploy edilmemiş olabilir
Sürüm yükseltmesinden sonra mevcut Syslog connection'larını yeniden yapılandırmam gerekir mi?
Çoğu kurulumda hayır: çerçeveleme tipi, paralel bağlantı sayısı, kuyruğa yazma bekleme süresi ve toplu yazma çerçevesi boş bırakıldığında bugünkü davranışı korur. Ancak Bellek Tavanı alanı doldurulmasa da 64 MB'lık üst sınır uygulanır; ortalama kayıt boyutu büyük olan (örneğin 200 KB) kurulumlarda kuyruk eskisine göre daha erken dolar. Böyle bir kurulumunuz varsa yükseltmeden sonra Bellek Tavanı değerini gözden geçirin.
Büyük kayıtların birden fazla syslog olayına bölünmediğinden nasıl emin olurum?
Syslog Message Format olarak RFC_5425 seçin (veya Çerçeveleme Tipi'ni açıkça OCTET_COUNTING yapın) ve alıcı rsyslog sunucusundaki maxFrameSize ile maxMessageSize değerlerinin en büyük kaydınızı karşılayacak şekilde yükseltildiğinden emin olun. Bu, kayıt içindeki satır sonlarının yol açtığı istenmeyen bölünmeyle ilgilidir; kaydı bilinçli olarak ve yalnız seçtiğiniz bir boyutu aştığında bölen Maksimum Mesaj Boyutu ile ilgisi yoktur — bkz. bir sonraki soru.
Syslog alıcım için çok büyük olan bir mesajı, düşürmek yerine Apinizer bölebilir mi?
Evet. Maksimum Mesaj Boyutu alanını (varsayılan 0, yani bölme yok) alıcınızın veya ağ yolunuzun kabul ettiği en büyük tek mesaj boyutuna ayarlayın. Mesajı bu boyutu aşan her kayıt, alıcının yeniden birleştirebilmesi için [chunk i/N id] öneki taşıyan birden fazla syslog mesajı olarak gönderilir. Bkz. yukarıdaki Büyük Mesajları Bölme.