Kurumsal ortamlarda log toplama problemi çoğu zaman “hangi platformu kullanacağız?” sorusuyla başlar. Oysa daha kritik soru şudur: farklı formatta, farklı frekansta ve farklı risk seviyesinde üretilen logları aynı teslimat omurgasında nasıl taşıyacağız? Vector bu iş için güçlü bir araç çünkü sadece bir ajan değil; dönüştürme, zenginleştirme ve yönlendirme katmanını da sade biçimde kurmaya izin veriyor.
Bu rehberde, birden fazla log kaynağını Vector ile toplayan ve iki farklı hedefe yönlendiren temel bir kurulum iskeleti kuracağız.
Hangi senaryo için uygun?
Şu durumlarda bu model oldukça kullanışlıdır:
- Linux sunuculardan syslog akıyor.
- Uygulamalar JSON veya satır tabanlı log üretiyor.
- Bazı loglar uzun süreli depoya, bazıları hızlı arama sistemine gitmeli.
- Ortak etiket standardı ve filtre mantığı merkezi yönetilmek isteniyor.
Bu örnekte üç kaynak alacağız:
/var/log/messages- Bir uygulama log dosyası
- Journald
Temel Vector yapılandırması
Önce kaynakları tanımlayalım:
[sources.syslog_file]
type = "file"
include = ["/var/log/messages"]
read_from = "beginning"
[sources.app_file]
type = "file"
include = ["/srv/apps/*/current/log/app.log"]
read_from = "end"
[sources.journald]
type = "journald"
current_boot_only = trueBurada özellikle uygulama loglarını wildcard ile toplamak, çok servisli yapılarda konfigürasyon tekrarını azaltır.
Ortak zenginleştirme katmanı
Kaynakları toplamak yetmez. Logun hangi ortamdan, hangi servisten ve hangi düğümden geldiğini hızlıca anlamak gerekir. Bunu remap ile yapabiliriz:
[transforms.normalize]
type = "remap"
inputs = ["syslog_file", "app_file", "journald"]
source = '''
.environment = "production"
.host = get_hostname!()
.team = "platform"
if exists(.file) && includes!(.file, "/srv/apps/") {
.log_type = "application"
} else {
.log_type = "infrastructure"
}
'''Kurumsal yapılarda en büyük sorunlardan biri, aynı olayın farklı ekiplerce farklı etiketlerle aranmasıdır. Bu katman, daha ilk toplama noktasında ortak dil kurar.
Gürültüyü erkenden azaltmak
Tüm logu aynı hedefe aynen göndermek pahalıdır. Özellikle health check, rutin cron çıktısı veya tekrar eden düşük değerli kayıtlar index maliyetini artırır. Basit bir filtre ekleyelim:
[transforms.filter_noise]
type = "filter"
inputs = ["normalize"]
condition = '''
!match(string!(.message) ?? "", r'healthcheck|/readyz|/livez')
'''Bu filtreyi agresif tutmamak gerekir. İlk aşamada silmek yerine ayrı hedefe yönlendirmek daha güvenli olabilir.
İki hedefe birden yönlendirme
Şimdi aynı akışı hem Elasticsearch benzeri arama katmanına hem de uzun süreli objeye dayalı depoya gönderelim:
[sinks.search]
type = "http"
inputs = ["filter_noise"]
uri = "https://logs.example.internal/ingest"
encoding.codec = "json"
compression = "gzip"
[sinks.archive]
type = "aws_s3"
inputs = ["normalize"]
bucket = "central-log-archive"
region = "eu-central-1"
key_prefix = "vector/%Y/%m/%d/"
encoding.codec = "json"
compression = "gzip"Burada dikkat edilmesi gereken nokta şu: arama katmanına filtrelenmiş akış giderken, arşiv katmanına normalize edilmiş ama filtrelenmemiş veri gidebilir. Bu ayrım operasyon ve maliyet dengesini güçlendirir.
Operasyonel olarak nelere dikkat edilmeli?
Vector kurulduktan sonra asıl değer, çalışma davranışını izlemekten gelir. Ben şu kontrolleri öneririm:
- Buffer doluluk oranı
- Hedefe yazma hataları
- Kaynak bazlı gecikme
- Düşürülen event sayısı
- Konfigürasyon değişim sıklığı
Özellikle merkezi log omurgasında sessiz veri kaybı, açık hatadan daha tehlikelidir. Bu yüzden pipeline’ın kendisini de gözlemlemek gerekir.
Sonuç
Vector ile merkezî log toplama pipeline’ı kurmak, sadece ajan kurmak değildir. Asıl iş, log kaynaklarını ortak bir veri ve operasyon sözleşmesi altında toplamak, gürültüyü erkenden azaltmak ve doğru veriyi doğru hedefe yollamaktır. Gözlemlenebilirlik olgunluğu çoğu zaman kullandığınız arama aracından değil, veriyi oraya hangi disiplinle taşıdığınızdan anlaşılır.