Log Yönetimi: Elasticsearch, Logstash ve Kibana (ELK) Kurulumu

Bir uygulama hata verdiğinde ilk sorumuz genellikle aynıdır: Ne oldu? Tek sunuculu küçük bir projede cevabı birkaç log dosyasına bakarak bulabilirsiniz, ancak servis sayısı, trafik ve sunucu sayısı arttıkça bu yöntem hızla yetersiz kalır. Log Yönetimi: Elasticsearch, Logstash ve Kibana (ELK) Kurulumu yaklaşımı, farklı kaynaklardan gelen olayları merkezi bir yapıda toplamak, aranabilir hale getirmek ve anlamlı dashboard'lara dönüştürmek için güçlü bir temel oluşturur. Benim üretim sistemlerinde en faydalı bulduğum yaklaşım, önce logların yapısını standartlaştırmak, ardından toplama ve saklama katmanlarını bu yapıya göre kurmaktır. Bu rehberin sonunda yalnızca ELK bileşenlerini kurmayı değil, log pipeline'ını güvenlik, retention, backup, alerting ve kapasite yönetimiyle birlikte düşünmeyi öğreneceksiniz.

Bu içerikte ELK Stack Elasticsearch Logstash Kibana kurulumu nasıl yapılır sorusundan başlayarak merkezi log yönetimi için ELK Stack nasıl kurulur ve yapılandırılır sorusuna production odaklı cevaplar vereceğiz. Elasticsearch Logstash Kibana ile sunucu ve uygulama logları nasıl toplanır konusu Filebeat, Elastic Agent ve OpenTelemetry Collector seçenekleriyle birlikte değerlendirilecek. ELK Stack log analizi indeks yönetimi dashboard ve alert yapılandırması için data stream, lifecycle, ECS, Kibana Discover, KQL ve ES|QL gibi temel araçları da ele alacağız. Kurumsal ELK Stack kurulum ve merkezi log yönetimi hizmeti değerlendirirken hangi güvenlik, kapasite ve operasyon kriterlerinin önemli olduğunu ayrıca açıklayacağız. Elasticsearch ELK Stack ve log yönetimi danışmanlığı yakınımda şeklinde araştırma yapan ekipler için de yalnız kurulumu değil, sürdürülebilir merkezi log mimarisinin nasıl değerlendirilmesi gerektiğini göstereceğiz.

Log Yönetimi Nedir?

Log yönetimi, uygulama, işletim sistemi, ağ cihazı, container ve diğer altyapı bileşenlerinin ürettiği olay kayıtlarının toplanması, taşınması, saklanması, aranması ve gerektiğinde alarm üretmek için kullanılmasını kapsar. Sağlıklı bir log sistemi yalnızca dosyaları merkezi sunucuya kopyalamaz, olayların zaman bilgisini, kaynağını, servis adını, seviyesini ve bağlamsal alanlarını da korur. Bu sayede aynı hatanın yüzlerce sunucudaki etkisini tek sorguyla görmek mümkün hale gelir. İyi log yönetimi özellikle dağıtık sistemlerde hata çözme süresini ciddi ölçüde azaltabilir. Tasarımın ilk aşamasında log hacmi, retention, güvenlik ve aranabilirlik gereksinimlerinin birlikte belirlenmesi gerekir.

Log Nedir?

Log, bir sistemde gerçekleşen olayın zaman, içerik ve bağlam bilgisiyle kaydedilmiş halidir. Bir web isteğinin başarıyla tamamlanması, database bağlantısının kesilmesi, kullanıcının oturum açması veya uygulamanın exception üretmesi log kaydı oluşturabilir. İyi bir log yalnızca serbest metin mesajı taşımaz, mümkün olduğunda service.name, log.level, trace.id ve HTTP durum kodu gibi alanlarla yapılandırılır. Bu yapı arama ve aggregation işlemlerini kolaylaştırır. Logların hedefi her şeyi kaydetmek değil, operasyon ve güvenlik açısından anlamlı olayları yeterli bağlamla kaydetmektir.

Merkezi Log Yönetimi Nedir?

Merkezi log yönetimi, farklı sistemlerde oluşan logların ortak bir platforma aktarılması ve tek arayüz üzerinden aranabilmesidir. Örneğin üç API sunucusu, iki worker ve bir reverse proxy kullanan sistemde her makineye ayrı ayrı SSH ile bağlanmak yerine olaylar Elasticsearch gibi merkezi bir depoda toplanabilir. Collector katmanı logları kaynaktan alır, ingestion katmanı gerekirse dönüştürür ve Kibana kullanıcıya sorgulama arayüzü sağlar. Bu model incident sırasında zaman kazandırır. Merkezi yapının kendisi de production sistemi olduğundan erişim kontrolü, backup ve monitoring gerektirir.

Log Yönetimi Neden Önemlidir?

Log yönetimi uygulama davranışının geçmişe dönük olarak anlaşılmasını sağlar. Monitoring çoğu zaman bir problemin var olduğunu söylerken loglar problemin nedenini bulmaya yardımcı olan ayrıntıyı verir. Güvenlik ekipleri authentication hatalarını ve şüpheli erişimleri loglar üzerinden inceleyebilir. Yazılım ekipleri yeni deployment sonrasında hata oranının artıp artmadığını görebilir. Bu nedenle log sistemi geliştirme, operasyon ve güvenlik ekiplerinin ortak gözlem katmanı olarak değerlendirilmelidir.

Hata Ayıklama

Hata ayıklama sırasında en değerli bilgi, hatanın ne zaman, hangi servis sürümünde ve hangi istek bağlamında oluştuğunu bilmektir. Structured log kullanıldığında exception türü, request ID ve servis adı ayrı alanlar halinde sorgulanabilir. Bir müşteri işlemi başarısız olduğunda tüm sistemi metin aramasıyla taramak yerine ilgili correlation ID üzerinden olay zinciri takip edilebilir. Deployment version bilgisinin loglara eklenmesi regresyon analizini kolaylaştırır. Log sistemi bu nedenle uygulama debugging sürecinin sonradan eklenen aracı değil, uygulama tasarımının parçası olmalıdır.

Performans Analizi

Loglar response time, database query süresi ve işlem adımlarına ilişkin performans verileri taşıyabilir. Bu alanlar Elasticsearch içinde aggregation yapılarak zaman serisine dönüştürülebilir. Örneğin belirli endpoint için p95 response süresinin deployment sonrası arttığı gözlemlenebilir. Çok ayrıntılı performans ölçümleri için metric ve tracing araçları daha uygun olsa da loglar olay bağlamını anlamada güçlü tamamlayıcıdır. Performans alanları tutarlı isimlerle kaydedildiğinde dashboard üretmek de kolaylaşır.

Güvenlik

Authentication, authorization ve yönetici işlemleri güvenlik incelemelerinde kritik log kaynaklarıdır. Başarısız SSH girişleri, tekrar eden login denemeleri veya olağan dışı yönetim işlemleri merkezi platformda ilişkilendirilebilir. Kullanıcı girdilerinin doğrudan loglanması log injection riskine yol açabileceğinden structured logging tercih edilmelidir. Secret, password ve token değerleri loglara kesinlikle yazılmamalıdır. Güvenlik loglarının retention ve erişim politikası normal uygulama loglarından daha farklı olabilir.

Denetim ve Uyumluluk

Audit loglar belirli işlemin kim tarafından ve ne zaman yapıldığını gösterebilir. Yönetim panelinde rol değişikliği, kritik konfigürasyon güncellemesi veya veri erişimi gibi olaylar denetim izi oluşturabilir. Bu kayıtların değiştirilemezlik ve retention gereksinimi kuruma göre farklıdır. Kişisel veri mevzuatı loglarda gereksiz veri toplamamayı da gerektirir. Uyumluluk hedefi nedeniyle tüm veriyi sınırsız süre saklamak yerine gerekçeli retention politikası oluşturulmalıdır.

Incident Response

Incident sırasında ekiplerin hızlı cevaplaması gereken sorular olayın başlangıç zamanı, etkilenen servisler ve hata yayılımıdır. Merkezi log sistemi bu soruları ortak sorgular üzerinden cevaplamayı mümkün kılar. Deployment, host ve trace alanlarının loglara eklenmesi timeline çıkarmayı kolaylaştırır. Alert ilk sinyali üretirken Kibana Discover veya ES|QL ayrıntılı araştırma için kullanılabilir. Incident sonrasında kullanılan sorgular saved search veya dashboard haline getirilerek benzer olayların daha hızlı teşhis edilmesi sağlanabilir.

Dağıtık Sistemlerde Log Yönetimi Neden Zorlaşır?

Dağıtık sistemde tek kullanıcı isteği birden fazla servis, queue ve database üzerinden ilerleyebilir. Her bileşen farklı log formatı ve timestamp davranışı kullanırsa olayları birleştirmek zorlaşır. Container'ların yeniden oluşturulması local filesystem loglarının kısa ömürlü olmasına da yol açabilir. Saat senkronizasyonu bozuksa aynı olay zincirindeki kayıtlar yanlış sırada görünebilir. Bu nedenle correlation ID, merkezi zaman standardı, ECS benzeri alan sözleşmesi ve güvenilir log taşıma pipeline'ı dağıtık sistemlerde temel gereksinimlerdir.

ELK Stack Nedir?

ELK Stack adı Elasticsearch, Logstash ve Kibana bileşenlerinin baş harflerinden gelir. Elasticsearch verinin indexlenmesi ve aranması görevini üstlenirken Logstash farklı kaynaklardan event alıp dönüştürebilir. Kibana ise verilerin sorgulanması, görselleştirilmesi, dashboard ve alert yönetimi için kullanıcı arayüzü sunar. Modern Elastic ekosisteminde Elastic Agent, Fleet, ingest pipeline, data stream ve OpenTelemetry entegrasyonları da bu yapının önemli parçalarıdır. Bu nedenle production mimarisi tasarlanırken yalnız üç klasik bileşeni değil, veri toplama ve lifecycle katmanlarını da değerlendirmek gerekir.

Elasticsearch Nedir?

Elasticsearch dağıtık arama ve analiz motorudur. Log event'leri JSON document olarak indexlenir ve field bazlı sorgular hızlı biçimde çalıştırılabilir. Full-text search, aggregation ve zaman serisi analizleri merkezi log platformunun temel özelliklerini sağlar. Veriler shard'lara bölünerek node'lar arasında dağıtılabilir ve replica'larla dayanıklılık artırılabilir. Elasticsearch aynı zamanda ingest pipeline, lifecycle, snapshot ve security özellikleriyle log saklama katmanının ötesinde geniş bir operasyon modeli sunar.

Logstash Nedir?

Logstash event ingestion ve transformation için kullanılan pipeline aracıdır. Input plugin'leri farklı kaynaklardan veri alırken filter aşaması parsing, enrichment ve alan dönüşümü yapabilir. Output plugin'leri işlenmiş event'i Elasticsearch, Kafka veya farklı hedeflere iletebilir. Logstash özellikle legacy plaintext logların Grok ile ayrıştırılması veya birçok kaynağın tek standarda dönüştürülmesi gerektiğinde değerlidir. Basit JSON log akışlarında ise Logstash eklemek her zaman gerekli değildir.

Kibana Nedir?

Kibana Elasticsearch'teki verileri keşfetmek ve görselleştirmek için kullanılan web arayüzüdür. Discover bölümü tekil log event'lerini incelemek için kullanılırken Lens ve dashboard araçları aggregation sonuçlarını görsel hale getirir. Alerting belirli query veya threshold koşullarına göre bildirim üretmeye yardımcı olur. Kullanıcı ve rol yönetimiyle ekiplerin yalnız ihtiyaç duyduğu verilere erişmesi sağlanabilir. Production Kibana doğrudan public porta açılmamalı ve TLS, SSO veya kontrollü reverse proxy gibi erişim katmanlarıyla korunmalıdır.

ELK ile Elastic Stack Arasındaki Fark

ELK tarihsel olarak Elasticsearch, Logstash ve Kibana üçlüsünü ifade eder. Elastic Stack kavramı ise Beats, Elastic Agent, Fleet ve diğer ilgili bileşenleri de içine alan daha geniş kullanım alanını anlatır. Modern log mimarisinde her logun mutlaka Logstash'ten geçmesi gerekmez. Elastic Agent doğrudan Elasticsearch ve ingest pipeline kullanabilir. Bu nedenle yeni tasarımlarda klasik ELK ismi yaygın şekilde kullanılmaya devam etse de gerçek mimari daha fazla bileşen seçeneğine sahiptir.

Beats ve Elastic Agent Ekosistemin Neresindedir?

Beats ailesi Filebeat gibi belirli veri türlerine odaklanan hafif collector araçlarından oluşur. Elastic Agent ise log, metric ve güvenlik verilerini tek agent ve merkezi policy modeliyle yönetmeyi hedefler. Elastic'in güncel dokümantasyonu, uygun integration ve output desteği bulunduğunda Elastic Agent'ın merkezi Fleet yönetimi sayesinde Beats'e göre daha kolay yönetim sağlayabildiğini belirtir. Mevcut Filebeat kurulumlarının çalışmaya devam edebileceği ve geçişin ihtiyaçlara göre kademeli yapılabileceği de vurgulanır. Yeni geniş ölçekli kurulumlarda collector seçimi özellik uyumluluğu kontrol edilerek yapılmalıdır.

ELK Stack Nasıl Çalışır?

ELK veri akışı log kaynağından başlar ve collector üzerinden ingestion katmanına ulaşır. Logstash kullanılıyorsa parsing ve enrichment burada uygulanır, kullanılmıyorsa Elastic Agent veya Filebeat veriyi doğrudan Elasticsearch ingest pipeline'a gönderebilir. Elasticsearch event'leri mapping kurallarına göre data stream veya index içine yazar. Kibana aynı cluster üzerinden arama ve aggregation sorguları çalıştırır. Production pipeline'da her adımın event sayısı, latency ve hata oranı izlenerek veri kaybı olup olmadığı ölçülebilir.

Log Üreten Sistem

Kaynak sistem web uygulaması, Linux host, database, reverse proxy veya container olabilir. En iyi başlangıç uygulamanın logu structured JSON olarak stdout veya yönetilen dosyaya yazmasıdır. Event içinde zaman, seviye, servis adı ve request bilgileri yer almalıdır. Collector kaynak dosyanın rotation davranışını da doğru takip etmelidir. Hassas değerlerin daha kaynaktayken loga hiç yazılmaması sonraki katmanlarda maskeleme ihtiyacını azaltır.

Log Collector / Shipper

Collector log dosyasını veya container output'unu okuyarak event'leri merkezi pipeline'a gönderir. Filebeat daha odaklı ve hafif bir seçenek sunarken Elastic Agent merkezi Fleet policy yönetimi sağlayabilir. Kubernetes'te node seviyesinde collector DaemonSet olarak çalıştırılabilir. Collector'ın disk state veya registry mekanizması yeniden başlatma sonrasında kaldığı yerden devam etmeye yardımcı olur. Output bağlantısı kesildiğinde retry ve buffering davranışının ne olduğu üretim mimarisinde açıkça bilinmelidir.

Logstash Ingestion Katmanı

Logstash gelen event'i input, filter ve output aşamalarından geçirir. Grok, Dissect veya JSON filter ile alanlar çıkarılabilir ve ECS isimlerine dönüştürülebilir. Persistent Queue etkinleştirilirse kısa süreli output kesintilerinde event'ler disk üzerinde tutulabilir. Pipeline throughput worker ve batch ayarlarıyla ölçülerek optimize edilmelidir. Logstash kullanmak transformation ihtiyacı varsa değer üretir, yalnızca arada bir hop oluşturuyorsa gereksiz operasyon yüküne dönüşebilir.

Elasticsearch Storage ve Search Katmanı

Elasticsearch event'leri document olarak shard'lara yazar. Mapping her alanın text, keyword, date veya başka veri türünde nasıl saklanacağını belirler. Log verileri için modern data stream yaklaşımı rollover ve lifecycle yönetimini kolaylaştırır. Query, aggregation ve full-text search işlemleri shard'larda çalıştırılır ve sonuçlar birleştirilir. Index sayısı, shard boyutu ve mapping alan sayısı kontrol edilmezse cluster kaynak tüketimi zamanla artabilir.

Kibana Visualization Katmanı

Kibana kullanıcıların Elasticsearch'e doğrudan REST sorgusu yazmadan verileri analiz etmesini kolaylaştırır. Data view veya Streams üzerinden ilgili log veri kümesine ulaşılabilir. Discover ile ham event incelenirken Lens görselleştirmeleri hata oranı veya response süresi gibi göstergeler oluşturabilir. Dashboard'lar service ve environment filtreleriyle operasyon ekranına dönüştürülebilir. Alert kuralları kritik sorguların sürekli elle kontrol edilmesi ihtiyacını azaltır.

Uçtan Uca Log Akışı

Uçtan uca akışın sağlıklı olması yalnız her servisin çalışmasıyla ölçülmemelidir. Kaynakta üretilen event sayısı ile Elasticsearch'e ulaşan event sayısı arasında düzenli kontrol yapılmalıdır. Collector, Logstash ve Elasticsearch throughput metric'leri bu karşılaştırmanın ara noktalarını oluşturur. Synthetic test logu belirli aralıklarla gönderilerek gerçek delivery latency ölçülebilir. Bu yaklaşım log pipeline'ını da kendi SLO'ları olan production sistemi olarak yönetmeyi sağlar.

Application → Filebeat → Logstash → Elasticsearch → Kibana

Bu klasik akışta uygulama log dosyasına veya container output'una event yazar ve Filebeat bu event'i okur. Filebeat Beats protokolü üzerinden Logstash'in 5044 portuna güvenli bağlantı kurabilir. Logstash event'i parse ederek alanları standardize eder ve TLS üzerinden Elasticsearch'e gönderir. Elasticsearch veriyi uygun data stream'e yazar, Kibana ise aynı veri üzerinde sorgu ve dashboard oluşturur. Pipeline'ın her bağlantısında TLS, authentication, retry ve backpressure davranışının test edilmesi gerekir.

Her Log Sistemi İçin Logstash Gerekli mi?

Hayır, Logstash merkezi log sisteminin zorunlu bileşeni değildir. Modern structured log üreten uygulamalarda Elastic Agent veya Filebeat veriyi doğrudan Elasticsearch'e gönderebilir ve basit dönüşümler ingest pipeline üzerinde yapılabilir. Logstash daha güçlü transformation, birçok input kaynağını birleştirme veya persistent queue ihtiyacı bulunduğunda anlam kazanır. Kafka kullanılan yüksek hacimli mimarilerde Logstash consumer katmanı olarak da konumlandırılabilir. Yeni proje tasarlarken önce neden Logstash'e ihtiyaç duyulduğu yazılmalı, yalnız klasik ELK şemasında bulunduğu için eklenmemelidir.

Doğrudan Elasticsearch'e Gönderim

Uygulamanın Elasticsearch API'sine doğrudan log göndermesi teknik olarak mümkündür ancak application ile observability altyapısını sıkı bağlayabilir. Elasticsearch kesintisi uygulama request akışını etkilememelidir. Bu nedenle uygulamanın log gönderimini asynchronous yapması veya collector katmanı kullanması daha güvenli olur. Credential'ların uygulamalara geniş ölçekte dağıtılması da ek yönetim gerektirir. Pratikte uygulamanın stdout ya da dosyaya structured log yazması ve collector'ın transport sorumluluğunu üstlenmesi daha esnek modeldir.

Filebeat → Elasticsearch

Filebeat kaynak dosyaları okuyup doğrudan Elasticsearch'e gönderebilir. Filebeat module veya processor'ları temel parsing ihtiyaçlarını karşılayabilir. Elasticsearch ingest pipeline ek dönüşümleri uygulayabilir ve arada Logstash işletme ihtiyacını ortadan kaldırabilir. Küçük ve orta ölçekli Linux log toplama projelerinde bu model sade ve etkilidir. Elasticsearch bağlantısı TLS ile korunmalı ve Filebeat için minimum index veya data stream yetkisine sahip credential kullanılmalıdır.

Elastic Agent → Elasticsearch

Elastic Agent Fleet policy ile yönetildiğinde integration ayarlarını merkezi olarak alabilir. System, Nginx veya custom logs integration aracılığıyla event'ler doğrudan Elasticsearch data stream'lerine gönderilebilir. Integration paketleri ingest pipeline ve hazır dashboard gibi varlıkları da kurabilir. Çok sayıda host için tek agent üzerinden log ve metric yönetimi operasyon kolaylığı sağlayabilir. Kullanılacak output ve integration özelliklerinin güncel sürümde desteklendiği deployment öncesinde kontrol edilmelidir.

Filebeat → Logstash → Elasticsearch

Bu model parsing veya enrichment merkezi noktada yapılmak istendiğinde uygundur. Filebeat host üzerinde hafif collector olarak kalırken Logstash pipeline kuralları merkezi sunucuda yönetilir. Legacy plaintext formatların Grok ile ayrıştırılması buna iyi örnektir. Logstash Persistent Queue output kesintilerinde ek dayanıklılık katmanı sağlayabilir. Buna karşılık Logstash node'larının kapasitesi, TLS sertifikaları ve pipeline deployment süreci ayrıca işletilmelidir.

Kafka → Logstash → Elasticsearch

Yüksek hacimli veya burst davranışı gösteren sistemlerde Kafka ingestion ile Elasticsearch arasında bağımsız buffer oluşturabilir. Producer event'i Kafka'ya yazar ve Logstash consumer group üzerinden işleyebilir. Elasticsearch yavaşladığında logların belirli retention süresince Kafka'da kalması replay avantajı sağlar. Ancak Kafka'nın broker, partition, replication ve monitoring sorumluluğu vardır. Küçük log hacminde yalnız buffer ihtimali için Kafka kurmak sistemin bakım maliyetini gereksiz artırabilir.

Logstash Kullanılması Gereken Durumlar

Birden fazla farklı protokolden veri alınıyorsa Logstash güçlü input ekosistemi sunar. Legacy plaintext logların karmaşık parsing kurallarıyla structured hale getirilmesi gerektiğinde Grok ve Dissect değerlidir. Event'in harici kaynaktan lookup ile zenginleştirilmesi veya output'un koşullara göre farklı hedeflere yönlendirilmesi de uygun kullanım alanıdır. Persistent Queue kısa süreli downstream kesintilerinde disk buffering sağlayabilir. Bu yeteneklerden hiçbiri gerekmiyorsa daha sade collector ve ingest pipeline mimarisi değerlendirilmelidir.

Logstash Kullanılmaması Gereken Durumlar

Uygulamalar zaten ECS uyumlu JSON log üretiyorsa geniş parsing katmanına ihtiyaç kalmayabilir. Tek kaynak ve basit birkaç field dönüşümü için ingest pipeline yeterli olabilir. Logstash ek JVM belleği, deployment ve monitoring sorumluluğu getirir. Küçük ekiplerde gereksiz bileşen sayısı incident çözümünü zorlaştırabilir. Tasarımın hedefi en çok aracı kullanmak değil, veri güvenilirliğini en az gerekli bileşenle sağlamaktır.

Filebeat, Elastic Agent ve OpenTelemetry Collector Arasındaki Fark

Bu üç collector benzer görünen ancak farklı yönetim modellerine sahip araçlardır. Filebeat log odaklı, olgun ve basit yapı sunar. Elastic Agent log, metric ve güvenlik toplama işlevlerini Fleet üzerinden merkezi policy altında birleştirebilir. OpenTelemetry Collector ise telemetry pipeline'larını daha vendor-neutral biçimde kurmak isteyen ekipler için geniş receiver, processor ve exporter modeli sunar. Seçim mevcut ekosistem, merkezi yönetim ihtiyacı ve gelecekte başka observability backend'lerine veri gönderme planı dikkate alınarak yapılmalıdır.

Filebeat

Filebeat özellikle dosya ve belirli service loglarını hafif biçimde toplamak için geliştirilmiştir. Input veya integration yapılarına göre logları okuyabilir ve Elasticsearch ya da Logstash'e gönderebilir. Existing Filebeat kurulumları olgun automation ile yönetiliyorsa hemen değiştirilmesi zorunlu değildir. Küçük deployment'larda tek configuration file yaklaşımı oldukça anlaşılırdır. Yeni geniş ölçekli kurulumlarda Elastic Agent'ın gerekli integration'ları destekleyip desteklemediği karşılaştırılmalıdır.

Elastic Agent

Elastic Agent farklı telemetry türlerini tek binary üzerinden yönetmeyi hedefler. Fleet kullanıldığında agent policy merkezi Kibana arayüzünden değiştirilebilir ve hostlara dağıtılabilir. Elastic'in güncel migration dokümantasyonu tek agent, merkezi policy ve remote upgrade gibi avantajları özellikle vurgular. Bununla birlikte Beats'teki bazı ileri configuration özellikleri birebir taşınmayabilir. Bu nedenle migration önce test ortamında yapılmalı ve kullanılan integration ile output özellikleri tek tek doğrulanmalıdır.

Fleet

Fleet, Elastic Agent'ların enrollment, policy ve health bilgisini merkezi olarak yönetir. Bir agent policy içine System veya Nginx gibi integration'lar eklenebilir. Policy değişikliği aynı policy'ye bağlı hostlara merkezi olarak gönderilir. Agent durumları Healthy, Offline veya başka durumlarla izlenebilir ve sorun yaşayan hostun kendi agent loglarına ulaşılabilir. Büyük host sayısında configuration drift'i azaltması Fleet'in önemli avantajlarından biridir.

OpenTelemetry Collector

OpenTelemetry Collector log, metric ve trace verilerini receiver, processor ve exporter pipeline'ları üzerinden işleyebilir. Vendor-neutral telemetry standardını merkeze alan ekipler için Elasticsearch dışında başka hedeflere veri gönderme esnekliği sağlar. Kubernetes ve microservice ortamlarında telemetry pipeline'ının ortak katmanı olarak kullanılabilir. Elastic Agent'ın güncel sürümlerinde OpenTelemetry Collector tabanlı çalışma modeline yönelik entegrasyonlar da gelişmektedir. Elastic'in güncel dokümantasyonu Agent'ın bazı veri akışlarında OpenTelemetry Collector bileşenlerini kullandığını belirtmektedir.

Hangi Log Collector Ne Zaman Kullanılmalı?

Seçim için önce kaynak çeşitliliği, host sayısı ve merkezi yönetim ihtiyacı belirlenmelidir. Basit Linux loglarında mevcut Filebeat kurulumu yeterli olabilir. Yüzlerce host ve çok sayıda integration için Fleet yönetimli Elastic Agent operasyon yükünü azaltabilir. Trace, metric ve log için açık telemetry standardı hedefleniyorsa OpenTelemetry Collector değerlendirilebilir. Araç seçiminin proof of concept sonucunda throughput, kaynak tüketimi ve failure davranışıyla doğrulanması gerekir.

Basit Linux Logları

Tek veya birkaç Linux sunucusundaki syslog ve auth loglarını toplamak için Filebeat oldukça sade çözüm sunabilir. System module parsing ve dashboard oluşturmayı kolaylaştırır. Existing automation Ansible ile Filebeat configuration dağıtıyorsa Fleet kurmak zorunlu olmayabilir. Güvenli Elasticsearch output ve düzgün registry storage temel gereksinimlerdir. Gelecekte host sayısı arttığında Elastic Agent migration seçeneği açık tutulabilir.

Çok Sayıda Sunucu

Sunucu sayısı büyüdüğünde tek tek configuration file yönetmek operasyon yükünü artırır. Fleet managed Elastic Agent merkezi policy ve agent health görünürlüğü sağlayabilir. Yeni integration değişikliği hostlara toplu uygulanabilir. Remote upgrade imkanı sürüm yönetimini kolaylaştırabilir. Yine de policy değişiklikleri önce küçük canary grubunda test edilip ardından geniş kitleye dağıtılmalıdır.

Kubernetes

Kubernetes log toplama genellikle node seviyesinde DaemonSet collector ile yapılır. Container metadata, namespace ve pod bilgisi event'e eklenmelidir. Elastic Agent veya OpenTelemetry Collector bu modelde kullanılabilir. Multiline container logları source'a yakın noktada doğru birleştirilmelidir. Collector resource request ve limitleri cluster workload'una göre ölçülerek belirlenmelidir.

Observability

Log, metric ve trace birlikte değerlendirilecekse tek telemetry kimliği önemli hale gelir. trace.id ve service.name alanları log ile distributed trace arasında bağlantı kurabilir. Elastic Agent Elastic integration deneyimini kolaylaştırırken OpenTelemetry standardı daha açık instrumentation modeli sağlar. Application instrumentation ile infrastructure collection birbirinden ayrılabilir. Hangi aracın kullanılacağı mevcut monitoring ve tracing mimarisiyle birlikte değerlendirilmelidir.

Vendor-Neutral Mimari

Telemetry verisinin gelecekte farklı backend'lere gönderilebilmesi isteniyorsa OpenTelemetry Collector güçlü seçenek olabilir. Collector pipeline'ında farklı exporter tanımlanabilir ve application instrumentation backend'e doğrudan bağlı kalmaz. Log schema yine kurum içinde standardize edilmelidir. Vendor-neutral tasarım her ürünü aynı anda kullanmak anlamına gelmez. Amaç uygulama ve telemetry üretim katmanını belirli storage ürününden gereksiz ölçüde bağımsız tutmaktır.

ELK Kurulum Mimarisi Nasıl Seçilir?

Mimari seçimi günlük log hacmi, retention, sorgu yükü ve availability beklentisi üzerinden yapılmalıdır. Tek sunuculu ELK laboratuvar ve küçük sistemler için kolaydır ancak host arızası tüm log platformunu etkiler. Production ortamında Elasticsearch cluster, Kibana ve ingestion node'ları ayrı kaynak profilleriyle ölçeklenebilir. Docker Compose geliştirme veya küçük tek host deployment için pratik olabilirken Kubernetes ya da managed servis daha büyük operasyon gereksinimlerine cevap verebilir. En doğru çözüm en çok node'u içeren değil, ölçülen ihtiyaçları güvenilir biçimde karşılayan mimaridir.

Tek Sunuculu ELK

Elasticsearch, Kibana ve Logstash aynı sunucuda çalıştırılabilir. Lab, eğitim veya düşük hacimli internal sistemler için kurulum kolaylığı sağlar. Ancak CPU, RAM ve disk contention tek makinede toplanır. Sunucu arızalandığında storage ve arayüz aynı anda kaybolabilir. Production kritik log sistemi için backup bulunsa bile bu mimari yüksek availability sağlamaz.

Ayrı Logstash Sunucusu

Parsing yoğun olduğunda Logstash CPU ve JVM yükünü Elasticsearch'ten ayırmak mantıklıdır. Birden fazla Logstash instance load balancer arkasında çalışabilir. Persistent Queue için her node'un yeterli local disk alanı gerekir. Pipeline configuration aynı repository üzerinden dağıtılmalıdır. Logstash node kaybında collector'ların diğer healthy endpoint'e bağlanabilmesi gereklidir.

Multi-Node Elasticsearch Cluster

Multi-node cluster shard ve replica'ları farklı node'lara dağıtabilir. Resilient production cluster için master seçiminde çoğunluk korunması gerekir. Elastic dokümantasyonu yüksek availability hedefleyen cluster'larda en az üç master-eligible node ve her kritik shard için birden fazla kopya gerektiğini belirtir. Node rolleri cluster büyüdükçe ayrıştırılabilir. Storage ve network latency cluster stability açısından güçlü donanım kadar önemlidir.

Docker Compose

Docker Compose laboratuvar ve development ortamında Elastic bileşenlerini hızlıca başlatmayı sağlar. Version tüm servislerde aynı tutulabilir ve persistent volume ile data container lifecycle'dan ayrılabilir. Memory limit özellikle Elasticsearch için açıkça tanımlanmalıdır. Secret değerler Compose dosyasına düz metin yazılmamalıdır. Production tek host deployment'ta kullanılabilse de cluster availability ve upgrade prosedürü ayrıca tasarlanmalıdır.

Kubernetes

Kubernetes pod scheduling, secret ve persistent volume yönetimi sunar ancak Elasticsearch stateful davranışı nedeniyle doğru operator kullanımı önemlidir. Elastic Cloud on Kubernetes cluster lifecycle ve TLS işlemlerini otomatikleştirebilir. Storage class latency ve volume topology Elasticsearch performansını doğrudan etkiler. Resource request ve limitler gerçek indexing yüküne göre ayarlanmalıdır. Kubernetes kullanılıyor olması Elasticsearch'ü otomatik olarak yüksek availability hale getirmez.

Elastic Cloud

Managed Elastic deployment node provisioning, bazı upgrade ve snapshot işlemlerini hizmet olarak sağlayabilir. Küçük operasyon ekibi için infrastructure bakımını azaltması önemli avantajdır. Maliyet GB günlük ingestion, retention ve compute ihtiyacına göre değerlendirilmelidir. Network erişimi ve data residency gereksinimleri kurum politikasına uygun olmalıdır. Managed hizmet kullanmak log schema ve retention tasarımı sorumluluğunu ortadan kaldırmaz.

Küçük Ekip İçin Önerilen Mimari

Küçük ekip için gereksiz bileşen sayısını azaltmak önemlidir. Structured JSON log, Elastic Agent veya Filebeat ve doğrudan Elasticsearch ingest pipeline çoğu durumda iyi başlangıçtır. Logstash yalnız gerçek parsing veya buffering ihtiyacı varsa eklenebilir. Tek node ile başlanıyorsa snapshot ve disk alerting mutlaka kurulmalıdır. Trafik ve retention büyüdükçe multi-node veya managed deployment'a geçiş planı hazırlanmalıdır.

Production İçin Önerilen Mimari

Production tasarımında collector katmanı redundant olmalı ve Elasticsearch cluster tek host failure'ını tolere edebilmelidir. En az üç master-eligible node kullanan resilient cluster modeli çoğunluk kaybı riskini azaltır. Data node sayısı ingest hacmi ve query yüküne göre artırılır. Kibana ve Logstash stateless katmanlar olarak birden fazla instance ile çalıştırılabilir. Snapshot repository cluster dışındaki failure domain'de tutulmalı ve restore tatbikatı düzenli yapılmalıdır.

ELK İçin Donanım Gereksinimleri

ELK için tek bir doğru CPU veya RAM sayısı yoktur, çünkü kaynak ihtiyacı event hacmi ve sorgu davranışına bağlıdır. Elasticsearch hem JVM heap hem operating system page cache kullandığı için belleği yalnız Java heap olarak değerlendirmek hatalıdır. Disk kapasitesi retention ve replica çarpanından etkilenir, disk performansı ise indexing ve merge işlemlerinde kritik rol oynar. Logstash parsing yoğun pipeline'larda CPU kullanabilir. Kibana genellikle Elasticsearch data node'larından daha düşük kaynak ister ancak kullanıcı ve alert yükü büyüdüğünde ayrı ölçeklenmelidir.

CPU

Elasticsearch indexing, compression, merge ve query işlemlerinde CPU kullanır. Grok ağırlıklı Logstash pipeline'ları da özellikle regex parsing sırasında yüksek CPU tüketebilir. Core sayısı yalnız event/saniye ile değil query concurrency ile birlikte değerlendirilmelidir. Development ortamında birkaç core yeterli olabilirken production için load test sonucu kullanılmalıdır. CPU saturation sürekli yüzde yüz seviyesine yaklaşıyorsa latency ve queue davranışları birlikte incelenmelidir.

RAM

Elasticsearch RAM'i JVM heap ve filesystem cache arasında kullanır. Cluster metadata, aggregation ve indexing buffer heap tüketirken Lucene segmentleri işletim sistemi cache'inden faydalanır. Tüm RAM'i heap'e vermek bu nedenle performansı düşürebilir. Logstash JVM ve event queue için ayrıca RAM ister. Capacity testleri gerçek mapping ve gerçek event boyutuna yakın veriyle yapılmalıdır.

Disk

Disk kapasitesi günlük ingest hacmi, compression oranı, replica ve retention süresinin birleşimidir. Ayrıca merge, watermark ve snapshot işlemleri için serbest alan bırakılmalıdır. Elasticsearch disk tamamen dolmadan önce shard allocation davranışını sınırlar. Node disklerini yüzde yüze yakın çalıştırmak güvenli kapasite kullanımı değildir. Disk throughput ve IOPS özellikle hot tier için kapasite kadar önemlidir.

SSD Neden Önemlidir?

Elasticsearch segment write, merge ve random read davranışından dolayı düşük latency storage'dan faydalanır. SSD indexing sırasında bekleme süresini azaltabilir. Dashboard sorgularında hot data segmentlerine hızlı erişim kullanıcı deneyimini iyileştirir. Warm ve cold tier daha düşük maliyetli storage kullanabilir ancak sorgu beklentisi buna göre ayarlanmalıdır. Storage seçimi yalnız fiyat başına GB üzerinden yapılmamalıdır.

Elasticsearch JVM Heap

JVM heap Elasticsearch process içindeki managed memory alanıdır. Modern Elasticsearch node rollerine ve kullanılabilir belleğe göre otomatik heap sizing sağlayabilir. Manual değer gerekiyorsa Xms ve Xmx eşit tutulması yaygın uygulamadır. Heap aşırı büyütüldüğünde operating system page cache için daha az RAM kalır. Heap pressure ve garbage collection metric'leri manuel değişiklik yapmadan önce incelenmelidir.

Logstash Bellek Gereksinimi

Logstash JVM üzerinde çalışır ve pipeline event'leri bellekte işler. Event boyutu büyükse batch ve worker sayısı memory kullanımını etkiler. Persistent Queue disk üzerinde buffering sağlasa da pipeline processing tamamen memory dışına taşınmaz. Çok sayıda pipeline aynı instance üzerinde ayrı resource ihtiyacı yaratır. Heap ve process memory gerçek throughput testiyle gözlenmelidir.

Kibana Kaynak Gereksinimi

Kibana Node.js tabanlı web uygulamasıdır ve saved objects, dashboard request'leri, alert ve reporting görevleri çalıştırabilir. Birkaç kullanıcı bulunan sistem ile yüzlerce concurrent kullanıcı aynı resource ihtiyacına sahip değildir. Reporting işlemleri CPU ve memory tüketebilir. Birden fazla Kibana instance kullanılıyorsa encryption key değerleri aynı tutulmalıdır. User experience için Kibana latency yanında Elasticsearch query latency de ölçülmelidir.

Günlük Log Hacmine Göre Boyutlandırma

Boyutlandırma günlük GB hesabıyla başlar ancak tek başına yeterli değildir. Ortalama event boyutu, event/saniye peak değeri, mapping field sayısı ve replica sayısı hesaba katılmalıdır. Retention 30 günden 90 güne çıktığında storage ihtiyacı doğrusal olarak büyüyebilir. Compression gerçek veriyle test edilmelidir. En güvenilir capacity planı sample production loglarını temsil eden benchmark ile oluşturulur.

Log Hacmi Nasıl Hesaplanır?

Log hacmi hesabı capacity planning'in temelidir. Ortalama event/saniye değeri ile event boyutu çarpılarak saatlik ve günlük raw veri hacmi tahmin edilebilir. Bunun üzerine Elasticsearch index overhead, replica, lifecycle ve güvenli disk boşluğu eklenmelidir. Peak trafik ortalamadan birkaç kat yüksek olabileceği için ingestion throughput ayrıca test edilmelidir. Hesabın aylık olarak gerçek cluster metric'leriyle güncellenmesi storage sürprizlerini azaltır.

Event/Saniye

Event/saniye belirli zaman aralığında üretilen log kayıtlarının sayısını gösterir. Ortalama değer kapasite hesabı için kullanışlıdır fakat peak değer buffer ve indexing throughput açısından daha önemlidir. Deployment veya incident sırasında log seviyesi artarak event sayısı normalin birkaç katına çıkabilir. Her source için ayrı EPS ölçmek hangi servisin büyümeye neden olduğunu gösterir. Collector ve Logstash throughput metric'leri aynı birimle karşılaştırılabilir.

Ortalama Event Boyutu

Event boyutu JSON alan sayısı ve message içeriğine göre değişir. Bir access log birkaç yüz byte olabilirken stack trace birkaç kilobyte ulaşabilir. Ortalama değer sample log seti üzerinden ölçülmelidir. P95 event boyutu multiline exception etkisini anlamaya yardımcı olur. Gereksiz büyük request veya response body'lerini loglamak hem güvenlik hem maliyet açısından kaçınılması gereken davranıştır.

Günlük GB Hesabı

Basit yaklaşımda saniyedeki event sayısı ortalama event byte değeri ve 86.400 saniye ile çarpılır. Örneğin 1.000 EPS ve 800 byte ortalama event yaklaşık 69 GB raw günlük trafik üretir. Elasticsearch stored size compression ve mapping nedeniyle bu raw değerden farklı olabilir. Replica storage miktarını artırır. Gerçek cluster'daki store.size metric'i tahmini zamanla kalibre etmek için kullanılmalıdır.

Retention Süresi

Retention logların minimum ne kadar süre saklanacağını belirler. Operasyon logları 14 veya 30 gün yeterli olabilirken güvenlik ve audit verisi kurum politikasına göre daha uzun tutulabilir. Tüm dataset'lere aynı retention vermek maliyeti gereksiz artırabilir. Data stream veya ILM policy dataset bazında farklı süreler uygulayabilir. Retention kararı operasyonel değer, mevzuat ve storage maliyetinin ortak sonucudur.

Replica Etkisi

Bir primary shard için bir replica tutulduğunda shard verisinin ikinci kopyası başka node üzerinde saklanır. Bu dayanıklılık ve query kapasitesi sağlar ancak disk kullanımını artırır. Küçük single-node lab'da replica atanamadığı için cluster yellow olabilir. Production resilient cluster'da kritik data için replica gereklidir. Searchable snapshot gibi bazı tier modellerinde replica yaklaşımı farklı olabilir.

Index Overhead

Elasticsearch yalnız raw message saklamaz, indexlenmiş field yapıları ve segment metadata'sı da disk kullanır. Çok sayıda keyword field, yüksek cardinality ve stored source boyutu overhead'i etkiler. LogsDB gibi log odaklı index mode storage verimliliğini geliştirebilir. Gerçek compression oranı veri setine göre değişir. Capacity hesaplarında yalnız gzip ile sıkıştırılmış raw log dosyasına bakmak doğru sonuç vermez.

Disk Büyüme Tahmini

Günlük indexed size retention günüyle çarpılarak temel storage ihtiyacı hesaplanabilir. Replica ve snapshot storage ayrı eklenir. Merge işlemleri ve watermark güvenliği için serbest disk bırakılmalıdır. Growth trend aylık bazda izlenerek altı veya on iki aylık kapasite tahmini oluşturulabilir. Storage yalnız dolmaya yakınken değil, trend alarmı üzerinden önceden artırılmalıdır.

Ubuntu Sunucuyu ELK Kurulumuna Hazırlama

Ubuntu üzerinde ELK kurulumu package install komutundan önce temel host hazırlığı gerektirir. Saat senkronizasyonu doğru değilse log event'leri yanlış zaman sırasına yerleşebilir. DNS, hostname ve private network adresleri cluster discovery için istikrarlı olmalıdır. Firewall yalnız gerekli node ve collector kaynaklarına port erişimi vermelidir. Disk alanı, filesystem ve kernel ayarları Elasticsearch başlamadan önce doğrulanırsa sonradan yaşanan birçok bootstrap sorunu önlenebilir.

Sistem Güncellemesi

Sunucu package index'i güncellenmeli ve kritik güvenlik yamaları uygulanmalıdır. Kernel veya systemd güncellemesi reboot gerektiriyorsa Elasticsearch kurulmadan önce tamamlamak daha temiz başlangıç sağlar. Production node'larında update politikası rolling maintenance modeline göre yürütülmelidir. Paket sürümleri infrastructure automation içinde kayıt altına alınabilir. İşletim sistemi güncellemesi Elastic upgrade ile aynı anda yapılmak zorunda değildir ve riskler mümkün olduğunca ayrılmalıdır.

sudo apt update
sudo apt upgrade

Hostname

Her Elasticsearch node anlamlı ve benzersiz hostname kullanmalıdır. Hostname monitoring ve cluster node listesinde problemin hangi makinede olduğunu anlamayı kolaylaştırır. Dinamik veya tekrar kullanılan isimler incident sırasında karışıklık yaratabilir. Node name ile hostname aynı tutulabilir ancak zorunlu değildir. Infrastructure inventory ve DNS kaydı hostname değişiklikleriyle birlikte güncellenmelidir.

DNS

Cluster node'ları ve collector endpoint'leri sabit DNS isimleri kullanabilir. DNS resolution failure ingestion veya cluster discovery problemlerine yol açabilir. Production DNS düşük latency ve yüksek availability sunmalıdır. TLS certificate subject alanları kullanılan DNS isimleriyle uyumlu olmalıdır. IP'yi application veya agent config içinde çok sayıda yerde hardcode etmek yerine kontrollü service name kullanmak yönetimi kolaylaştırır.

NTP ve Saat Senkronizasyonu

Log analizinde timestamp temel sıralama alanıdır. Host saatleri birbirinden birkaç dakika farklıysa dağıtık request timeline'ı yanlış görünür. NTP veya işletim sisteminin güvenilir time synchronization servisi bütün node'larda aktif olmalıdır. UTC kullanmak çok bölgeli sistemlerde timezone hesaplarını kolaylaştırır. Application local timezone ile log üretse bile ingest sırasında normalize edilmiş @timestamp alanı oluşturulmalıdır.

UFW Firewall

Firewall portları yalnız ihtiyaç duyan kaynaklara açmalıdır. Elasticsearch HTTP portu 9200 public internete açık bırakılmamalıdır. Multi-node transport trafiği 9300 yalnız cluster node ağında erişilebilir olmalıdır. Kibana erişimi reverse proxy veya VPN katmanına yönlendirilebilir. Logstash 5044 portu yalnız agent network'lerinden bağlantı kabul edecek şekilde sınırlandırılabilir.

SSH Hardening

ELK node yönetimi için SSH erişimi minimum kullanıcı grubuyla sınırlandırılmalıdır. Password login yerine anahtar tabanlı authentication ve gerekli durumlarda MFA destekli bastion yaklaşımı kullanılabilir. Root ile doğrudan login kapatılabilir. SSH logları da merkezi log sistemine alınarak başarısız girişler izlenebilir. Yönetim erişimi ile uygulama trafiğinin aynı public network yüzeyini paylaşmaması tercih edilir.

Disk Alanını Kontrol Etme

Kurulum öncesinde data path'in bulunduğu filesystem kapasitesi kontrol edilmelidir. Elasticsearch data directory root filesystem'iyle aynı küçük partition üzerindeyse log büyümesi tüm işletim sistemini etkileyebilir. Disk mount noktası, filesystem ve IOPS özellikleri belirlenmelidir. Capacity alert'leri daha ilk günden tanımlanmalıdır. df çıktısı yalnız anlık durumu gösterdiğinden büyüme trend'i monitoring sisteminde ayrıca tutulmalıdır.

df -h
lsblk

vm.max_map_count ve Sistem Ayarları

Elasticsearch Linux üzerinde çok sayıda memory mapped region kullanabilir ve vm.max_map_count uygun değerde olmalıdır. Güncel Debian package kurulum script'leri systemd tabanlı sistemlerde bazı kernel parametrelerini ayarlamaya çalışır. Elastic'in güncel 9.x Debian kurulum dokümantasyonu bu davranışı açıkça belirtir. Production node'da mevcut değer ve package sonrası sonuç yine doğrulanmalıdır. File descriptor ve memory lock gibi diğer bootstrap gereksinimleri de deployment modeline göre kontrol edilmelidir.

Elastic Sürümü Nasıl Seçilmeli?

Elastic Stack bileşenlerinde sürüm uyumu kritik konudur. Elasticsearch, Kibana, Logstash ve kullanılan Beats paketleri mümkün olduğunca aynı Elastic Stack sürümünde tutulmalıdır. Elastic'in güncel kurulum dokümantasyonu stack bileşenlerinin aynı sürümde kullanılmasını açıkça önerir. 25 Ağustos 2026 itibarıyla resmi package dokümantasyonu Elasticsearch 9.5.2'yi güncel 9.x paket olarak göstermektedir. Production'da patch sürümü bile release note ve staging testi sonrasında uygulanmalıdır.

Güncel Stable Sürümü Kontrol Etmek

Kuruluma başlamadan önce resmi package repository ve release note kontrol edilmelidir. Eski blog yazılarındaki patch sürümünü kopyalamak güvenlik düzeltmelerini kaçırabilir. 25 Ağustos 2026 tarihinde Elastic'in resmi 9.x Debian dokümantasyonu 9.5.2 paketini göstermektedir ve registry de aynı sürüm image'larını 18 Ağustos 2026 tarihinde yayınlanmış olarak listeler. Version seçimi yalnız en büyük numarayı almak değildir, bilinen issue ve compatibility notları da incelenmelidir. Infrastructure code kullanılan exact sürümü açıkça kaydetmelidir.

Elasticsearch, Kibana ve Logstash Sürümlerini Eşleştirmek

Stack bileşenleri aynı release serisinde tutulmalıdır. Elasticsearch 9.5.2 çalışırken Kibana için de 9.5.2 package tercih edilmesi deployment davranışını öngörülebilir hale getirir. Logstash ve Filebeat sürümleri de aynı stack version politikasıyla yönetilebilir. Upgrade sırasında compatibility matrix ve upgrade order resmi dokümantasyondan kontrol edilmelidir. Version drift otomatik inventory veya package policy ile tespit edilebilir.

Major ve Minor Version Farkları

Major upgrade backward compatibility açısından daha büyük değişiklikler taşıyabilir. Minor sürüm yeni özellik ve davranış ekleyebilir, patch sürümü ise genellikle düzeltmelere odaklanır. Ancak yalnız semantic version varsayımıyla upgrade yapılmamalıdır. Release note, deprecation ve migration araçları incelenmelidir. Özellikle index compatibility ve snapshot restore sınırları major geçişlerde ayrıca planlanmalıdır.

7.x ve 8.x Rehberlerini Kullanmanın Riskleri

Eski rehberler Java kurulumu, security defaults ve package repository konusunda güncel davranıştan farklı olabilir. Security auto-configuration modern Elasticsearch kurulumlarında TLS ve enrollment süreçlerini değiştirmiştir. 9.x ile LogsDB ve Streams gibi log yönetimi özellikleri de daha farklı varsayımlar taşır. Eski komutun çalışması güvenli veya önerilen olduğu anlamına gelmez. Kurulum adımları her zaman kullanılan major sürümün resmi dokümantasyonuyla karşılaştırılmalıdır.

Sürümü Sabitlemek

Production package upgrade'in beklenmedik zamanda otomatik gelmesi istenmeyebilir. Infrastructure automation exact version veya kontrollü repository policy kullanabilir. Upgrade staging'de test edildikten sonra rolling şekilde uygulanır. Docker image tag'i de explicit sürüm içermelidir. Version pinning güncellemeleri sonsuza kadar ertelemek için değil, değişikliği kontrollü hale getirmek için kullanılmalıdır.

Release Notes Kontrolü

Release note yeni feature kadar bug fix ve bilinen sorun bilgisini de içerir. Patch upgrade öncesinde search, indexing veya security davranışını etkileyen notlar incelenmelidir. Elastic'in Ağustos 2026 durum kaydı 9.5.1'deki belirli query sorununun 9.5.2 ile düzeltildiğini belirtmiştir. Bu örnek patch sürümlerin production doğruluğu açısından neden takip edilmesi gerektiğini gösterir. Upgrade sonrası smoke query ve dashboard testleri bu nedenle pipeline'ın parçası olmalıdır.

Güncel Elasticsearch İçin Ayrıca Java Kurmak Gerekir mi?

Güncel Elasticsearch Debian paketi kendi OpenJDK dağıtımını içerir. Bu nedenle çoğu standart kurulumda ayrı sistem Java'sı kurmak gerekmez. Elastic'in resmi Debian package dokümantasyonu bundled OpenJDK bulunduğunu açıkça belirtir. Custom JVM yalnız belirli kurumsal zorunluluk veya desteklenen özel kullanım ihtiyacı varsa değerlendirilmelidir. Eski ELK rehberlerinde görülen manuel Java kurulumu güncel package davranışını yansıtmayabilir.

Bundled OpenJDK

Elasticsearch package desteklenen Java runtime'ını beraberinde getirir. Bu yaklaşım Java version compatibility riskini azaltır. Sistem genelinde başka Java kullanan uygulamalar Elasticsearch runtime'ını etkilemez. Upgrade sırasında Elasticsearch ile birlikte uyumlu JDK da güncellenebilir. Custom Java gereksinimi yoksa bundled runtime kullanmak operasyon açısından daha sade seçenektir.

Sistem Java'sı ile Bundled JVM Arasındaki Fark

Sistem Java'sı host üzerindeki diğer uygulamalar tarafından paylaşılabilir ve ayrı package lifecycle'ına sahiptir. Bundled JVM ise Elasticsearch dağıtımıyla birlikte test edilen runtime'dır. Sistem Java'sı beklenmedik güncellendiğinde Elasticsearch compatibility riski doğabilir. Bundled model bu bağımlılığı azaltır. Kurumsal security policy özel JDK zorunlu kılıyorsa destek matrix kontrol edilmeden değişiklik yapılmamalıdır.

Custom JVM Ne Zaman Kullanılmalı?

Custom JVM ancak organization standardı veya belirli destek gereksinimi bulunuyorsa düşünülmelidir. Kullanılacak JDK sürümünün Elastic support matrix ile uyumlu olması gerekir. ES_JAVA_HOME gibi ayarlar package ortamında custom path tanımlayabilir. JVM değişikliği benchmark ve staging testinden geçmelidir. Sorun çözme sırasında default bundled JVM'e dönülebilecek rollback planı bulunmalıdır.

Eski ELK Rehberlerinde Java Kurulumunun Nedeni

Elasticsearch'ün daha eski dönemlerinde external Java dependency yaygın kurulum gereksinimiydi. Bu nedenle internette apt install openjdk ile başlayan çok sayıda eski rehber bulunur. Güncel package kendi JDK'sını taşıdığı için bu adım çoğu durumda gereksizdir. Eski rehberin başka security veya repository adımları da outdated olabilir. Sürüm tarihi belirtilmeyen kurulum yazıları production için doğrudan uygulanmamalıdır.

Ubuntu'ya Elastic APT Repository Nasıl Eklenir?

Elastic Debian repository package güncellemelerini standart apt akışına dahil eder. Güncel yöntem signing key'i keyring dosyasına ekler ve repository satırında signed-by kullanır. 9.x için repository ayrı elastic-9.x.list dosyasına yazılabilir. Eski apt-key yaklaşımı modern Ubuntu güvenlik modelinde tercih edilmemelidir. Repository eklendikten sonra package origin ve candidate version kontrol edilerek yanlış kaynak kullanılmadığı doğrulanmalıdır.

Elastic PGP Key

Elastic package'ları signing key ile imzalanır. Key download edilip GPG keyring formatına dönüştürülebilir. Böylece apt yalnız beklenen repository imzasına güvenebilir. Key fingerprint resmi dokümantasyonla karşılaştırılmalıdır. Production automation key'i rastgele üçüncü taraf URL'sinden indirmemelidir.

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

Keyring Kullanımı

Keyring dosyası belirli repository satırındaki signed-by parametresine bağlanır. Bu yaklaşım signing key güvenini tüm apt kaynaklarına global olarak yaymak yerine ilgili repository ile sınırlar. Dosya root tarafından yönetilmelidir. Automation file checksum veya fingerprint doğrulaması ekleyebilir. Key rotation duyuruları release management sürecinde takip edilmelidir.

9.x APT Repository

Güncel 9.x repository satırı Elastic'in resmi artifact endpoint'ini kullanır. Major sürümün dosya adında açıkça belirtilmesi yanlışlıkla başka major branch'e geçişi azaltır. Production upgrade policy repository aktif olsa bile package version'ı kontrollü tutabilir. Aynı repository satırının iki kez eklenmesi apt warning üretir. Elastic dokümantasyonu duplicate entry kontrolünü de özellikle belirtir.

echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/9.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-9.x.list

apt update

Repository eklendikten sonra apt package metadata'sı güncellenmelidir. Bu işlem signing key veya repository syntax problemi varsa erken hata verir. Output içindeki certificate ve signature warning'leri göz ardı edilmemelidir. Automation command exit code'u kontrol etmelidir. Production node'da package update planı maintenance süreciyle birlikte yönetilmelidir.

sudo apt update

Paket Kaynağını Doğrulamak

Install öncesi candidate version ve repository origin kontrol edilmelidir. Böylece yanlış mirror veya eski major repository kullanılması engellenir. apt-cache policy elasticsearch uygun kontrol yöntemlerinden biridir. Kibana ve Logstash için de aynı stack version görüldüğü doğrulanabilir. Bu küçük kontrol upgrade sırasında version mismatch sorunlarını önemli ölçüde azaltır.

Eski apt-key Yönteminden Kaçınmak

apt-key tabanlı eski rehberler signing key'i global güven deposuna ekleyebilir. Modern repository tanımında keyring ve signed-by kullanmak daha kontrollü yaklaşımdır. Yeni sunucuda eski komutları kopyalamak yerine current Elastic documentation izlenmelidir. Infrastructure repository definition tek yerde tutulmalıdır. Legacy node migration sırasında eski key ve duplicate source entry'leri temizlenmelidir.

Ubuntu'ya Elasticsearch Kurulumu

Repository hazırlandıktan sonra Elasticsearch apt üzerinden kurulabilir. Güncel Elastic dokümantasyonu 9.x repository'de sudo apt-get install elasticsearch komutuyla current package kurulmasını gösterir. Debian package systemd service tanımı ve default config path'lerini oluşturur. Service kurulumdan sonra production ayarları kontrol edilerek manuel başlatılmalıdır. İlk başlangıç security auto-configuration işlemlerini oluşturduğu için console ve certificate dosyaları dikkatle yönetilmelidir.

Elasticsearch Paketini Kurmak

Package kurulumundan önce apt candidate version kontrol edilmelidir. Exact version gerekiyorsa package version explicit verilebilir. Tüm cluster node'ları aynı Elasticsearch sürümüne planlı şekilde getirilmelidir. Upgrade sırasında tek seferde tüm node'ları durdurmak yerine desteklenen rolling procedure kullanılmalıdır. Yeni kurulumda package config ve data path izinleri değiştirilmeden önce default davranış anlaşılmalıdır.

sudo apt-get update
sudo apt-get install elasticsearch

systemd Servisini Etkinleştirmek

Elasticsearch'ün host reboot sonrasında otomatik başlaması için systemd enable yapılabilir. Daemon reload package service unit'inin systemd tarafından okunmasını sağlar. Production cluster'da automatic start node dependency ve network readiness ile uyumlu olmalıdır. Service user permission'ları değiştirilmemelidir. Custom override gerekiyorsa package unit dosyasını doğrudan düzenlemek yerine systemd override mekanizması kullanılmalıdır.

sudo systemctl daemon-reload
sudo systemctl enable elasticsearch.service

Elasticsearch'i Başlatmak

Service ilk kez başlatıldığında security auto-configuration devreye girebilir. Debian package systemd altında çalıştığı için elastic superuser password terminale otomatik yazılmayabilir ve reset tool ile oluşturulması gerekir. İlk startup logları certificate ve bootstrap hataları açısından kontrol edilmelidir. Multi-node deployment ise discovery ayarları production network tasarımına göre yapılmalıdır. Elastic'in güncel package dokümantasyonu systemd start komutunu ve security startup davranışını açıklar.

sudo systemctl start elasticsearch.service

Servis Durumunu Kontrol Etmek

systemctl status process'in active olup olmadığını gösterir. Ancak active state Elasticsearch cluster'ın healthy olduğunu tek başına kanıtlamaz. HTTP API testi ve cluster health ayrıca yapılmalıdır. Restart loop veya permission hatası varsa service output ilk ipucunu sağlar. Production monitoring systemd state ile Elasticsearch API metric'lerini birlikte izlemelidir.

sudo systemctl status elasticsearch

Elasticsearch Loglarını Kontrol Etmek

Debian package default logları /var/log/elasticsearch altında tutar. Elastic dokümantasyonu service'in default olarak systemd journal'a ayrıntılı log yazmayabileceğini belirtir. Bootstrap check, discovery, certificate ve disk uyarıları bu loglarda görülür. Log dosyası permission'ları yalnız gerekli yönetim kullanıcılarına açık olmalıdır. Elasticsearch loglarının kendisi de ayrı monitoring pipeline'a alınabilir ancak recursive log storm oluşmamasına dikkat edilmelidir.

curl ile Elasticsearch'i Test Etmek

Security auto-configuration HTTP TLS etkinleştirdiği için test isteği HTTPS kullanmalıdır. Debian package'ta CA certificate varsayılan olarak /etc/elasticsearch/certs/http_ca.crt konumunda bulunur. elastic password environment variable üzerinden kullanılabilir. Certificate validation kapatmak yerine CA açıkça curl'e verilmelidir. Elastic'in resmi örneği de bu yöntemi kullanmaktadır.

curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic:$ELASTIC_PASSWORD https://localhost:9200

Elasticsearch Security Auto-Configuration

Modern Elasticsearch ilk node başlangıcında uygun koşullarda security ayarlarını otomatik yapılandırabilir. TLS certificate'ları HTTP ve transport katmanları için oluşturulur ve Kibana enrollment süreci hazırlanır. Debian package altında elastic password'ünün reset tool ile oluşturulması gerekebilir. Auto-configuration devre dışı bırakılmamalı, production network ve certificate tasarımına göre geliştirilmelidir. Elastic'in güncel security dokümantasyonu HTTP CA, transport keystore ve enrollment davranışını ayrıntılı biçimde açıklar.

Elastic Superuser

elastic built-in superuser geniş cluster yetkilerine sahiptir. Bu hesap günlük dashboard kullanımı veya agent ingestion için kullanılmamalıdır. İlk setup ve gerektiğinde yönetim görevleri sonrasında ayrı least privilege kullanıcılar ve API key'ler oluşturulmalıdır. Debian package kurulumunda password reset tool güvenli şekilde password oluşturabilir. Superuser credential secret manager içinde sınırlı erişimle tutulmalıdır.

Otomatik TLS Sertifikaları

İlk security setup HTTP ve transport katmanları için TLS materyali oluşturabilir. Bu certificate'lar Elasticsearch client bağlantılarında plain HTTP kullanılmasını engeller. Production domain ve certificate lifecycle ihtiyacına göre kurum CA'sı veya yönetilen PKI kullanılabilir. Sertifika expiration ve rotation monitoring'e alınmalıdır. TLS validation probleminde verification'ı kapatmak yerine trust chain düzeltilmelidir.

HTTP CA Certificate

Auto-configuration HTTP certificate'larını imzalayan CA'yı http_ca.crt olarak oluşturur. Debian kurulumunda dosya /etc/elasticsearch/certs/http_ca.crt altında bulunabilir. Logstash, standalone Agent ve başka client'lar bu CA'yı trust ederek HTTPS certificate'ını doğrulayabilir. CA certificate secret değildir ancak değiştirilmesi güven zincirini etkiler. Elastic dokümantasyonu client'ların CA certificate veya fingerprint üzerinden trust oluşturabileceğini belirtir.

Transport TLS

Transport TLS Elasticsearch node'ları arasındaki cluster iletişimini şifreler ve node authentication sağlar. Multi-node production cluster'da bu katman açık kalmalıdır. HTTP TLS kullanıcı ve client trafiğini, transport TLS ise node-to-node trafiği korur. Certificate subject ve node discovery adresleri uyumlu olmalıdır. Transport portu yalnız cluster node private network'ünde erişilebilir hale getirilmelidir.

Enrollment Token

Enrollment token yeni Elasticsearch node veya Kibana instance'ını mevcut secured cluster'a bağlamak için kullanılabilir. Elastic'in güncel CLI dokümantasyonu elasticsearch-create-enrollment-token aracının node ve kibana scope'larını desteklediğini belirtir. Token kısa ömürlüdür ve yalnız setup sırasında kullanılmalıdır. Kibana token süresi dolarsa yeni token oluşturulabilir. Enrollment token kalıcı service credential gibi saklanmamalıdır.

Şifre Resetleme

Built-in user password'leri elasticsearch-reset-password aracıyla yenilenebilir. Tool generated veya interactive password seçeneği sunar. Password reset sırasında application ve integration credential bağımlılıkları bilinmelidir. Günlük ingestion için superuser password yerine API key veya özel service account tercih edilmelidir. Reset işlemi audit kaydıyla change management sürecine dahil edilmelidir.

Varsayılan Güvenliği Kapatmamak

Lab ortamında certificate hatasını hızlı çözmek için security'yi tamamen kapatmak cazip görünebilir. Bu yaklaşım production'a taşındığında 9200 portunun authentication olmadan erişilebilir hale gelmesine neden olabilir. Doğru çözüm TLS trust ve credential configuration'ını düzeltmektir. Development ile production security modeli mümkün olduğunca aynı prensipleri kullanmalıdır. Güvenliği kapatmak yerine internal CA'yı client'lara güvenilir biçimde dağıtmak daha sağlıklı yöntemdir.

elasticsearch.yml Nasıl Yapılandırılır?

elasticsearch.yml node ve cluster davranışının temel static configuration dosyasıdır. Debian package'ta varsayılan konumu /etc/elasticsearch/elasticsearch.yml şeklindedir. Cluster name, node name, network binding, data path ve discovery ayarları burada tanımlanabilir. Production cluster'da dosyanın configuration management aracıyla version control mantığında yönetilmesi tercih edilir. Secret değerler normal YAML içine yazılmak yerine Elasticsearch keystore gibi secure setting mekanizmalarında tutulmalıdır.

cluster.name

cluster.name hangi cluster'a ait olduğunuzu gösteren logical isimdir. Aynı cluster'a katılacak node'ların aynı cluster name kullanması gerekir. Development ve production için farklı isim belirlemek yanlış cluster'a node join riskini azaltır. Monitoring ve alert etiketlerinde cluster name kullanmak faydalıdır. İsim tek başına güvenlik sınırı değildir ve network ile TLS kontrolleri ayrıca gereklidir.

node.name

node.name cluster içinde node'u tanımlar. Hostname veya role bilgisi içeren anlamlı isimler operasyonu kolaylaştırabilir. Node adı dashboard ve shard allocation çıktılarında sıkça görünür. Otomatik provisioning kullanılıyorsa isimler unique olacak şekilde template oluşturulmalıdır. Node değiştiğinde monitoring geçmişinin doğru yorumlanabilmesi için instance metadata ayrıca tutulabilir.

network.host

network.host Elasticsearch HTTP ve transport network binding davranışını etkileyebilir. Public interface'e 0.0.0.0 ile bağlanmak yalnız firewall ve private network tasarımı doğruysa kullanılmalıdır. Production'da mümkünse private interface adresi seçilir. Network binding değiştiğinde Elasticsearch production bootstrap checks etkinleşebilir. Public internete erişim gerekiyormuş gibi 9200 portunu doğrudan açmak yerine application proxy veya private connectivity kullanılmalıdır.

http.port

Elasticsearch REST API varsayılan olarak 9200 portunu kullanır. Port değiştirmek tek başına güvenlik sağlamaz. Client, Logstash ve Kibana configuration'ları kullanılan endpoint ile eşleşmelidir. Firewall yalnız gerekli source network'lere erişim vermelidir. Monitoring health check de HTTPS ve certificate validation kullanmalıdır.

path.data

path.data shard ve node state dosyalarının saklandığı konumu belirler. Production'da yeterli kapasite ve IOPS sunan dedicated storage kullanılmalıdır. Data directory başka process tarafından değiştirilmemelidir. Filesystem-level copy backup olarak kabul edilmemelidir. Node migration ve restore işlemleri resmi snapshot ve cluster prosedürleriyle yapılmalıdır.

path.logs

path.logs Elasticsearch process loglarının konumunu belirler. Data ve application log storage gereksinimleri birbirinden ayrılabilir. Log rotation policy disk taşmasını önlemelidir. Elasticsearch logları güvenlik veya cluster sorunu içerdiği için merkezi monitoring'e alınabilir. Ancak logging loop ve gereksiz debug seviyesi dikkatle yönetilmelidir.

discovery.seed_hosts

discovery.seed_hosts yeni node'un mevcut master-eligible node'ları bulmasına yardımcı olur. Multi-node cluster'da stable private DNS veya IP adresleri kullanılabilir. Elastic'in güncel Debian kurulum dokümantasyonu yeni node'ların enrollment sonrasında seed host yapılandırmasının tüm node'larda doğru tutulmasını özellikle belirtir. Tek node lab ayarı production discovery tasarımıyla karıştırılmamalıdır. DNS failure cluster formation sorununa dönüşebileceğinden name resolution da izlenmelidir.

cluster.initial_master_nodes

cluster.initial_master_nodes yeni cluster ilk kez bootstrap edilirken kullanılır. Cluster kurulduktan sonra bu ayarın kalıcı bırakılması tehlikeli olabilir ve yanlış yeni cluster oluşumu riski yaratabilir. Elastic'in güncel multi-node kurulum adımlarında cluster oluşumundan sonra bu değerin kaldırılması açıkça istenir. Existing cluster'a node eklerken initial bootstrap süreci tekrar yapılmamalıdır. Automation first-cluster bootstrap ile ordinary node join durumlarını ayırmalıdır.

Production Ayarları ile Lab Ayarları Arasındaki Fark

Lab tek node, küçük heap ve localhost erişimiyle çalışabilir. Production ise redundant node, private network, TLS, snapshot ve capacity monitoring ister. Development kolaylığı için security kapatmak iki ortam arasında riskli fark oluşturur. Production discovery ve master election davranışı gerçek multi-node test ortamında denenmelidir. Config file'ların aynı template'ten environment variable veya inventory değerleriyle üretilmesi drift'i azaltır.

Elasticsearch'i İnternete Açmak Neden Risklidir?

Elasticsearch API yalnız search endpoint'i değildir, cluster ve index üzerinde güçlü yönetim işlemleri sunabilir. Public internet üzerinde doğrudan erişilebilir 9200 portu brute force, exploit ve yanlış yetkilendirme riskini büyütür. Authentication ve TLS zorunlu olsa bile private network yaklaşımı exposure alanını azaltır. Remote operator erişimi VPN veya zero trust gateway üzerinden yapılabilir. Application'ların doğrudan cluster management API'lerine ulaşması yerine minimum endpoint ve credential kullanması gerekir.

Port 9200 Riski

9200 Elasticsearch REST API portudur ve index read, write veya yönetim endpoint'lerine erişim sağlayabilir. Authentication bulunmayan eski veya yanlış yapılandırılmış cluster'lar ciddi veri kaybı riski taşır. Port değiştirmek scanner ve attacker riskini ortadan kaldırmaz. Firewall source allowlist ve private network temel kontrol olmalıdır. Public search API gerekiyorsa application layer araya konulmalıdır.

Authentication

Elasticsearch her client isteğini uygun kimlikle doğrulamalıdır. Kibana, Logstash ve collector aynı superuser credential'ını paylaşmamalıdır. API key veya özel user minimum privilege ile sınırlandırılabilir. Credential rotation deployment akışına dahil edilmelidir. Failed authentication logları security monitoring sisteminde alarm üretmek için kullanılabilir.

TLS

TLS client ile Elasticsearch arasında credential ve log verisinin ağda açık metin taşınmasını engeller. Certificate validation kapatılırsa man-in-the-middle riski artar. Internal CA client trust store'a eklenebilir. Certificate expiration alert edilmelidir. HTTP ve transport TLS farklı trust ve certificate gereksinimlerine sahip olabilir.

Firewall

Firewall Elasticsearch API'sine yalnız Kibana, Logstash ve gerekli backend network'lerinden bağlantı kabul edebilir. Yönetici erişimi ayrı bastion veya VPN subnet'inden gelebilir. Default deny yaklaşımı yanlışlıkla yeni public source eklenmesini engeller. Firewall değişiklikleri infrastructure code üzerinden review edilebilir. Cloud security group ve host firewall birlikte kullanılıyorsa rule ownership açık olmalıdır.

Private Network

Elasticsearch node'ları private subnet üzerinde çalıştırılabilir. Internet-facing reverse proxy veya application doğrudan data node rolü taşımaz. Private DNS cluster discovery ve client endpoint için kullanılabilir. Backup repository erişimi kontrollü egress rule ile sağlanır. Network segmentation compromise durumunda hareket alanını azaltır.

VPN

Operatörlerin Kibana veya Elasticsearch administration endpoint'lerine erişimi VPN üzerinden sağlanabilir. Bu yöntem public internet exposure'ını azaltır. VPN user identity ve MFA ile desteklenmelidir. Split tunneling ve DNS configuration doğru yapılmalıdır. Incident sırasında emergency access yöntemi önceden test edilmelidir.

IP Allowlist

Allowlist yalnız bilinen source IP veya network'lerin erişimine izin verir. Sabit office veya collector subnet'leri için faydalıdır. Dynamic developer IP'lerini sürekli eklemek operasyon sorununa dönüşebilir. VPN arkasında tek kontrollü source kullanmak daha iyi olabilir. IP allowlist authentication'ın yerine geçmez, ek güvenlik katmanıdır.

Elasticsearch API'sini Public Internet'e Açmamak

En güvenli varsayılan Elasticsearch'ü private service olarak tutmaktır. Public kullanıcı istekleri application API üzerinden geçer. Kibana reverse proxy ve SSO arkasında yayınlanabilir. Remote administration VPN üzerinden yapılabilir. Böylece cluster API attack surface önemli ölçüde daraltılır.

Elasticsearch JVM Heap Nasıl Ayarlanır?

Elasticsearch heap ayarı indexing ve query performansını doğrudan etkileyebilir. Modern sürümlerde node rolü ve memory miktarına göre otomatik heap sizing kullanılabildiğinden başlangıçta manuel Xmx değiştirmek her zaman gerekli değildir. Heap aşırı büyütülürse filesystem cache için RAM azalır ve Lucene performansı etkilenebilir. Çok küçük heap ise garbage collection ve circuit breaker problemlerine yol açabilir. Karar heap pressure, GC ve workload benchmark sonuçlarına dayanmalıdır.

JVM Heap Nedir?

Heap Java object'lerinin tutulduğu managed memory alanıdır. Elasticsearch cluster state, aggregation ve çeşitli request yapıları için heap kullanır. Lucene segment data'nın büyük bölümü filesystem cache üzerinden çalıştığı için tüm node RAM'i heap değildir. Heap dolduğunda garbage collector kullanılmayan object'leri temizler. Sürekli yüksek heap pressure kapasite veya query design problemine işaret edebilir.

Otomatik Heap Ayarları

Güncel Elasticsearch birçok durumda otomatik JVM heap sizing uygular. Bu nedenle eski rehberlerdeki sabit yüzde elli kuralını doğrudan uygulamak yerine default davranış önce gözlenmelidir. Node rolleri ve total memory otomatik hesaplamayı etkileyebilir. Container kullanılıyorsa memory limit açıkça tanımlanmalıdır. Manual override gerekiyorsa change öncesi ve sonrası workload metric'leri karşılaştırılmalıdır.

Xms ve Xmx

Xms başlangıç heap boyutunu, Xmx maksimum heap boyutunu belirler. Manuel ayar yapıldığında ikisini eşit tutmak runtime resizing davranışını önler. Değer package default dosyalarını doğrudan değiştirmek yerine custom jvm.options.d dosyasında yönetilebilir. Container memory limitinin üzerinde heap tanımlanmamalıdır. Büyük heap her zaman daha hızlı Elasticsearch anlamına gelmez.

Heap'i Aşırı Büyütmenin Problemleri

Heap büyüdükçe işletim sistemi page cache için daha az RAM kalır. Lucene disk segment okumalarında page cache performansından büyük ölçüde faydalanır. Çok büyük heap GC pause davranışını da etkileyebilir. Node memory'nin tamamını Java'ya vermek bu nedenle yanlış yaklaşımdır. Search latency ve disk read metric'leri heap değişiklikleriyle birlikte izlenmelidir.

OS Page Cache

Elasticsearch index segmentleri filesystem üzerinde tutulur ve sık erişilen data işletim sistemi cache'inde kalabilir. Page cache search performansını önemli ölçüde iyileştirir. Heap dışında yeterli RAM bırakmak bu yüzden gereklidir. Disk yavaşsa cache miss maliyeti daha belirgin hale gelir. Hot tier node sizing heap ve cache ihtiyacını birlikte karşılamalıdır.

Garbage Collection

JVM artık kullanılmayan object'leri garbage collection ile temizler. Sık ve uzun GC pause query latency'yi artırabilir. GC sorununa yalnız heap artırarak cevap vermek doğru olmayabilir. Mapping explosion, ağır aggregation ve büyük request'ler heap tüketiminin gerçek nedeni olabilir. GC log ve Elasticsearch JVM metric'leri birlikte analiz edilmelidir.

Heap Pressure Monitoring

Heap pressure sürekli yüksek seviyede ise indexing veya query rejection görülebilir. Kibana Stack Monitoring veya metric collector üzerinden JVM kullanım trend'i izlenebilir. Alert yalnız anlık spike yerine süre bazlı koşul kullanmalıdır. Node rolü ve workload'a göre threshold değerlendirilir. Capacity artırmadan önce en çok memory kullanan query ve mapping pattern'leri analiz edilmelidir.

Tek Node ve Multi-Node Elasticsearch Arasındaki Fark

Tek node cluster kurulum kolaylığı sağlar ancak host failure karşısında availability sunmaz. Replica aynı node üzerinde tutulamayacağı için bir replica yapılandırılmış index single-node cluster'da yellow durumda kalabilir. Multi-node cluster shard kopyalarını farklı node'lara dağıtabilir ve master election ile cluster state yönetimini sürdürebilir. Production availability gereksinimi varsa minimum resilient topology planlanmalıdır. Elastic dokümantasyonu üç master-eligible node'u dayanıklı cluster tasarımının temel koşullarından biri olarak tanımlar.

Single Node

Single node lab, eğitim ve düşük kritik internal kullanım için uygundur. Tüm primary shard'lar aynı host üzerinde bulunur. Host disk veya process failure durumunda cluster unavailable olur. Snapshot alınmış olsa bile restore için yeni node ve zaman gerekir. Production critical audit loglarının tek kopyasını yalnız bu node üzerinde tutmak uygun değildir.

Master-Eligible Node

Master-eligible node cluster state ve master election süreçlerine katılır. Cluster'ın index oluşturma, mapping update ve shard allocation kararları elected master üzerinden koordine edilir. Yüksek availability için çoğunluk oluşturabilecek yeterli sayıda master-eligible node gerekir. Dedicated master node büyük cluster'da data workload'ından ayrılabilir. Master node'a yoğun client query göndermek önerilmez.

Data Node

Data node shard'ları saklar ve indexing ile search işlemlerini yürütür. Hot, warm, cold veya content gibi farklı roller storage ve workload profiline göre ayrılabilir. Data node kapasitesi günlük ingestion ve query yükü üzerinden belirlenir. Replica shard farklı data node'a yerleştirilmelidir. Node failure sonrasında shard recovery network ve disk üzerinde ek yük oluşturur.

Replica

Replica primary shard'ın ek kopyasıdır. Primary'nin bulunduğu node kaybolduğunda replica promote edilerek data availability korunabilir. Search request'leri replica üzerinde de çalıştırılabilir. Replica storage ve indexing network maliyetini artırır. Critical data için availability gereksinimi bu maliyetten daha önemlidir.

Quorum

Elasticsearch master election ve cluster state değişiklikleri için voting configuration çoğunluğu kullanır. Üç master-eligible node varsa iki node erişilebilir kaldığında çoğunluk sağlanabilir. İki node kaybolursa cluster yeni master seçemez. Elastic dokümantasyonu yüksek availability için en az üç master-eligible node gerektiğini açıkça belirtir. Network partition senaryolarının staging veya chaos test ortamında anlaşılması faydalıdır.

High Availability

High availability yalnız node sayısını artırmak değildir. Shard replica, master quorum, availability zone dağılımı ve client failover birlikte tasarlanmalıdır. İki data copy aynı physical host veya zone üzerindeyse tek failure ikisini de etkileyebilir. Load balancer client request'lerini healthy node'lara dağıtmalıdır. Snapshot yüksek availability'nin yerine geçmez, disaster recovery katmanıdır.

Production'da Kaç Node Kullanılmalı?

Kesin sayı workload'a göre değişir, ancak resilient cluster için Elastic en az üç master-eligible node önerir. Küçük üç node cluster'da bu node'ların data rolü de olabilir. Cluster büyüdükçe dedicated master ve data tier rolleri ayrılabilir. Data node sayısı ingest, search ve storage kapasitesine göre hesaplanmalıdır. Availability zone sayısı ve failure tolerance node sayısı kadar önemli tasarım girdisidir.

Elasticsearch Cluster Health Nasıl Kontrol Edilir?

Cluster health primary ve replica shard allocation durumunu özetler. Green tüm primary ve replica shard'ların atandığını, yellow primary'lerin çalıştığını fakat bazı replica'ların atanmadığını gösterir. Red en az bir primary shard'ın unavailable olduğu daha ciddi durumdur. Health rengi tek başına root cause söylemez. _cat API'leri ve allocation explain çıktısı hangi node veya shard'ın problem yaşadığını bulmak için kullanılır.

Green

Green status tüm shard kopyalarının beklenen şekilde atandığını gösterir. Production için normal hedef budur. Green olması search latency veya disk kapasitesinin mükemmel olduğu anlamına gelmez. JVM, indexing rejection ve disk watermarks ayrıca izlenmelidir. Deployment sonrası cluster green olsa bile uygulama smoke query çalıştırmak faydalıdır.

Yellow

Yellow status tüm primary shard'ların available olduğunu ancak bazı replica'ların atanamadığını gösterir. Single-node cluster'da bir replica konfigürasyonu doğal olarak yellow oluşturabilir. Multi-node production cluster'da yellow durum node kaybı veya allocation constraint belirtisi olabilir. Uzun süre yellow kalmak redundancy kaybı anlamına gelir. Unassigned replica nedeni allocation API ile incelenmelidir.

Red

Red status en az bir primary shard'ın atanamadığını gösterir. Bazı data veya system feature'ları unavailable olabilir. Disk failure, node kaybı veya allocation problemi olası nedenlerdir. Data silmek veya shard'ı force allocate etmek gibi riskli işlemler root cause anlaşılmadan yapılmamalıdır. Snapshot restore gerekebilecek senaryolar için runbook önceden hazırlanmalıdır.

_cluster/health

_cluster/health status, node sayısı ve shard allocation özetini sağlar. Monitoring agent bu endpoint'ten metric alabilir. CI veya deployment health gate olarak da kullanılabilir. Authentication ve HTTPS zorunlu olmalıdır. Health API success dönmesi application data query'sinin doğru çalıştığını tek başına doğrulamaz.

GET _cluster/health

_cat/nodes

_cat/nodes cluster node'larının temel rol ve kaynak bilgilerini okunabilir tabloda gösterir. Beklenen node cluster'a katılmamışsa hızlı kontrol sağlar. Node role dağılımı deployment sonrası doğrulanabilir. Human-readable endpoint automation için JSON API kadar stabil olmayabilir. Script kullanımında explicit column ve format seçmek daha güvenlidir.

_cat/indices

_cat/indices index health, shard, document ve storage özetini gösterir. Büyük index veya red status hızlıca fark edilebilir. Modern logs data stream kullanıldığında backing index sayısı da önemlidir. Index isimleri system data içerebileceği için çıktının paylaşımında dikkatli olunmalıdır. Capacity analizi için data stream ve shard API'leriyle birlikte kullanılır.

Unassigned Shard Analizi

Unassigned shard için yalnız yeniden başlatma denemek doğru yöntem değildir. Allocation explain API node disk, role, filter veya replica constraint gibi gerçek nedeni gösterebilir. Disk high watermark shard relocation'ı etkileyebilir. Node count yetersizse replica atanamaz. Root cause çözüldükten sonra Elasticsearch allocation işlemini çoğu durumda otomatik tamamlar.

Ubuntu'ya Kibana Kurulumu

Kibana Elasticsearch ile aynı Elastic Stack version'da kurulmalıdır. Aynı 9.x APT repository kullanılarak package alınabilir. Kibana varsayılan olarak local erişime uygun şekilde başlar ve production yayınlama modeli ayrıca yapılandırılmalıdır. İlk bağlantı security auto-configuration ile oluşturulan enrollment token üzerinden gerçekleştirilebilir. Service çalıştıktan sonra status ve loglar kontrol edilmeden reverse proxy katmanına geçilmemelidir.

Kibana Paketini Kurmak

Kibana package candidate version'ın Elasticsearch ile aynı olduğu doğrulanmalıdır. Version mismatch bazı feature veya saved object işlemlerinde sorun oluşturabilir. Package config dosyasını /etc/kibana altında oluşturur. Production secrets normal YAML içine yazılmadan keystore veya secret management sistemi kullanılabilir. Upgrade package install öncesi saved objects ve Elasticsearch snapshot planıyla birlikte değerlendirilmelidir.

sudo apt-get install kibana

Kibana Servisini Başlatmak

Enrollment veya config hazırlandıktan sonra Kibana systemd ile başlatılabilir. İlk startup saved objects migration veya Elasticsearch connectivity nedeniyle biraz sürebilir. Kibana server is not ready yet mesajı görülüyorsa yalnız browser refresh yapmak yerine backend logları incelenmelidir. Elasticsearch cluster health ve certificate trust kontrol edilmelidir. Production health monitor Kibana status endpoint'ini izleyebilir.

sudo systemctl start kibana.service

systemd ile Otomatik Başlatma

Kibana service host reboot sonrasında otomatik başlatılabilir. Elasticsearch endpoint hazır değilse Kibana retry edebilir ancak dependency availability izlenmelidir. Birden fazla Kibana instance load balancer arkasında kullanılacaksa encryption key değerleri bütün instance'larda aynı olmalıdır. Service override ve environment variable yönetimi automation ile yapılabilir. Elastic'in güncel dokümantasyonu package kurulumlarında systemd enable ve start yöntemini destekler.

sudo systemctl daemon-reload
sudo systemctl enable kibana.service

Kibana Loglarını Kontrol Etmek

Kibana connectivity, saved objects migration ve plugin hataları loglarda görünür. Debian package systemd logları journalctl -u kibana.service üzerinden incelenebilir. TLS certificate validation error burada açıkça görülebilir. Debug logging yalnız troubleshooting süresince etkinleştirilmeli ve sonrasında normale dönülmelidir. Logların kendisinde token veya hassas header bulunmadığı da kontrol edilmelidir.

Kibana Status Kontrolü

Kibana status yalnız process durumundan daha fazla bilgi sağlar. Elasticsearch connection veya bazı plugin state'leri burada gözlenebilir. Reverse proxy health check gereksiz authentication loop üretmemelidir. Status endpoint erişimi public internete açık bırakılmamalıdır. Alerting ve task manager problemleri kullanıcı arayüzü açılıyor olsa bile ayrıca izlenmelidir.

Kibana'yı Elasticsearch'e Bağlamak

Yeni self-managed kurulumda Kibana enrollment token ile Elasticsearch security configuration'ını alabilir. Elastic'in güncel kurulum akışında token kısa ömürlüdür ve gerektiğinde yeniden üretilebilir. Kibana Elasticsearch'e built-in service account üzerinden bağlanabilir. CA certificate validation açık tutulmalıdır. Birden fazla cluster veya custom certificate kullanılan yapılarda elasticsearch.hosts ve trust ayarları explicit yönetilebilir.

Enrollment Token Oluşturmak

İlk token süresi dolduysa Elasticsearch node üzerinde yeni Kibana enrollment token üretilebilir. Tool scope değeri kibana olarak seçilir. Token yalnız setup amacıyla kısa süre kullanılır. Output güvenli terminal veya secret transfer kanalı üzerinden Kibana operatörüne ulaştırılmalıdır. Token chat veya uzun ömürlü documentation içinde saklanmamalıdır.

sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s kibana

Verification Code

Kibana ilk setup sırasında browser ile terminal sürecini eşleştirmek için verification adımı isteyebilir. Kod yalnız kısa süreli setup bilgisidir. Public veya paylaşılan ekranlarda gösterilmemelidir. Headless automation kullanılıyorsa kibana-setup gibi desteklenen araçlarla non-interactive enrollment değerlendirilebilir. Setup tamamlandığında permanent authentication normal user ve service credential üzerinden devam eder.

Kibana System User

Kibana'nın Elasticsearch ile backend iletişimi için özel built-in service identity kullanılır. Bu kimlik son kullanıcı dashboard erişimi için tasarlanmamıştır. Human user'lar kendi role ve authentication yöntemleriyle Kibana'ya giriş yapmalıdır. Service credential'ın yetkisi broad superuser hesabına göre daha kontrollüdür. Password tabanlı custom setup yapılırsa credential secret management içinde tutulmalıdır.

TLS Certificate Validation

Kibana Elasticsearch certificate chain'ini doğrulamalıdır. Self-signed internal CA kullanılıyorsa Kibana trust configuration'a CA dosyası eklenir. Verification'ı none yapmak hızlı workaround gibi görünse de production güvenliğini düşürür. Certificate hostname ile configured Elasticsearch host uyuşmalıdır. Rotation sırasında eski ve yeni trust chain kontrollü geçişle yönetilmelidir.

Elasticsearch Hosts

Kibana bir veya birden fazla Elasticsearch endpoint'i tanımlayabilir. High availability cluster'da resilient endpoint veya load balancer kullanmak tek node bağımlılığını azaltır. URL HTTPS kullanmalıdır. Public hostname yerine private service endpoint tercih edilir. DNS ve certificate subject aynı name üzerinden yönetildiğinde operasyon kolaylaşır.

Bağlantıyı Test Etmek

Kibana loglarında Elasticsearch connectivity success kontrol edilmelidir. Browser UI açılması ilk doğrulamadır ancak saved object oluşturma ve Discover query de test edilmelidir. Certificate, authentication ve cluster health sorunları birbirinden ayrılmalıdır. Kibana'nın kullandığı identity ile gerekli system index izinleri bulunmalıdır. Deployment sonrasında otomatik smoke test login veya API health çağrısı çalıştırabilir.

Kibana Encryption Keys

Kibana session, saved objects ve reporting özelliklerinde encryption key'ler kullanır. Bu değerler restart sonrasında değişirse session veya encrypted saved object erişimi bozulabilir. Birden fazla Kibana instance kullanılıyorsa aynı key setinin bütün instance'larda tutulması gerekir. Elastic'in güncel dokümantasyonu security ve saved object encryption key'lerinin en az 32 karakter olmasını ister. Key'ler kibana.yml içine açıkça gömülmek yerine secret manager veya Kibana keystore ile yönetilebilir.

Security Encryption Key

xpack.security.encryptionKey Kibana session güvenliği için kalıcı key sağlar. Her startup'ta farklı random key oluşması mevcut session'ların geçersizleşmesine yol açabilir. High availability Kibana instance'ları aynı değeri kullanmalıdır. Key en az 32 karakter olmalıdır. Rotation planı kullanıcı session etkisini dikkate almalıdır.

Encrypted Saved Objects Key

xpack.encryptedSavedObjects.encryptionKey alert action credential gibi hassas saved object alanlarını şifrelemek için kullanılır. Elastic dokümantasyonu bu key açıkça ayarlanmazsa bazı feature'ların kullanılamayabileceğini belirtir. Key rotation yapılırken eski verilerin de decrypt edilebilmesi için decryption-only key modeli desteklenir. Bütün Kibana instance'larında configuration aynı olmalıdır. Key backup ve disaster recovery runbook'unun parçasıdır.

Reporting Encryption Key

xpack.reporting.encryptionKey reporting job metadata'sını korur. Static key tanımlanmazsa restart sonrasında pending report'lar başarısız olabilir. Load balanced Kibana instance'ları aynı reporting key kullanmalıdır. Elastic'in güncel reporting dokümantasyonu minimum 32 karakterlik static key kullanılmasını açıklar. Reporting aktif değilse bile gelecekte feature kullanımı için configuration standardı oluşturmak faydalıdır.

Key'leri Kalıcı Hale Getirmek

Key'ler host yeniden başlatıldığında veya container recreate olduğunda değişmemelidir. Secret manager deployment sırasında aynı değerleri bütün Kibana instance'larına sağlamalıdır. Container image içine key baked edilmemelidir. Backup sırasında secret source ve access policy ayrıca korunmalıdır. Rotation kontrollü planlanıp saved object decrypt davranışı staging'de test edilmelidir.

Secret Management

Kibana key'leri Git repository'sinde tutulmamalıdır. Secret manager veya encrypted infrastructure secret sistemi kullanılabilir. Deployment identity yalnız ihtiyaç duyduğu key path'lerine read erişimi almalıdır. İnsan kullanıcıların secret değerlerini doğrudan görme ihtiyacı minimum tutulmalıdır. Secret erişimi audit log ile izlenebilir.

Kibana'yı Güvenli Şekilde Yayınlamak

Kibana kullanıcıların loglara ve bazen hassas operasyon bilgilerine eriştiği yönetim arayüzüdür. Bu nedenle 5601 portunu doğrudan internete açmak yerine reverse proxy, HTTPS ve authentication katmanı kullanılmalıdır. VPN veya IP allowlist erişim yüzeyini daha da azaltabilir. Enterprise ortamda SSO role mapping ile user lifecycle merkezi kimlik sistemi üzerinden yönetilebilir. Kibana user role'ları dashboard ihtiyacına göre minimum privilege ile sınırlandırılmalıdır.

5601 Portunu Doğrudan İnternete Açmamak

Kibana portu public internetten doğrudan erişilebilir olduğunda login yüzeyi ve potansiyel application vulnerability alanı genişler. Reverse proxy veya private network ek kontrol sağlar. Firewall 5601'e yalnız reverse proxy hostundan erişim verebilir. Kullanıcılar proxy'nin HTTPS domain'i üzerinden bağlanır. Internal portun public olmadığını external scan ile doğrulamak faydalıdır.

Nginx Reverse Proxy

Nginx Kibana önünde TLS termination ve access control katmanı olabilir. Proxy yalnız private Kibana endpoint'ine bağlantı kurar. Request header'ları doğru iletilmeli ve WebSocket davranışı test edilmelidir. Rate limit veya additional authentication gerekiyorsa burada uygulanabilir. Nginx logları da merkezi log platformuna gönderilerek Kibana erişimleri izlenebilir.

HTTPS

Browser ile reverse proxy arasındaki trafik HTTPS olmalıdır. Login credential ve dashboard data ağda açık taşınmamalıdır. TLS 1.2 veya kurum politikasına uygun modern protokoller kullanılabilir. Certificate expiration alert edilmelidir. Internal proxy ile Kibana arasındaki trafik de güvenlik ihtiyacına göre TLS kullanabilir.

Let's Encrypt

Public DNS üzerinde erişilebilen uygun sistemlerde otomatik certificate yönetimi için ACME tabanlı sertifika kullanılabilir. Challenge yöntemi network mimarisine göre seçilmelidir. Private-only Kibana için internal CA daha uygun olabilir. Certificate renewal otomatik test edilmelidir. Renewal başarısızlığının kullanıcı erişimini kesmemesi için expiration alarmı bulunmalıdır.

Firewall

Public firewall yalnız reverse proxy HTTPS portunu açabilir. Kibana 5601 internal network'te kalır. Elasticsearch 9200 de yalnız Kibana ve ingestion servislerine erişilebilir tutulur. Yönetim SSH erişimi ayrı kaynaklardan sınırlandırılır. Rule değişiklikleri infrastructure code üzerinden review edilmelidir.

IP Allowlist

Kurumsal ofis veya VPN çıkış IP'leri Kibana proxy üzerinde allowlist edilebilir. Bu yaklaşım login endpoint'inin internetten görülebilirliğini azaltır. Remote developer IP'leri sık değişiyorsa VPN kullanmak daha sürdürülebilirdir. Allowlist tek authentication yöntemi değildir. SSO ve role control yine uygulanmalıdır.

VPN

Kibana yalnız VPN private network'ünden erişilebilir hale getirilebilir. Böylece public DNS veya açık ingress gerekmeyebilir. VPN authentication MFA ile korunmalıdır. Emergency operations için bağlantı runbook'u test edilmelidir. VPN outage durumunda log platformuna erişimin incident sürecini nasıl etkilediği düşünülmelidir.

SSO

SSO user account lifecycle'ını merkezi identity provider ile yönetmeyi kolaylaştırır. Role mapping group membership üzerinden yapılabilir. Çalışan ayrıldığında ayrı Kibana password'u unutulmaz. Admin ve read-only user grupları ayrılmalıdır. Break-glass account güçlü koruma ve audit altında tutulmalıdır.

Nginx ile Kibana Reverse Proxy

Nginx reverse proxy kurulumu Kibana'yı kontrollü domain üzerinden sunmanın yaygın yöntemlerinden biridir. DNS önce proxy sunucusuna yönlendirilir ve proxy request'i private Kibana endpoint'ine aktarır. HTTPS certificate burada terminate edilebilir. Forwarded header'lar Kibana'nın gerçek protocol ve client bilgilerini doğru yorumlamasını sağlar. Configuration değişiklikleri nginx -t ile test edilmeden reload edilmemelidir.

Domain ve DNS

Kibana için örneğin logs.example.internal gibi anlamlı domain seçilebilir. Internal-only sistemlerde private DNS kullanılması public exposure'ı önler. TLS certificate domain ile eşleşmelidir. DNS TTL migration veya proxy değişim planına göre belirlenebilir. Aynı domain production ve staging cluster'larına yanlış yönlenmemelidir.

Nginx Kurulumu

Nginx Ubuntu package repository üzerinden kurulabilir. Security update'leri düzenli uygulanmalıdır. Default site kaldırılıp yalnız gerekli virtual host bırakılabilir. Service non-root worker process modeliyle çalışır ancak low port bind master process tarafından yönetilir. Configuration backup ve automation repository'sinde tutulmalıdır.

Proxy Pass

proxy_pass Kibana'nın private host ve portuna yönlendirme yapar. Backend endpoint localhost veya private network olabilir. Timeout değerleri ağır dashboard veya reporting request'lerini dikkate almalıdır. Upstream failure logları Nginx error log'da görünür. Birden fazla Kibana instance load balancing için upstream grubu kullanılabilir.

Forwarded Headers

X-Forwarded-Proto ve client IP header'ları proxy arkasındaki uygulamanın gerçek bağlantı bilgisini anlamasına yardımcı olur. Header'ların internetten gelen sahte değerlerle override edilmemesi için Nginx kontrollü şekilde set etmelidir. Audit loglarda gerçek client IP kullanılması incident analizini kolaylaştırır. TLS proxy'de terminate ediliyorsa protocol bilgisinin Kibana'ya doğru iletilmesi gerekir. Trusted proxy listesi açıkça tanımlanmalıdır.

WebSocket Desteği

Kibana bazı real-time veya development özelliklerinde bağlantı upgrade davranışına ihtiyaç duyabilir. Reverse proxy gerekli Upgrade ve Connection header'larını doğru yönetmelidir. Proxy timeout çok kısa tutulursa uzun bağlantılar kesilebilir. Configuration browser developer tools ve Kibana loglarıyla test edilmelidir. Her header'ı internetten olduğu gibi backend'e geçirmenin güvenli olmadığı unutulmamalıdır.

HTTPS

Nginx virtual host TLS certificate ve private key kullanmalıdır. HTTP request'leri HTTPS'e redirect edilebilir. HSTS yalnız domain'in tamamen HTTPS kullanılacağı doğrulandıktan sonra etkinleştirilmelidir. Cipher ve protocol policy kurum standardına göre belirlenir. Certificate private key yalnız Nginx service tarafından okunabilir olmalıdır.

Sertifika Yenileme

Certificate renewal otomatik olsa bile başarı durumu izlenmelidir. Expiration metric veya scheduled check alert üretmelidir. Renewal sonrasında Nginx reload yapılması gerekebilir. Yeni certificate'ın chain ve domain coverage'ı doğrulanmalıdır. Test environment renewal sürecini production'dan önce doğrulamak için kullanılabilir.

Kibana Kullanıcı ve Rol Yönetimi

Kibana kullanıcı yetkileri herkesin tüm loglara eriştiği model yerine iş ihtiyacına göre sınırlandırılmalıdır. Developer kendi servis loglarını okuyabilirken security ekibi audit dataset'lerine erişebilir. Dashboard viewer kullanıcısının index management veya user yönetimi yetkisine ihtiyacı yoktur. Built-in superuser günlük kullanıcı hesabı olarak kullanılmamalıdır. Spaces farklı ekiplerin dashboard ve saved object alanlarını organize etmeye yardımcı olabilir.

Built-In Users

Elastic Stack bazı sistem bileşenleri ve başlangıç yönetimi için built-in user'lar sağlar. Bu hesapların her biri farklı teknik amaç taşır. elastic superuser geniş yetkili olduğundan dashboard görüntüleme için kullanılmamalıdır. Kibana backend identity ile human user hesapları ayrılmalıdır. Password ve service credential rotation policy uygulanmalıdır.

Roles

Role cluster, index ve Kibana application privilege'larını bir araya getirir. Developer yalnız belirli logs-app-* data stream'lerini okuyabilir. Security admin farklı dataset ve management izinlerine sahip olabilir. Role isimleri ekip ve amaç bilgisini açıkça göstermelidir. Kullanılmayan role'lar periyodik access review sırasında kaldırılmalıdır.

Role Mappings

External identity provider group'ları Elasticsearch role'larına eşlenebilir. Böylece user yetkisi tek tek local account üzerinden yönetilmez. Group değişikliği login sonrasında yeni role'a yansıyabilir. Mapping rule çok geniş wildcard kullanmamalıdır. Production admin group membership ayrıca approval sürecine bağlanmalıdır.

Spaces

Kibana Spaces dashboard, visualization ve bazı feature varlıklarını ekip bazında ayırmaya yardımcı olur. Development ve security ekipleri kendi görünüm alanlarına sahip olabilir. Space data-level isolation değildir ve underlying index permission yine Elasticsearch role ile sağlanmalıdır. Saved object promotion environment'lar arasında export veya automation ile yapılabilir. Space naming standardı dashboard yönetimini kolaylaştırır.

Least Privilege

Her kullanıcı yalnız görevini yapacak minimum yetkiye sahip olmalıdır. Read-only dashboard kullanıcısına index delete izni verilmez. Agent API key yalnız hedef data stream'e write yetkisi alır. Admin yetkisi geçici yükseltme modeliyle yönetilebilir. Access review düzenli yapılarak eski ekip üyelerinin yetkileri temizlenmelidir.

Salt Okuma Dashboard Kullanıcısı

Salt okuma dashboard kullanıcısı belirli space ve data view'ları görüntüleyebilir. Saved object düzenleme ve management özellikleri kapatılabilir. Index tarafında yalnız read ve view metadata benzeri gerekli privilege'lar tanımlanır. Dashboard linki paylaşılsa bile kullanıcı başka index'leri sorgulayamamalıdır. Bu model operasyon ekranlarını geniş ekiplere güvenli şekilde açmayı kolaylaştırır.

Admin Hesabını Günlük Kullanımda Kullanmamak

Superuser ile günlük dashboard kullanmak yanlış tıklamanın etkisini büyütür. Normal kullanıcı hesabı read veya editor role ile çalışmalıdır. Yönetim gerektiğinde ayrı privileged account kullanılabilir. Böylece audit loglarda yönetim işlemleri normal sorgulardan ayrılır. Credential compromise durumunda da saldırganın doğrudan cluster-wide yetki elde etme riski azalır.

Ubuntu'ya Logstash Kurulumu

Logstash aynı Elastic 9.x APT repository üzerinden kurulabilir. Package installation sonrasında pipeline dosyaları ve system configuration ayrı path'lerde yönetilir. İlk production pipeline kurulmadan önce syntax validation yapılmalıdır. Logstash service Elasticsearch'e TLS ve minimum yetkili API key ile bağlanmalıdır. Persistent Queue ve DLQ gereksinimi default memory queue davranışıyla karşılaştırılarak ayrıca yapılandırılmalıdır.

Logstash Paketini Kurmak

Package version Elasticsearch ile aynı stack release politikasına göre seçilmelidir. Install sonrasında default pipeline configuration'ın production ihtiyaçlarına uygun olmadığı kabul edilmelidir. Plugin version'ları package ile gelen sürümle kaydedilebilir. Custom plugin yalnız zorunluysa eklenmeli ve upgrade compatibility test edilmelidir. Configuration repository üzerinden deploy edilmesi rollback işlemini kolaylaştırır.

sudo apt-get install logstash

systemd Servisini Başlatmak

Pipeline config validation tamamlandıktan sonra Logstash service başlatılabilir. Başlangıçta JVM ve plugin loading biraz zaman alabilir. Service active görünse bile pipeline output connection error yaşayabilir. Logstash monitoring API ve event throughput ayrıca izlenmelidir. Production host reboot davranışı için service enable yapılabilir.

Logstash Configuration Directory

Debian package configuration dosyalarını genellikle /etc/logstash altında tutar. Pipeline config conf.d veya pipelines.yml üzerinden organize edilebilir. Çok sayıda bağımsız pipeline ayrı dosya ve pipeline ID ile yönetilmelidir. Secret değer pipeline config içine düz metin yazılmamalıdır. Configuration syntax CI içinde production'a ulaşmadan test edilebilir.

Logstash Loglarını Kontrol Etmek

Logstash logları plugin connection, parsing ve pipeline restart sorunlarını gösterir. Sürekli _grokparsefailure gibi tag artışı application log formatının değiştiğini işaret edebilir. Elasticsearch output retry logları downstream problem göstergesidir. Debug seviyesini sürekli açık tutmak hem disk hem güvenlik maliyeti yaratabilir. Logstash'in kendi logları ayrı system dataset olarak merkezi platformda izlenebilir.

Pipeline Configuration Testi

Production service restart öncesinde configuration syntax doğrulanmalıdır. Logstash -t veya --config.test_and_exit benzeri test seçeneğiyle config parse edebilir. Syntax success event'in semantic olarak doğru işlendiğini garanti etmez. Sample event stdin ve rubydebug output üzerinden ayrıca test edilmelidir. CI test fixture'ları gerçek log formatı değişimlerinde regression yakalamaya yardımcı olur.

Logstash Pipeline Nasıl Çalışır?

Logstash pipeline üç temel aşamadan oluşur: input, filter ve output. Input event'i kaynaktan kabul eder, filter gerekli dönüşümleri uygular ve output event'i hedefe gönderir. Her event Ruby tabanlı Logstash event modelinde field ve metadata taşır. Plugin'ler bu aşamaların farklı protokol ve işlem türlerini destekler. Pipeline performansı yalnız worker sayısıyla değil parsing maliyeti, output latency ve queue davranışıyla birlikte değerlendirilmelidir.

Input

Input plugin event'in Logstash'e nasıl girdiğini belirler. Beats, Kafka, HTTP, TCP veya file input kullanılabilir. Her input'un acknowledgement ve backpressure davranışı farklıdır. Veri kaybı toleransı düşük sistemlerde protocol semantics anlaşılmalıdır. Input portları yalnız gerekli source network'lerden erişilebilir tutulmalıdır.

Filter

Filter event alanlarını parse, rename, remove veya enrich eder. Grok regex tabanlı extraction sağlarken Dissect sabit delimiter yapılarında daha düşük parsing maliyeti sunabilir. JSON filter structured payload'ı doğrudan field'lara açar. Date filter event timestamp'ini doğru @timestamp alanına çevirebilir. Filter zinciri sample event testleriyle doğrulanmalıdır.

Output

Output işlenmiş event'i Elasticsearch veya başka hedefe gönderir. Bir event koşula göre farklı output'lara yönlendirilebilir. Elasticsearch output TLS ve API key authentication kullanabilir. Output yavaşladığında pipeline queue dolabilir ve input'a backpressure oluşur. Delivery failure metric ve retry logları alert edilmelidir.

Event

Event Logstash pipeline içinde işlenen veri birimidir. Field değerleri nested object veya scalar olabilir. @metadata alanları output'a yazılmadan routing bilgisini taşımak için kullanılabilir. Event boyutu memory ve queue disk kullanımını etkiler. Gereksiz büyük payload filter aşamasında drop veya truncate edilmelidir.

Plugin

Plugin Logstash input, filter, output veya codec yeteneği ekler. Resmi desteklenen plugin sürümleri stack upgrade sırasında compatibility açısından kontrol edilmelidir. Community veya custom plugin kullanılıyorsa maintenance riski ayrıca değerlendirilir. Plugin failure tüm pipeline throughput'unu etkileyebilir. Kullanılmayan plugin'leri yalnız mevcut diye pipeline'a eklemekten kaçınılmalıdır.

Codec

Codec input veya output sırasında event'in serialization biçimini belirler. JSON codec structured payload'ı doğrudan event'e çevirebilir. Multiline codec bazı source türlerinde birden fazla satırı tek event olarak birleştirir. Multiline işlemini mümkün olduğunca source'a yakın collector'da yapmak interleaved event riskini azaltabilir. Codec seçimi log formatı sözleşmesiyle birlikte test edilmelidir.

Logstash Input Plugin'leri

Logstash farklı veri kaynakları için geniş input plugin ekosistemi sunar. Her input'un protocol, acknowledgement ve security özellikleri farklıdır. Beats input agent'lardan log kabul etmek için yaygınken Kafka input yüksek hacimli queue tabanlı mimaride kullanılır. TCP ve UDP kolay entegrasyon sağlasa da delivery garantileri application protocol'e göre daha zayıf olabilir. Production input tasarımında yalnız bağlantının kurulması değil veri kaybı ve backpressure davranışı da test edilmelidir.

Beats Input

Beats input Filebeat gibi shipper'lardan event kabul eder. Varsayılan örneklerde 5044 portu sık kullanılır. TLS certificate ve client verification ile güvenli taşıma sağlanabilir. Beats protocol acknowledgement sağladığı için Logstash Persistent Queue ile birlikte daha güçlü dayanıklılık elde edilebilir. Input connection ve event throughput monitoring API üzerinden izlenmelidir.

File Input

File input Logstash'in local filesystem üzerindeki dosyaları doğrudan okumasını sağlar. Küçük veya legacy sistemlerde kullanılabilir. Ancak her application hostunda Logstash çalıştırmak Filebeat'e göre daha ağır olabilir. File rotation ve sincedb state doğru yönetilmelidir. Remote network filesystem üzerinde log takip etmek reliability açısından dikkatle test edilmelidir.

Syslog Input

Syslog input network cihazı veya Linux service loglarını kabul edebilir. UDP kullanıldığında packet loss durumunda protocol-level retry bulunmaz. TCP daha güvenilir transport sağlar ancak sender behavior yine incelenmelidir. Syslog timestamp ve hostname parsing doğru timezone ile normalize edilmelidir. Internet-facing syslog listener yerine private collector network kullanılmalıdır.

HTTP Input

HTTP input uygulama veya webhook benzeri source'lardan POST ile event kabul edebilir. TLS ve authentication eklenmelidir. Request body JSON ise parsing daha sade olur. Retry behavior sender tarafından uygulanmalıdır. Endpoint rate limit ve request size sınırıyla korunmalıdır.

Kafka Input

Kafka input topic partition'larından event tüketir. Consumer group kullanımı horizontal Logstash scaling sağlar. Offset commit ve event processing semantics doğru anlaşılmalıdır. Persistent Queue Kafka'nın yerini almak zorunda değildir ancak Logstash restart sırasında kısa buffer sağlayabilir. Kafka lag pipeline sağlık metric'i olarak izlenmelidir.

TCP Input

TCP input stream tabanlı sender'lar için basit integration sağlar. TLS etkinleştirilebilir. Application framing ve newline davranışı doğru codec ile eşleşmelidir. Sender reconnect ve retry uygulamalıdır. Protocol acknowledgement sınırlıysa downstream failure durumunda tam delivery guarantee sağlandığı varsayılmamalıdır.

UDP Input

UDP düşük overhead sağlar ancak delivery veya ordering garantisi yoktur. Network congestion altında packet kaybı olabilir. Security ve audit loglarında kayıpsız taşıma isteniyorsa TCP veya acknowledgement destekli protocol daha uygundur. UDP input buffer ve OS socket ayarları yüksek EPS'de önem kazanır. Synthetic test ile gerçek loss rate ölçülebilir.

Logstash Filter Plugin'leri

Filter plugin'leri ham event'i aranabilir ve standardize edilmiş veri modeline dönüştürür. Parsing mümkün olduğunca basit ve deterministik tutulmalıdır. JSON zaten structured veri sağlıyorsa tekrar Grok uygulamak gereksizdir. Filter error tag'leri ayrı metric olarak izlenmelidir. ECS field isimleri yeni pipeline'larda ortak schema hedefi olarak kullanılabilir.

Grok

Grok regex tabanlı pattern'lerle plaintext mesajdan field çıkarır. Legacy web server veya application loglarında güçlüdür. Pattern çok genel yazılırsa CPU maliyeti ve yanlış match riski artar. Known prefix'ler önce Dissect ile ayrıştırılıp yalnız değişken bölüm Grok ile işlenebilir. _grokparsefailure oranı deployment sonrası alarm olarak izlenmelidir.

JSON

JSON filter message içindeki JSON payload'ı structured field'lara açabilir. Yeni application loglarında en tercih edilen ingestion modellerinden biridir. Application producer schema'yı kontrol ettiği için regex parsing ihtiyacı azalır. Invalid JSON event'ler ayrı tag veya DLQ benzeri akışta incelenebilir. Nested dynamic key sayısı mapping explosion riskine karşı sınırlandırılmalıdır.

Dissect

Dissect delimiter konumu belirli plaintext logları hızlı biçimde parçalar. Regex kullanmadığı için Grok'a göre daha düşük CPU maliyeti sağlayabilir. Log formatı sabit kolonlardan oluşuyorsa iyi seçimdir. Değişken formatlı bölüm ayrıca Grok ile işlenebilir. Format değişikliği sample test ile pipeline deployment öncesinde yakalanmalıdır.

Mutate

Mutate field rename, convert, remove veya replace gibi temel dönüşümler sağlar. Legacy field adlarını ECS alanlarına çevirmek için kullanılabilir. Gereksiz field'ları Elasticsearch'e göndermeden önce kaldırmak storage maliyetini azaltabilir. Type conversion mapping conflict oluşmasını önleyebilir. Mutate rule'ları okunabilir küçük bloklar halinde tutulmalıdır.

Date

Date filter log mesajındaki event zamanını @timestamp alanına parse eder. Ingestion zamanı ile gerçek olay zamanı farklı olabilir. Timezone açıkça belirtilmelidir. Parse failure event'in yanlış zaman aralığında görünmesine neden olabilir. Timestamp format değişiklikleri fixture test ile korunmalıdır.

GeoIP

GeoIP IP adresinden yaklaşık coğrafi metadata çıkarabilir. Security veya traffic dashboard'larında ülke ve bölge analizi için kullanılabilir. Kişisel veri ve privacy politikaları IP saklama süresini etkileyebilir. GeoIP database update mekanizması takip edilmelidir. Her internal IP için gereksiz lookup yapmak pipeline maliyetini artırabilir.

User Agent

User Agent filter browser ve device bilgilerini HTTP header'dan çıkarabilir. Web analytics veya client compatibility analizi için yararlıdır. User agent string yüksek cardinality oluşturabileceğinden hangi alanların indexleneceği seçilmelidir. Parsing CPU maliyeti yüksek trafik sistemlerinde ölçülmelidir. Privacy ve retention politikası client metadata'yı da kapsamalıdır.

Drop

Drop filter gereksiz event'in Elasticsearch'e gitmesini engeller. Health check access logları çok yüksek hacim oluşturuyorsa belirli koşulla drop edilebilir. Güvenlik için önemli event'lerin yanlışlıkla düşürülmemesi gerekir. Drop ratio metric olarak izlenmelidir. Kural değişikliği önce sample data üzerinde test edilmelidir.

Translate

Translate kod veya kısa değeri daha anlamlı metadata ile eşleyebilir. Örneğin internal service code human-readable service name'e dönüştürülebilir. Büyük dictionary memory ve reload davranışı açısından test edilmelidir. Lookup datası version control altında tutulabilir. Çok sık değişen enrichment verisi için external store veya ingest enrichment seçeneği daha uygun olabilir.

Grok Nedir?

Grok Logstash'in regex pattern kütüphanesini kullanarak structured olmayan metinden anlamlı field'lar çıkarma yöntemidir. Nginx access log veya eski application formatı gibi sabit metin şablonlarında kullanışlıdır. Pattern semantic isimler vererek IP, status ve response time alanlarını event'e çıkarabilir. Çok genel regex yüksek CPU tüketebilir ve yanlış event match'lerine neden olabilir. Yeni uygulamalarda producer tarafında JSON logging kullanmak mümkünse parsing yükünü azaltır.

Grok Pattern

Grok pattern hazır pattern parçalarını field isimleriyle birleştirir. %{IP:client.ip} benzeri ifade eşleşen IP değerini named field'a yazabilir. Pattern mümkün olduğunca log formatının başından anchor edilmelidir. Optional bölüm sayısı arttıkça test case ihtiyacı büyür. Pattern repository içinde fixture loglarla birlikte saklanmalıdır.

Structured Field Çıkarma

Plaintext mesajdaki status, method veya response time ayrı field'lara ayrıldığında Kibana query çok daha güçlü hale gelir. Numeric değerler doğru type'a convert edilmelidir. Timestamp date filter ile normalize edilebilir. Field isimleri ECS standardına yakın tutulmalıdır. Gereksiz raw duplicate alanlar storage ihtiyacına göre kaldırılabilir.

Syslog Parsing

Syslog formatında timestamp, host ve program adı Grok veya dedicated parser ile ayrıştırılabilir. RFC varyasyonları test edilmelidir. Timezone ve year eksikliği timestamp yorumunu etkileyebilir. Facility ve severity değerleri normalized field'lara çevrilebilir. Network cihazlarının vendor-specific message bölümü ayrı parser gerektirebilir.

Web Server Log Parsing

Access log method, URL, status ve response byte bilgisi taşır. Custom Nginx log formatı parser ile birebir eşleşmelidir. Request time numeric field olarak çıkarılırsa latency dashboard oluşturulabilir. User agent ve referrer ayrı alanlarda tutulabilir. Query string içinde token veya kişisel veri varsa ingestion öncesi redaction yapılmalıdır.

_grokparsefailure

Grok event'i pattern ile eşleştiremediğinde failure tag ekleyebilir. Bu oran pipeline health metric olarak izlenmelidir. Application deployment log formatını değiştirdiğinde failure sayısı bir anda artabilir. Failed sample'lar ayrı index yerine controlled debug stream'e kısa retention ile yönlendirilebilir. Sorun çözülmeden parse failure event'lerini sessizce drop etmek veri görünürlüğünü kaybettirir.

Custom Grok Pattern

Kuruma özgü log formatları custom Grok pattern gerektirebilir. Pattern adı generic değil domain anlamını taşımalıdır. Reusable pattern küçük parçalara bölünürse bakım kolaylaşır. Unit test fixture olumlu ve olumsuz örnekler içermelidir. Pattern değişikliği Logstash config deployment ile birlikte versionlanmalıdır.

Grok Performans Problemleri

Backtracking yapan karmaşık regex yüksek CPU tüketebilir. Çok sayıda alternatif pattern her event'te sırayla denendiğinde throughput düşebilir. İlk sabit kolonları Dissect ile ayırmak performansı iyileştirebilir. JSON producer formatına geçiş uzun vadeli çözüm olabilir. Pipeline worker sayısını artırmadan önce filter CPU profile incelenmelidir.

Grok mu JSON Logging mi?

Yeni uygulamalarda structured JSON logging çoğu durumda Grok parsing'den daha sağlamdır. Producer field'ları doğrudan belirlediği için parser regex format değişikliklerinden etkilenmez. JSON event schema yine kontrol edilmeli ve rastgele dynamic key üretimine izin verilmemelidir. Legacy uygulamalar değiştirilemiyorsa Grok veya Dissect değerli çözümdür. Migration sırasında eski plaintext ve yeni JSON event'ler ayrı pipeline veya conditional parser ile geçici olarak birlikte işlenebilir.

Plaintext Logların Dezavantajları

Plaintext mesaj insan için okunabilir olsa da makine tarafından field bazlı analiz edilmesi zordur. Aynı message formatındaki küçük punctuation değişikliği parser'ı bozabilir. Numeric değer type bilgisini kaybeder. Stack trace multiline handling gerektirir. Arama çoğunlukla expensive full-text query'lere bağımlı kalır.

Structured JSON Log

JSON log event field ve value yapısını açık biçimde taşır. Log level, service name ve request ID doğrudan ayrı field olabilir. Collector çoğu durumda message parse etmeden event'i aktarabilir. Schema version field eklemek backward compatibility yönetimini kolaylaştırır. Secret ve PII redaction producer katmanında uygulanabilir.

Parsing Maliyeti

Regex parsing CPU maliyeti event sayısı arttıkça belirgin hale gelir. JSON parse da maliyetsiz değildir ancak format deterministik olduğu için daha öngörülebilir davranır. Application zaten object modelinde log context oluşturuyorsa string formatlayıp tekrar parse etmek gereksiz işlemdir. Parsing throughput load test ile ölçülmelidir. Yüksek hacimli pipeline'da küçük CPU tasarrufu toplam node sayısını etkileyebilir.

Schema Tutarlılığı

Structured log producer'ların aynı field isimlerini kullanması gerekir. Bir servis request_id, diğeri requestId kullanırsa merkezi query zorlaşır. ECS ortak field sözleşmesi sağlayabilir. Custom alanlar organization namespace altında tutulabilir. Schema değişiklikleri application review sürecinin parçası olmalıdır.

Yeni Uygulamalarda JSON Logging Tercihi

Yeni projede logging library structured JSON output verecek şekilde ilk günden ayarlanabilir. Development console için human-readable formatter ayrı kullanılabilir. Production event tek satır JSON olursa collector multiline ihtiyacı azalır. Trace ve service metadata logger middleware tarafından otomatik eklenebilir. Bu yaklaşım Logstash filter zincirini önemli ölçüde sadeleştirir.

Legacy Uygulamalarda Grok

Legacy application source değiştirilemiyorsa Grok mevcut formatı structured hale getirir. Parser format version'a göre conditional çalışabilir. En sık kullanılan log örnekleri fixture olarak saklanmalıdır. Yeni release formatı değiştirdiğinde CI parser testleri failure üretmelidir. Uzun vadede application logging modernization planı oluşturulabilir.

Multiline Loglar Nasıl İşlenir?

Java stack trace veya Python traceback tek mantıksal event olmasına rağmen birden fazla satır içerir. Collector her satırı ayrı event gönderirse Kibana'da exception analizi çok zorlaşır. Multiline birleştirme mümkün olduğunca kaynağa yakın yapılmalıdır, çünkü merkezi Logstash'te farklı host event'lerinin birbirine karışma riski oluşabilir. Pattern başlangıç satırını veya devam satırını güvenilir biçimde tanımlamalıdır. Structured application logging stack trace'i tek JSON field içinde taşıyarak bu ihtiyacı büyük ölçüde azaltır.

Java Stack Trace

Java exception ilk satırda exception türü ve message, sonraki satırlarda stack frame üretir. Multiline parser yeni timestamp ile başlayan satırı yeni event kabul edebilir. Caused by ve nested exception satırları aynı event içinde kalmalıdır. Çok büyük stack trace event size limitlerini etkileyebilir. Structured logger exception object'ini JSON alanı olarak serialize ederse parsing daha güvenilir olur.

Python Traceback

Python traceback Traceback ile başlayıp exception satırıyla sonlanabilir. Web framework ek request log satırları formatı değiştirebilir. Multiline rule gerçek production örnekleriyle test edilmelidir. Traceback içindeki dosya path ve source line kişisel veya secret bilgi taşımamalıdır. Exception type ayrı field'a çıkarılırsa alert oluşturmak kolaylaşır.

Multiline Codec

Logstash multiline codec birden fazla satırı tek event halinde birleştirebilir. Ancak aynı input connection üzerinde birden fazla hostun event'leri karışıyorsa yanlış birleşme riski vardır. Bu nedenle Beats gibi multi-host input'ta multiline işlemini Filebeat tarafında yapmak genellikle daha güvenlidir. Codec buffer memory ve timeout ayarları kontrol edilmelidir. Testte concurrent log source senaryoları denenmelidir.

Filebeat Multiline

Filebeat log kaynağına yakın çalıştığı için hangi satırların aynı dosyadan geldiğini bilir. Timestamp pattern veya whitespace üzerinden continuation rule tanımlanabilir. Yanlış pattern birden fazla bağımsız event'i tek dev event'e dönüştürebilir. Max lines ve timeout sınırları güvenlik için kullanılabilir. Structured JSON log kullanıldığında multiline işlemi çoğu zaman gereksiz hale gelir.

Event'lerin Yanlış Birleştirilmesini Önlemek

Multiline başlangıç pattern'i olabildiğince kesin tanımlanmalıdır. Generic whitespace kuralı application message'larını yanlış birleştirebilir. Fixture set farklı exception ve normal log örnekleri içermelidir. Maximum event size ve line count sınırı runaway buffer'ı önler. Multiline failure oranı monitoring ile görülebilir hale getirilmelidir.

Logstash Output Plugin'leri

Output plugin event'in pipeline sonrasında hangi sisteme gönderileceğini belirler. Elasticsearch merkezi log storage için temel hedef olsa da Kafka veya S3 gibi farklı output'lar arşiv ve buffering modellerinde kullanılabilir. Bir event birden fazla output'a gönderildiğinde delivery semantics ve duplicate davranışı düşünülmelidir. Conditional routing environment veya event type bazında farklı data stream seçebilir. Output failure queue ve backpressure üzerinde doğrudan etki oluşturur.

Elasticsearch

Elasticsearch output bulk indexing kullanarak event'leri cluster'a gönderir. Data stream kullanımı modern log storage modeline uygundur. API key yalnız gerekli data stream write izinlerine sahip olmalıdır. HTTPS CA verification açık tutulmalıdır. Bulk failure ve retry metric'leri pipeline health kapsamında izlenmelidir.

Kafka

Kafka output Logstash'ten event'i başka consumer'lar için durable stream'e aktarabilir. Analytics ve security ekipleri aynı topic'ten bağımsız tüketim yapabilir. Partition key ordering ihtiyacına göre belirlenmelidir. Producer acknowledgement ve retry ayarları veri kaybı toleransına göre seçilir. Kafka ekosisteminin kendisi ayrıca monitoring ve capacity gerektirir.

File

File output debug veya geçici local archive için kullanılabilir. Production primary backup yöntemi olarak Elasticsearch data'nın file output kopyasına güvenilmemelidir. Disk rotation ve capacity sınırı belirlenmelidir. Hassas logların local filesystem permission'ı sıkı olmalıdır. Debug file output test sonrasında kapatılmalıdır.

S3

Object storage output uzun vadeli raw log arşivi için kullanılabilir. Elasticsearch retention kısa tutulurken compliance raw archive daha uzun saklanabilir. Object encryption ve lifecycle policy uygulanmalıdır. Restore veya replay prosedürü önceden test edilmelidir. Raw log içinde PII varsa storage access policy aynı hassasiyeti taşımalıdır.

Birden Fazla Output

Aynı event Elasticsearch ve archive output'a gönderilebilir. Ancak output'lardan biri yavaşsa pipeline behavior test edilmelidir. Bir hedef başarısızken diğerinin ilerlemesi plugin semantics'e bağlı olabilir. Duplicate delivery downstream sistemlerde idempotency gerektirebilir. Kritik sistemlerde ayrı pipeline veya queue ile output'ları izolasyonlu tutmak daha sağlıklı olabilir.

Conditional Output

Event field veya tag'e göre farklı data stream seçilebilir. Security logları ayrı retention ve access policy'ye yönlendirilebilir. Conditional expression error'ları DLQ tarafından bazı durumlarda yakalanabilir. Rule'lar çok dallandıkça test ve bakım zorlaşır. Routing mümkün olduğunca ECS event.dataset ve namespace gibi standart alanlara dayanmalıdır.

Logstash Configuration Nasıl Test Edilir?

Logstash configuration production'a doğrudan kopyalanmamalıdır. Önce syntax validation, ardından sample event processing testi yapılmalıdır. stdout ve rubydebug parsed event'in beklenen field'ları üretip üretmediğini açıkça gösterir. Staging pipeline gerçek Elasticsearch mapping ve certificate yapılandırmasıyla integration test çalıştırmalıdır. Config reload kullanılacaksa incomplete file deploy anında pipeline'ın yanlış configuration okumaması için atomic deployment yöntemi seçilmelidir.

Syntax Validation

Syntax validation missing brace, plugin option veya parse error'larını service restart öncesinde yakalar. CI pipeline her configuration commit'inde bu testi çalıştırabilir. Plugin connection henüz kurulmadığı için syntax success full integration success anlamına gelmez. Custom environment variable'lar test ortamında dummy değerle sağlanmalıdır. Validation exit code build gate olarak kullanılabilir.

stdout + rubydebug

rubydebug event'in nested field yapısını okunabilir biçimde gösterir. Grok sonucu doğru field type üretiliyor mu hızlıca anlaşılır. Test output production'da sürekli açık bırakılmamalıdır. Secret veya PII sample event içinde bulunmamalıdır. Expected output fixture ile otomatik karşılaştırma daha güçlü regression testi sağlar.

Sample Event Testi

Gerçek log formatından anonimleştirilmiş sample set hazırlanmalıdır. Normal event yanında exception ve edge case örnekleri bulunmalıdır. Parser tüm örneklerde aynı schema'yı üretmelidir. Invalid event'in nasıl tag veya DLQ akışına girdiği de test edilir. Application ekipleri log formatını değiştirdiğinde fixture update etmek zorunda olmalıdır.

Production'a Almadan Önce Staging

Staging Elasticsearch production'a yakın mapping ve lifecycle kullanmalıdır. Yeni Logstash pipeline küçük sample trafik üzerinde çalıştırılabilir. Parse failure, throughput ve indexing error metric'leri incelenir. TLS certificate ve API key permission problemi production öncesinde görülür. Rollback için previous config artifact saklanmalıdır.

Pipeline Reload

Logstash configuration reload service restart ihtiyacını azaltabilir. Ancak config file yarım yazılırken reload tetiklenirse hata oluşabilir. Deployment önce yeni dosyayı temporary path'e yazıp validation sonrası atomic replace yapabilir. Reload failure monitoring'e alarm olarak düşmelidir. Büyük filter değişikliklerinde kontrollü rolling restart daha öngörülebilir olabilir.

Logstash Persistent Queue Nedir?

Persistent Queue Logstash'in in-flight event queue'sunu memory yerine local disk üzerinde saklamasına yardımcı olur. Elastic'in güncel dokümantasyonuna göre Persistent Queue varsayılan olarak kapalıdır ve queue.type: persisted ile etkinleştirilir. Queue abnormal termination sonrasında event'lerin yeniden işlenmesini sağlayabilir ve kısa trafik patlamalarını buffer edebilir. Buna rağmen local disk failure veya host kaybına karşı replication sağlamaz. Queue kapasitesi ve checkpoint ayarları durability ile performance arasında bilinçli denge gerektirir.

In-Memory Queue

Default Logstash queue memory üzerinde çalışır. Process crash veya host failure sırasında memory'deki event'ler kaybolabilir. Düşük kritik test pipeline'ında bu kabul edilebilir olabilir. Input protocol kendi retry ve acknowledgement davranışına sahipse risk kısmen azalır. Production delivery SLO'su queue seçimini belirlemelidir.

Persistent Queue

Persistent Queue event'leri disk page'lerinde saklar. Logstash restart sonrasında ACK edilmemiş event'leri yeniden processing için okuyabilir. Duplicate processing mümkün olduğundan downstream idempotency düşünülmelidir. Local filesystem kullanılması önerilir ve NFS desteklenmez. Queue disk kapasitesi log volume burst senaryosuna göre hesaplanmalıdır.

Disk Üzerinde Buffer

Elasticsearch kısa süre unavailable olduğunda Persistent Queue event kabul etmeye devam edebilir. Queue dolduğunda backpressure input'a kadar ilerler. Buffer süresi queue.max_bytes, event boyutu ve ingestion rate ile ilgilidir. Örneğin 100 MB/dakika akışta 10 GB queue teorik olarak yüz dakika civarı raw buffer sağlar ancak serialization overhead hesaba katılmalıdır. Disk alert queue kapasitesiyle birlikte tasarlanmalıdır.

Logstash Restart Durumu

Controlled veya abnormal restart sonrasında disk queue'daki unacknowledged event'ler yeniden işlenebilir. Output'a gitmiş fakat ACK checkpoint'e yazılmamış event duplicate olabilir. Consumer sistem duplicate'i tolere etmelidir. Restart öncesi queue drain seçeneği maintenance senaryolarında kullanılabilir. Uzun queue drain deployment süresini artırabileceği için capacity planına dahil edilmelidir.

Backpressure

Output processing input hızından düşük olduğunda queue dolmaya başlar. Queue limitine ulaşıldığında Logstash input plugin'e göre yeni event kabulünü yavaşlatabilir. Beats input bağlantıları bekleyebilir ve collector kendi queue'sunda buffering yapabilir. UDP gibi acknowledgement sunmayan protocol'larda backpressure veri kaybı riskini çözmez. End-to-end pipeline design her transport katmanının davranışını dikkate almalıdır.

queue.max_bytes

queue.max_bytes her pipeline persistent queue kapasitesini belirler. Elastic'in güncel setting referansında default değer 1024 MB olarak belirtilmektedir. Değer toplam host diskinden bağımsız düşünülmemelidir, çünkü her pipeline kendi kapasitesine sahip olabilir. Diskte queue için yeterli alan ve watermark bırakılmalıdır. Queue usage monitoring alert üretmelidir.

Durability ve Performance Trade-Off

Checkpoint daha sık yapılırsa crash sırasında kaybedilebilecek event sayısı azalabilir ancak disk fsync maliyeti artar. Elastic dokümantasyonu queue.checkpoint.writes: 1 değerinin maksimum durability sağlayabildiğini fakat performance'i ciddi biçimde etkileyebileceğini belirtir. Default değer çoğu workload için daha dengeli başlangıç sunar. Kritik audit pipeline ayrı durability profili kullanabilir. Değişiklik gerçek disk üzerinde benchmark edilmelidir.

Dead Letter Queue Nedir?

Dead Letter Queue işlenemeyen bazı event'leri geçici olarak disk üzerinde saklamaya yarar. Elastic'in güncel Logstash dokümantasyonuna göre DLQ özellikle Elasticsearch output'taki belirli document-level indexing hataları ve conditional evaluation error'ları için kullanılabilir. DLQ varsayılan olarak kapalıdır ve ayrıca etkinleştirilmelidir. Event DLQ'ya girdiğinde problem çözülmüş sayılmaz, queue izlenmeli ve event'ler düzeltilerek yeniden işlenmelidir. Boyut limiti dolduğunda hangi event'in drop edileceği policy ile belirlenebilir.

İşlenemeyen Event'ler

Mapping type conflict gibi event-level error Elasticsearch bulk request içinde belirli document'in reddedilmesine neden olabilir. DLQ etkinse uygun failure event'i metadata ile birlikte saklanabilir. Böylece ana pipeline diğer event'leri işlemeye devam eder. Problemli event'in original data ve failure reason bilgisi analiz edilebilir. Correction pipeline event'i yeni schema ile yeniden gönderebilir.

Mapping Errors

Bir field bazen number bazen string gelirse Elasticsearch mapping conflict oluşturabilir. Producer schema validation bu sorunu kaynağında önlemelidir. DLQ son savunma olarak failed event'i saklayabilir. Mapping'i her farklı value için dynamic şekilde değiştirmek doğru çözüm değildir. Event producer ve index template birlikte düzeltilmelidir.

DLQ'yu Etkinleştirmek

Logstash settings dosyasında dead_letter_queue.enable: true ile DLQ açılabilir. Her pipeline için ayrı DLQ directory oluşabilir. Storage local filesystem üzerinde tutulmalıdır. Permission ve disk capacity ayarları service user ile uyumlu olmalıdır. Enable sonrasında synthetic mapping failure ile gerçekten event yazıldığı test edilmelidir.

DLQ Boyutunu İzlemek

DLQ büyümesi sessiz data quality problemidir. Elastic node stats API pipeline bazında queue size bilgisini sağlayabilir. Threshold yalnız byte değil growth rate üzerinden de alert üretebilir. Sudden increase yeni application deployment veya mapping değişikliğine işaret edebilir. DLQ cleanup yapılmadan önce event'lerin işlenip işlenmediği doğrulanmalıdır.

DLQ Event'lerini Yeniden İşlemek

Logstash dead_letter_queue input plugin ile DLQ event'lerini okuyabilir. Correction filter problemli field'ı dönüştürebilir veya yeni index'e yönlendirebilir. Reprocessing duplicate oluşturmaması için document ID stratejisi değerlendirilebilir. Successful processing sonrasında consumed segment cleanup seçeneği kullanılabilir. Root cause producer tarafında çözülmezse yeni event'ler tekrar DLQ'ya düşmeye devam eder.

DLQ'yu Unutmamanın Önemi

DLQ'yu etkinleştirmek tek başına veri güvenliği sağlamaz. Queue dolarsa yeni failed event'ler policy'ye göre kaybedilebilir. DLQ size ve age alert'leri dashboard'da görünür olmalıdır. Incident ownership hangi ekibin event schema hatasını düzelteceğini belirlemelidir. Weekly review bile hiç izlenmeyen DLQ'dan çok daha değerlidir.

Log Kaybı Nasıl Önlenir?

Log kaybını önlemek tek bir queue özelliğiyle çözülemez. Source, collector, transport, Logstash, Elasticsearch ve snapshot katmanlarının her birinin failure davranışı bilinmelidir. Acknowledgement destekli protocol event'in sonraki katmana ulaştığını doğrulayabilir. Persistent Queue veya Kafka geçici downstream kesintilerinde buffer sağlar. End-to-end synthetic event ve count reconciliation gerçek delivery seviyesinin ölçülmesini sağlar.

Acknowledgement

Sender event'in receiver tarafından kabul edildiğini bilmelidir. Beats protocol acknowledgement bu konuda UDP'den daha güçlüdür. Ancak receiver'ın ACK vermesi event'in Elasticsearch'e kalıcı yazıldığı anlamına gelmeyebilir. Pipeline'ın her hop'undaki semantics ayrı değerlendirilmelidir. Audit sistemlerinde delivery guarantee business requirement olarak açıkça tanımlanmalıdır.

Persistent Queue

Persistent Queue Logstash process restart sırasında event'leri korumaya yardımcı olur. Local disk failure'a karşı replication sağlamaz. Queue checkpoint ayarı durability seviyesini etkiler. Queue dolarsa upstream backpressure oluşur. Monitoring queue depth'i sürekli takip etmelidir.

Filebeat Registry

Filebeat hangi dosyanın hangi offset'ine kadar okunduğunu local state içinde takip eder. Restart sonrasında kaldığı konumdan devam edebilir. Registry storage kaybolursa duplicate veya skipped data riski configuration'a göre oluşabilir. Log rotation davranışı doğru input ile yönetilmelidir. Container ephemeral filesystem içinde registry tutuluyorsa persistent state ihtiyacı değerlendirilmelidir.

Kafka Buffer

Kafka log pipeline'a replicated durable buffer ekleyebilir. Elasticsearch uzun süre unavailable olsa bile event'ler Kafka retention süresince tutulabilir. Consumer lag backlog miktarını görünür kılar. Replay data recovery ve reindex senaryolarında değerlidir. Kafka'nın kendi replication ve disk capacity sorunları ayrıca işletilmelidir.

Retry

Collector ve output temporary connection failure'da retry yapmalıdır. Retry exponential backoff kullanarak downstream service'i daha fazla zorlamamalıdır. Permanent mapping error sonsuz retry yerine DLQ gibi farklı yol gerektirir. Maximum retry veya queue retention data loss SLO ile uyumlu olmalıdır. Retry metric'leri alert edilmeli ve yalnız log satırlarında gizli kalmamalıdır.

Backpressure

Downstream yavaşladığında upstream üretim hızı kontrol altına alınmalıdır. Queue kapasitesi sınırsız değildir. Beats input backpressure ile connection kabulünü yavaşlatabilir. Application log dosyası büyümeye devam ediyorsa host disk capacity ayrıca risk olur. Pipeline tasarımı bütün buffer noktalarını tek kapasite modeli içinde ele almalıdır.

DLQ

DLQ permanent event-level processing hatalarını kaybetmeden incelemeye yardımcı olur. Network outage gibi bulk request failure'ları DLQ ile çözülmez ve retry mekanizmasına bağlıdır. Mapping error'lar için DLQ faydalıdır. Queue size ve age izlenmelidir. Reprocess ve cleanup runbook'u bulunmalıdır.

End-to-End Delivery Kontrolü

Kaynak belirli sequence ID veya synthetic heartbeat event üretebilir. Elasticsearch'te beklenen event görülüyor mu otomatik kontrol edilir. Source count ile indexed count periyodik karşılaştırılabilir. Ingestion latency percentile SLO olarak tutulabilir. Böylece pipeline çalışıyor görünse bile sessiz veri kaybı erken fark edilir.

Filebeat Kurulumu

Filebeat host üzerinde log dosyalarını okuyup Elasticsearch veya Logstash'e gönderen hafif shipper'dır. Existing deployment'larda hala etkili ve olgun çözümdür. Yeni büyük kurulumlarda Elastic Agent seçeneği ayrıca değerlendirilmelidir. Filebeat service başlamadan önce config syntax ve output connection test edilmelidir. TLS certificate ve credential minimum yetkiyle yapılandırılmalıdır.

Filebeat Nedir?

Filebeat dosya ve belirli integration loglarını takip eder. Harvester süreçleri kaynak dosyaları okur ve event'leri internal queue üzerinden output'a yollar. Registry state restart sonrasında offset devamlılığı sağlar. Module'ler yaygın servisler için parsing ve dashboard varlıklarını kolaylaştırabilir. Filebeat full transformation engine olarak Logstash'in yerini almak zorunda değildir.

Ubuntu'ya Filebeat Kurmak

Aynı Elastic 9.x repository üzerinden Filebeat package kurulabilir. Package version Elasticsearch ile mümkün olduğunca aynı stack sürümünde seçilmelidir. Installation sonrasında service hemen production output'a gönderilmeden configuration test edilmelidir. File permission log dosyalarını okuyacak şekilde düzenlenir ancak gereksiz root erişimi verilmez. Upgrade canary host üzerinde denenebilir.

filebeat.yml

filebeat.yml input, processor, module ve output davranışını tanımlar. Secret değerler plain YAML yerine keystore veya deployment secret sistemiyle sağlanabilir. Configuration file permission'ı sıkı olmalıdır. Birden fazla environment aynı template'ten farklı variables ile üretilebilir. Changes code review ve syntax testinden geçmelidir.

Input

Input hangi log dosyası veya source'un okunacağını belirler. Path wildcard rotation davranışını doğru yakalamalıdır. Multiline rule source formatına göre input seviyesinde uygulanabilir. Gereksiz dosyaları broad wildcard ile okumak ingestion maliyetini artırır. Input dataset ve service metadata ekleyerek downstream routing'i kolaylaştırabilir.

Output

Filebeat Elasticsearch veya Logstash output kullanabilir. İki output aynı anda standart Filebeat configuration'da aktif edilmez ve routing ihtiyacı farklı yöntem gerektirebilir. Elasticsearch output TLS CA ve API key ile korunmalıdır. Logstash output 5044 endpoint'ine secure connection kurabilir. Output test komutu production başlamadan connectivity doğrular.

Filebeat Servisini Başlatmak

Config test ve output test başarılı olduktan sonra service başlatılabilir. Initial registry yeni olduğunda mevcut dosyanın ne kadarının okunacağı input ayarına bağlıdır. Backfill istenmiyorsa başlangıç davranışı önceden test edilmelidir. Service systemd tarafından otomatik başlatılabilir. Agent health ve event rate monitoring'e eklenmelidir.

Filebeat Configuration Testi

filebeat test config YAML syntax ve configuration parse işlemini doğrulayabilir. Environment variable veya keystore value eksikse test sırasında hata görülebilir. Syntax success file path permission veya output connectivity başarısını garanti etmez. CI packaged config üzerinde bu testi çalıştırabilir. Production rollout yalnız validation sonrası yapılmalıdır.

Output Connection Testi

filebeat test output configured output'a bağlantıyı doğrular. TLS certificate trust, DNS ve authentication problemi erken görülür. Test superuser credential ile değil production'da kullanılacak gerçek least privilege identity ile yapılmalıdır. Success sonrasında sample event'in Elasticsearch'te göründüğü de kontrol edilmelidir. Network policy değişiklikleri sonrası test automation yeniden çalıştırılabilir.

Filebeat ile Linux Sistem Loglarını Toplamak

Linux syslog ve authentication logları host sağlığı ile güvenlik olayları için temel veri kaynaklarıdır. Filebeat System module veya güncel integration yapıları bu logları parse edip ECS alanlarına dönüştürebilir. Distribution'a göre log path ve journald kullanımı değişebilir. Hazır ingest pipeline ve Kibana dashboard başlangıç görünürlüğünü hızlandırır. Production'da hangi log kategorisinin retention ve erişim politikası gerektirdiği ayrıca belirlenmelidir.

Syslog

Syslog service ve kernel olaylarını içerir. Ubuntu sürümüne göre rsyslog dosyaları veya systemd journal kaynak olarak kullanılabilir. Facility, severity ve process metadata parse edilmelidir. Timezone normalize edilerek @timestamp oluşturulur. Çok gürültülü service'ler ayrı dataset veya filter policy ile yönetilebilir.

Auth Logları

Authentication logları SSH girişleri, sudo işlemleri ve bazı PAM olaylarını içerir. Security ekibi başarısız login ve olağan dışı privilege yükseltme davranışını buradan inceleyebilir. Username kişisel veri politikası kapsamında değerlendirilebilir. Retention normal application debug logundan daha uzun olabilir. Alert threshold brute force davranışına göre oluşturulabilir.

System Module

Filebeat System module yaygın Linux log formatları için input ve parsing configuration sağlar. Manual Grok yazma ihtiyacını azaltır. Module asset'leri Elasticsearch ingest pipeline ve Kibana dashboard kurabilir. Distribution log path'i module default'undan farklıysa override edilmelidir. Upgrade öncesinde module field değişiklikleri staging'de kontrol edilmelidir.

Filebeat Modules

Module'ler Nginx veya system gibi belirli source'lar için hazır configuration sağlar. Parser ve dashboard birlikte gelmesi hızlı başlangıç avantajıdır. Custom log format kullanılıyorsa default pipeline tam eşleşmeyebilir. Module output field'ları ECS ile uyumlu olacak şekilde tasarlanmıştır. Yeni deployment'larda aynı functionality'nin Elastic Agent integration karşılığı da değerlendirilmelidir.

Ingest Pipelines

Module setup Elasticsearch ingest pipeline oluşturabilir. Event Elasticsearch'e geldiğinde processor'lar parsing ve enrichment yapar. Böylece Logstash gerekmeden structured data elde edilebilir. Ingest node CPU kullanımı indexing cluster üzerinde ek yük oluşturur. Ağır parsing workload'unda Logstash'e ayırmak daha dengeli olabilir.

Hazır Kibana Dashboard'ları

Hazır dashboard ilk gün görünürlük sağlar. Authentication failure, host ve process dağılımı gibi temel görseller bulunabilir. Production ekibi dashboard'u kendi SLO ve incident ihtiyaçlarına göre özelleştirmelidir. Dashboard field'ları integration version ile uyumlu olmalıdır. Custom değişiklikler export edilip source control'de saklanabilir.

Filebeat Logstash'e Nasıl Bağlanır?

Filebeat Logstash'e gönderim yapacaksa Elasticsearch output devre dışı bırakılır ve Logstash output tanımlanır. 5044 portu yaygın Beats input portudur. TLS certificate validation iki taraf arasında açık tutulmalıdır. Filebeat collector Logstash server certificate'ını güvenilir CA üzerinden doğrular. Logstash unavailable olduğunda Filebeat retry ve internal queue davranışı host disk büyümesiyle birlikte izlenmelidir.

output.elasticsearch'i Kapatmak

Filebeat aynı configuration'da hangi output'un aktif olduğunu açıkça göstermelidir. Elasticsearch output comment veya remove edilerek Logstash output kullanılır. Yanlışlıkla iki farklı environment config merge edilmemelidir. Output değişikliği config testinden geçmelidir. Existing direct Elasticsearch pipeline migration sırasında duplicate log oluşmadığı kontrol edilmelidir.

output.logstash

Logstash output bir veya birden fazla host tanımlayabilir. Load balancing veya failover ihtiyacı topology'ye göre seçilir. TLS CA path ve certificate name validation yapılmalıdır. Filebeat metadata Logstash routing için kullanılabilir. Connection ve publish failure metric'leri agent monitoring'de izlenmelidir.

Port 5044

5044 standart zorunlu port değildir ancak Beats input örneklerinde yaygın kullanılır. Firewall yalnız Filebeat source network'lerine izin vermelidir. Port public internetten erişilebilir olmamalıdır. Load balancer kullanılıyorsa TCP ve TLS pass-through davranışı doğru yapılandırılmalıdır. Port availability yalnız telnet ile değil TLS handshake ve actual output test ile doğrulanmalıdır.

TLS

Filebeat ile Logstash arasındaki trafik application logları ve bazen hassas metadata taşır. TLS bu veriyi network üzerinde korur. Logstash server certificate trusted CA tarafından imzalanmalıdır. Private CA Filebeat hostlarına güvenli distribution ile taşınabilir. Certificate rotation kesintisiz geçiş için overlap dönemiyle planlanabilir.

Certificate Validation

Filebeat server certificate'ın CA zinciri ve hostname bilgisini doğrulamalıdır. Verification'ı kapatmak test kolaylığı sağlar gibi görünse de impersonation riskini artırır. DNS name certificate SAN alanıyla eşleşmelidir. Internal load balancer kullanılıyorsa certificate load balancer hostname'ini kapsamalıdır. Expiration alert agent bağlantısı kesilmeden önce uyarı üretmelidir.

Connection Test

Filebeat output test komutu Logstash connectivity ve TLS handshake'i doğrulayabilir. Test configuration gerçek production certificate ve host değerini kullanmalıdır. Success sonrasında Logstash input event counter artışı görülmelidir. Sample event Elasticsearch'e ulaşana kadar end-to-end kontrol tamamlanmış sayılmaz. Firewall veya certificate değişikliklerinden sonra synthetic test otomatik çalıştırılabilir.

Filebeat mi Elastic Agent mı?

Filebeat ve Elastic Agent arasında seçim mevcut operasyon modeline göre yapılmalıdır. Filebeat tek amaçlı log shipper olarak basit ve olgun configuration sunar. Elastic Agent Fleet ile merkezi policy, integration ve remote lifecycle yönetimi sağlar. Elastic'in güncel dokümantasyonu Agent'ın uygun feature desteği bulunduğunda Beats'ten daha merkezi yönetim sunduğunu belirtmektedir. Mevcut Filebeat kurulumunu aceleyle değiştirmek yerine integration ve output compatibility kontrol edilerek kademeli migration yapılmalıdır.

Tek Amaçlı Shipper

Filebeat log shipping görevine odaklanır. Configuration file küçük ve anlaşılır tutulabilir. Host automation mevcutsa ek Fleet Server altyapısı gerekmez. Kaynak tüketimi düşük olabilir. Tek ihtiyacın file log collection olduğu küçük sistemlerde bu sadelik gerçek avantajdır.

Tek Birleşik Agent

Elastic Agent aynı host üzerinde log, metric ve başka telemetry integration'larını tek deployment modeliyle yönetebilir. Birden fazla Beat process yerine tek agent policy yaklaşımı kullanılır. Fleet integration asset'lerini merkezi olarak dağıtabilir. Host inventory ve health tek arayüzde görülebilir. Feature ihtiyaçları Agent capability tablosuyla doğrulanmalıdır.

Fleet ile Merkezi Yönetim

Fleet agent policy oluşturmayı ve hostlara dağıtmayı kolaylaştırır. Policy değişikliği tek merkezden uygulanır. Agent status ve version görünür hale gelir. Çok sayıda sunucuda configuration drift azalır. Fleet Server'ın kendisi production availability ve TLS gerektiren yeni infrastructure bileşeni olarak yönetilmelidir.

Merkezi Policy

Agent policy hangi integration'ların ve ayarların kullanılacağını belirler. Development, production ve security host grupları ayrı policy alabilir. Policy update rollout öncesi test grubu üzerinde denenebilir. Secret veya API key Fleet tarafından uygun mekanizmalarla yönetilmelidir. Çok büyük global policy yerine workload'a göre anlamlı policy grupları tercih edilmelidir.

Remote Upgrade

Fleet belirli Agent deployment'larında remote binary upgrade işlevi sunabilir. Bu özellik yüzlerce hostta manual package işlemini azaltır. Upgrade bir anda tüm hostlara uygulanmak yerine canary ve batch planıyla yürütülmelidir. Integration compatibility ve host OS support kontrol edilmelidir. Upgrade failure durumunda agent health alarm üretmelidir.

API Key Yönetimi

Elastic Agent enrollment ve data output için API key tabanlı yetkilendirmeler kullanabilir. Her agent'a superuser password dağıtmak gerekmez. Key minimum policy kapsamına göre oluşturulabilir. Host compromise durumunda ilgili agent credential revoke edilebilir. Key lifecycle ve Fleet Server erişim politikası audit edilmelidir.

Hangi Durumda Filebeat Kullanılmalı?

Mevcut Filebeat deployment stabil ve ihtiyaç duyulan bütün input ile processor özelliklerini karşılıyorsa kullanmaya devam edilebilir. Küçük host sayısında config management zaten varsa Fleet eklemek gereksiz olabilir. Custom Filebeat behavior Agent tarafından henüz desteklenmiyorsa migration bekletilebilir. Tek log source olan basit appliance sistemlerinde Filebeat anlaşılır çözümdür. Yeni feature ihtiyacında Agent capability yeniden değerlendirilebilir.

Hangi Durumda Elastic Agent Kullanılmalı?

Çok sayıda hostta merkezi policy ve health visibility isteniyorsa Elastic Agent güçlü adaydır. Log, metric ve güvenlik integration'larını tek lifecycle altında toplamak yönetimi kolaylaştırabilir. Fleet integration paketleri hazır ingest pipeline ve dashboard sunabilir. Yeni deployment'ta ihtiyaç duyulan bütün integrations GA ve output'lar destekleniyorsa Agent tercih edilebilir. Migration öncesi existing dashboard ve field farklılıkları test edilmelidir.

Fleet Nedir?

Fleet Elastic Agent'ların merkezi yönetim katmanıdır. Kibana içinden agent policy oluşturulabilir, integration eklenebilir ve host enrollment yapılabilir. Fleet Server agent'lar ile Elasticsearch arasındaki yönetim iletişimini koordine eder. Production Fleet Server yüksek availability ve güvenilir TLS endpoint'i olarak tasarlanmalıdır. Policy değişikliği geniş host grubuna dağıtıldığı için access control ve change review kritik önem taşır.

Fleet Server

Fleet Server agent'ların policy ve lifecycle yönetimi için merkezi service görevi görür. Self-managed deployment'ta ayrıca kurulması gerekir. Birden fazla instance load balancer arkasında kullanılabilir. TLS certificate ve Elasticsearch output credential'ı güvenli tutulmalıdır. Fleet Server downtime agent'ların mevcut policy ile veri toplamayı bir süre sürdürebilmesine rağmen yönetim işlevlerini etkileyebilir.

Elastic Agent

Elastic Agent host üzerinde çalışır ve assigned policy'ye göre integration input'larını başlatır. Log ve metric verilerini configured output'a gönderir. Fleet'e periyodik check-in yaparak health ve policy state bildirir. Agent hostta yüksek yetki gerektiren integration kullanıyorsa permission kapsamı açıkça bilinmelidir. Tamper protection veya endpoint özellikleri kullanılan sistemlerde upgrade prosedürü ayrıca test edilmelidir.

Agent Policy

Agent Policy integration ve output davranışlarının ortak şablonudur. Aynı role sahip yüzlerce host tek policy kullanabilir. Production web server ve database server ayrı policy alabilir. Değişiklik tüm bağlı agent'ları etkileyebileceği için change preview önemlidir. Policy naming environment ve workload bilgisini açıkça göstermelidir.

Integration

Integration belirli application veya service için data collection, ingest pipeline ve dashboard gibi asset'leri paketleyebilir. Nginx veya System integration hazır alan standardizasyonu sağlar. Integration version upgrade field ve dashboard davranışını değiştirebilir. Custom logs integration uygulamaya özel dosya path'lerini toplamak için kullanılabilir. Her integration yalnız ihtiyaç duyulan stream'leri açmalıdır.

Enrollment Token

Enrollment token yeni agent'ın hangi Fleet policy'ye bağlanacağını belirler. Token installation command içinde kullanılabilir. Public documentation veya image içine gömülmemelidir. Compromise şüphesi varsa revoke veya rotate edilmelidir. Enrollment sonrasında agent kendi output authentication mekanizmasını kullanır.

Merkezi Konfigürasyon

Fleet policy değişikliği merkezi olarak agent'lara dağıtılır. Bu model Ansible ile her hosta ayrı YAML kopyalama ihtiyacını azaltabilir. Buna karşılık yanlış policy update geniş etki alanına sahiptir. Canary policy veya küçük agent grubu üzerinde test yapmak güvenlidir. Policy history ve change owner kaydı tutulmalıdır.

Agent Health Monitoring

Fleet agent'ın Healthy, Offline veya error durumlarını gösterir. Offline host gerçek sunucu downtime veya network problemine işaret edebilir. Health yalnız UI'da izlenmemeli alert mekanizmasına bağlanmalıdır. Agent logları failure nedeni için incelenebilir. Fleet Server ve Elasticsearch output health de aynı incident kapsamında değerlendirilmelidir.

Elastic Agent ile Log Toplama

Elastic Agent kurulumu Fleet'te policy oluşturmayla başlar. Host agent bu policy için enrollment token kullanarak Fleet Server'a kaydolur. System veya Custom Logs integration log source path'lerini tanımlar. Data uygun logs data stream'lerine gönderilir ve Kibana'da Discover üzerinden görülebilir. Agent rollout küçük test grubu ile başlayıp health ve duplicate data kontrolü sonrasında genişletilmelidir.

Agent Kurulumu

Agent package veya archive işletim sistemine uygun resmi kaynaktan indirilmelidir. Version cluster compatibility politikasına göre seçilir. Installation command root permission gerektirebilir çünkü system log ve service metric erişimi gerekebilir. Binary checksum doğrulanabilir. Host inventory agent version ve policy bilgisini kaydetmelidir.

Fleet'e Enrollment

Fleet UI ilgili policy için enrollment command üretir. Command Fleet Server URL ve enrollment token içerir. TLS certificate validation production'da kapatılmamalıdır. Agent enrollment sonrası Fleet ekranında healthy görünmelidir. Token değeri terminal history veya automation loguna açık şekilde yazılmamalıdır.

System Integration

System integration Linux system log ve metric kaynaklarını toplayabilir. Hangi stream'lerin açık olduğu policy'de seçilir. Gereksiz metric veya log stream'leri kapatmak storage maliyetini azaltır. Ingest pipeline ECS alanlarını oluşturabilir. Production host group'ları environment namespace ile ayrılmalıdır.

Custom Logs Integration

Uygulamaya özgü log dosyaları Custom Logs integration ile toplanabilir. Path ve multiline configuration source formatına göre tanımlanır. Dataset adı uygulama domain'ini açıkça göstermelidir. JSON parser ve processor'lar structured field'ları korumalıdır. Dynamic field explosion yaratabilecek nested user object'leri doğrudan indexlenmemelidir.

Policy Atama

Agent belirli policy'ye enrollment sırasında veya Fleet üzerinden atanır. Policy değişikliği hostun topladığı dataset'leri etkiler. Production ve development aynı policy'yi kullanmak zorunda değildir. Çok sayıda hostu yanlış policy'ye taşımamak için naming ve tag standardı uygulanmalıdır. Policy change sonrasında event rate farkı kontrol edilmelidir.

Logları Kibana'da Görmek

Agent data stream'e event yazdıktan sonra Discover veya Streams ekranında loglar görülebilir. service.name, host.name ve dataset field'ları filter için kullanılır. Yeni integration'ın dashboard varlıkları otomatik kurulmuş olabilir. Event timestamp source time ile doğru eşleşmelidir. Missing field görüldüğünde ingest pipeline ve raw event birlikte incelenmelidir.

Agent Durumunu İzlemek

Fleet health ekranı agent connectivity hakkında hızlı bilgi verir. Offline veya unhealthy state alert üretmelidir. Data gelmiyorsa agent healthy olsa bile integration input error olabilir. Event count synthetic log ile doğrulanmalıdır. Agent upgrade ve policy rollout başarı oranı ayrı metric olarak takip edilebilir.

Elastic Common Schema (ECS) Nedir?

ECS farklı log ve telemetry kaynaklarının ortak field isimleri kullanmasını sağlayan veri şemasıdır. Aynı host.name veya service.name alanı farklı application'larda aynı anlamı taşıdığında merkezi query ve dashboard tekrar kullanılabilir. Security, observability ve application ekipleri ortak alan sözleşmesinden faydalanır. Custom field gerektiğinde ECS alanını yanlış anlamda kullanmak yerine organization namespace tercih edilebilir. Schema standardizasyonu mapping explosion ve dashboard maintenance sorunlarını da azaltır.

Neden Ortak Log Şeması Gereklidir?

Her servis farklı field adı kullanırsa tek query ile tüm sistemde error aramak zorlaşır. Standard schema shared dashboard ve alert oluşturmayı kolaylaştırır. Collector veya Logstash field rename işlemini merkezi olarak uygulayabilir. En iyi sonuç producer application'ın baştan ortak schema ile log üretmesidir. Schema version ve custom extension policy documentation içinde tutulmalıdır.

@timestamp

@timestamp event'in zaman bilgisini standart date field olarak taşır. Kibana time filter bu alanı yaygın olarak kullanır. Ingestion time yerine gerçek event time parse edilmelidir. Timezone UTC'ye normalize edilebilir. Invalid timestamp event'ler ayrı error tag ile izlenmelidir.

message

message log event'in human-readable ana mesajını taşıyabilir. Structured field'lar ayrı olsa bile operator hızlı bağlam için message değerini kullanır. Message içine bütün JSON object'i string olarak tekrar koymak storage duplication yaratabilir. Secret veya PII burada da redaction policy'ye tabidir. Full-text search ihtiyacına göre mapping davranışı kontrol edilir.

log.level

log.level debug, info, warn veya error gibi severity bilgisini taşır. String değerler servisler arasında aynı casing standardını kullanmalıdır. Dashboard error rate bu field üzerinden aggregation yapabilir. Production'da debug seviyesi sürekli açık bırakılmamalıdır. Custom severity değerleri mapping ve alert rules ile uyumlu hale getirilmelidir.

service.name

service.name event'i üreten logical application service'i tanımlar. Container ID gibi ephemeral değer yerine stabil service identity sağlar. Dashboard filter ve alert grouping için en değerli alanlardan biridir. Deployment version ayrıca service.version benzeri alanda tutulabilir. Service naming CI/CD ve tracing sistemiyle aynı standardı kullanmalıdır.

host.name

host.name event'in geldiği physical veya virtual hostu gösterir. Container workload'da host ve container identity ayrı alanlarda tutulmalıdır. Host bazlı error spike infrastructure problemi hakkında ipucu verebilir. Autoscaling instance isimleri kısa ömürlü olsa da event tarihsel analiz için değer taşır. Cloud instance ID ek metadata olarak ayrıca kullanılabilir.

event.dataset

event.dataset verinin mantıksal dataset türünü tanımlar. Örneğin application access ve error logları farklı dataset kullanabilir. Data stream naming ve lifecycle policy bu alanla ilişkilendirilebilir. Dashboard dataset filter üzerinden daha temiz sorgu yapar. Dataset adı sık sık değiştirilmemelidir.

trace.id

trace.id distributed trace içindeki bütün işlemleri ortak kimlikle ilişkilendirir. Application logger active trace context'i log event'e ekleyebilir. Kibana log kaydından ilgili trace'e geçiş bu sayede mümkün olur. Trace ID yüksek cardinality alanıdır ancak exact match için değerlidir. Retention ve indexing ihtiyacı kullanım senaryosuna göre belirlenmelidir.

transaction.id

transaction.id trace içindeki belirli işlem veya transaction kimliğini gösterebilir. Bir request birden fazla service transaction'ına ayrılabilir. Log ve APM korelasyonunda daha dar bağlam sağlar. Application instrumentation bu alanı otomatik ekleyebilir. Custom random request ID ile semantic olarak karıştırılmamalıdır.

Custom Field'lar

ECS'de karşılığı olmayan business alanları custom namespace altında tutulabilir. Örneğin app.order.id gibi açık organization prefix'i kullanılabilir. User-controlled key'lerin doğrudan field name'e dönüşmesi mapping explosion yaratabilir. Dynamic object yerine flattened type bazı use case'lerde daha güvenli olabilir. Custom schema documentation uygulama ekipleriyle paylaşılmalıdır.

Uygulamalar ECS Uyumlu Log Nasıl Üretmeli?

En iyi merkezi log pipeline parser'a güvenmek yerine uygulamanın doğru structured event üretmesiyle başlar. JSON logger timestamp, log level ve service metadata'yı standart alanlarda yazabilir. Request middleware correlation ve trace context'i otomatik ekleyebilir. Language farklı olsa bile field sözleşmesi aynı tutulmalıdır. Böylece Java, Python veya Node.js servislerinden gelen loglar Kibana'da tek query ile analiz edilebilir.

JSON Logging

Application logger her event'i tek satır JSON olarak yazabilir. Nested field yapısı kontrollü ve schema uyumlu olmalıdır. Logger exception object'ini message stringine dönüştürmek yerine error alanlarına map edebilir. Development ortamında pretty console formatter ayrı kullanılabilir. Production stdout JSON output collector için daha güvenilir olur.

Java

Java logging framework JSON encoder kullanarak ECS benzeri alanlar üretebilir. MDC request veya trace context'i log event'e eklemek için yaygın yöntemdir. Exception stack trace yapılandırılmış error field'larında tutulabilir. Thread ve logger metadata gerektiği kadar eklenmelidir. Debug düzeyi production'da dynamic olarak kısa süre açılıp sonra kapatılabilir.

Python

Python logging custom formatter veya structured logging library ile JSON üretebilir. Request context middleware üzerinden logger'a aktarılabilir. Trace ID OpenTelemetry context'ten alınabilir. Exception bilgi alanları ayrı tutulmalıdır. Dictionary içindeki user input key'leri doğrudan Elasticsearch field name'e çevrilmemelidir.

Node.js

Node.js logger object tabanlı event üretmeye uygundur. Request ID child logger context'ine eklenebilir. Error object serialize edilirken stack ve type ayrı alanlara yazılmalıdır. Console string concatenation yerine structured object kullanmak daha temizdir. Async request context trace correlation için instrumentation ile entegre edilebilir.

.NET

.NET structured logging message template yaklaşımıyla field bilgisi üretebilir. Scope içinde request ve trace metadata taşınabilir. JSON console formatter container stdout için kullanılabilir. Sensitive property destructuring sırasında redaction uygulanmalıdır. ECS naming custom sink veya processor katmanında standardize edilebilir.

Structured Context

Her log event'e bütün request body'yi eklemek yerine anlamlı context field seçilmelidir. User ID, order ID veya trace ID gibi alanlar incident analizi için yeterli olabilir. Secret ve token context'e hiç eklenmemelidir. High cardinality alanların index ihtiyacı ayrıca değerlendirilir. Context middleware standardı tüm service'lerde aynı davranışı sağlayabilir.

Service Metadata

Service name, version, environment ve deployment identifier her event'te otomatik eklenebilir. Bu alanlar release sonrası regression analizinde çok faydalıdır. Container image digest veya Git commit kısa değeri deployment metadata olarak kullanılabilir. Application developer her log çağrısında bu bilgiyi manuel yazmamalıdır. Logger bootstrap veya agent metadata bunu otomatik sağlamalıdır.

Correlation ID ve Trace ID Neden Önemlidir?

Dağıtık sistemde tek kullanıcı isteği birçok service üzerinden ilerler. Yalnız timestamp ve user ID ile bütün event zincirini bulmak zor olabilir. Correlation ID veya trace ID aynı request bağlamındaki logları birleştirir. Distributed tracing kullanılıyorsa trace ID loglara otomatik taşınabilir. Incident sırasında bir error event'ten aynı trace içindeki upstream ve downstream loglara geçmek root cause süresini ciddi biçimde azaltır.

Bir İsteği Mikroservisler Arasında Takip Etmek

API gateway request'e correlation ID ekleyebilir. Downstream HTTP veya message header üzerinden bu kimlik diğer servislere taşınır. Her service log event'e aynı ID'yi yazar. Kibana exact filter ile bütün request timeline'ını gösterebilir. Async queue işlemlerinde message metadata üzerinden context propagation ayrıca uygulanmalıdır.

request.id

request.id tek uygulama veya gateway request kimliğini gösterebilir. Reverse proxy tarafından üretilen ID application'a header ile geçirilebilir. Client-controlled value kullanılıyorsa length ve character validation yapılmalıdır. High cardinality olması normaldir çünkü her request benzersiz olabilir. Exact lookup için keyword mapping uygundur.

trace.id

Trace ID distributed tracing standardında birden fazla service span'ını ortak root altında birleştirir. Application logger active trace context'ten bu değeri alabilir. Elasticsearch log kaydı trace verisiyle ilişkilendirilebilir. Trace sampling uygulansa bile loglarda trace ID bulunması incident bağlamını koruyabilir. Format instrumentation standardıyla uyumlu tutulmalıdır.

transaction.id

Transaction ID belirli service veya transaction segmentini trace içinde tanımlar. Aynı trace içinde birden fazla transaction olabilir. Error log hangi transaction sırasında oluştuğunu gösterir. APM navigation daha spesifik hale gelir. Request ID ile aynı value kullanılacağı varsayılmamalıdır.

Distributed Tracing ile Log Korelasyonu

OpenTelemetry instrumentation trace context'i application request lifecycle boyunca taşır. Logger integration bu context'i structured log alanlarına ekler. Kibana veya observability UI log ile trace arasında geçiş sunabilir. Bu model yalnız error message değil latency ve dependency context'i de gösterir. Correlation sistemi doğru çalışıyor mu synthetic request ile düzenli test edilebilir.

Elasticsearch Index Nedir?

Elasticsearch index benzer document'lerin logical storage alanıdır. Modern log kullanımında doğrudan günlük index isimleri oluşturmak yerine data stream tercih edilebilir. Data stream arka planda backing index'leri yönetir ve rollover işlemini otomatikleştirir. Mapping field türlerini, shard dağılımı ise fiziksel paralellik ve storage davranışını belirler. Index tasarımı retention ve query performansının temelidir.

Document

Document Elasticsearch'te indexlenen JSON event'tir. Bir log satırı çoğunlukla tek document olur. Document source field'ları query ve aggregation için mapping'e göre işlenir. Çok büyük document indexing ve network maliyetini artırır. Request veya response body'nin tamamını default log document'e koymamak gerekir.

Field

Field document içindeki isim ve value çiftidir. Elasticsearch field type üzerinden search ve aggregation davranışını belirler. Aynı field'ın farklı event'lerde incompatible type alması mapping conflict oluşturabilir. ECS field isimleri ortak standard sağlar. Gereksiz field'ların indexlenmesi storage ve heap maliyeti yaratabilir.

Mapping

Mapping field'ın keyword, text, date veya numeric gibi type bilgisini tanımlar. Dynamic mapping hızlı başlangıç sağlar ancak uncontrolled JSON key'lerde field explosion oluşturabilir. Index template production mapping'i merkezi tanımlar. Mapping değişikliği existing field type'ı her zaman doğrudan değiştiremez ve reindex gerekebilir. Schema deployment application release süreciyle koordine edilmelidir.

Shard

Shard Elasticsearch index'in fiziksel parçasıdır ve Lucene index olarak çalışır. Bir index bir veya daha fazla primary shard'a bölünebilir. Çok fazla küçük shard heap ve cluster metadata overhead yaratır. Çok büyük shard recovery süresini uzatabilir. Rollover shard boyutunu hedef aralıkta tutmaya yardımcı olur.

Replica

Replica primary shard'ın kopyasıdır. Node failure durumunda availability sağlar ve search workload'una yardımcı olabilir. Aynı shard'ın primary ve replica kopyası aynı node üzerinde tutulmaz. Replica sayısı storage maliyetini artırır. Production resilience ihtiyacı ve query kapasitesi birlikte değerlendirilmelidir.

Segment

Lucene shard içinde immutable segmentler oluşturur. Yeni indexing segment üretir ve background merge zamanla küçük segmentleri birleştirir. Merge disk I/O ve temporary storage kullanabilir. Force merge yalnız uygun read-only lifecycle aşamasında düşünülmelidir. Segment sayısı query performance ve disk kullanımını etkileyebilir.

Modern Log Yönetiminde Data Stream Nedir?

Data stream sürekli gelen zaman serisi verisini backing index'ler üzerinden yöneten Elasticsearch abstraction'ıdır. Yeni loglar current write index'e yazılır, rollover olduğunda yeni backing index write hedefi olur. Kullanıcı ve application tek data stream adı üzerinden query yapmaya devam eder. Lifecycle retention ve template yönetimi daha düzenli hale gelir. Log gibi append-only veri için data stream modern Elasticsearch kullanımının temel parçalarından biridir.

Data Stream

Data stream logical isim altında birden fazla hidden backing index barındırır. Write request current write backing index'e yönlendirilir. Search request bütün ilgili backing index'leri kapsayabilir. Rollover application configuration değiştirmeden gerçekleşir. Data stream timestamp alanı gerektirir ve zaman serisi kullanımına uygundur.

Backing Indices

Backing index data stream verisinin fiziksel index parçalarıdır. Her rollover yeni backing index oluşturur. Eski backing index read ağırlıklı hale gelir. ILM veya Data Stream Lifecycle retention süresi dolan backing index'leri silebilir. Kullanıcı normalde backing index isimlerini application config içinde kullanmamalıdır.

Append-Only Log Verisi

Log event'ler çoğunlukla bir kez yazılır ve sonradan değiştirilmez. Bu davranış data stream modeline çok uygundur. Update veya delete özel API veya backing index hedeflemesi gerektirebilir. Sık last-write-wins update yapan data için normal index veya alias daha uygun olabilir. Audit log için immutability ayrıca application ve access policy ile korunmalıdır.

logs-- Naming

Modern Elastic integration'larında logs data stream isimleri type, dataset ve namespace parçalarını taşır. Bu model environment ve source ayrımını kolaylaştırır. Örneğin log dataset'i application veya system domain'ini gösterebilir. Namespace production ve development separation için kullanılabilir. Naming schema değişikliği dashboard ve lifecycle policy'leri etkileyebileceği için baştan standardize edilmelidir.

Dataset

Dataset belirli log kaynağı veya uygulama türünü tanımlar. Nginx access ve application error farklı dataset olabilir. Field event.dataset sorgu ve routing için kullanılabilir. Her service için yüzlerce gereksiz dataset oluşturmak shard ve template yönetimini zorlaştırabilir. Dataset business ve operasyon kullanımına göre anlamlı granularity'de seçilmelidir.

Namespace

Namespace data stream'i environment veya organizational boundary açısından ayırabilir. prod, staging ve dev yaygın örneklerdir. Retention veya access role namespace bazında farklılaştırılabilir. Namespace değerleri sınırlı kontrollü listeden gelmelidir. User-generated namespace dynamic stream explosion riskine yol açmamalıdır.

Data Stream vs Klasik Index

Data stream rollover ve backing index yönetimini application'dan gizler. Klasik günlük index naming manuel template ve alias yönetimi gerektirebilir. Append-only timestamped loglarda data stream daha doğal modeldir. Sık document update gerektiren dataset klasik index'e ihtiyaç duyabilir. Yeni log platformu tasarımında data stream default seçenek olarak değerlendirilebilir.

LogsDB Nedir?

LogsDB Elasticsearch'te log verileri için storage verimliliğini artırmayı hedefleyen index mode'dur. Elastic'in güncel dokümantasyonuna göre LogsDB, Elastic Stack 9.0 ve sonrasında yeni logs-*-* data stream'lerinde varsayılan olarak etkinleştirilebilir. Elastic benchmark'ları belirli dataset'lerde storage footprint'in önemli ölçüde azalabildiğini, bunun karşılığında küçük indexing performance maliyeti oluşabildiğini belirtir. Sonuç veri yapısına ve sürüme göre değişir. Bu nedenle production storage tahmini gerçek log setiyle test edilmelidir.

Log Verileri İçin Optimize Edilmiş Index Mode

LogsDB log event'lerinin common structure özelliklerinden yararlanarak storage kullanımını optimize eder. Normal index mode'dan farklı internal sorting ve compression davranışları bulunabilir. Kullanıcı query API'lerini tamamen değiştirmek zorunda değildir. Existing custom mapping ve integration compatibility kontrol edilmelidir. Upgrade edilmiş cluster'larda eski data stream'lerin otomatik olarak mode değiştirmeyebileceği unutulmamalıdır.

Storage Verimliliği

Elastic'in yayınladığı benchmark'larda belirli log dataset'lerinde yüzde 60'a kadar storage footprint azalması görülebileceği belirtilmektedir. Bu sayı her workload için garanti değildir. Field cardinality, source content ve mapping compression oranını etkiler. Indexing performance üzerinde yaklaşık yüzde 10 ile 20 arası küçük etki görülebileceği aynı dokümantasyonda ifade edilir. Capacity plan kendi dataset benchmark'ına dayanmalıdır.

logs-- Data Streams

9.x Elastic Stack'te yeni logs-*-* data stream'leri LogsDB mode kullanabilir. Integration tarafından oluşturulan data stream template'leri bu davranışı yönetebilir. Existing upgraded stream'in mode'u otomatik değişmeyebilir. Custom component template ile mode kontrol edilebilir. Değişiklik production'a uygulanmadan önce indexing latency ve query behavior ölçülmelidir.

Hangi Elastic Sürümlerinde Kullanılır?

Elastic'in güncel Logs data stream dokümantasyonu LogsDB'nin Elastic Stack 9.0'dan itibaren yeni logs-*-* data stream'lerinde otomatik mode olarak kullanılabildiğini belirtir. 8.x'ten upgrade edilen cluster'larda existing stream'ler aynı mode'a otomatik geçmeyebilir. Serverless ortamında davranış ayrıca platform tarafından yönetilebilir. Bu nedenle yalnız major version'a bakmadan ilgili data stream template incelenmelidir. Upgrade planı storage tahminlerini bu değişikliğe göre güncellemelidir.

LogsDB Kullanılmaması Gereken Durumlar

Her index log verisi değildir. Sık update edilen content data veya özel sorting gereksinimi LogsDB kullanımına uygun olmayabilir. Existing application query behavior benchmark edilmelidir. Custom index setting ile çakışan özellik varsa normal mode korunabilir. Karar storage tasarrufu kadar indexing throughput ve feature compatibility üzerinden verilmelidir.

Index Template Nedir?

Index template belirli index veya data stream pattern'i için mapping ve settings sözleşmesini merkezi olarak tanımlar. Yeni backing index oluştuğunda aynı schema tekrar uygulanır. Component template ortak mapping parçalarını farklı template'lerde paylaşmayı sağlar. Template priority birden fazla eşleşme olduğunda hangi ayarın üstün geldiğini etkiler. Production mapping'i manuel index create çağrılarına bırakmak yerine template üzerinden yönetmek drift'i azaltır.

Index Pattern

Index pattern hangi index veya data stream isimlerinin template'e eşleşeceğini belirler. Pattern çok geniş yazılırsa ilgisiz system index'ler yanlış mapping alabilir. Log dataset ve namespace naming standardı template design'i kolaylaştırır. Test index adıyla matching sonucu deployment öncesi doğrulanabilir. Template overlap durumunda priority davranışı açıkça bilinmelidir.

Mappings

Template mappings field type ve dynamic behavior tanımlar. ECS alanları consistent mapping alabilir. High cardinality veya user-generated object için özel strategy belirlenebilir. Dynamic template bazı naming pattern'lerini type'a bağlayabilir. Mapping change backwards compatibility açısından application log producer'larla koordine edilmelidir.

Settings

Index settings shard sayısı, replica ve lifecycle gibi davranışları tanımlayabilir. LogsDB mode veya refresh interval template'te belirlenebilir. Environment bazlı override gereksinimleri ayrı template priority ile yönetilebilir. Çok fazla custom setting upgrade compatibility'yi zorlaştırabilir. Default Elasticsearch behavior'dan sapılan her ayarın gerekçesi documentation'da bulunmalıdır.

Component Templates

Component template ortak mapping ve setting bloklarını reusable hale getirir. Base ECS custom field seti birçok data stream template'inde paylaşılabilir. Integration tarafından yönetilen component template'leri doğrudan değiştirmek yerine supported custom extension yöntemi kullanılmalıdır. Naming collision önlenmelidir. Infrastructure code component ve index template dependency sırasını yönetmelidir.

Priority

Bir index adı birden fazla template'e eşleşebilir. Priority hangi composable index template'in seçileceğini belirler. Integration template'ini yanlış yüksek priority custom template ile override etmek data ingestion'ı bozabilir. Deployment önce simulate template API ile sonucu kontrol edebilir. Priority değerleri organization standardında anlamlı aralıklarla ayrılmalıdır.

Data Stream Template

Template data stream oluşturulacağını belirtirse matching name ilk write sırasında stream oluşturabilir. Timestamp mapping ve lifecycle ayarları burada uygulanır. Rollover yeni backing index'e aynı template configuration'ını taşır. Template değişikliği existing backing index'leri otomatik reindex etmez. Yeni generation'da yeni mapping uygulanacağı için backwards compatibility düşünülmelidir.

Elasticsearch Mapping Nasıl Tasarlanır?

Mapping log platformunun query kabiliyeti ve kaynak tüketimini belirleyen en önemli tasarım alanlarından biridir. Exact match veya aggregation gereken alanlar keyword, full-text message alanları text olarak tutulabilir. Timestamp date, IP adresi ip type olmalıdır. User-controlled dynamic key'ler sınırsız field oluşturmayacak şekilde yönetilmelidir. Mapping kararları gerçek query kullanımına göre yapılmalı, yalnız gelecekte belki aranır düşüncesiyle her alan indexlenmemelidir.

keyword

Keyword exact match, filter ve aggregation için uygundur. Service name, environment veya HTTP method buna örnektir. Çok uzun unique string'leri keyword indexlemek storage ve memory maliyetini artırabilir. User agent full string gibi alanlarda index ihtiyacı ayrıca düşünülmelidir. Normalizer gerekiyorsa casing standardını search davranışıyla birlikte yönetir.

text

Text type analyzer kullanarak full-text search sağlar. Log message bunun yaygın örneğidir. Aggregation için text field uygun değildir ve keyword subfield gerektirebilir. Her string'e hem text hem keyword vermek gereksiz index büyümesi yaratabilir. Query ihtiyacına göre explicit mapping tercih edilmelidir.

date

Date type timestamp alanlarını zaman aralığı sorguları için optimize eder. @timestamp doğru date formatında olmalıdır. Epoch veya ISO 8601 formatları mapping configuration'a göre parse edilebilir. Timezone application tarafından açık şekilde taşınmalıdır. Invalid date event'i mapping error oluşturmadan ingestion sırasında normalize edilmelidir.

numeric

Response time, byte count ve status code gibi alanlar numeric type olabilir. Aggregation ve range query bu şekilde daha verimli çalışır. Numeric değeri string olarak loglamak dashboard hesaplarını zorlaştırır. Uygun integer veya floating type gerçek değer aralığına göre seçilmelidir. Çok hassas decimal için scaled float gibi seçenekler değerlendirilir.

ip

IP type IPv4 ve IPv6 adresleri için özel query davranışı sunar. CIDR range query güvenlik analizinde faydalıdır. Client IP'nin proxy header'dan güvenilir şekilde çıkarılması gerekir. IP kişisel veri olarak değerlendirilebileceği için retention ve access policy uygulanmalıdır. Invalid IP string mapping failure yaratmamalı, parser tarafından işaretlenmelidir.

boolean

Boolean true ve false state'leri açık biçimde taşır. success gibi alanlar string yerine boolean olduğunda query daha tutarlı olur. Null ve missing semantic ayrı düşünülmelidir. Application aynı field'a bazen string bazen boolean göndermemelidir. Schema validation producer tarafında bu hatayı önleyebilir.

object

Object nested JSON yapısındaki alanları ayrı leaf field'lar olarak mapping'e ekler. Kontrollü schema için uygundur. User-defined key sayısı sınırsız object mapping explosion oluşturabilir. Object array semantic'i nested type ihtiyacından farklıdır. Mapping tasarımında query relationship beklentisi dikkate alınmalıdır.

flattened

Flattened type key sayısı kontrol edilemeyen object yapılarında her key için ayrı mapping field oluşturmadan veri saklamaya yardımcı olabilir. Dynamic labels veya metadata kullanımında faydalıdır. Query özellikleri normal explicit mapping kadar zengin olmayabilir. Critical business field'lar yine explicit type almalıdır. Flattened kullanımı mapping explosion'a karşı kontrollü kaçış yolu olarak değerlendirilmelidir.

Mapping'i Kontrolsüz Dynamic Bırakmanın Riski

Dynamic mapping yeni field görüldüğünde otomatik mapping oluşturabilir. User request'ten gelen arbitrary JSON key'leri doğrudan loglanıyorsa kısa sürede binlerce field oluşabilir. Cluster state ve heap kullanımı artar. Field limit aşıldığında yeni document indexing başarısız olabilir. Production template dynamic behavior'ı bilinçli şekilde sınırlamalıdır.

Mapping Explosion Nedir?

Mapping explosion index veya data stream'de çok fazla unique field oluşmasıdır. Dynamic key üreten application logları bunun en yaygın nedenlerindendir. Her field cluster state ve mapping metadata yükünü artırır. Kibana field listeleri yavaşlayabilir ve heap pressure artabilir. Schema standardizasyonu, field limitleri ve flattened type gibi yöntemler riskin kontrol edilmesine yardımcı olur.

Çok Fazla Unique Field

Her yeni field Elasticsearch mapping metadata'sına eklenir. Binlerce gereksiz field memory ve cluster state boyutunu büyütür. Query kullanıcıları aynı anlamı taşıyan yüzlerce field ile karşılaşabilir. Field kullanım analizi hangi alanların gerçekten gerekli olduğunu gösterebilir. Producer team schema contract'a uymalıdır.

Dynamic JSON Key'leri

User attribute veya label isimlerini field key olarak doğrudan yazmak tehlikelidir. Her kullanıcı farklı key gönderirse field sayısı sınırsız büyür. Key-value yapı flattened veya controlled array modeline dönüştürülebilir. Allowed field listesi application seviyesinde uygulanabilir. Unknown key raw message içinde saklanıp index dışı bırakılabilir.

Elasticsearch Heap Etkisi

Mapping metadata master ve data node heap üzerinde yer kaplar. Çok büyük cluster state update'leri master işlemlerini yavaşlatabilir. Kibana field capability query'leri de daha ağır hale gelebilir. Heap artırmak root cause'u çözmez. Field sayısı ve mapping size dashboard'da izlenmelidir.

Field Limitleri

Elasticsearch index setting field sayısına limit koyabilir. Limit aşıldığında yeni mapping eklenmesi engellenebilir. Limiti sürekli artırmak schema problemini ertelemekten başka işe yaramayabilir. Failed event DLQ'ya düşüyorsa field limit nedeni hızlıca görünür olmalıdır. Capacity policy field limit ile producer schema review'u birlikte uygular.

flattened Kullanımı

Flattened object unknown key'leri tek mapping alanı altında saklayabilir. Dynamic labels için field explosion riskini azaltır. Exact query bazı nested key'ler üzerinde yine yapılabilir ancak full mapping özellikleri sınırlıdır. High-value alanlar ayrıca explicit field'a çıkarılabilir. Bu model telemetry metadata için pratik denge sağlayabilir.

Log Schema Standardizasyonu

ECS ve organization-specific extension standardı field isimlerini kontrol eder. Shared logging library producer ekiplerin aynı alanları kullanmasını sağlar. Schema validation CI veya runtime sırasında yapılabilir. New field eklemek review gerektirebilir. Böylece mapping explosion yalnız Elasticsearch setting'iyle değil source development süreciyle önlenir.

High Cardinality Nedir?

High cardinality bir field'ın çok sayıda farklı değere sahip olmasıdır. Request ID, session ID ve user ID gibi alanlar doğal olarak yüksek cardinality taşıyabilir. Exact lookup için değerli olsalar da geniş aggregation yapmak memory ve CPU açısından pahalı olabilir. Her high-cardinality field'ın dashboard aggregation'a eklenmesi gerekmez. Indexing ve doc values ihtiyacı gerçek query kullanımına göre seçilmelidir.

User ID

User ID çok sayıda benzersiz değere sahip olabilir. Incident sırasında belirli user işlemlerini bulmak için exact search değerlidir. Top user aggregation büyük dataset'te maliyetli olabilir. PII veya privacy policy user identifier retention'ını etkileyebilir. Hash veya pseudonymous identifier bazı kullanım alanlarında değerlendirilebilir.

Request ID

Her request benzersiz ID taşıyabilir, dolayısıyla cardinality event sayısına yaklaşabilir. Exact lookup debugging için çok değerlidir. Request ID üzerinde geniş terms aggregation genellikle anlamlı değildir. Keyword mapping ve index kullanımı yeterlidir. Retention log dataset ile aynı lifecycle üzerinden yönetilebilir.

URL

URL path static route ise cardinality düşüktür, ancak query string veya dynamic ID içerirse hızla yükselir. Application route template'i ayrı field olarak loglamak daha iyi aggregation sağlar. Raw URL yalnız gerektiğinde saklanabilir. Query string token veya PII içerebilir. Dashboard status analizinde normalized route kullanılmalıdır.

Session ID

Session ID yüksek cardinality ve güvenlik açısından hassas değer olabilir. Gerçek authentication session token asla loglanmamalıdır. Debugging için gerekiyorsa irreversible hash kullanılabilir. Retention kısa tutulabilir. Dashboard aggregation yerine exact incident lookup amacıyla kullanılması daha güvenlidir.

Cardinality'nin Bellek ve Query Maliyeti

Unique value aggregation büyük field üzerinde fazla memory ve CPU kullanabilir. Kibana dashboard her refresh'te bu query'yi çalıştırıyorsa cluster load artar. Top-N için normalized low-cardinality field tercih edilebilir. Query profile veya slow log pahalı aggregation'ı ortaya çıkarabilir. Capacity yalnız indexing değil dashboard query pattern'lerine göre de belirlenmelidir.

Gereksiz Alanları Indexlememek

Log içinde saklanması gereken her alan search için indexlenmek zorunda değildir. Raw payload source içinde tutulup index kapatılabilir. High-cardinality debug metadata yalnız stored source olabilir. Drop fields collector aşamasında gereksiz veriyi tamamen kaldırabilir. Bu karar query requirement envanteri üzerinden verilmelidir.

Log Retention Nasıl Yönetilir?

Retention logların ne kadar süre erişilebilir kalacağını tanımlar. Tüm loglar için tek süre kullanmak genellikle ekonomik değildir. Debug application logları kısa tutulabilirken security ve audit dataset'leri daha uzun süre gerekebilir. ILM veya Data Stream Lifecycle otomatik deletion ve rollover sağlayabilir. Retention policy compliance, incident investigation süresi ve storage maliyetinin birlikte değerlendirilmesiyle belirlenmelidir.

Retention Nedir?

Retention minimum veya policy tarafından belirlenen saklama süresidir. Süre dolduğunda data silinmeye uygun hale gelebilir. Data Stream Lifecycle retention semantiğinde data'nın en az belirtilen süre tutulması garanti edilir, silme tam o anda gerçekleşmek zorunda değildir. Storage capacity buna göre safety margin içermelidir. Legal hold gereken dataset normal lifecycle'dan ayrılabilir.

Operasyonel Loglar

Application info ve error logları incident analizinin çoğunu kapsar. 14, 30 veya 60 günlük retention ekip ihtiyaçlarına göre yeterli olabilir. Daha eski data gerekiyorsa snapshot veya düşük maliyetli tier kullanılabilir. Debug logları normalden daha kısa tutulmalıdır. Service owner hangi historical window'a gerçekten baktığını ölçerek retention kararına katkı sağlayabilir.

Security Logları

Authentication ve network security logları threat investigation için daha uzun süre değerli olabilir. Security ekibi saldırının haftalar önce başladığını araştırmak isteyebilir. Retention policy risk değerlendirmesine göre belirlenir. Access role application developer'dan daha sıkı olabilir. Archive storage ve searchable retention ayrı süreler olarak tasarlanabilir.

Audit Logları

Audit log yönetici veya kritik business işlemlerini kaydeder. Retention yasal ve iç kontrol gereksinimlerinden etkilenebilir. Değiştirme ve silme yetkisi normal dashboard user'ında bulunmamalıdır. Snapshot veya archive policy ile uzun vadeli korunabilir. Audit dataset'e debug data karıştırılmamalıdır.

Yasal Gereksinimler

Log retention yerel mevzuat, sektör standardı ve sözleşme gereksinimlerinden etkilenebilir. Gereğinden fazla kişisel veri saklamak da risk oluşturur. Legal ve privacy ekipleri retention kararına dahil edilmelidir. Dataset bazında saklama gerekçesi documentation'da tutulmalıdır. Silme policy'sinin gerçekten çalıştığı düzenli doğrulanmalıdır.

Maliyet ve Retention Dengesi

Retention iki katına çıktığında storage ihtiyacı yaklaşık olarak ciddi oranda artar. Eski verinin query sıklığı düşükse cold veya frozen tier maliyeti azaltabilir. LogsDB storage verimliliği log data için ek fayda sağlayabilir. Gereksiz debug ve duplicate event'leri kaynağında azaltmak en ucuz optimizasyondur. Her dataset'in business değeri retention maliyetiyle karşılaştırılmalıdır.

Index Lifecycle Management (ILM) Nedir?

ILM index ve data stream backing index'lerini yaş ve kullanım durumuna göre otomatik aşamalardan geçirebilir. Elastic'in güncel dokümantasyonunda hot, warm, cold, frozen ve delete olmak üzere beş lifecycle phase tanımlanır. Rollover write index'i uygun boyutta tutarken eski veriler daha düşük maliyetli tier'lara taşınabilir. Delete phase retention sonunda data'yı kaldırır. ILM policy design cluster'ın gerçek data tier topology'siyle uyumlu olmalıdır.

Rollover

Rollover mevcut write index belirli age, size veya document koşuluna ulaştığında yeni write index oluşturur. Data stream application aynı logical name'e yazmaya devam eder. Shard'ların aşırı büyümesini önlemeye yardımcı olur. Tek başına daily index naming'e göre traffic variation'a daha iyi uyum sağlar. Max primary shard size gerçek recovery ve query benchmark'ına göre belirlenmelidir.

Hot Phase

Hot phase aktif yazılan ve sık sorgulanan veriyi barındırır. En hızlı disk ve yeterli CPU burada kullanılır. Rollover bu phase'de yapılabilir. Active index merge ve refresh işlemleri nedeniyle I/O yükü taşır. Retention süresinin tamamını hot tier'da tutmak gereksiz maliyet oluşturabilir.

Warm Phase

Warm phase artık sık yazılmayan ancak düzenli sorgulanan veriler için kullanılabilir. Daha düşük compute veya storage profili tercih edilebilir. Index read-only hale getirilip force merge gibi işlemler uygulanabilir. Query latency hot tier'a göre farklı olabilir. Dashboard default time range genellikle hot ve warm data'yı kapsayabilir.

Cold Phase

Cold phase seyrek sorgulanan eski data için daha düşük maliyetli storage sunar. Searchable snapshot kullanılabilir. Query latency daha yüksek kabul edilir. Security investigation gibi özel durumlarda historical search yapılabilir. Cold data'nın availability beklentisi SLO içinde açıkça tanımlanmalıdır.

Frozen Phase

Frozen phase çok seyrek sorgulanan historical data için kullanılır. Searchable snapshot kısmen mount edilerek local storage ihtiyacı azaltılabilir. Query önemli ölçüde daha yavaş olabilir. Dashboard günlük operasyon için frozen data'yı sürekli taramamalıdır. Elastic ILM dokümantasyonu frozen phase içinde searchable snapshot action'ını destekler.

Delete Phase

Delete phase retention sonunda index'i kalıcı olarak kaldırır. Searchable snapshot oluşturulmuşsa policy ilgili snapshot davranışını ayrıca yönetebilir. Silme öncesi belirli snapshot policy'nin çalışmasını bekleyen action kullanılabilir. Legal hold gereken data bu policy dışında tutulmalıdır. Deletion metric ve storage trend'i lifecycle'ın gerçekten çalıştığını doğrulamalıdır.

ILM Policy

ILM policy phase age ve action'larını tanımlayan reusable configuration'dır. Dataset risk ve query behavior'ına göre farklı policy kullanılabilir. Built-in integration policy doğrudan edit edilmeden önce custom extension veya duplicate yaklaşımı değerlendirilmelidir. Policy değişikliği existing managed index'leri etkileyebilir. Staging'de hızlandırılmış phase süreleriyle lifecycle behavior test edilebilir.

Data Stream Lifecycle Nedir?

Data Stream Lifecycle data stream'ler için daha sade rollover ve retention automation modeli sağlar. Elastic'in güncel dokümantasyonu automatic rollover ve configurable retention özelliklerini temel yetenekler olarak açıklar. ILM'den farklı olarak hardware-centric hot, warm ve cold tier action'larını merkeze almak zorunda değildir. Yalnız data stream'lerde kullanılabilir, normal individual index'lerde kullanılamaz. Yeni log platformunda basit retention ihtiyacı varsa Data Stream Lifecycle güçlü seçenek olabilir.

Automatic Rollover

Data Stream Lifecycle incoming data'yı backing index'lere otomatik bölmek için rollover yapabilir. Application rollover condition yönetmez. Backing index boyutu ve performance Elasticsearch tarafından lifecycle bağlamında yönetilir. Yeni mapping generation yeni backing index'te uygulanabilir. Rollover state monitoring'de görünür olmalıdır.

Retention

Data stream seviyesinde retention süresi belirlenebilir. Elastic semantics belirtilen süreyi data'nın en az tutulacağı süre olarak ele alır. Daha eski data daha sonra lifecycle process tarafından silinebilir. Global retention ve stream-specific override desteklenen deployment modeline göre kullanılabilir. Compliance dataset için explicit policy documentation tutulmalıdır.

Data Streams İçin Lifecycle

Bu lifecycle yalnız data stream'lere uygulanır. Append-only logs ve metrics için doğal kullanım sunar. Normal index lifecycle ihtiyacında ILM kullanılmaya devam edilebilir. Streams UI modern Kibana sürümlerinde retention yönetimini merkezi hale getirebilir. Deployment automation API üzerinden lifecycle tanımlayabilir.

ILM ile Arasındaki Fark

ILM hot, warm, cold ve frozen tier action'ları gibi daha ayrıntılı hardware-aware lifecycle sunar. Data Stream Lifecycle daha basit retention ve storage optimization ihtiyacına odaklanır. Serverless ortamda ILM yerine Data Stream Lifecycle kullanılır. Self-managed cluster'da ikisi kullanım senaryosuna göre seçilebilir. Aynı backing index aynı anda iki lifecycle sistemi tarafından yönetilmemelidir.

Hangisi Ne Zaman Kullanılmalı?

Basit logs retention ve otomatik rollover istiyorsanız Data Stream Lifecycle değerlendirilebilir. Dedicated hot, warm ve frozen tier üzerinde ayrıntılı action ihtiyacı varsa ILM daha uygundur. Existing ILM-managed integration'ı yalnız yeni feature var diye hemen migrate etmek gerekmez. Migration davranışı test edilmeli ve existing backing index yönetiminin nasıl devam ettiği anlaşılmalıdır. Policy seçiminde operasyon ekibinin yönetebileceği model tercih edilmelidir.

Hot-Warm-Cold-Frozen Mimarisi

Data tier mimarisi log verisini yaşlandıkça farklı performans ve maliyet profillerine taşır. Yeni data hot tier'da hızlı SSD üzerinde indexlenebilir. Daha eski data warm veya cold node'larda daha ekonomik storage'a geçebilir. Çok nadir sorgulanan historical data frozen tier ve searchable snapshot ile tutulabilir. Bu model retention süresini uzatırken hot storage maliyetini kontrol etmeye yardımcı olur.

Hot Tier

Hot tier active indexing ve sık query workload'unu taşır. En güçlü CPU ve hızlı SSD burada kullanılır. Shard rollover hot tier'da gerçekleşir. Capacity peak ingest ve dashboard concurrency ile hesaplanmalıdır. Disk watermark'a ulaşmadan önce data sonraki tier'a geçmelidir.

Warm Tier

Warm data artık yazılmayan veya çok az değişen backing index'leri içerir. Compute hot tier'dan daha düşük olabilir. Force merge ve read-only behavior storage kullanımını azaltabilir. Sorgu latency biraz daha yüksek kabul edilebilir. Kullanıcı dashboard'larının default time range'i warm data'yı sık tarıyorsa kapasite buna göre planlanmalıdır.

Cold Tier

Cold tier historical data için daha düşük storage maliyeti hedefler. Searchable snapshot kullanımı local replica ihtiyacını azaltabilir. Incident veya audit query'leri bu tier'a erişebilir. Query daha yavaş olabilir. Business SLO bu gecikmeyi açıkça kabul etmelidir.

Frozen Tier

Frozen tier çok düşük sorgu sıklığı olan veriyi searchable snapshot üzerinden tutabilir. Local cache gerektiğinde snapshot segmentlerini getirir. First query latency yüksek olabilir. Daily dashboard query'sini frozen tier'a yönlendirmek maliyet ve performans açısından uygun değildir. Archive-like search ihtiyacı için güçlü seçenektir.

Veri Yaşına Göre Storage Maliyeti

Son yedi gün hot, sonraki yirmi üç gün warm ve daha eski data cold gibi policy oluşturulabilir. Bu sayılar örnektir ve gerçek query davranışına göre belirlenmelidir. Dataset bazında farklı lifecycle uygulanabilir. Security logları application access logundan daha uzun yaşayabilir. Storage maliyet dashboard'u retention kararının finansal etkisini görünür hale getirir.

Searchable Snapshots

Searchable snapshot snapshot repository'deki index data'sını search için mount etmeyi sağlar. ILM cold ve frozen phase'lerinde kullanılabilir. Elastic dokümantasyonu frozen phase'de partially mounted index modelini açıklar. Repository availability query başarısını etkileyebilir. Snapshot repository backup değilmiş gibi yanlış anlaşılmamalı, repository'nin kendisi de durable storage üzerinde tutulmalıdır.

Elasticsearch Shard Boyutlandırması

Shard sayısı Elasticsearch cluster performansını doğrudan etkiler. Çok fazla küçük shard cluster state ve heap overhead yaratırken aşırı büyük shard recovery ve relocation süresini uzatır. Tek sabit ideal shard boyutu yoktur. Rollover max primary shard size ve gerçek query benchmark'ı birlikte kullanılmalıdır. Shard size distribution monitoring'de periyodik olarak gözden geçirilmelidir.

Primary Shard

Primary shard document indexing'in ana shard kopyasıdır. Index creation sırasında primary shard sayısı belirlenir. Çok yüksek sayı düşük hacimli data stream'de gereksiz overhead oluşturur. Single primary birçok orta hacimli logs stream için yeterli başlangıç olabilir. Throughput ve shard size büyüdükçe gerçek benchmark ile artırılabilir.

Replica Shard

Replica shard primary'nin kopyasıdır ve farklı node'a atanır. Availability ve read throughput için kullanılır. Replica sayısı write amplification ve storage maliyetini artırır. Critical production data en az bir replica ile korunabilir. Searchable snapshot architecture bazı eski data tier'larında farklı replica strategy kullanabilir.

Çok Fazla Küçük Shard Problemi

Her shard belirli memory ve cluster metadata overhead taşır. Günlük yüzlerce küçük index binlerce shard oluşturabilir. Cluster master state update ve recovery işlemleri ağırlaşır. Data stream rollover time yerine size condition kullanarak bu sorunu azaltabilir. Tiny dataset'ler shared stream veya daha uzun rollover interval kullanabilir.

Aşırı Büyük Shard Problemi

Çok büyük shard node failure sonrasında uzun süre recover olabilir. Relocation network bandwidth'i uzun süre tüketebilir. Merge ve query latency de etkilenebilir. Rollover daha küçük manageable shard üretir. Snapshot ve restore süresi shard distribution ile birlikte test edilmelidir.

Rollover ile Shard Yönetimi

Rollover current write index hedef boyuta ulaştığında yeni backing index oluşturur. Trafiği değişken uygulamada sabit günlük index'ten daha dengeli shard boyutu sağlayabilir. Max primary shard size lifecycle policy'de tanımlanabilir. Çok düşük threshold shard sayısını gereksiz artırır. Hedef recovery time ve indexing throughput üzerinden belirlenmelidir.

Shard Sayısını Monitoring ile İzlemek

Total shard ve shard per node metric zaman içinde takip edilmelidir. Yeni integration yanlış template nedeniyle shard sayısını hızla artırabilir. Dashboard node storage ve shard count'u birlikte göstermelidir. Growth trend capacity planning'e girdi sağlar. Shard limit'e yaklaşıldığında yalnız node eklemek yerine dataset design incelenmelidir.

Disk Dolması Nasıl Önlenir?

Elasticsearch disk tamamen dolmadan önce allocation watermark mekanizmasıyla koruma uygular. Güncel Elastic dokümantasyonunda default low, high ve flood stage seviyeleri sırasıyla yüzde 85, yüzde 90 ve yüzde 95 kullanım olarak gösterilmektedir. High seviyede shard relocation tetiklenebilir, flood stage'de affected index'lere write block uygulanabilir. En iyi yaklaşım bu eşiklere güvenmek değil capacity trend ve lifecycle retention ile önceden alan açmaktır. Disk alert'i kalan gün tahmini üzerinden de çalışmalıdır.

Retention

Saklama süresi gerçek business ihtiyacına göre sınırlanmalıdır. Sonsuz log retention çoğu sistemde gereksizdir. Old backing index lifecycle ile otomatik silinir. Compliance data farklı policy kullanabilir. Retention change storage trend üzerinde ölçülmelidir.

ILM / DSL

ILM veya Data Stream Lifecycle manual index deletion ihtiyacını azaltır. Rollover index size'ı kontrol eder. Retention expired data otomatik silinebilir. Lifecycle error monitoring'e alınmalıdır. Policy yalnız tanımlanmış değil gerçekten stream'e uygulanmış olmalıdır.

Disk Watermark

Watermark shard allocation'ın disk seviyesine göre davranmasını sağlar. Default değerler safety mechanism'dir. Threshold'u geçici yükseltmek root cause çözümü değildir. Capacity artırılmalı veya retention ile data azaltılmalıdır. Watermark alert storage trend'den önce son savunma olarak görülmelidir.

Low Watermark

Elastic güncel default'ta low watermark için yüzde 85 disk kullanım seviyesini belirtir. Bu seviyede node'a bazı yeni shard allocation işlemleri sınırlandırılabilir. Cluster shard dağılımı dengesiz hale gelmeden kapasite artırımı başlatılmalıdır. Large disklerde max headroom behavior ayrıca önemlidir. Custom threshold değişikliği tüm tier'larla tutarlı olmalıdır.

High Watermark

High watermark default yüzde 90 kullanım civarında shard'ların node'dan başka yere relocate edilmesini tetikleyebilir. Diğer node'larda da yeterli alan yoksa relocation çözüm üretemez. Network ve disk I/O bu sırada artar. Capacity operation high seviyeye ulaşmadan yapılmalıdır. Watermark sürekli aşılıyorsa retention veya node sizing kökten yeniden değerlendirilmelidir.

Flood Stage

Flood stage default yüzde 95 seviyesinde affected index'lere read-only allow delete block uygulanabilir. Bu davranış disk tamamen dolmadan cluster'ı korumaya çalışır. Kibana system index'leri etkilenirse arayüz feature'ları da sorun yaşayabilir. Disk kullanımı high watermark altına düştüğünde block modern Elasticsearch tarafından otomatik kaldırılabilir. Flood stage incident emergency capacity problemi olarak ele alınmalıdır.

Disk Alerting

Alert yalnız yüzde 90 eşik alarmı olmamalıdır. Daily growth trend kalan kapasitenin kaç gün olduğunu tahmin edebilir. Tier bazında farklı disk profile'ları bulunabilir. Snapshot repository capacity ayrı izlenmelidir. Incident notification storage owner ekibine yönlendirilmelidir.

Capacity Planning

Indexed GB/gün ve retention değişimi monthly forecast'a dönüştürülebilir. Product traffic growth modele eklenmelidir. Replica ve rollover overhead hesaba katılır. Node addition lead time operasyon planına dahil edilir. Capacity review düzenli takvimle yapılmalıdır.

Kibana Discover Nasıl Kullanılır?

Kibana Discover log investigation için en sık kullanılan arayüzlerden biridir. Data view veya uygun data stream seçildikten sonra zaman aralığı daraltılır. Search ve filters ile service, host veya log level üzerinden event seti küçültülür. Document details tek event'in bütün field'larını gösterir. Incident sırasında kullanılan query saved search olarak saklanıp ekip içinde tekrar kullanılabilir.

Data View

Data View Kibana'nın hangi index veya data stream field'larını sorgulayacağını tanımlar. Modern Streams kullanımında bazı deneyimler doğrudan stream üzerinden ilerleyebilir. Data view çok geniş wildcard kullanırsa field conflict ve query maliyeti artabilir. Team bazında anlamlı dataset view'ları oluşturulabilir. Time field çoğunlukla @timestamp seçilir.

Time Range

Log query ilk olarak doğru time range'e daraltılmalıdır. Son 15 dakika ile 90 günlük query aynı maliyete sahip değildir. Incident timestamp biliniyorsa birkaç dakikalık pencere performansı ve signal ratio'yu iyileştirir. Browser timezone display davranışı ekip tarafından anlaşılmalıdır. Saved dashboard global time range override yapabilir.

Search

Discover search bar KQL veya desteklenen query modunu kullanabilir. Structured field filter full-text message search'ten daha kesin sonuç verir. service.name ve log.level gibi alanlar ilk filtre için uygundur. Wildcard query yüksek cardinality büyük field üzerinde pahalı olabilir. Query history yararlı incident sorgularını tekrar bulmayı kolaylaştırır.

Filters

Field value üzerinden include veya exclude filter eklenebilir. Filter chip görsel olarak query'nin hangi koşulları kullandığını gösterir. Pinned filter birden fazla Kibana görünümünde korunabilir. Çok sayıda filter yerine anlamlı KQL expression bazen daha okunabilir olur. Incident ekran görüntüsünde active filter'ların görünür olması yanlış yorum riskini azaltır.

Field Explorer

Field explorer hangi alanların mevcut olduğunu ve sample value dağılımını gösterir. Mapping conflict field kullanımını zorlaştırabilir. High cardinality field listesi performans açısından dikkatle incelenmelidir. Gereksiz yüzlerce field schema problemi göstergesidir. ECS field naming aradığınız bilgiyi daha hızlı bulmayı sağlar.

Document Details

Tek event açıldığında bütün structured alanlar görülebilir. Trace ID, container ID ve host metadata incident context sağlar. Raw document sensitive field içeriyorsa user role erişimi sınırlandırılmalıdır. Field value üzerinden yeni filter eklenebilir. Duplicate veya parse failure event'i document details'ta daha kolay teşhis edilir.

Saved Search

Sık kullanılan incident query saved search olarak kaydedilebilir. Örneğin belirli service'in error ve timeout event'leri ortak operasyon view olabilir. Saved search role ve space izinleriyle paylaşılır. Query schema değiştiğinde update edilmelidir. Dashboard paneli saved search üzerine kurulabilir.

KQL ve ES|QL ile Log Arama

KQL field bazlı filtreleme için Kibana içinde pratik query dili sunar. ES|QL ise pipeline benzeri syntax ile filter, transform ve aggregation işlemlerini ifade edebilir. Operasyon ekipleri basit field search için KQL, daha analitik tablo üretimi için ES|QL kullanabilir. Query'ler production data üzerinde pahalı aggregation oluşturabileceğinden zaman aralığı dar tutulmalıdır. Saved query library incident response sürecini standardize eder.

Kibana Query Language

KQL field ve value üzerinden kolay filter expression yazmayı sağlar. Örneğin error level ve belirli service tek query'de birleştirilebilir. KQL Lucene query syntax ile karıştırılmamalıdır. Wildcard kullanımının performance etkisi düşünülmelidir. Team common query pattern'lerini kısa documentation içinde paylaşabilir.

Field Bazlı Filtre

service.name, http.response.status_code veya host.name gibi field'lar exact filter için uygundur. Structured log bu yüzden plaintext message'dan daha güçlüdür. Filter mapping type ile uyumlu olmalıdır. Numeric range query status veya latency üzerinde kullanılabilir. Missing field ayrı koşulla araştırılabilir.

Boolean Queries

AND, OR ve NOT koşulları incident query kapsamını belirler. Parantez kullanımı operator precedence hatalarını azaltır. Çok geniş OR listesi query maliyetini artırabilir. Tag veya normalized category field oluşturmak daha sade query sağlar. Saved query test dataset üzerinde beklenen event sayısıyla doğrulanabilir.

ES|QL

ES|QL veriyi source'tan alıp pipeline operator'larıyla dönüştürmeye yarar. Filter, stats ve sort adımları analitik sorguları okunabilir hale getirebilir. Log investigation sırasında top error service veya status distribution hesaplanabilir. Query result table dashboard veya investigation workflow'unda kullanılabilir. Büyük time range için aggregation maliyeti gözlenmelidir.

Pipeline Tabanlı Analiz

Pipeline syntax önce veri kaynağını seçip sonra filter ve aggregation uygular. Her adımın etkisi query'nin okunmasını kolaylaştırır. Shared query repository incident playbook'un parçası olabilir. Field type yanlışsa pipeline error verebilir. Schema consistency analitik query reuse oranını artırır.

Aggregation

Error count service bazında group edilebilir. Response time average veya percentile hesaplanabilir. High-cardinality request ID üzerinde terms aggregation yapılmamalıdır. Time bucket boyutu dataset büyüklüğüne göre seçilir. Dashboard query'leri refresh interval ile birlikte cluster load yaratır.

Zaman Serisi Analizi

Log event count zaman bucket'larına bölündüğünde trend ve spike görünür. Deployment timestamp dashboard annotation ile ilişkilendirilebilir. Error rate total request count'a oranlanabilir. Seasonal traffic baseline alert threshold seçiminde faydalıdır. Logs metric'in yerine geçmese de olay bağlamı sunarak analizi tamamlar.

Kibana Dashboard Nasıl Oluşturulur?

İyi dashboard yalnız çok sayıda grafik içeren ekran değildir. Kullanıcının belirli operasyon sorusuna hızlı cevap vermelidir. İlk panel error rate, ikinci panel en çok hata veren service ve üçüncü panel latency trend gösterebilir. Global environment ve service filter dashboard'u yeniden kullanılabilir hale getirir. Her panelin query maliyeti ölçülmeli ve refresh interval gereksiz kısa tutulmamalıdır.

Lens

Lens drag-and-drop yaklaşımıyla field aggregation görselleri oluşturmayı kolaylaştırır. Terms, count ve time histogram hızlıca hazırlanabilir. Field type visualization seçimini etkiler. High-cardinality field yanlış seçilirse çok fazla bucket üretebilir. Panel title hangi soruyu cevapladığını açık biçimde belirtmelidir.

Histogram

Time histogram event sayısını zaman bucket'larına böler. Error spike veya traffic artışı kolayca fark edilir. Automatic interval geniş time range'de uygun bucket seçebilir. Incident analysis sırasında daha küçük interval kullanılabilir. Dashboard refresh her seferinde büyük historical range'i taramamalıdır.

Log Level Grafiği

Info, warn ve error event sayıları aynı grafikte gösterilebilir. Error ratio deployment sonrası değişimi hızlı gösterir. Service filter ile hangi application'ın artışa neden olduğu bulunabilir. Log level standardı bütün producer'larda aynı olmalıdır. Debug event miktarı production'da beklenenden yüksekse ayrıca alert üretilebilir.

En Çok Hata Veren Servisler

service.name üzerinden error count aggregation top problemli service'leri gösterir. Request volume yüksek service doğal olarak daha çok absolute error üretebilir. Bu nedenle error rate oranı ayrıca hesaplanmalıdır. Unknown service name event'leri schema quality problemi olarak izlenebilir. Panel owner service catalog ile uyumlu naming kullanmalıdır.

HTTP Status Codes

HTTP status code dağılımı 2xx, 4xx ve 5xx trendlerini gösterir. 4xx artışı client veya authorization problemine, 5xx artışı server regression'a işaret edebilir. Endpoint route field ile breakdown yapılabilir. Raw URL yerine normalized route aggregation daha kararlıdır. Health check traffic gerekirse ayrı filter ile çıkarılabilir.

Response Time

Response time average yerine p95 veya p99 değerleri user experience'i daha iyi gösterebilir. Log field numeric ve ortak unit kullanmalıdır. Millisecond ile second karışıklığı dashboard sonuçlarını bozabilir. Deployment version filter performans regresyonunu bulmaya yardımcı olur. APM metric'leri varsa dashboard log context'iyle birlikte kullanılabilir.

Host Bazlı Loglar

Host name veya container node field üzerinden event distribution görülebilir. Tek hostun error oranı diğerlerinden yüksekse infrastructure problemi olabilir. Autoscaling host sayısı değiştiğinde absolute count yorumlanırken request volume dikkate alınmalıdır. Dead host log yokluğu alert ile ayrıca tespit edilmelidir. Host metadata cloud zone bilgisiyle zenginleştirilebilir.

Dashboard Filter

Environment, service ve namespace gibi global filter'lar dashboard reuse sağlar. Default production filter yanlışlıkla development data karışmasını önleyebilir. Filter control values high-cardinality field üzerinde pahalı olabilir. Kullanıcı filter state paylaşılmış dashboard URL'sinde görülebilir. Security role underlying data access'i yine enforcement olarak sağlamalıdır.

Loglardan Alert Nasıl Üretilir?

Alerting belirli log koşulunun düzenli query ile izlenmesini sağlar. Error rate threshold, belirli exception pattern veya authentication failure artışı rule oluşturabilir. Tek event için alarm üretmek gürültü yaratabileceğinden zaman penceresi ve minimum count önemlidir. Notification channel Slack benzeri sistem, e-posta veya incident platformu olabilir. Alert'in yalnız tetiklenmesi değil recovery ve deduplication davranışı da test edilmelidir.

Error Rate

Error rate belirli interval'da error event'lerin toplam request'e oranını ölçebilir. Absolute error count düşük trafik service'inde farklı yorumlanmalıdır. Threshold baseline ve SLO'ya göre seçilir. Deployment sonrası kısa süreli spike ayrı sensitivity gerektirebilir. Alert service owner'a doğru routing ile gitmelidir.

Belirli Exception

Kritik exception type exact field üzerinden izlenebilir. Message regex yerine structured error.type daha sağlamdır. Tek occurrence çok kritik değilse count threshold kullanılabilir. New exception type dashboard'da top value analiziyle keşfedilebilir. Alert message sample trace ID ekleyerek incident investigation'ı hızlandırabilir.

HTTP 5xx Artışı

5xx count veya ratio belirli service için izlenebilir. Health check endpoint'leri normal request metric'inden ayrılabilir. 502 reverse proxy problemi ile 500 application exception farklı route gerektirebilir. Alert dashboard linki ilgili time range ve service filter ile hazırlanabilir. Recovery condition error rate normale döndüğünde notification gönderebilir.

Authentication Failure

Failed login belirli user veya source IP üzerinde kısa sürede arttığında security alert oluşturulabilir. Threshold normal user typo davranışıyla brute force'u ayırmalıdır. GeoIP veya network zone enrichment investigation'a yardım eder. IP veya username privacy erişim policy'sine tabidir. Alert security ekibine ayrı channel üzerinden yönlendirilebilir.

Service Log Yokluğu

Belirli kritik service normalde sürekli event üretiyorsa log yokluğu collector veya service failure işareti olabilir. Absence alert expected baseline'a göre çalışır. Düşük trafikli gece saatlerinde false positive oluşmaması için zaman profili kullanılabilir. Service health metric ile korelasyon yapılabilir. Synthetic heartbeat log bu kontrolü daha deterministik hale getirir.

Threshold Rule

Threshold rule belirli query sonucunun sayısal eşiği aşmasını izler. Window ve evaluation interval doğru seçilmelidir. Çok kısa interval cluster query load'ını artırır. Group by field cardinality sınırlı tutulmalıdır. Alert flapping recovery threshold veya consecutive check ile azaltılabilir.

Notification Channels

Alert e-posta, webhook veya incident management connector üzerinden gönderilebilir. Connector credential Kibana encrypted saved objects içinde korunmalıdır. Elastic dokümantasyonu self-managed alerting için encrypted saved objects encryption key'in explicit yapılandırılmasını gerektirir. Notification failure ayrıca izlenmelidir. Test alert düzenli çalıştırılarak connector'ın gerçekten ulaşabilir olduğu doğrulanmalıdır.

ELK ile Güvenlik Log Yönetimi

ELK authentication, firewall, web server ve audit loglarını merkezi analiz için bir araya getirebilir. Security use case normal application debugging'den farklı retention ve access control gerektirir. Event field'ları ECS ile standardize edildiğinde farklı source'lar arasında correlation kolaylaşır. Alert rules brute force veya suspicious admin action gibi davranışları tespit edebilir. Güvenlik log sisteminin kendisi de audit ve tamper risklerine karşı korunmalıdır.

SSH Login Logları

SSH success ve failure event'leri auth loglarından toplanabilir. Source IP, username ve authentication method structured field'lara ayrılır. Geographic veya network zone enrichment şüpheli erişimi değerlendirmeye yardımcı olur. Admin login out-of-hours alert üretilebilir. False positive azaltmak için bastion ve automation account davranışı baseline'a dahil edilmelidir.

sudo Events

Sudo logları hangi kullanıcının hangi privilege command'ı çalıştırdığını gösterebilir. Kritik server'da beklenmedik package install veya user management işlemi alert olabilir. Command argument içinde secret bulunabileceği için log redaction policy gereklidir. Authorized automation account ayrı field ile tanımlanabilir. Audit retention normal shell debug logundan daha uzun olabilir.

Authentication Failures

Başarısız login sayısı source IP ve user bazında aggregation yapılabilir. Distributed password spray birçok IP'den düşük sayıda deneme üretebileceği için yalnız per-IP threshold yeterli olmayabilir. Time window ve distinct user count birlikte analiz edilebilir. Successful login sonrasında önceki failure sequence'i correlation için değerlidir. Alert security investigation dashboard'una link vermelidir.

Web Server Attacks

Access loglarda path traversal, scanner veya injection pattern'leri görülebilir. Raw query string hassas veri taşıyabileceği için dikkatli saklanmalıdır. WAF logları web server event'leriyle correlation edilebilir. HTTP status ve response size anomaly ek sinyal sağlar. Detection yalnız regex message search'e değil normalized fields ve threat context'e dayanmalıdır.

Firewall Logs

Firewall deny ve allow event'leri network davranışını görünür hale getirir. Source, destination, port ve action alanları structured olmalıdır. Çok yüksek hacimli normal deny logları sampling veya policy ile yönetilebilir ancak security değer kaybolmamalıdır. Internal east-west traffic ayrı dataset olabilir. Retention investigation horizon'a göre belirlenir.

Audit Logs

Audit logs yönetim veya güvenlik açısından kritik işlemleri kaydeder. Elasticsearch kendi audit logging feature'ı appropriate license ve configuration altında kullanabilir. OS auditd veya application audit event'leri ayrı data stream'de tutulabilir. Access yalnız security ve compliance rollerine verilebilir. Delete yetkisi ingestion user'ında bulunmamalıdır.

Elastic Security / SIEM

Elastic Security log event'leri üzerinde detection ve investigation workflow'ları sağlayabilir. ECS uyumlu data detection rule reuse için önemlidir. Endpoint ve network integration'ları aynı event platformunda ilişkilendirilebilir. Rule tuning false positive oranını yönetmek için düzenli yapılmalıdır. SIEM kullanmak ham log security ve retention policy sorumluluğunu ortadan kaldırmaz.

Docker Container Logları ELK'ye Nasıl Gönderilir?

Docker container uygulamaları stdout ve stderr üzerinden log üretebilir. Docker default JSON log dosyaları host üzerinde tutulur ve collector bu dosyaları okuyabilir. Elastic Agent veya Filebeat container metadata ekleyerek service, container ID ve image bilgilerini event'e taşır. Application structured JSON yazıyorsa message içindeki JSON yeniden parse edilerek ECS alanlarına çıkarılabilir. Host log rotation ve collector registry birlikte yönetilmezse duplicate veya disk dolması sorunları oluşabilir.

Docker JSON Logs

Docker json-file logging driver stdout event'lerini host dosyalarında tutabilir. Dosya path'i Docker tarafından yönetilir ve application doğrudan bu path'e yazmamalıdır. Log rotation Docker daemon veya logging driver setting'leriyle yapılmalıdır. Collector Docker log formatını decode ederek original message'ı çıkarır. Container remove işlemi local log retention'ını etkileyebileceği için merkezi shipping gecikmemelidir.

Filebeat

Filebeat container input veya autodiscover benzeri yöntemlerle Docker loglarını toplayabilir. Host filesystem ve Docker metadata access izinleri gerekir. Container ID ve label'lar enrichment için kullanılabilir. Docker socket mount gerekiyorsa güvenlik etkisi değerlendirilmelidir. Existing Filebeat container deployment modern Elastic Agent seçeneğiyle karşılaştırılabilir.

Elastic Agent

Elastic Agent Docker veya container log integration'ları üzerinden event toplayabilir. Fleet policy hostlara merkezi olarak dağıtılabilir. Container metadata ECS alanlarına eklenebilir. Agent'ın Docker socket veya host path erişimi minimum tutulmalıdır. Production policy log ve metric stream'lerini gerçek ihtiyaç kadar açmalıdır.

Container Metadata

Container name, ID, image ve labels debugging için değerlidir. Ephemeral container ID tek başına service identity olarak kullanılmamalıdır. Stable service name ayrıca event'e eklenmelidir. Label sayısı kontrol edilmezse dynamic field veya cardinality problemi oluşabilir. Allowlist edilen metadata alanları indexlenmelidir.

Structured Application Logs

Container application stdout'a tek satır JSON yazabilir. Collector Docker wrapper JSON'un içindeki message alanını parse eder. Application timestamp host timestamp yerine event time olarak kullanılabilir. Stack trace tek JSON string field'ında tutulursa multiline daha kolay yönetilir. Secret veya request body logging container ortamında da aynı güvenlik kurallarına tabidir.

Container ID ve Service Name

Container ID belirli process instance'ı bulmak için faydalıdır. Service name logical application'ı temsil ettiği için dashboard aggregation'da daha değerlidir. Deployment version ve image digest ayrı metadata olarak eklenebilir. Error yalnız tek container'da görülüyorsa host veya instance problemi araştırılabilir. Autoscaling sonrası eski container event'leri tarihsel analizde yine erişilebilir kalır.

Kubernetes Logları Nasıl Merkezi Toplanır?

Kubernetes container stdout loglarını node filesystem üzerinde saklar ve merkezi collector genellikle node başına DaemonSet olarak çalışır. Collector pod, namespace, container ve node metadata'sını event'e ekler. Elastic Agent, OpenTelemetry Collector veya Fluent Bit gibi araçlar bu modelde kullanılabilir. Multiline ve JSON parsing source'a yakın collector katmanında yapılmalıdır. Kubernetes API metadata enrichment için collector service account yalnız gerekli read izinlerine sahip olmalıdır.

Node-Level Collector

Node-level collector o node üzerinde çalışan bütün pod log dosyalarını okuyabilir. Her application container'a ayrı agent sidecar ekleme ihtiyacını azaltır. DaemonSet scheduler her node'a bir collector instance yerleştirir. Host path read-only mount kullanılmalıdır. Node drain veya reboot sırasında registry state ve delivery backlog davranışı test edilmelidir.

DaemonSet

DaemonSet yeni node eklendiğinde collector pod'un otomatik oluşmasını sağlar. Resource request ve limit belirlenmelidir. High log burst collector CPU limitine takılırsa ingestion lag artabilir. Toleration gerekirse control plane veya special node logları da toplanabilir. Upgrade rolling strategy event gap oluşturmayacak şekilde test edilmelidir.

Elastic Agent

Elastic Agent Kubernetes integration ile log ve metric toplayabilir. Fleet policy cluster veya node gruplarına uygulanabilir. Kubernetes metadata ECS alanlarına eklenir. Agent pod'un host log path ve API access yetkileri sınırlandırılmalıdır. Fleet Server connectivity cluster network policy ile güvenli tutulmalıdır.

Fluent Bit

Fluent Bit hafif log collector olarak Kubernetes ortamlarında yaygın kullanılan bir seçenektir. Elasticsearch veya OpenTelemetry uyumlu output seçenekleri sağlayabilir. Parser ve buffer davranışı gerçek failure senaryolarında test edilmelidir. Data schema ECS'e çevrilecekse transform katmanı planlanmalıdır. Tool seçimi existing platform team yetkinliğiyle uyumlu olmalıdır.

Kubernetes Metadata

Namespace, pod name, container name ve labels incident analizi için yararlıdır. Ancak bütün label key'lerini ayrı Elasticsearch field'a çevirmek mapping explosion oluşturabilir. Label allowlist veya flattened mapping kullanılabilir. Workload owner ve application name gibi stable metadata öncelikli tutulmalıdır. Pod UID exact instance takibi için değerli olabilir.

Pod / Namespace / Container Fields

Pod name ephemeral olabilir, deployment veya service name daha stabil logical identity sunar. Namespace environment veya team boundary gösterebilir. Container name aynı pod içindeki sidecar ve application ayrımını sağlar. Dashboard filter bu alanlarla hızlı drill-down yapabilir. RBAC log access namespace bazında ayrılabilir.

Multiline Container Logs

Container runtime her newline'ı ayrı kayıt olarak tutabilir. Stack trace tek event'e birleştirilmezse search experience bozulur. Collector multiline parser application formatını bilmelidir. Structured JSON logging bu problemi büyük ölçüde ortadan kaldırır. Max lines ve timeout runaway event oluşmasını önler.

Logstash Yerine Ingest Pipeline Kullanılabilir mi?

Elasticsearch ingest pipeline event indexlenmeden önce processor çalıştırarak parsing ve enrichment yapabilir. Basit JSON decode, field rename ve date normalization için Logstash gereksiz olabilir. Ağır Grok veya birçok source ve output routing ihtiyacı Logstash'i daha uygun hale getirebilir. Ingest workload Elasticsearch node CPU'sunu tükettiği için yoğun transformation indexing kapasitesiyle yarışır. Mimari seçim workload benchmark ve operasyon sadeleşmesi birlikte değerlendirilerek yapılmalıdır.

Elasticsearch Ingest Node

Ingest role event'i indexing öncesinde pipeline processor'lardan geçirir. Küçük cluster'da data node aynı zamanda ingest role taşıyabilir. Büyük parsing workload dedicated ingest node'a ayrılabilir. Pipeline failure response sender'a geri dönebilir. Ingest metric ve processor latency monitoring'e alınmalıdır.

Processor'lar

Grok, dissect, set, rename ve geoip benzeri processor'lar ingest pipeline'da kullanılabilir. Pipeline JSON API veya Kibana üzerinden yönetilebilir. Version control automation API deployment yapmalıdır. Processor on_failure bloğu malformed event'leri farklı route'a yönlendirebilir. Complex branching arttıkça test ihtiyacı büyür.

Basit Dönüşümler

Field rename, remove ve timestamp parse gibi işler ingest pipeline için uygundur. Collector doğrudan Elasticsearch'e gönderim yapabilir. Arada Logstash hostu bulunmadığı için infrastructure sayısı azalır. CPU maliyeti Elasticsearch cluster'a taşınır. Basit workload'da bu trade-off genellikle kabul edilebilir olabilir.

Karmaşık Pipeline'lar

Birçok conditional, external lookup ve farklı output gerektiğinde Logstash daha esnek olabilir. Pipeline event'i Kafka veya S3 gibi farklı hedeflere de gönderebilir. Persistent Queue ek disk buffering sağlar. Ingest pipeline yalnız Elasticsearch indexing flow'u içinde çalışır. Architecture requirement listesi hangi aracın daha uygun olduğunu açıkça gösterebilir.

Logstash vs Ingest Pipeline

Logstash ayrı compute ve geniş plugin ekosistemi sunar. Ingest pipeline daha az infrastructure component ile Elasticsearch içinde dönüşüm yapar. Küçük structured logging sisteminde ingest pipeline sade seçimdir. Legacy parsing-heavy pipeline'da Logstash daha güçlü kontrol sağlayabilir. Her iki yöntemde de field schema ve error handling aynı kalite standardına sahip olmalıdır.

İş Yükünü Elasticsearch'e Taşımanın Etkisi

Ingest processor CPU ve memory kullanımı data node indexing işiyle paylaşılabilir. Traffic burst sırasında search latency etkilenebilir. Dedicated ingest node bu contention'ı azaltabilir. Pipeline CPU cost metric ile ölçülmelidir. Logstash kaldırıldığında toplam node sayısı azalsa bile Elasticsearch kapasitesi yeniden hesaplanmalıdır.

Kafka ELK Mimarisine Ne Zaman Eklenmeli?

Kafka ingestion ile Elasticsearch arasında durable message buffer ve replay özelliği gerektiğinde değerlidir. Çok yüksek event hacminde producer ve consumer scaling'i birbirinden ayırır. Elasticsearch bakım veya yavaşlık yaşadığında Kafka retention backlog'u tutabilir. Ancak Kafka broker, partition, replication ve monitoring operasyonu kendi başına ciddi sistemdir. Küçük log pipeline'da yalnız olası trafik artışı için eklemek gereksiz olabilir.

Trafik Patlamaları

Incident veya product campaign sırasında log event rate kısa sürede birkaç kat artabilir. Kafka producer burst'ü topic'e kabul edip consumer'ın daha düzenli hızda processing yapmasını sağlar. Partition count throughput ihtiyacına göre planlanır. Broker disk capacity retention süresiyle uyumlu olmalıdır. Sustained traffic growth buffer ile gizlenmemeli, downstream capacity artırılmalıdır.

Buffering

Kafka event'leri configured retention süresince disk üzerinde tutar. Elasticsearch unavailable olduğunda Logstash consumer durabilir ve backlog büyür. Recovery sonrasında consumer catch-up yapar. Catch-up throughput normal ingestion'dan yüksek kapasite gerektirebilir. Lag alert gerekli recovery time tahminini göstermelidir.

Replay

Parser bug nedeniyle yanlış indexlenen loglar Kafka retention içindeyse yeniden tüketilebilir. Yeni consumer group veya offset reset ile replay yapılabilir. Duplicate data oluşmaması için target yeni data stream olabilir. Replay production query workload'ını etkileyebilir. Event schema version parser seçimini kolaylaştırır.

Consumer Independence

Aynı topic'i observability ve security consumer'ları bağımsız okuyabilir. Bir consumer yavaşladığında diğerinin offset'i etkilenmez. Data ownership ve schema contract producer ile consumer ekipleri arasında paylaşılmalıdır. Topic access ACL minimum yetkiyle sınırlandırılmalıdır. PII bütün consumer'lara otomatik açılmamalıdır.

Kafka → Logstash

Logstash Kafka input consumer group içinde çalışabilir. Birden fazla Logstash node partition'ları paylaşarak horizontal scale sağlar. Persistent Queue kısa local restart senaryosunda ek buffer sunabilir. Elasticsearch output throughput backlog recovery'yi belirler. Offset commit ve event ACK semantics test edilmelidir.

Kafka'nın Operasyonel Maliyeti

Kafka broker availability, disk, replication ve upgrade yönetimi gerektirir. Schema ve topic lifecycle ayrı yönetim alanıdır. Küçük DevOps ekibi için bu yük Elasticsearch kadar önemli olabilir. Managed Kafka operasyonu azaltabilir ancak network ve maliyet devam eder. Business requirement replay veya multi-consumer değilse daha basit queue yeterli olabilir.

Küçük Sistemlerde Neden Gereksiz Olabilir?

Günlük birkaç GB log için Filebeat ve Elasticsearch doğrudan akışı yeterli olabilir. Persistent Queue kısa kesintileri karşılayabilir. Kafka ek host ve monitoring gerektirir. Incident root cause ararken fazladan hop debugging süresini uzatabilir. Ölçülmeyen gelecekteki ölçek korkusuyla architecture büyütmek yerine ihtiyaç ortaya çıktığında eklemek daha sağlıklıdır.

Production ELK Güvenliği

Production ELK logların kendisi hassas veri taşıdığı için güçlü güvenlik gerektirir. TLS bütün servis bağlantılarında kullanılmalı ve certificate verification kapatılmamalıdır. Human user, Agent ve Logstash farklı minimum yetkili identity'ler kullanmalıdır. Network segmentation Elasticsearch ve Kibana'yı doğrudan internetten ayırır. Secret management ve audit logging platformun kendi yönetim işlemlerini de görünür hale getirir.

TLS Everywhere

Collector-to-Logstash, Logstash-to-Elasticsearch ve Kibana-to-Elasticsearch bağlantıları TLS kullanmalıdır. Internal network güvenli kabul edilerek plain credential taşınmamalıdır. Certificate rotation automation ve expiration alert gerektirir. CA trust merkezi PKI üzerinden dağıtılabilir. Mutual TLS belirli machine-to-machine bağlantılarda ek kimlik doğrulama sağlayabilir.

Authentication

Her service ve kullanıcı unique veya scoped credential kullanmalıdır. Shared elastic password bütün sistemlere dağıtılmamalıdır. API key application ingestion için daha kolay revoke edilebilir. SSO human access yönetimini merkezileştirir. Failed login ve credential error logları monitoring'e alınmalıdır.

RBAC

Role-based access control index ve Kibana feature izinlerini kullanıcı görevine göre sınırlar. Developer production security data stream'ini görmeyebilir. Dashboard viewer management feature'ına erişmez. Role mapping identity provider group'larıyla otomatikleştirilebilir. Role permission audit periyodik yapılmalıdır.

Least Privilege

Logstash yalnız hedef data stream'e write izni almalıdır. Kibana read-only user yalnız gerekli index'leri okuyabilir. Snapshot automation yalnız repository ve snapshot işlemleri için gerekli yetkiye sahip olabilir. Superuser kullanım sıklığı audit edilmelidir. Permission exception'ları süreli ve gerekçeli olmalıdır.

API Keys

API key service-to-service authentication için kullanılabilir. Key belirli index privilege ile sınırlandırılır. Compromise halinde ilgili key revoke edilip yenisi oluşturulur. Key value yalnız creation sırasında görülüyorsa secret manager'a güvenli kaydedilmelidir. Expiration desteklenen use case'te rotation burden azaltabilir.

Secret Management

Password, API key ve encryption key Git'e yazılmamalıdır. Secret manager deployment identity'ye runtime access sağlar. Secret log output'a veya shell history'ye düşmemelidir. Rotation procedure dependent service restart veya reload davranışını kapsamalıdır. Access audit hangi user'ın secret okuduğunu gösterebilir.

Network Segmentation

Elasticsearch data node'ları private subnet üzerinde tutulabilir. Logstash ingestion network ile data network arasında kontrollü interface kullanabilir. Kibana reverse proxy dışında public route almamalıdır. Firewall east-west traffic'i de minimum servis ilişkisine göre sınırlar. Backup repository egress'i explicit allow rule ile yönetilebilir.

Firewall

9200 yalnız Kibana ve ingestion kaynaklarına açık olabilir. 9300 yalnız Elasticsearch node'ları arasında kullanılır. 5044 agent subnet'lerine, 5601 ise reverse proxy'ye sınırlandırılır. Cloud security group ve host firewall rule'ları çakışmayacak şekilde yönetilmelidir. External port scan production checklist'in parçası olabilir.

Audit Logging

Cluster authentication ve management işlemleri audit log ile izlenebilir. Admin role değişikliği veya security setting update kritik event olarak alert edilebilir. Audit log access normal application logdan daha sıkı olabilir. Retention compliance ihtiyacına göre belirlenir. Platform admin'in audit logu silememesi için archive veya external forwarding düşünülebilir.

Logstash ile Elasticsearch Arasında TLS

Logstash output Elasticsearch'e HTTPS üzerinden bağlanmalıdır. CA certificate Logstash hostuna güvenilir dosya olarak dağıtılır. Certificate verification açık kalır ve endpoint hostname certificate SAN ile eşleşir. Authentication için API key veya minimum privilege user kullanılabilir. Superuser password pipeline config içine yazılmamalıdır.

CA Certificate

Elasticsearch auto-configuration tarafından oluşturulan HTTP CA veya kurum CA'sı Logstash trust için kullanılabilir. CA file permission service user'ın okuyabileceği şekilde ayarlanır. CA certificate değişimi rolling deployment gerektirebilir. Birden fazla CA geçiş döneminde trust bundle kullanılabilir. Certificate file checksum automation ile doğrulanabilir.

Certificate Verification

Verification server certificate'ın trusted CA tarafından imzalandığını ve uygun identity'yi taşıdığını doğrular. Self-signed certificate hatasını çözmek için verification kapatılmamalıdır. DNS ve certificate SAN mismatch düzeltilmelidir. Load balancer endpoint'i kullanılıyorsa certificate o hostname'i kapsamalıdır. TLS handshake failure alert pipeline outage olarak görülmelidir.

API Key

Logstash Elasticsearch output API key ile authenticate olabilir. Key yalnız ilgili data stream create veya write izinlerini taşımalıdır. Index template yönetimi ayrı deployment identity tarafından yapılabilir. API key rotation pipeline reload ile uygulanabilir. Compromise durumunda tek key revoke edilmesi shared password modelinden daha kontrollüdür.

Logstash User

Password-based user tercih edilirse özel Logstash writer role oluşturulmalıdır. Superuser kullanılmamalıdır. Monitoring izinleri write permission'dan ayrı değerlendirilebilir. Password secret store'da tutulmalıdır. Kullanılmayan old credential rotation sonrası revoke edilmelidir.

Minimum Index Permissions

Writer identity yalnız gerekli logs-* namespace'lerine yazabilmelidir. Security ve application dataset farklı role kullanabilir. Wildcard'ın gereğinden geniş olması accidental data overwrite riskini artırır. Template veya lifecycle management permission ayrı automation user'a verilebilir. Permission test production öncesi staging API key ile yapılmalıdır.

SSL Verification'ı Kapatmamak

Certificate error genellikle CA trust, hostname veya expiration problemidir. Verification'ı kapatmak bağlantıyı çalıştırabilir ancak server identity kontrolünü kaybettirir. Bu özellikle credential taşıyan connection'da ciddi risktir. Root cause certificate chain üzerinden çözülmelidir. Development ortamı da mümkün olduğunca aynı trust modelini kullanmalıdır.

Filebeat / Elastic Agent ile Logstash Arasında TLS

Collector ile Logstash arasındaki Beats veya başka transport bağlantısı TLS ile korunmalıdır. Logstash server certificate sunar ve Agent trusted CA üzerinden doğrular. Daha güçlü machine authentication gerektiğinde mutual TLS kullanılabilir. Certificate rotation agent sayısı yüksek deployment'larda otomasyon gerektirir. TLS failure event shipping'i durdurabileceği için expiration ve handshake metric'leri alert edilmelidir.

Server Certificate

Logstash Beats input için server certificate ve private key kullanabilir. Certificate input endpoint DNS ismini kapsamalıdır. Private key yalnız Logstash service tarafından okunmalıdır. Expiration uzun süre unutulmayacak monitoring ile takip edilir. Certificate replacement pipeline restart veya reload davranışı test edilmelidir.

Certificate Authority

Agent'lar Logstash certificate'ını imzalayan CA'ya güvenmelidir. Internal CA file configuration management ile hostlara dağıtılabilir. CA private key agent hostlara taşınmaz. Root ve intermediate certificate chain doğru oluşturulmalıdır. CA rotation planı overlap trust period içermelidir.

Mutual TLS

Mutual TLS server'ın client certificate'ını da doğrulamasını sağlar. Böylece yalnız authorized agent certificate'ı input'a bağlanabilir. Certificate issue ve revocation süreçleri device lifecycle ile entegre edilmelidir. Shared certificate bütün hostlara kopyalanmamalıdır. mTLS API key veya başka authorization modelinin yerine değil ek identity katmanı olarak kullanılabilir.

Client Authentication

Collector machine identity certificate veya protocol-specific credential ile doğrulanabilir. Client certificate subject üzerinden source group ayrımı yapılabilir. Compromised host certificate revoke edilmelidir. Logstash connection logları failed client authentication için alert sağlayabilir. Enrollment automation new host certificate provisioning'i kapsamalıdır.

Certificate Rotation

Certificate expiry beklenmeden yenilenmelidir. Yeni CA kullanılacaksa agent trust bundle önce her hosta dağıtılır. Ardından server certificate değişir ve eski CA daha sonra kaldırılır. Canary agent handshake test edilir. Rotation süreci yılda bir hatırlanan manual komut yerine otomatik runbook haline getirilmelidir.

Loglarda Hassas Veri Nasıl Korunur?

Log sistemi çoğu zaman production verisinin geniş bir kopyasını oluşturabileceği için hassas veri kontrolü kaynağında başlamalıdır. Password, API key ve JWT hiçbir zaman normal log event'e yazılmamalıdır. Kredi kartı ve kişisel kimlik bilgileri mümkün olduğunca hiç toplanmamalıdır. Gerekli alanlar masking veya irreversible tokenization ile korunabilir. Collector redaction son savunma olarak kullanılabilir ancak application producer'ın güvenli logging standardı daha önemlidir.

Password

Password değeri success veya failure fark etmeksizin loglanmamalıdır. Authentication error yalnız user identifier ve failure type içerebilir. Request body logging middleware password field'ını allowlist dışına çıkarmalıdır. Debug mode secret field'ları açmamalıdır. Mevcut logda password tespit edilirse retention beklenmeden incident ve deletion prosedürü uygulanmalıdır.

API Key

API key header veya query parameter içinde bulunabilir. HTTP request logger authorization header'ı tamamen redact etmelidir. Key'in yalnız son birkaç karakterini identifier olarak göstermek gerekirse security review yapılmalıdır. Leak durumunda key hemen revoke edilmelidir. Log archive ve snapshot'larda eski key'in bulunabileceği unutulmamalıdır.

JWT

JWT signed olsa da içindeki claim'ler decode edilebilir ve token aktif credential olabilir. Full token loglanmamalıdır. Gerekirse token ID veya hash correlation için kullanılabilir. Authorization failure reason ayrı field olarak tutulabilir. Request header redaction default policy olmalıdır.

Credit Card

Full kart numarası loglanmamalıdır. Payment provider response veya request body debug output dikkatle filtrelenmelidir. Son dört hanenin gösterilmesi bile compliance policy ile değerlendirilmelidir. CVV hiçbir koşulda loglanmamalıdır. Payment log dataset'ine erişim normal developer loglarından daha sıkı olabilir.

Kimlik Bilgileri

Ulusal kimlik numarası veya passport verisi incident debugging için çoğu zaman gereksizdir. Business event ID daha güvenli correlation alanıdır. Gerekiyorsa masked veya tokenized value kullanılabilir. Retention kısa tutulmalıdır. Access yalnız gerçek iş ihtiyacı olan role'a verilmelidir.

PII

PII isim, e-posta, IP ve başka tanımlayıcı bilgileri kapsayabilir. Her field için logging necessity değerlendirilmelidir. Data minimization en güçlü güvenlik kontrolüdür. Retention ve user access bu data class'a göre belirlenir. PII inventory log schema documentation içinde tutulmalıdır.

Log Redaction

Redaction hassas field değerini event storage'a girmeden kaldırır veya değiştirir. Application logger serializer seviyesinde uygulanması en güvenli yerdir. Collector processor ikinci kontrol sağlayabilir. Regex redaction tüm secret formatlarını yakalamayabilir. Automated test known secret sample'ın final Elasticsearch document'ta bulunmadığını doğrulayabilir.

Masking

Masking value'nun yalnız bir bölümünü görünür bırakabilir. Customer support belirli identifier'ın son karakterlerine ihtiyaç duyuyorsa kullanılabilir. Masking reversible olmamalıdır. Raw value başka hidden field'da tutuluyorsa güvenlik faydası kaybolur. Query ihtiyacı için deterministic hash alternatif olabilir.

Drop Fields

Collector veya Logstash gereksiz hassas field'ı tamamen event'ten silebilir. Allowlist yaklaşımı denylist'ten daha güvenli olabilir. New application field otomatik olarak storage'a gitmez. Drop işlemi audit edilerek hangi data'nın intentionally kaldırıldığı bilinir. Debug investigation için raw payload açma isteği controlled feature flag gerektirebilir.

KVKK Açısından Log Yönetimi

Loglar kişisel veri içerdiğinde KVKK kapsamındaki veri işleme ilkeleri açısından ayrıca değerlendirilmelidir. Teknik ekip her log alanını sınırsız saklamak yerine işleme amacı ve retention gerekçesini belirlemelidir. Veri minimizasyonu uygulama seviyesinde başlanması gereken temel yaklaşımdır. Erişim rolleri ve audit trail kişisel log verisine kimin baktığını gösterebilmelidir. Hukuki yorum için kurumun hukuk veya kişisel veri ekibinin görüşü alınmalıdır.

Kişisel Veri İçeren Loglar

E-posta, IP, kullanıcı adı ve cihaz bilgisi kişisel veri kapsamına girebilir. Log schema inventory hangi dataset'in hangi kişisel alanları taşıdığını göstermelidir. Developer convenience için request body'nin tamamını saklamak gereksiz risk yaratır. Debug ihtiyacı business ID üzerinden karşılanabilir. Data classification dashboard ve index access policy'ye yansıtılmalıdır.

Veri Minimizasyonu

Yalnız operasyon amacı için gerekli alanlar loglanmalıdır. Kullanılmayan field'ı retention sonrasında silmek yerine hiç toplamamak daha güvenlidir. Application logging library sensitive key allowlist uygulayabilir. Review sırasında yeni log statement'ları da veri açısından incelenmelidir. Data minimization storage maliyetini de azaltır.

Retention

Kişisel veri içeren logların saklama süresi amaçla orantılı olmalıdır. Her dataset aynı uzun retention'ı kullanmamalıdır. Lifecycle policy otomatik deletion sağlar. Archive ve snapshot retention da aynı veri politikasını dikkate almalıdır. Legal requirement değiştiğinde policy ve restore archive süreçleri birlikte güncellenmelidir.

Yetkilendirme

Production log erişimi role bazlı sınırlandırılmalıdır. Developer yalnız sorumlu olduğu service dataset'ini görebilir. Support role masked field view kullanabilir. Superuser günlük analiz için kullanılmamalıdır. Access review eski çalışan veya ekip değişikliğinde permission temizliğini sağlar.

Audit Trail

Kritik log dataset'ine erişim ve yönetim işlemleri audit edilmelidir. Role değişikliği veya index deletion event'leri özellikle önemlidir. Audit logların kendisi ayrı retention ve access policy kullanabilir. Admin activity normal user query'sinden ayrılabilir. Investigation sırasında audit record güvenilir zaman kaynağı olarak kullanılmalıdır.

Silme Politikası

Retention sona erdiğinde lifecycle data'yı otomatik silmelidir. Snapshot ve external archive içinde aynı data devam ediyorsa deletion policy bunları da kapsamalıdır. User-specific deletion requirement log immutability ve yasal yükümlülüklerle birlikte değerlendirilmelidir. Manual index delete yerine policy-driven process tercih edilir. Silmenin gerçekleştiği monitoring ile doğrulanmalıdır.

Production Debug Loglarının Riski

Debug log normal seviyeden çok daha fazla request context veya internal data içerebilir. Production'da sürekli açık bırakılması PII ve secret sızıntısı riskini büyütür. Incident sırasında süreli olarak açılabilir ve otomatik kapanma mekanizması kullanılabilir. Debug dataset daha kısa retention alabilir. Debug activation kim tarafından yapıldı audit edilmelidir.

Log Injection ve Log Poisoning Nedir?

Log injection kullanıcı girdisinin log formatını bozacak veya sahte event gibi görünecek biçimde kaydedilmesidir. Plaintext loglarda newline karakteri saldırganın yeni satır oluşturmasına izin verebilir. Structured JSON logger control character'ları doğru escape ederek riski azaltır. Yine de log verisi güvenilir input kabul edilmemelidir. Parser, dashboard ve alert query'leri user-controlled field'ları güvenli şekilde işlemelidir.

Kullanıcı Girdisini Loglama

Username, URL veya header değerleri kullanıcı kontrolünde olabilir. Bu değerler log formatına raw string concatenation ile eklenmemelidir. Structured logger field value olarak encode etmelidir. Maximum length sınırı log amplification saldırısını azaltır. Sensitive header allowlist dışı bırakılmalıdır.

Newline Injection

Kullanıcı input'unda newline varsa plaintext log dosyasında yeni event gibi görünebilir. SIEM rule veya human analyst yanıltılabilir. JSON serializer newline'ı escaped sequence olarak tutmalıdır. Legacy plaintext formatında control character sanitization uygulanabilir. Parser testleri malicious newline sample içermelidir.

Sahte Log Kaydı

Saldırgan message içine sahte timestamp veya severity yazabilir. Structured field source application tarafından oluşturulduğunda user message bunları override etmemelidir. Collector trusted metadata ile untrusted payload field'larını ayrı tutmalıdır. Dashboard severity için trusted log.level alanını kullanmalıdır. Raw message yalnız evidence olarak gösterilir.

Structured Logging ile Riski Azaltmak

Structured logger key ve value sınırını korur. User input JSON serializer tarafından escape edilir. Timestamp ve service field application tarafından ayrı oluşturulur. Parser regex'in sahte prefix'e aldanma riski azalır. Schema validation invalid field type'ı erken yakalar.

Input Sanitization

Log security uygulama input validation'ın yerine geçmez. Ancak loglanan alan için control character ve length policy uygulanabilir. Sanitization original business value'yu değiştirmemelidir. Security investigation için raw value gerekiyorsa güvenli encoded form saklanabilir. Sanitization rule unit test ile korunmalıdır.

Güvenilmeyen Log Verisi

Merkezi log platformu source event'i güvenilir command olarak yorumlamamalıdır. Dashboard HTML rendering escape uygulamalıdır. Alert webhook template user field'larını shell veya query içine kontrolsüz eklememelidir. External enrichment URL'si user input'tan doğrudan oluşturulmamalıdır. Log pipeline güvenilmeyen veri işleyen application gibi güvenlik review'undan geçmelidir.

ELK Stack Monitoring

Log platformu diğer sistemleri izlediği için kendi sağlığının gözden kaçması sık yapılan hatadır. Elasticsearch heap, disk, shard ve indexing metric'leri düzenli izlenmelidir. Logstash event throughput, queue ve DLQ değerleri ayrı dashboard'a konulmalıdır. Kibana task manager, alerting ve response time health'i takip edilmelidir. Büyük kritik deployment'ta monitoring verisini aynı cluster'da tutmanın failure correlation riski nedeniyle dedicated monitoring cluster değerlendirilebilir.

Elasticsearch Monitoring

Node CPU, heap, disk ve shard metric'leri temel health göstergeleridir. Indexing rate ile query latency birlikte izlenmelidir. Rejection ve circuit breaker event'leri kapasite sorununu erken gösterir. Cluster state update latency master node baskısını gösterebilir. Monitoring alertleri yalnız red cluster durumuna indirgenmemelidir.

Kibana Monitoring

Kibana process memory, event loop latency ve request response süreleri izlenebilir. Alerting task backlog kullanıcı arayüzü normal görünürken sorun yaşayabilir. Birden fazla instance load balancer health'i ayrı kontrol edilir. Saved object migration upgrade sırasında kritik metric'tir. Reporting queue uzunluğu resource ihtiyacını gösterebilir.

Logstash Monitoring

Pipeline event in ve out count veri kaybı araştırmasında temel metric'tir. Filter duration hangi plugin'in CPU tükettiğini gösterebilir. Persistent Queue usage ve DLQ size alarm üretmelidir. Elasticsearch output retry sayısı downstream sorunu gösterir. Pipeline reload failure deployment health gate olarak ele alınmalıdır.

Elastic Agent Monitoring

Agent health Fleet üzerinden izlenebilir. Offline host sayısındaki artış Fleet Server veya network problemi olabilir. Integration input error event shipping'i etkileyebilir. Agent version drift upgrade policy başarısızlığını gösterebilir. Data count ile health state birlikte değerlendirilmelidir çünkü healthy agent yanlış log path nedeniyle sıfır event üretebilir.

Dedicated Monitoring Cluster

Ana Elasticsearch cluster completely unavailable olduğunda aynı cluster'da tutulan monitoring metric'leri de erişilemez olabilir. Critical platform için ayrı küçük monitoring cluster bu kör noktayı azaltır. Maliyet ve operasyon yükü daha yüksektir. Cross-cluster erişim güvenliği tasarlanmalıdır. Dedicated monitoring'in kendisi de backup ve alert gerektirir.

Stack Monitoring Dashboard

Stack Monitoring node ve service health bilgilerini merkezi arayüzde gösterir. Cluster CPU, JVM ve index trendleri hızlı incelenebilir. Default dashboard organization SLO'ları için custom alert ile tamamlanmalıdır. Historical baseline capacity planning'e yardımcı olur. Monitoring data retention normal application logdan farklı olabilir.

Log Pipeline Sağlığı Nasıl Ölçülür?

Pipeline health yalnız service'lerin running olmasına bakılarak ölçülemez. Event/saniye, ingestion lag, queue depth ve failed event sayısı birlikte takip edilmelidir. Elasticsearch indexing latency downstream kapasiteyi gösterir. Synthetic event source'tan Kibana-visible data'ya kadar end-to-end latency ölçebilir. Bu metric'ler pipeline için gerçek SLO oluşturmanın temelidir.

Events Per Second

Kaynak, collector, Logstash input ve Elasticsearch indexed EPS karşılaştırılabilir. Ani düşüş service outage veya collector path problemi gösterebilir. Ani artış incident veya logging bug olabilir. Baseline günün saatine göre değişebilir. EPS alert relative deviation üzerinden daha doğru sonuç verebilir.

Ingestion Lag

Ingestion lag event @timestamp ile Elasticsearch ingest time arasındaki fark olarak ölçülebilir. Normalde birkaç saniye olan lag dakikalara çıkıyorsa queue backlog oluşmuş olabilir. Host clock drift false lag üretebilir. Percentile trend yalnız average'dan daha yararlıdır. SLO örneğin event'lerin yüzde 99'unun 60 saniye içinde aranabilir olması şeklinde tanımlanabilir.

Logstash Queue Depth

Queue depth input ve output hızları arasındaki farkı gösterir. Persistent Queue sürekli büyüyorsa Elasticsearch veya network kapasitesi yetmiyor olabilir. Burst sonrası queue'nun ne kadar sürede boşaldığı recovery capacity'yi gösterir. Queue maximum'a yaklaşmadan alert verilmelidir. Queue metric pipeline bazında ayrı izlenir.

Persistent Queue Usage

Byte usage configured queue.max_bytes değerine oranlanabilir. Yüzde seksen seviyesine gelmeden operator backlog nedenini araştırmalıdır. Queue full olduğunda input backpressure artar. Disk free space queue'dan bağımsız olarak ayrıca alert edilmelidir. Queue drain time maintenance planına girdi sağlar.

DLQ Size

DLQ büyümesi schema veya mapping error anlamına gelebilir. Event count yanında byte size ve oldest event age izlenmelidir. New release sonrası spike deployment correlation sağlar. DLQ consumer repair pipeline başarısı ayrıca ölçülmelidir. Sıfır DLQ hedefi her event'i sessiz drop etmek anlamına gelmemelidir.

Failed Events

Parser, output ve mapping failure count ayrı kategorilerde tutulmalıdır. Top failure reason root cause önceliğini gösterir. Retryable network error permanent schema error'dan ayrılmalıdır. Alert error rate ve absolute count kombinasyonu kullanabilir. Failed sample securely capture edilerek debugging kolaylaştırılabilir.

Elasticsearch Indexing Latency

Bulk indexing latency downstream capacity hakkında önemli sinyal verir. Disk I/O, merge veya heap pressure latency'yi artırabilir. Logstash output batch timeout bundan etkilenir. Indexing latency ile search latency aynı anda yükseliyorsa node saturation olasıdır. Data tier ve index mode bazında metric ayrıştırılabilir.

End-to-End Latency

Source timestamp ile searchable time arasındaki gerçek süre ölçülmelidir. Synthetic event belirli ID ile periyodik gönderilebilir. Collector ve Logstash metric'leri hangi hop'un geciktiğini gösterir. Dashboard kullanıcı deneyimi için bu değer raw service health'ten daha anlamlıdır. Alert delivery SLO da ingestion latency'ye eklenmelidir.

Log Pipeline'da Veri Kaybı Nasıl Tespit Edilir?

Veri kaybı çoğu zaman service tamamen durduğunda değil küçük oranlarda sessizce yaşanır. Source event count ile final indexed count karşılaştırılması en temel yöntemdir. Collector ve Logstash her hop'ta counter sağlarsa kaybın nerede oluştuğu bulunabilir. Sequence ID veya synthetic log eksik kayıtları görünür kılar. Delivery SLO kabul edilebilir loss oranını açıkça tanımlamalıdır.

Source Event Count

Application kaç log event ürettiğini metric olarak sayabilir. Bu sayı collector'ın okuduğu event ile karşılaştırılır. Her log call için counter performans maliyeti yaratıyorsa batch veya sample ölçüm kullanılabilir. Important audit event ayrı counter tutabilir. Source restart counter reset davranışı monitoring tarafından anlaşılmalıdır.

Collector Event Count

Filebeat veya Agent input event counter source'a yakın gerçek okuma miktarını gösterir. Source count yüksek collector count düşükse path veya permission problemi olabilir. Output event count ile input event count queue backlog'u gösterir. Drop processor intentionally removed event'leri ayrı metric'te göstermelidir. Agent health sıfır data problemiyle birlikte incelenmelidir.

Logstash Input/Output Count

Logstash pipeline input ve output event sayısı filter drop veya failure etkisini gösterir. Normal intentional drop oranı baseline olarak bilinir. Output count geride kalıyorsa queue büyümesi beklenir. Conditional route bir event'i iki output'a gönderiyorsa raw count yorumunda duplication hesaba katılmalıdır. Pipeline ID bazında metric tutulmalıdır.

Elasticsearch Indexed Count

Elasticsearch data stream indexing rate final storage'a ulaşan event miktarını gösterir. Refresh gecikmesi query-visible count ile immediate indexing count arasında kısa fark yaratabilir. Mapping reject event'leri output success sayısından düşebilir. DLQ ve bulk failure metric'leri bu farkı açıklar. Daily reconciliation dataset bazında yapılabilir.

Sequence ID

Event source monoton sequence numarası üretebiliyorsa missing range tespit edilebilir. Distributed service'de global sequence üretmek pahalı olabilir. Per-instance sequence yeterli olabilir. Restart sonrası epoch veya instance ID ile sequence yeniden başlatılabilir. Audit system gibi kayıpsız gereksinimlerde güçlü yöntemdir.

Synthetic Log

Scheduled job belirli unique ID içeren test event üretir. Monitoring Elasticsearch'te bu ID'yi belirli süre içinde arar. Bulamazsa pipeline end-to-end alert verir. Synthetic event normal retention ve parser yolundan geçmelidir. Çok sık üretmek gereksiz data oluşturacağından SLO'ya uygun interval seçilir.

Delivery SLO

Örneğin application loglarının yüzde 99,99'unun 60 saniye içinde Elasticsearch'te aranabilir olması hedeflenebilir. Security audit data daha sıkı loss tolerance isteyebilir. SLO measurement source count ve synthetic event kullanabilir. Error budget pipeline iyileştirme önceliğini belirler. SLO yalnız dokümanda değil dashboard ve alertlerle izlenmelidir.

Log Yönetimi İçin SLO Nasıl Belirlenir?

Log platformunun da uygulamalar gibi ölçülebilir hizmet hedefleri olmalıdır. Ingestion availability, maximum lag, search availability ve retention guarantee temel SLO alanlarıdır. Her dataset aynı hedefi gerektirmez. Security audit logları kayba karşı daha sıkı, low-value debug logları daha esnek olabilir. SLO'lar ekip kapasitesi ve storage maliyetiyle gerçekçi biçimde belirlenmelidir.

Ingestion Availability

Collector'ın event kabul edip storage'a iletebildiği zaman oranı ölçülür. Planned maintenance SLO calculation politikasına göre ayrı değerlendirilebilir. Redundant Logstash ve Elasticsearch node'ları availability'yi artırır. Kafka veya Persistent Queue kısa kesintileri görünmez hale getirebilir. SLO end-to-end success üzerinden ölçülmelidir.

Maximum Ingestion Lag

Log birkaç saat sonra aranabilir oluyorsa incident sırasında pratik değeri düşer. P95 ve p99 lag threshold belirlenmelidir. Normal operation ile backlog recovery için farklı hedef olabilir. Clock synchronization lag ölçümünün doğruluğunu etkiler. Alert threshold queue capacity dolmadan müdahale edecek kadar erken olmalıdır.

Search Availability

Kibana UI ve Elasticsearch query endpoint'inin erişilebilirliği birlikte ölçülebilir. Cluster green olmak search request success'i garanti etmez. Representative saved query synthetic monitor tarafından çalıştırılabilir. Slow query de availability SLO'nun latency bileşeni olabilir. Historical frozen data için farklı latency hedefi tanımlanabilir.

Retention Guarantee

Policy belirli dataset'in en az kaç gün erişilebilir kalacağını garanti eder. Lifecycle bug nedeniyle erken deletion ciddi veri kaybıdır. Daily check en eski available event timestamp'ini doğrulayabilir. Snapshot retention separate disaster recovery policy olarak izlenmelidir. Legal retention için audit evidence saklanabilir.

Veri Kaybı Toleransı

Her log type sıfır loss gerektirmeyebilir. Debug loglarında çok düşük oranda loss kabul edilebilirken financial audit event'lerinde kabul edilemez olabilir. Requirement transport ve buffering tasarımını belirler. UDP gibi protocol critical audit için uygun olmayabilir. SLO farklı dataset'lerde farklı delivery guarantee tanımlar.

Alert Delivery

Log event Elasticsearch'e ulaşsa bile alert connector çalışmıyorsa incident notification gecikebilir. Alert evaluation ve notification delivery ayrı SLO olarak izlenmelidir. Synthetic rule düzenli test alert gönderebilir. Connector credential expiration veya webhook network failure görünür olur. On-call channel değişikliği automation ile güncellenmelidir.

Elasticsearch Backup Nasıl Alınır?

Elasticsearch için desteklenen backup yöntemi snapshot mekanizmasıdır. Elastic'in resmi dokümantasyonu node data directory'sini filesystem seviyesinde kopyalamanın güvenilir veya desteklenen cluster backup yöntemi olmadığını açıkça belirtir. Snapshot repository S3 uyumlu object storage veya supported shared filesystem gibi cluster dışı yerde tutulabilir. Snapshot Lifecycle Management periyodik snapshot ve retention'ı otomatikleştirebilir. Backup gerçekten değerli sayılmak için restore testinden geçmelidir.

Elasticsearch Data Dizinini Kopyalamak Neden Yeterli Değildir?

Cluster node'larının data directory'leri aynı exact point-in-time state'i temsil etmeyebilir. Elasticsearch consistency birden fazla shard ve node arasında koordine edilir. Elastic dokümantasyonu node'ları durdurup filesystem copy almanın bile desteklenen backup olmadığını belirtir. Raw directory restore corruption veya sessiz data kaybına yol açabilir. Backup yalnız snapshot API üzerinden yapılmalıdır.

Snapshot Repository

Snapshot alınmadan önce cluster dışı repository register edilir. Repository data node diskinden farklı failure domain'de olmalıdır. Object storage veya supported filesystem backend kullanılabilir. Repository content Elasticsearch dışındaki process tarafından değiştirilmemelidir. Access credential snapshot service için minimum permission taşımalıdır.

S3

Object storage büyük snapshot setleri için ölçeklenebilir backend sunabilir. Repository plugin veya built-in cloud integration deployment modeline göre kullanılır. Bucket encryption ve lifecycle policy uygulanmalıdır. Cross-region veya account isolation disaster recovery ihtiyacına göre değerlendirilebilir. Network egress ve storage request maliyeti backup bütçesine dahil edilmelidir.

Shared Filesystem

Supported shared filesystem repository self-managed cluster'da kullanılabilir. Bütün gerekli node'lar aynı repository path'e uygun permission ile erişebilmelidir. Filesystem başka process tarafından snapshot content üzerinde değişiklik yapmamalıdır. Storage failure Elasticsearch cluster ile aynı physical hosta bağlı olmamalıdır. Backup repository'nin kendisi ayrıca korunabilir.

Snapshot

Snapshot running cluster'dan alınabilir ve segment bazlı incremental davranıştan faydalanır. Snapshot index ve data stream yanında cluster state ve feature state bilgilerini de içerebilir. Closed index behavior ve version compatibility restore planında dikkate alınmalıdır. Snapshot success status monitoring'e alınmalıdır. Tek successful snapshot disaster recovery planının tamamı değildir.

Snapshot Lifecycle Management

SLM schedule üzerinden snapshot oluşturmayı ve retention yönetimini otomatikleştirir. Policy günlük veya saatlik RPO ihtiyacına göre belirlenebilir. Snapshot failure alert edilmelidir. Repository capacity ve old snapshot cleanup izlenir. Policy change backup compliance review'undan geçmelidir.

Retention

Snapshot retention production index retention'dan farklı olabilir. Son yedi daily, dört weekly ve birkaç monthly snapshot örnek policy olabilir. Gerçek değer business RPO, compliance ve storage maliyetine göre seçilir. Çok kısa retention delayed corruption discovery durumunda risk yaratabilir. Çok uzun retention PII deletion ve maliyet sorunları doğurabilir.

Snapshot Restore Nasıl Test Edilir?

Backup job'un successful görünmesi restore edilebilir olduğu anlamına gelmez. Ayrı test cluster düzenli aralıklarla snapshot restore etmelidir. Random data stream veya kritik system feature state geri yüklenebilir. Kibana dashboard, index template ve alert gibi feature state'ler gerekirse ayrıca doğrulanır. Disaster recovery tatbikatı RTO'nun teorik değil gerçek süre olarak ölçülmesini sağlar.

Backup Başarılı Demek Restore Edilebilir Demek Değildir

Repository permission veya version compatibility problemi restore sırasında ortaya çıkabilir. Snapshot metadata success olsa bile operation runbook hatalı olabilir. Restore test engineer'ın adımları gerçekten çalıştırabildiğini gösterir. Test sonucu data count ve representative query ile doğrulanmalıdır. Backup KPI yalnız created snapshot sayısı değil successful restore oranını da içermelidir.

Test Cluster

Restore production cluster üzerine doğrudan denenmemelidir. Isolated test cluster aynı veya compatible Elasticsearch sürümünü kullanır. Network production data outputlarından ayrılır. Restore sonrasında integration veya application test query çalıştırılabilir. Test cluster işlem sonunda güvenli biçimde silinir.

Index Restore

Belirli index veya data stream snapshot'tan seçilerek restore edilebilir. Name conflict varsa rename pattern kullanılabilir. Document count ve sample hash compare yapılabilir. Mapping ve settings beklendiği gibi gelmelidir. Restore throughput gerçek RTO tahmini için ölçülür.

Data Stream Restore

Data stream restore backing index ve stream metadata'sını uygun şekilde geri getirir. Lifecycle policy'nin restore sonrasında beklenen behavior göstermesi kontrol edilmelidir. Write index state test edilir. Integration template version compatibility ayrıca değerlendirilebilir. Historical query eski backing index'leri bulmalıdır.

Kibana Feature State

Snapshot feature state Kibana saved objects gibi sistem verilerini içerebilir. Restore hangi feature state'in alınacağını açıkça seçmelidir. Security configuration ve credentials backup semantics ayrıca anlaşılmalıdır. Dashboard ve alert rule restore sonrasında UI'da doğrulanır. Environment-specific connector credential'lar test cluster'da notification göndermemelidir.

Restore Doğrulama

Document count tek doğrulama değildir. Representative KQL veya ES|QL query sonuçları expected değerle karşılaştırılabilir. Dashboard yüklenir ve data görünür. Lifecycle, template ve ingest pipeline configuration kontrol edilir. Restore report audit artifact olarak saklanabilir.

Disaster Recovery Tatbikatı

Belirli aralıklarla tam cluster kaybı senaryosu simüle edilebilir. Yeni infrastructure provision edilir ve snapshot repository bağlanır. Critical data restore edilir. Application veya Kibana access doğrulanır. Gerçek tamamlanma süresi RTO hedefiyle karşılaştırılır ve runbook eksikleri düzeltilir.

Elasticsearch High Availability

High availability node failure durumunda cluster'ın hizmet vermeye devam etmesini hedefler. Replica shard data availability sağlar, master-eligible çoğunluk cluster state kararlarını devam ettirir. Elastic'in güncel önerisinde resilient cluster için en az üç master-eligible node bulunması gerekir. Availability zone dağılımı aynı physical failure'ın bütün kopyaları etkilemesini önler. Snapshot ise HA değil disaster recovery aracıdır.

Replica

Replica primary shard'ın başka node üzerindeki kopyasıdır. Primary node kaybolduğunda replica promote edilebilir. Bir replica ile tek node failure'a karşı data copy korunabilir. Replica aynı zone içinde kalırsa zone failure'a karşı koruma sağlamaz. Shard allocation awareness zone distribution için kullanılabilir.

Multi-Node Cluster

Multi-node cluster workload ve shard kopyalarını farklı hostlara dağıtır. Node sayısı üç olmak tek başına HA garantisi değildir. Master, data role ve replica distribution doğru olmalıdır. Client request birden fazla endpoint'e gidebilmelidir. Maintenance tek node'u durdururken cluster çoğunluğu korunmalıdır.

Availability Zone

Zone farklı power ve network failure domain'ini temsil eder. Data copy'ler mümkün olduğunca farklı zone'larda tutulmalıdır. Üç zone varsa master-eligible node'ların zone'lara dağıtılması resilient seçimdir. Cross-zone network latency düşük ve stabil olmalıdır. Snapshot repository zone failure'dan bağımsız olmalıdır.

Master-Eligible Nodes

Elasticsearch cluster state çoğunluk kararına dayanır. Üç master-eligible node bir node kaybında kalan iki node ile master seçimini sürdürebilir. Elastic daha büyük cluster'larda master role'larını dedicated node'lara ayırmayı önerebilir. Master node disk ve network latency cluster management işlemlerini etkiler. Çok sayıda gereksiz master-eligible node seçim süresini artırabilir.

Node Failure

Node unreachable olduğunda primary veya replica shard'lar kalan node'larda yeniden atanabilir. Recovery disk ve network üzerinde yük oluşturur. Cluster green'e dönene kadar redundancy azalabilir. Capacity bir node kaybında remaining node'ların production traffic'i taşıyabileceği şekilde planlanmalıdır. Node failure alert infrastructure owner'a anında gitmelidir.

Disk Failure

Disk failure node data'sını unavailable hale getirebilir. Replica başka node üzerinde olmalıdır. Local RAID replica ve cluster-level redundancy'nin yerine geçmez. Failed node restore edilmek yerine yeni clean node cluster'a eklenebilir. Permanent data loss riski snapshot ile disaster recovery katmanında azaltılır.

Snapshot'ın HA Yerine Geçmemesi

Snapshot restore zaman alır ve service downtime yaratabilir. HA ise failure anında service continuity sağlar. Replica ve quorum olmadan yalnız günlük snapshot kullanan single node production uzun kesinti yaşayabilir. İki yaklaşım birbirini tamamlar. Architecture hem node failure hem bölgesel disaster senaryosunu ayrı ele almalıdır.

ELK Upgrade Nasıl Yapılır?

Elastic Stack upgrade release note, compatibility, snapshot ve staging testleriyle planlanmalıdır. Elasticsearch rolling upgrade desteklenen version path üzerinden yapılır. Kibana ve Logstash version'ları stack compatibility kuralına göre ilerletilir. Upgrade öncesi snapshot alınmalı fakat rollback yalnız package downgrade olarak düşünülmemelidir. Post-upgrade query, dashboard, ingestion ve alert smoke testleri tamamlanmalıdır.

Release Notes

Release note breaking change, deprecation ve known issue bilgisi sağlar. Plugin ve integration compatibility ayrıca kontrol edilmelidir. Patch release bile query behavior veya bug fix içerebilir. Upgrade ticket ilgili release note risklerini özetlemelidir. Known critical issue varsa target patch yeniden seçilebilir.

Version Compatibility

Elastic Stack component version'ları resmi compatibility guidance ile eşleştirilmelidir. Elasticsearch cluster node'ları rolling upgrade sırasında geçici mixed version çalışabilir ancak yalnız desteklenen sıra ve sınırlar içinde. Kibana target Elasticsearch version ile uyumlu olmalıdır. Agent ve integration compatibility ayrıca gözden geçirilir. Eski client library minimum compatibility test edilir.

Snapshot

Upgrade öncesi recent successful snapshot bulunmalıdır. Snapshot repository health test edilir. Restore runbook yalnız kağıt üzerinde kalmamalıdır. Snapshot version compatibility downgrade yerine yeni cluster restore stratejisini etkiler. Configuration files ve secret metadata snapshot dışında ayrıca backup edilmelidir.

Upgrade Assistant

Major upgrade öncesi deprecation ve incompatible index durumlarını tespit eden araçlar kullanılabilir. Kibana Upgrade Assistant varsa recommended remediation adımları izlenir. Old index version archive veya reindex gerektirebilir. Deprecated setting'ler infrastructure code'dan temizlenmelidir. Assistant output change checklist'e eklenebilir.

Staging Test

Production log sample'ına benzer data staging cluster'da upgrade edilir. Logstash pipeline, Agent integration ve dashboard'lar doğrulanır. Snapshot restore ve lifecycle behavior test edilir. Performance benchmark eski sürümle karşılaştırılır. Staging production config'in güvenli kopyasına mümkün olduğunca yakın olmalıdır.

Rolling Upgrade

Node'lar desteklenen sırayla tek tek upgrade edilerek cluster availability korunabilir. Master-eligible çoğunluğun aynı anda durdurulmaması gerekir. Elastic troubleshooting dokümantasyonu production'da en az üç master-eligible node bulunmasını ve upgrade sırasında yarısından fazlasının durdurulmamasını özellikle vurgular. Node geri döndüğünde cluster health kontrol edilir. Bir sonraki node'a geçmeden shard recovery durumu değerlendirilmelidir.

Post-Upgrade Validation

Cluster green state, indexing ve search smoke testleri çalıştırılır. Kibana dashboard ve alert action doğrulanır. Logstash throughput ile DLQ trend'i karşılaştırılır. Agent health ve integration data stream'leri kontrol edilir. Performance regression birkaç saat gerçek trafik altında izlenir.

Rollback Planı

Elasticsearch upgrade rollback her zaman eski package'a dönmek kadar basit değildir. Snapshot version compatibility ve index formatı dikkate alınmalıdır. Major upgrade için eski cluster'ı snapshot'tan yeniden oluşturma planı gerekebilir. Application producer yeni schema'yı eski cluster ile uyumlu tutmalıdır. Rollback decision threshold change başlamadan önce belirlenmelidir.

Dev, Staging ve Production ELK Ortamları

Log altyapısının development ve production ortamları birbirinden ayrılmalıdır. Test uygulamasının yüksek hacimli dummy logları production alert'lerini etkilememelidir. Ayrı cluster en güçlü izolasyonken küçük sistemlerde ayrı namespace ve access policy kullanılabilir. Production PII development cluster'a kopyalanmamalıdır. Dashboard ve pipeline configuration code üzerinden environment'lar arasında kontrollü promote edilmelidir.

Ayrı Cluster

Production ve non-production için ayrı Elasticsearch cluster data ve failure isolation sağlar. Staging load test production storage'ı etkilemez. Security credential tamamen ayrılır. Maliyet daha yüksektir. Critical regulated environment'ta bu izolasyon çoğu zaman değerlidir.

Ayrı Namespace

Aynı cluster kullanılıyorsa data stream namespace environment ayrımında kullanılabilir. Role production namespace erişimini sınırlandırır. Lifecycle dev data için daha kısa tutulabilir. Shared cluster resource contention yine devam eder. Test mapping explosion production master state'i etkileyebileceğinden güçlü guard gerekir.

Ayrı Retention

Development logları birkaç gün yeterli olabilir. Production incident ve audit ihtiyacı daha uzun retention gerektirir. Lifecycle policy namespace veya dataset bazında atanabilir. Staging load test data'sı otomatik hızlı silinmelidir. Storage cost raporu environment'a göre ayrılabilir.

Test Logları

Test environment synthetic veya anonymized data kullanmalıdır. Production credential ve user PII bulunmamalıdır. Parser fixture testleri gerçek formatı temsil ederken hassas value içermemelidir. Performance test log volume production peak'e yakın olabilir. Test sonunda data lifecycle otomatik cleanup yapmalıdır.

Production PII

Production kişisel veri development log cluster'a taşınmamalıdır. Incident reproduction business ID ve synthetic scenario ile yapılabilir. Gerekli sample anonymization security review'dan geçmelidir. Production dashboard screenshot bile PII taşıyabileceği için paylaşım controlled olmalıdır. Access logları audit edilmelidir.

Dashboard Promotion

Dashboard development veya staging Space içinde hazırlanabilir. Saved object export veya API automation production'a promote edebilir. Production'da elle düzenleme drift yaratabilir. Data view ID ve namespace environment'a göre parameterize edilmelidir. Dashboard regression screenshot veya query test ile doğrulanabilir.

Configuration as Code

Index template, pipeline, role ve lifecycle policy repository'de deklaratif tanım olarak tutulabilir. CI syntax ve simulate test çalıştırır. Production change review ve approval ile uygulanır. Secret değer repository dışında kalır. Rollback previous configuration commit'e dönmeyi kolaylaştırır.

ELK Kurulumu Nasıl Otomatikleştirilir?

Manual SSH komutları küçük lab için yeterli olabilir ancak production reproducibility için infrastructure automation gerekir. Bash başlangıç bootstrap script'i olarak kullanılabilir. Ansible package ve configuration yönetimini, Terraform infrastructure provisioning'i üstlenebilir. Kubernetes'te Helm veya Elastic Cloud on Kubernetes declarative deployment sağlar. Hedef her node'un aynı standardı tekrar üretebilmesi ve değişikliklerin review edilebilir olmasıdır.

Bash

Bash birkaç host için bootstrap ve health check automation sağlayabilir. Package repository ekleme ve service start adımları script'e alınabilir. Script idempotent değilse ikinci çalıştırmada configuration bozabilir. Secret command-line argument veya stdout'a yazılmamalıdır. Sistem büyüdüğünde Ansible gibi state-aware araç daha uygun olabilir.

Ansible

Ansible package, config file ve systemd service state'ini deklaratif yönetebilir. Inventory node role ve environment bilgisini taşır. Template elasticsearch.yml üretir. Vault veya external secret integration hassas değerleri korur. Rolling upgrade batch size ile node'lar sırayla güncellenebilir.

Terraform

Terraform VM, network, firewall ve managed service infrastructure'ını oluşturabilir. Elasticsearch internal config için provider veya başka automation ile birlikte kullanılabilir. State file secret içerme riski taşıdığı için backend security önemlidir. Plan çıktısı change review sağlar. Provisioning ile application configuration responsibility ayrılmalıdır.

Docker Compose

Compose development ELK stack'i tek command ile başlatabilir. Version ve network config repository'de tutulur. Volume persistent data sağlar. Security certificate initialization automation script ile yapılabilir. Production multi-host availability ihtiyacı Compose sınırlarının dışındadır.

Helm

Kubernetes package deployment Helm chart ile template edilebilir. Resource, ingress ve secret reference values environment bazında değişir. Stateful Elasticsearch için chart'ın lifecycle ve upgrade desteği dikkatle değerlendirilmelidir. Generic chart yerine supported operator daha güvenli olabilir. Helm release history rollback için sınırlı deployment metadata sağlar ancak data rollback ayrı konudur.

Elastic Cloud on Kubernetes

ECK Kubernetes operator pattern'iyle Elasticsearch ve Kibana resource'larını yönetir. TLS certificate ve rolling operation gibi görevleri automation sağlar. Stateful storage ve node role spec deklaratif tanımlanabilir. Operator version compatibility cluster upgrade planına dahil edilmelidir. Kubernetes CR backup yerine Elasticsearch snapshot yine gereklidir.

Infrastructure as Code

IaC network, compute ve configuration'ın review edilebilir tanımını oluşturur. Production ile staging drift azalır. Change Pull Request üzerinden incelenebilir. Secret code'dan ayrı backend'de tutulur. Disaster recovery sırasında environment daha hızlı yeniden oluşturulabilir.

ELK Stack Docker Compose ile Kurulmalı mı?

Docker Compose local development ve eğitim ortamında ELK kurulumu için çok kullanışlıdır. Bütün component version'ları aynı dosyada sabitlenebilir. Persistent volume ve private network oluşturmak kolaydır. Production tek host kullanımında da teknik olarak çalışabilir ancak host failure tüm stack'i etkileyebilir. Critical cluster availability gerekiyorsa multi-node orchestration veya dedicated VM yaklaşımı daha uygun olabilir.

Avantajları

Tek command ile stack başlatılabilir. Environment version repository'de açıkça görünür. Lab reset ve test hızlıdır. Developer laptop'ta application ile birlikte log pipeline kurulabilir. CI integration test için ephemeral environment oluşturmak kolaydır.

Dezavantajları

Tek Docker host failure bütün container'ları etkiler. Elasticsearch storage host volume veya named volume lifecycle'a bağlıdır. Memory limit yanlışsa host OOM yaşayabilir. Certificate ve secret bootstrap başlangıçta ek script gerektirir. Compose multi-host scheduler veya cluster self-healing sağlamaz.

Persistent Volume

Elasticsearch data container writable layer'da tutulmamalıdır. Named volume veya bind mount persistent storage kullanılabilir. Volume silmek cluster data'sını kaybettirebilir. Snapshot volume backup'tan farklıdır ve yine gereklidir. Permission container user ile uyumlu olmalıdır.

Container Memory

Elasticsearch container memory limitini bilmeli ve heap sizing buna göre çalışmalıdır. Hostta limit olmadan birden fazla service birbirinin belleğini tüketebilir. Logstash için ayrı limit gerekir. OOM event container restart loop oluşturabilir. Docker stats ile resource trend ölçülmelidir.

Networking

Compose internal network Elasticsearch ve Logstash iletişimini private tutabilir. Yalnız Kibana proxy veya gerekli portlar host'a publish edilir. 9200 developmentta bile yalnız localhost'a bind edilebilir. Service discovery container name yerine Compose service adıyla yapılır. Production public interface exposure final config üzerinde kontrol edilmelidir.

Secret Management

Compose YAML içine password veya encryption key yazılmamalıdır. Docker secrets veya external secret file yaklaşımı kullanılabilir. Local development dummy credential gerçek production'dan tamamen ayrıdır. .env file Git'e eklenmemelidir. Production secret rotation Compose recreate behavior ile test edilmelidir.

Lab vs Production

Lab tek node ve düşük retention kullanabilir. Production multi-node, backup ve TLS gerektirir. Lab certificate warning'ini kapatmak production pattern olmamalıdır. Compose lab sayesinde parser ve dashboard test edilebilir. Deployment model değişse bile ECS schema ve pipeline logic mümkün olduğunca aynı tutulmalıdır.

Kubernetes Üzerinde Elastic Stack

Kubernetes Elasticsearch için scheduling ve persistent volume altyapısı sağlar ancak stateful cluster behavior ayrı uzmanlık gerektirir. Elastic Cloud on Kubernetes operator supported lifecycle yönetimini kolaylaştırabilir. Node role, storage class ve resource request dikkatle tasarlanmalıdır. TLS ve secret operator tarafından üretilebilse de access policy ayrıca belirlenmelidir. Kubernetes backup mekanizması Elasticsearch snapshot'ın yerini tutmaz.

Elastic Cloud on Kubernetes

ECK custom resource üzerinden Elasticsearch cluster tanımlar. Operator desired state ile pod lifecycle yönetir. Certificate ve service discovery birçok durumda otomatik kurulur. Upgrade spec version değişikliğiyle kontrollü rolling işlem yapabilir. Operator ve stack version compatibility resmi matrix üzerinden doğrulanmalıdır.

StatefulSet Mantığı

Stateful workload stable storage identity gerektirir. Elasticsearch pod replacement persistent volume ile ilişkilendirilir. Ancak cluster shard replication application-level redundancy sağlar. Pod name ve PVC tek başına backup değildir. Node drain ve zone failure behavior staging cluster'da test edilmelidir.

Persistent Volume

Data path hızlı ve durable persistent volume üzerinde tutulmalıdır. Storage class topology zone distribution ile uyumlu olmalıdır. Volume expansion supported ise capacity increase daha kolay olabilir. Snapshot repository yine cluster dışı object storage olarak yapılandırılmalıdır. Kubernetes volume snapshot Elasticsearch backup yerine kullanılmamalıdır.

Node Roles

Hot data, master ve ingest roller farklı nodeSet'lerde tanımlanabilir. Resource profile role'a göre seçilir. Dedicated master pod'a data workload gönderilmemelidir. Zone topology spread availability'yi artırır. Role değişikliği cluster migration planıyla yapılmalıdır.

TLS

ECK internal certificate üretimini otomatikleştirebilir. External ingress certificate kurum standardına göre yönetilebilir. Agent veya Logstash trust bundle doğru secret'tan alınmalıdır. Verification kapatılmamalıdır. Certificate rotation operator tarafından yapılsa bile expiry monitoring faydalıdır.

Rolling Upgrade

Operator node'ları uygun sırayla güncelleyebilir. Cluster health ve shard availability upgrade sırasında izlenir. Pod disruption budget ve Kubernetes drain davranışı çoğunluk kaybına yol açmamalıdır. Major upgrade release note ayrıca takip edilir. Rollback data formatı nedeniyle yalnız deployment spec geri almak değildir.

Resource Requests ve Limits

Request scheduler'ın node capacity planını belirler. Limit OOM veya throttling riskini etkiler. Elasticsearch memory request ile JVM heap ve page cache birlikte düşünülmelidir. CPU limit çok düşükse indexing ve GC latency artabilir. Vertical scaling change shard recovery ve pod restart etkisiyle planlanmalıdır.

ELK'nin Maliyeti Nasıl Hesaplanır?

ELK maliyeti yalnız disk fiyatı değildir. Günlük ingestion, retention, replica ve data tier storage temel altyapı maliyetini belirler. Compute indexing ve dashboard query workload'u için gereklidir. Snapshot storage ve network transfer ayrıca eklenir. Self-managed yapıda operasyon ekibinin upgrade, backup ve incident zamanı da gerçek maliyetin önemli bölümüdür.

GB/Gün

Indexed GB/gün storage growth'un temel metriğidir. Raw source GB ile Elasticsearch stored size farklı olabilir. LogsDB ve compression oranı gerçek data üzerinde ölçülür. Product traffic growth forecast'a eklenir. Ingestion maliyeti managed hizmetlerde doğrudan fiyat metriği olabilir.

Retention

Retention uzadıkça toplam stored data büyür. Hot tier yerine eski data warm veya cold tier'a taşınabilir. Dataset bazında farklı süre maliyeti azaltır. Debug log kısa retention alabilir. Compliance gereksinimi daha uzun storage'ı zorunlu kılabilir.

Replica

Replica data copy sayısını artırır. Bir replica kabaca primary data için ikinci kopya storage gerektirir ancak compression ve tier behavior değişebilir. Availability için bu maliyet çoğu production sistemde gereklidir. Old searchable snapshot data farklı replica modeline geçebilir. Cost calculator availability trade-off'u açıkça göstermelidir.

Storage

Hot SSD GB başına daha pahalı olabilir. Warm ve cold tier daha ekonomik disk kullanabilir. IOPS ve throughput requirement yalnız kapasiteden daha önemli olabilir. Disk headroom watermark nedeniyle usable capacity'den düşülmelidir. Snapshot repository storage ayrıca hesaplanır.

Compute

Data node CPU ve RAM indexing ile search workload'a bağlıdır. Logstash parsing worker ayrıca compute kullanır. Kibana ve Fleet Server daha küçük fakat ayrı service katmanlarıdır. Peak incident query normal günlük yükten daha ağır olabilir. Capacity average değil peak ve failure mode üzerinden planlanmalıdır.

Network

Collector data center dışındaki Elasticsearch'e gönderiyorsa network egress maliyeti oluşabilir. Replica recovery zone'lar arası trafik yaratabilir. Snapshot object storage transferi ayrıca ücretlendirilir. Compression network kullanımını azaltabilir. Multi-region cluster yüksek availability ile ciddi network maliyeti oluşturabilir.

Snapshot Storage

Snapshot incremental segment reuse sayesinde full copy toplamından daha verimli olabilir. Retention arttıkça repository yine büyür. Cross-region copy disaster recovery maliyetini artırır. Restore test network ve retrieval fee oluşturabilir. Snapshot storage budget backup policy'nin parçası olmalıdır.

Operasyonel İnsan Maliyeti

Self-managed cluster upgrade, capacity ve incident müdahalesi ekip zamanı kullanır. Haftalık birkaç saat bakım yıllık ciddi maliyete dönüşebilir. Managed service daha yüksek infrastructure fiyatına rağmen engineer zamanını azaltabilir. On-call complexity de hesaba katılmalıdır. Tool seçimi yalnız lisans veya VM fiyatına göre yapılmamalıdır.

Log Maliyetini Nasıl Azaltırız?

En etkili maliyet optimizasyonu gereksiz logu hiç üretmemektir. Sürekli debug logging ve duplicate event'ler storage ile ingestion maliyetini doğrudan büyütür. Retention dataset değerine göre ayrılmalıdır. High-cardinality ve gereksiz field'lar mapping ile query maliyetini artırabilir. LogsDB, cold/frozen storage ve sampling ancak doğru logging policy'nin ardından ikinci optimizasyon katmanı olarak düşünülmelidir.

Gereksiz Debug Loglarını Kapatmak

Debug loglar event hacmini birkaç kat artırabilir. Production default level info veya daha uygun business seviyesi olmalıdır. Incident sırasında belirli service için süreli debug açılabilir. Otomatik timeout debug mode'u kapatır. Debug volume alert yanlışlıkla sürekli açık bırakılan logger'ı tespit eder.

Log Level Politikası

Error gerçekten operator action gerektiren problem anlamına gelmelidir. Her expected validation error'u error seviyesine yazmak alert gürültüsü oluşturur. Info high-volume request log ile business event ayrılabilir. Level standardı logging guideline içinde tanımlanmalıdır. Dashboard error rate bu standarda güvenebilmelidir.

Gereksiz Field'ları Drop Etmek

Large header, cookie veya duplicate metadata Elasticsearch'e gönderilmeden kaldırılabilir. Field usage analysis dashboardlarda hiç kullanılmayan alanları gösterir. Security için secret field drop zorunludur. Drop işlemi producer veya collector'da yapılabilir. Raw forensic archive ihtiyacı varsa ayrı controlled stream kullanılabilir.

Sampling

Çok yüksek hacimli success access loglarının küçük kısmı performans trendi için yeterli olabilir. Error ve security event sampling dışında tutulmalıdır. Sampling rate event'e field olarak eklenirse aggregation doğru normalize edilebilir. Deterministic sampling belirli user veya trace sequence'ini koruyabilir. Compliance loglarında sampling uygulanmadan önce risk değerlendirmesi yapılmalıdır.

Deduplication

Aynı error'un retry loop nedeniyle saniyede binlerce kez loglanması gereksiz maliyet yaratır. Application rate limit veya summarized counter kullanabilir. Central pipeline duplicate drop yapacaksa gerçek distinct event kaybı riski vardır. Fingerprint key dikkatle tasarlanmalıdır. Root cause retry loop'un kendisini düzeltmek en iyi çözümdür.

Retention Optimizasyonu

Dataset query frequency ölçülerek retention yeniden belirlenebilir. Son altı ayda hiç aranmayacak debug data'yı 180 gün hot storage'da tutmak gereksizdir. Security log farklı retention kullanabilir. Data Stream Lifecycle veya ILM policy otomatik silme sağlar. Policy değişikliği compliance approval almalıdır.

Cold/Frozen Storage

Eski data daha ucuz tier'a taşınabilir. Searchable snapshot local disk ihtiyacını azaltabilir. Query latency daha yüksek kabul edilir. Investigation kullanıcılarına historical query'nin yavaş olacağı açıklanmalıdır. Dashboard default range hot data'yı hedeflemelidir.

LogsDB

Elastic Stack 9.x log data stream'lerinde LogsDB storage optimizasyonu sağlayabilir. Elastic benchmark'ları belirli dataset'lerde yüksek storage tasarrufu göstermektedir. Kendi log schema'nızda sonuç farklı olabilir. Indexing throughput etkisi benchmark edilmelidir. Existing upgraded stream'lerin mode'u ayrıca kontrol edilmelidir.

High-Cardinality Alanları Azaltmak

Her request header veya query param ayrı keyword field olmamalıdır. Normalized route raw URL yerine aggregation için kullanılabilir. Session token tamamen drop edilmelidir. Dynamic label object flattened yapılabilir. Field usage raporu hangi high-cardinality alanların gerçekten sorgulandığını gösterebilir.

Elasticsearch, OpenSearch ve Loki Karşılaştırması

Merkezi log platformu seçerken search ihtiyacı, storage modeli ve operasyon ekibinin deneyimi birlikte değerlendirilmelidir. Elasticsearch full-text search, structured analytics ve geniş observability özellikleriyle kapsamlı platform sunar. OpenSearch benzer distributed search yaklaşımına sahip başka bir seçenektir. Loki ise log label indexleme modelini merkeze alarak farklı storage ve query yaklaşımı kullanır. Seçim isim popülerliğine göre değil, gerçek query, retention, entegrasyon ve operasyon ihtiyacına göre yapılmalıdır.

Elasticsearch

Elasticsearch field-level inverted index ve aggregation yetenekleriyle hem text hem structured log analizi sunar. ECS, data streams, lifecycle ve Kibana entegrasyonu geniş observability workflow oluşturur. Mapping ve shard design doğru yapılmalıdır. High-cardinality field ve storage maliyeti kontrol edilmezse cluster büyüyebilir. Complex investigation ve security analytics güçlü kullanım alanlarıdır.

OpenSearch

OpenSearch distributed search ve log analytics senaryolarında kullanılabilen alternatif teknolojidir. Index, shard ve search temelli model Elasticsearch'e kavramsal olarak benzerdir. Plugin, API ve lifecycle özellikleri sürüme göre farklı davranabilir. Migration yapılacaksa compatibility varsayılmamalı ve gerçek query seti test edilmelidir. Operasyon ekibinin mevcut yetkinliği karar üzerinde büyük rol oynar.

Grafana Loki

Loki log body'nin tamamını Elasticsearch tarzında field bazlı indexlemek yerine label odaklı farklı yaklaşım kullanır. Kubernetes ve metric dashboard workflow'larıyla sık tercih edilen kullanım alanları bulunur. Ad-hoc full-text ve structured analytics gereksinimi Elasticsearch'ten farklı performans davranışı gösterebilir. Label cardinality kontrolü kritik konudur. Seçim query pattern ve retention maliyetine göre benchmark edilmelidir.

Full-Text Search

Elasticsearch inverted index sayesinde message ve text field'larda güçlü full-text search sağlar. Bu özellik bilinmeyen incident pattern'lerini ad-hoc aramada değerlidir. Ancak her field full-text indexlenmemelidir. Loki raw log search yaklaşımı farklı trade-off taşır. Gerçek incident query'lerinin benchmark edilmesi araç seçiminde teorik feature listesinden daha faydalıdır.

Structured Analytics

Elasticsearch keyword ve numeric field'lar üzerinde aggregation için güçlüdür. Service error rate veya response time percentile hesaplanabilir. ECS ortak schema query reuse sağlar. Başka log sistemleri de aggregation sunabilir ancak veri modeli farklı olabilir. Dashboard gereksinimleri migration proof of concept içinde denenmelidir.

Storage Modeli

Elasticsearch birçok field için index yapıları oluşturur. Bu hızlı query karşılığında storage ve mapping management gerektirir. LogsDB storage verimliliğini geliştirmeyi hedefler. Loki label index ve chunk storage ile farklı maliyet yapısı sunar. Kendi event boyutu ve query dağılımınız olmadan yalnız benchmark bloglarına göre karar verilmemelidir.

Operasyonel Karmaşıklık

Distributed search cluster shard, replica, lifecycle ve memory yönetimi ister. Label tabanlı sistemler de object storage, compactor ve query component'leri gibi kendi operasyon alanlarına sahiptir. Managed service insan maliyetini azaltabilir. Existing Kubernetes veya Elastic deneyimi tool choice'u kolaylaştırabilir. Platform ekibinin sürdüremeyeceği sistem feature olarak güçlü olsa bile doğru seçim olmayabilir.

Hangi Senaryoda Hangisi Kullanılmalı?

Ad-hoc full-text, security analytics ve zengin structured query ihtiyacı Elasticsearch için güçlü senaryodur. Kubernetes loglarını düşük maliyetli label-based modelle metric ekosisteminde incelemek isteyen ekip farklı seçeneği değerlendirebilir. Existing search cluster altyapısı da maliyet avantajı sağlayabilir. Proof of concept gerçek 7 günlük production sample data ile yapılmalıdır. Query latency, storage ve engineer operasyon süresi birlikte karşılaştırılmalıdır.

ELK Stack Ne Zaman Kullanılmamalıdır?

ELK güçlü olduğu kadar işletilmesi gereken distributed sistemdir. Günlük birkaç megabyte log ve yalnız basit text görüntüleme ihtiyacı için bu yapı gereksiz olabilir. Tek geliştiricili küçük projede local journald veya managed basit logging hizmeti daha ekonomik olabilir. Operasyon ekibi yoksa cluster upgrade ve backup sorumluluğu ihmal edilebilir. Teknoloji seçimi problem boyutuyla orantılı olmalıdır.

Çok Küçük Log Hacmi

Tek sunucuda günlük birkaç megabyte log için full Elasticsearch cluster fazla kaynak tüketebilir. Basit file rotation ve searchable managed hizmet yeterli olabilir. Incident query ihtiyacı çok azsa storage maliyetinden çok operasyon maliyeti önem kazanır. Sistem büyürse merkezi platforma migration planlanabilir. Başlangıç logging schema yine structured tutulmalıdır.

Yalnızca Basit Log Görüntüleme

Tek ihtiyaç son yüz log satırını görmekse Kibana ve distributed search gerekmeyebilir. Container platformun built-in log viewer veya basit aggregation yeterlidir. Full-text historical search değeri yoksa Elasticsearch overhead anlamlı değildir. Security retention requirement bu kararı değiştirebilir. Kullanım senaryosu yazılı olarak tanımlanmalıdır.

Operasyon Ekibi Olmayan Küçük Projeler

Self-managed Elasticsearch bakım, patch ve backup ister. Kimse cluster health'i izlemiyorsa log sistemi incident sırasında kendisi unavailable olabilir. Managed logging çözümü daha düşük operasyon riski sunabilir. Maliyet yalnız aylık service fee değil engineer zamanı üzerinden karşılaştırılmalıdır. Uygulama logging standardı backend'den bağımsız tutulmalıdır.

Çok Düşük Maliyet Önceliği

Full-text index storage belirli kullanımda pahalı olabilir. Low-value high-volume logs için sampling veya cheaper archive gerekebilir. Search yalnız nadiren gerekiyorsa data'yı object storage'da tutup gerektiğinde farklı query yöntemi kullanmak düşünülebilir. Compliance hot search gerektirmeyebilir. Cost per useful query metriği karar için yardımcı olabilir.

Managed Service'in Daha Mantıklı Olduğu Durumlar

Küçük ekip infrastructure operasyonuna zaman ayıramıyorsa managed service değerli olabilir. Node replacement ve bazı backup işlemleri provider tarafından yönetilebilir. Data governance ve access policy sorumluluğu yine ekipte kalır. Vendor cost predictable traffic ile karşılaştırılmalıdır. Exit ve data export stratejisi baştan düşünülmelidir.

Uçtan Uca Örnek: Linux Sunucu Loglarını ELK'ye Aktarmak

Örnek bir production öncesi senaryoda Ubuntu üzerinde Elasticsearch ve Kibana kurulur, Logstash ayrı ingestion service olarak çalıştırılır ve application hostlarda Filebeat kullanılır. System logları Filebeat module ile toplanır. Filebeat TLS üzerinden Logstash'e, Logstash ise HTTPS üzerinden Elasticsearch'e gönderir. Event'ler data stream'e yazılır ve Kibana Discover'da görünür. Son adım dashboard, alert ve retention policy ekleyerek kurulumun operasyonel hale getirilmesidir.

Elasticsearch Kurulumu

Elastic 9.x repository eklenir ve current stable package kurulur. Security auto-configuration TLS certificate'larını oluşturur. elastic password reset tool ile belirlenir. Cluster private network binding ve snapshot repository yapılandırılır. Health green state ve HTTPS curl testiyle doğrulanır.

Kibana Kurulumu

Kibana aynı stack version'da package olarak kurulur. Enrollment token ile Elasticsearch'e bağlanır. Encryption key'ler kalıcı secret olarak tanımlanır. Nginx reverse proxy üzerinden HTTPS yayınlanır. Admin dışı read ve editor kullanıcı rolleri oluşturulur.

Logstash Kurulumu

Logstash aynı version package ile ayrı ingestion hosta kurulur. Beats input 5044 TLS ile açılır. Filter System module kullanıyorsa gereksiz double parsing yapılmaz. Elasticsearch output API key ve CA certificate kullanır. Persistent Queue delivery SLO gerektiriyorsa etkinleştirilir.

Filebeat Kurulumu

Linux application hostlarda Filebeat kurulabilir. System module veya input log path'i tanımlanır. Output Logstash private endpoint'e yönlendirilir. TLS CA validation açık tutulur. Config ve output test başarılı olduktan sonra service başlatılır.

System Module

System module syslog ve auth loglarını parse edebilir. Ingest asset setup gerekli Elasticsearch endpoint üzerinden yapılabilir. Dataset field'ları ECS standardı taşır. Auth loglar security retention policy'ye yönlendirilebilir. Module dashboard custom operation view ile tamamlanabilir.

Logstash Pipeline

Input Beats event kabul eder. Filter yalnız gerekli enrichment ve routing yapar. Output data stream naming metadata'ya göre belirlenir. Parse failure metric izlenir. Pipeline config CI'da fixture event ile test edilir.

Elasticsearch Data Stream

System loglar ilgili logs data stream'e yazılır. Index template mapping ve lifecycle uygular. Rollover backing index boyutunu kontrol eder. LogsDB 9.x uygun stream'lerde storage optimizasyonu sağlayabilir. Namespace production ve staging ayrımını korur.

Kibana Discover

Discover'da son 15 dakika filtrelenir. Host name ve event dataset ile loglar daraltılır. Authentication failure event detayları incelenir. Saved search incident playbook'a eklenir. Timestamp host NTP ile doğrulanır.

Dashboard

Host error count, SSH failure ve sudo event panelleri oluşturulur. Global host ve environment filtreleri eklenir. Dashboard refresh interval cluster yükünü artırmayacak şekilde seçilir. Field naming ECS sayesinde paneller birden fazla hostta çalışır. Dashboard export source control'de saklanabilir.

Alert

Beş dakika içinde belirli sayının üzerinde SSH failure security alert oluşturabilir. Log yokluğu critical host collector failure için ayrı rule olabilir. Notification connector encrypted saved objects key ile korunur. Test alert periyodik olarak çalıştırılır. Alert mesajı ilgili Kibana dashboard time range linkini içerebilir.

Uçtan Uca Örnek: Nginx Log Yönetimi

Nginx access ve error logları web uygulamasının trafik ve failure davranışını anlamak için değerli kaynaktır. Elastic Agent veya Filebeat logları host üzerinden toplayabilir. Default Nginx formatı integration pipeline ile parse edilebilir, custom format varsa ECS mapping ayrıca hazırlanır. HTTP status ve response time dashboard'ları kullanıcı etkisini görünür kılar. 5xx oranındaki artış release sonrası hızlı alert üretebilir.

Nginx Access Logs

Access log request method, path, status ve response byte bilgisi taşır. Log formatına request time eklemek latency analizi sağlar. Raw query string hassas token veya PII içerebilir. Route normalization high-cardinality URL sorununu azaltır. Health check request'leri ayrı field veya filter ile belirlenebilir.

Nginx Error Logs

Error log upstream timeout ve connection problemi gibi altyapı hatalarını gösterir. Severity parse edilerek log.level alanına dönüştürülebilir. Upstream address private topology bilgisi taşıyabilir ancak operasyon için değerlidir. Tek hata saniyede binlerce tekrar ediyorsa alert ve rate limit düşünülmelidir. Access log status ile error log aynı request ID üzerinden ilişkilendirilebilir.

Elastic Agent / Filebeat

Agent integration Nginx log path'lerini takip eder. Hazır ingest pipeline standard formatı ECS alanlarına dönüştürebilir. Custom log formatı varsa parser test edilmelidir. Agent policy environment bazında path override edebilir. Existing Filebeat module ile yeni Agent integration aynı anda çalışırsa duplicate data oluşabilir.

Parsing

Nginx custom log format parser ile birebir eşleşmelidir. Numeric status ve request time doğru type'a çevrilir. Invalid line failure tag alır. Format deployment'ta değişirse parser önce staging'de güncellenmelidir. Structured JSON Nginx log formatı mümkünse parsing'i sadeleştirebilir.

ECS Mapping

Client IP, HTTP method ve status ECS karşılıklarına map edilir. URL path ve domain ayrı alanlarda tutulabilir. User agent parser gerektiğinde eklenir. Service name reverse proxy instance yerine logical Nginx service'i gösterir. Host metadata agent tarafından eklenebilir.

HTTP Status Analizi

Status code class aggregation 2xx, 4xx ve 5xx trendlerini gösterir. 404 crawler traffic ile application broken link birbirinden route bazında ayrılabilir. 401 ve 403 security açısından ayrıca incelenebilir. 499 gibi Nginx-specific status semantics dashboard'da açıklanmalıdır. Total request rate ile ratio birlikte gösterilmelidir.

Response Time

Request time ve upstream response time ayrı loglanabilir. Böylece Nginx overhead ile backend latency ayrılır. p95 trend endpoint bazında hesaplanabilir. Dynamic ID içeren URL normalized route'a çevrilmelidir. SLO threshold ile alert oluşturulabilir.

5xx Alert

Beş dakikalık 5xx ratio baseline üstüne çıktığında alert tetiklenebilir. Low traffic service için minimum request count koşulu eklenmelidir. Upstream timeout ve application 500 ayrı alert kategorisi olabilir. Deployment version correlation mesajda gösterilebilir. Recovery notification service normale döndüğünde gönderilir.

Kibana Dashboard

Dashboard request rate, status distribution, latency ve top error route panellerini içerebilir. Host ve service filter global control olarak eklenir. Time range default son bir saat olabilir. Drill-down error log saved search'e geçebilir. Dashboard edit permission yalnız observability team veya service owner'a verilebilir.

Uçtan Uca Production Log Pipeline

Production-ready pipeline application'ın structured event üretmesiyle başlar. Elastic Agent veya başka collector event'i güvenli şekilde toplar. Logstash yalnız gerekliyse transformation ve buffering yapar, aksi durumda ingest pipeline tercih edilebilir. ECS normalization sonrası data stream'e yazılan loglara lifecycle retention uygulanır. Kibana analiz ve alert sağlar, snapshot disaster recovery için alınır ve pipeline'ın kendi health metric'leri sürekli izlenir.

Uygulama JSON Log Üretir

Application stdout'a ECS uyumlu JSON event yazar. Service, version, trace ve log level metadata otomatik eklenir. Password ve token redaction producer seviyesinde yapılır. Stack trace tek structured field olarak tutulur. Logging library testleri schema contract'ı doğrular.

Elastic Agent Toplar

Agent policy application log path veya container source'u tanımlar. Host ve container metadata eklenir. Fleet central health ve configuration sunar. Agent output TLS kullanır. Policy rollout canary group üzerinden uygulanır.

Logstash veya Ingest Pipeline İşler

Structured log basitse ingest pipeline rename ve enrichment yapabilir. Complex routing veya external lookup varsa Logstash kullanılabilir. Transformation logic iki yerde duplicate edilmemelidir. Failure handling ve parse error metric oluşturulur. Throughput production peak ile load test edilir.

ECS Formatına Dönüştürülür

Field naming common schema'ya uyarlanır. Timestamp, service ve error alanları doğru type alır. Custom business fields organization namespace altında tutulur. Unknown user key'ler mapping explosion yaratmayacak şekilde sınırlandırılır. Schema version event'e eklenebilir.

Data Stream'e Yazılır

Data stream type, dataset ve namespace ile logical storage sağlar. Rollover backing index'leri yönetir. 9.x log stream'lerinde LogsDB uygun mode olabilir. Index template mapping ve settings uygular. Application backing index adını bilmek zorunda kalmaz.

Lifecycle Retention Uygulanır

ILM veya Data Stream Lifecycle dataset'in retention süresini otomatik yönetir. Security ve application data farklı süre kullanabilir. Hot data hızlı storage'da tutulur. Eski data gerektiğinde cold veya frozen tier'a geçer. Policy failure alert edilir.

Kibana Analiz Eder

Discover incident araştırması sağlar. Dashboard error rate ve latency trendlerini gösterir. KQL veya ES|QL advanced query için kullanılır. Role-based access sensitive dataset'leri korur. Saved search incident runbook'un parçası olur.

Alert Oluşturulur

Error rate, authentication failure veya log absence rule oluşturulabilir. Threshold ve time window baseline'a göre ayarlanır. Notification connector secure secret kullanır. Alert deduplication on-call gürültüsünü azaltır. Synthetic test connector delivery'yi doğrular.

Snapshot Alınır

SLM düzenli snapshot oluşturur. Repository cluster dışındaki durable storage'dadır. Snapshot retention business RPO'ya göre belirlenir. Restore test ayrı cluster'da yapılır. Raw data directory copy backup olarak kullanılmaz.

Pipeline Monitoring Yapılır

Event count, lag, queue ve DLQ metric'leri dashboard'a konulur. Synthetic event end-to-end delivery kontrol eder. Disk, heap ve indexing latency alert edilir. Agent offline oranı izlenir. Platform kendi SLO'suna göre yönetilir.

ELK Kurulumunda Sık Karşılaşılan Hatalar

ELK troubleshooting sırasında hata mesajını hangi katmanın ürettiğini belirlemek önemlidir. Elasticsearch startup problemi Kibana'yı da unavailable gösterebilir. Certificate failure çoğu zaman trust veya hostname mismatch kaynaklıdır. Disk watermark write block oluşturarak ingestion'ı durdurabilir. Her probleme service restart uygulamak yerine log, health API ve network testiyle root cause bulunmalıdır.

Elasticsearch Başlamıyor

İlk olarak systemd status ve Elasticsearch logları kontrol edilir. Heap, file permission, disk veya bootstrap check error mesajı aranır. elasticsearch.yml syntax ve discovery config incelenir. Production network binding bootstrap check'leri daha sıkı hale getirebilir. Son config değişikliği rollback edilerek problem daraltılabilir.

Kibana Server Is Not Ready Yet

Bu mesaj Kibana process'in tamamen çöktüğü anlamına gelmez. Elasticsearch connectivity, saved objects migration veya cluster health problemi olabilir. Kibana journal logu incelenmelidir. Elasticsearch system index'leri disk flood-stage nedeniyle read-only olmuş olabilir. Certificate veya authentication failure ayrıca test edilir.

Logstash Pipeline Error

Pipeline syntax error service startup'ını veya belirli pipeline'ı durdurabilir. Config test komutu exact dosya üzerinde çalıştırılır. Plugin option version compatibility incelenir. Sample event filter exception'ı reproduce edebilir. Previous working config artifact rollback için tutulmalıdır.

Filebeat Elasticsearch'e Bağlanamıyor

DNS, firewall, TLS ve authentication sırayla kontrol edilir. filebeat test output hızlı teşhis sağlar. Elasticsearch HTTPS endpoint'ine plain HTTP gönderilmemelidir. CA certificate path file permission doğru olmalıdır. API key expired veya revoked ise yeni credential kontrollü dağıtılır.

Certificate Verification Failed

Certificate CA trust, hostname veya expiration nedeniyle doğrulanmayabilir. Verification kapatmak yalnız problemi gizler. openssl ile certificate subject ve chain incelenebilir. Client configured hostname SAN alanında bulunmalıdır. Clock drift certificate validity window'u da etkileyebilir.

Connection Refused

Connection refused genellikle hedef hostta port dinleyen process olmadığını gösterir. ss ile local listening port kontrol edilir. Service yalnız localhost'a bind olmuş olabilir. Firewall drop çoğu zaman timeout üretirken refused farklı davranış gösterebilir. DNS'nin doğru hosta çözüldüğü doğrulanmalıdır.

Port 9200 Kapalı

Elasticsearch process health kontrol edilir. Network host yalnız loopback binding kullanıyor olabilir. Firewall source IP'yi engelleyebilir. Public erişim için port açmak yerine client private network'e alınmalıdır. Curl HTTPS ve CA ile aynı host üzerinden test edilir.

Port 5601 Kapalı

Kibana service başlamamış veya yalnız localhost'a bağlı olabilir. Reverse proxy aynı hosttaysa localhost binding normaldir. Public user 5601'e değil HTTPS proxy portuna ulaşmalıdır. Proxy upstream connection test edilir. Kibana startup logları saved object migration için incelenir.

Port 5044 Kapalı

Logstash Beats input pipeline gerçekten yüklenmiş mi kontrol edilir. ss process'in 5044 dinlediğini gösterir. Firewall Filebeat subnet'ini engelliyor olabilir. TLS handshake yanlış certificate nedeniyle connection'ı kapatabilir. Logstash pipeline logu input initialization error için incelenir.

Elasticsearch Yellow/Red

Yellow replica unassigned, red primary unassigned anlamına gelir. Single-node yellow normal replica constraint olabilir. Multi-node cluster'da allocation explain root cause gösterir. Disk watermark ve node role sık nedenlerdendir. Shard'ı force allocate etmeden önce snapshot ve data loss etkisi anlaşılmalıdır.

Disk Watermark

Low, high ve flood stage uyarıları disk capacity problemine işaret eder. Retention çalışıyor mu kontrol edilir. Node ekleme veya storage büyütme kalıcı çözüm olabilir. Threshold'u yükseltmek yalnız temporary emergency action'dır. Elastic default watermarks disk completely full olmadan sistemi korumayı hedefler.

Out of Memory

OOM JVM heap veya container memory limit problemi olabilir. Kernel log ve Elasticsearch JVM metric'leri incelenir. Mapping explosion veya ağır aggregation root cause olabilir. Heap rastgele artırılmadan page cache ihtiyacı değerlendirilir. Query ve index workload benchmark sonucu sizing güncellenir.

ELK Troubleshooting Komutları

ELK troubleshooting birkaç temel Linux ve Elastic API komutuyla hızlıca daraltılabilir. systemd process durumunu, journal ve service logları hata mesajını gösterir. curl HTTPS API connectivity, ss listening port ve df disk kapasitesi için kullanılır. Elasticsearch health API cluster durumunu verir. Logstash ve Filebeat kendi config test komutlarıyla production restart öncesinde configuration doğrulaması sağlar.

systemctl status

systemctl status service active, failed veya restart durumunu gösterir. Exit code ve son log satırları ilk teşhis için yararlıdır. Service enabled state reboot behavior hakkında bilgi verir. Restart komutu çalıştırmadan önce failure reason kaydedilmelidir. Sürekli manual restart root cause'u gizleyebilir.

journalctl

journalctl -u kibana veya ilgili unit service loglarını zaman aralığıyla gösterir. Elasticsearch package default'unda ayrıntılı log dosyası ayrı path'te olabilir. Since ve follow seçenekleri deployment sırasında kullanışlıdır. Output paylaşılmadan secret veya internal hostname redaction yapılmalıdır. System clock problemi log timestamp analizini etkiler.

curl

Curl Elasticsearch API ve reverse proxy health testleri için uygundur. HTTPS CA validation ve authentication kullanılmalıdır. -k ile verification kapatmak yalnız temporary local diagnosis için bile yanlış certificate problemini gizleyebilir. Response code script içinde kontrol edilebilir. Cluster health JSON çıktısı automation tarafından parse edilebilir.

ss

ss -lntp hangi process'in hangi TCP portta dinlediğini gösterir. Elasticsearch 9200, Kibana 5601 veya Logstash 5044 listener hızlıca kontrol edilir. Localhost ve all-interface binding farkı görünür. Root permission process detail için gerekebilir. Listening port dış network firewall erişimini garanti etmez.

df

df -h filesystem capacity kullanımını gösterir. Data path hangi mountta bulunuyor kontrol edilir. Root filesystem ve Elasticsearch data disk ayrıysa doğru path incelenmelidir. Inode exhaustion ayrıca df -i ile görülebilir. Capacity trend monitoring anlık komuttan daha önemlidir.

free

free -h host memory kullanımını özetler. Linux filesystem cache'i used memory olarak gösterebilir ve her yüksek kullanım problem değildir. Elasticsearch heap metric Java memory durumunu daha doğru açıklar. Swap kullanımına dikkat edilmelidir. Container deployment'ta host memory yanında cgroup limit de kontrol edilir.

Elasticsearch Cluster Health

_cluster/health node ve shard durumunu özetler. Red veya yellow görüldüğünde allocation explain bir sonraki adımdır. Response authentication ve TLS üzerinden alınmalıdır. Health status change alert edilir. Green state query latency sorununu tek başına dışlamaz.

Logstash Config Test

Logstash config syntax validation service restart öncesinde çalıştırılır. Environment variable ve keystore dependency test context'te hazır olmalıdır. Success yalnız syntax kontrolüdür. Sample event processing ayrıca yapılır. CI bu testi her config Pull Request'inde otomatikleştirebilir.

Filebeat Test Config

filebeat test config YAML parse ve internal config validation sağlar. File permission error output test aşamasında ayrıca görülebilir. Production config exact file üzerinden test edilmelidir. Secret değer log çıktısına düşmemelidir. Successful config version deployment inventory'de kaydedilebilir.

Filebeat Test Output

Output test TLS, DNS ve authentication connectivity'yi doğrular. Elasticsearch veya Logstash endpoint'in erişilebilir olduğu görülür. Test certificate validation açık halde yapılmalıdır. Success sonrasında gerçek event'in indexed olduğu kontrol edilmelidir. Network policy değişiminden sonra bu command automation health check olabilir.

Log Yönetiminde Sık Yapılan Hatalar

Merkezi log platformlarında en pahalı hatalar çoğunlukla ilk kurulumun çalışmasıyla yetinmekten kaynaklanır. Security kapatılması, retention tanımlanmaması ve snapshot alınmaması sistem büyüdüğünde ciddi risk yaratır. Structured logging olmadan parser sayısı artar. Mapping ve shard sayısı kontrol edilmezse Elasticsearch kaynakları zamanla tükenebilir. Persistent Queue ve DLQ gibi dayanıklılık özellikleri kullanılıyorsa bunların yalnız etkinleştirilmesi değil izlenmesi de gerekir.

Elasticsearch Security'yi Kapatmak

Certificate configuration zor geldiği için security'yi kapatmak production riskini büyütür. Authentication olmadan index delete veya data read mümkün olabilir. Modern Elasticsearch security auto-configuration güvenli başlangıç sağlar. Sorun certificate trust üzerinden çözülmelidir. Development ve production farklı security paradigm kullanmamalıdır.

Elasticsearch'i Public Internet'e Açmak

9200 portu search kadar yönetim API'leri de taşır. Private network ve firewall kullanmak temel kontroldür. Application public request'leri doğrudan Elasticsearch'e proxy etmemelidir. VPN admin erişimi sağlar. External scan düzenli olarak exposure olmadığını doğrulayabilir.

Kibana 5601'i Kontrolsüz Açmak

Kibana hassas log ve management UI sunar. Reverse proxy HTTPS ve SSO arkasında yayınlanmalıdır. 5601 yalnız proxy subnet'ine açık kalabilir. Read-only user minimum index access alır. Public login endpoint brute force monitoring'e dahil edilmelidir.

Her Şeyi Debug Seviyesinde Loglamak

Debug event hacmi storage ve indexing maliyetini büyütür. Hassas context sızıntısı riski artar. Production default log level belirlenmelidir. Incident sırasında geçici debug activation uygulanabilir. Debug volume alert beklenmeyen artışı gösterir.

Structured Logging Kullanmamak

Plaintext log parser bakımını artırır. Field query ve dashboard oluşturmak zorlaşır. Format değişikliği Grok failure üretir. Yeni application JSON structured log kullanmalıdır. Legacy sistem kademeli parser ile migrate edilebilir.

Retention Tanımlamamak

Index'ler sonsuza kadar büyür ve disk watermark'a ulaşır. Manual delete incident sırasında risklidir. Lifecycle policy otomatik retention sağlar. Dataset değerine göre farklı süre kullanılmalıdır. Policy'nin gerçekten applied olduğu monitoring ile doğrulanmalıdır.

Mapping'i Kontrolsüz Bırakmak

Dynamic user key'ler binlerce field üretebilir. Heap ve cluster state büyür. Field limit artırmak root cause'u çözmez. Schema ve flattened mapping kullanılmalıdır. New field review logging standardının parçası olmalıdır.

Çok Fazla Shard Oluşturmak

Günlük küçük index modeli shard sayısını hızla büyütebilir. Her shard heap ve management overhead taşır. Data stream rollover size bazlı yönetim sağlar. Shard count per node izlenmelidir. Tiny data stream'ler consolidation için değerlendirilebilir.

Persistent Queue Kullanmamak

Kritik Logstash pipeline memory queue ile process crash sırasında in-flight data kaybedebilir. Persistent Queue bazı failure senaryolarında koruma sağlar. Her pipeline'ın data loss tolerance'ı değerlendirilmelidir. UDP source PQ ile tam güvenilir hale gelmez. Queue kullanımının disk maliyeti vardır.

DLQ'yu İzlememek

DLQ event'leri ana pipeline dışına aldığı için hata sessizleşebilir. Queue size büyürken dashboard normal görünebilir. Alert oldest age ve bytes izleyecek şekilde kurulmalıdır. Reprocessing runbook bulunmalıdır. Root cause schema producer'da düzeltilmelidir.

Snapshot Almamak

Replica backup değildir. Yanlış delete bütün replica'lara uygulanabilir. Snapshot cluster dışı repository'de data recovery sağlar. SLM automation kullanılabilir. Snapshot failure alert edilmelidir.

Restore Testi Yapmamak

Backup yalnız oluşturulduğu için güvenilir sayılmaz. Version veya permission problemi restore günü ortaya çıkabilir. Test cluster periyodik restore yapmalıdır. RTO ölçülmelidir. Runbook sonuçlara göre güncellenmelidir.

PII ve Secret'ları Loglamak

Log platformu geniş ekip erişimine sahip olabilir. Password, token ve full personal data hiç loglanmamalıdır. Redaction producer'da uygulanır. Leak incident credential rotation ve data cleanup gerektirir. Schema review sensitive field inventory tutmalıdır.

Production Öncesi ELK Kontrol Listesi

Production'a geçmeden önce yalnız dashboard'un açıldığını görmek yeterli değildir. Stack version, TLS, network exposure ve user privilege kontrol edilmelidir. Structured log, ECS ve data stream tasarımı storage katmanının sağlıklı büyümesini sağlar. Retention, Persistent Queue, DLQ ve snapshot operasyon dayanıklılığını tamamlar. Pipeline monitoring ve PII redaction olmadan kurulum teknik olarak çalışsa bile production-ready kabul edilmemelidir.

Elastic Stack Sürümleri Uyumlu mu?

Elasticsearch, Kibana ve Logstash aynı stack version politikasında olmalıdır. Agent ve integration compatibility kontrol edilir. Release note incelenir. Package candidate yanlış major repository'den gelmemelidir. Version inventory automation ile izlenmelidir.

TLS Aktif mi?

HTTP ve transport TLS Elasticsearch'te açık olmalıdır. Kibana ve Logstash certificate validation yapmalıdır. Agent-to-Logstash bağlantısı şifrelenmelidir. Certificate expiration alarmı bulunmalıdır. Verification bypass config production'da olmamalıdır.

Elasticsearch Public Internet'e Kapalı mı?

9200 private network üzerinde tutulmalıdır. Firewall yalnız gerekli service kaynaklarına izin verir. Admin erişimi VPN üzerinden yapılır. External scan public exposure olmadığını doğrular. Application direct cluster management access almaz.

Kibana Reverse Proxy Arkasında mı?

Kullanıcı 5601'e doğrudan ulaşmamalıdır. HTTPS proxy ve SSO uygulanabilir. Forwarded header güvenilir biçimde set edilir. Kibana backend port yalnız proxy hostuna açıktır. Proxy access log security monitoring'e alınır.

Kullanıcı Yetkileri Minimum mu?

Dashboard viewer read-only role kullanmalıdır. Admin account günlük query için kullanılmaz. Production security dataset'e yalnız ilgili ekip erişir. Role mapping test user ile doğrulanır. Access review periyodik yapılır.

API Key'ler Minimum Yetkili mi?

Logstash writer yalnız hedef stream'e write izni alır. Agent key başka environment'a yazamaz. Key secret manager'da tutulur. Rotation ve revoke procedure test edilir. Superuser credential service config'te bulunmaz.

Structured Log Kullanılıyor mu?

Yeni uygulamalar JSON event üretmelidir. Log level ve service metadata field olarak bulunur. Error object structured biçimde tutulur. Secret redaction producer seviyesinde uygulanır. Plaintext legacy log parser fixture testine sahiptir.

ECS Uygulanıyor mu?

Common field naming dashboard reuse sağlar. @timestamp, service.name ve log.level doğru kullanılır. Custom fields organization namespace altında tutulur. Dynamic key kontrol edilir. Trace field'ları tracing sistemiyle uyumludur.

Data Stream Kullanılıyor mu?

Append-only loglar data stream'de tutulabilir. Backing index application tarafından doğrudan hedeflenmez. Index template mapping ve lifecycle sağlar. Dataset ve namespace naming standardı bulunur. Rollover health izlenir.

Retention Policy Var mı?

Her dataset'in retention süresi tanımlıdır. Security ve debug log aynı süreyi kullanmak zorunda değildir. ILM veya Data Stream Lifecycle otomatik deletion sağlar. Lifecycle error alert edilir. Legal requirement documentation'da kayıtlıdır.

Disk Alert'i Var mı?

Disk usage yalnız flood stage'de fark edilmemelidir. Growth trend remaining days alert üretir. Low ve high watermark monitoring'e alınır. Snapshot repository capacity ayrı izlenir. Node expansion lead time planlanır.

Persistent Queue Gerekliyse Aktif mi?

Data loss tolerance düşük Logstash pipeline PQ kullanabilir. Queue size burst süresine göre hesaplanır. Local disk yeterli kapasiteye sahiptir. Checkpoint policy benchmark edilmiştir. Queue full alert tanımlıdır.

DLQ İzleniyor mu?

DLQ size ve age metric alert edilir. Reprocessing pipeline hazırdır. Mapping failure root cause sahipliği belirlenmiştir. Maximum queue size ve drop policy bilinmektedir. Consumed event cleanup prosedürü vardır.

Backup Var mı?

SLM düzenli snapshot oluşturur. Repository cluster dışındadır. Snapshot başarısızlığı alarm üretir. Retention RPO ihtiyacını karşılar. Filesystem data directory copy backup olarak kullanılmaz.

Restore Test Edildi mi?

Son snapshot isolated test cluster'a restore edilmiştir. Representative data query başarılıdır. Kibana feature state ihtiyacı doğrulanmıştır. RTO ölçülmüştür. Runbook güncel ve ekip tarafından erişilebilirdir.

Pipeline Monitoring Aktif mi?

EPS, lag, queue, DLQ ve indexing latency görünürdür. Agent offline alert vardır. Synthetic log end-to-end test eder. Alert connector health izlenir. Platform SLO dashboard'u bulunur.

PII/Secret Redaction Var mı?

Password ve token producer'dan itibaren loglanmaz. Sensitive field allowlist veya redaction uygulanır. Test sample secret'ın final index'e ulaşmadığını doğrular. PII retention ve access role tanımlıdır. Leak incident procedure credential revoke ve cleanup adımlarını kapsar.

Open Source ve İşbirliği ile Log Yönetimi

Merkezi log yönetimi öğrenmenin en iyi yollarından biri gerçek pipeline ve dashboard üzerinde ortak çalışma yapmaktır. Parser, ECS field standardı ve alert rule review edilerek ekip içinde daha iyi uygulamalar oluşur. OpenTelemetry gibi açık standartlar telemetry üreticileri arasında ortak dil sağlar. GitHub issue ve Pull Request süreçleri integration problemlerinin nasıl çözüldüğünü görmek için öğreticidir. Ortak laboratuvar projeleri yalnız araç bilgisi değil incident düşünme becerisi de kazandırır.

Elastic Ekosistemi

Elastic Stack birçok client, integration ve ingestion bileşeni içerir. Resmi dokümantasyon sürüm davranışlarını öğrenmenin ilk kaynağı olmalıdır. Community discussion gerçek edge case'ler hakkında fikir verebilir. Production kararı yalnız forum yorumuna dayandırılmamalıdır. Release note ve support matrix her upgrade'de tekrar kontrol edilmelidir.

Logstash Plugin'leri

Plugin ecosystem farklı input ve output entegrasyonları sunar. Plugin source code ve issue tracker davranışı anlamaya yardımcı olabilir. Custom plugin yazmadan önce mevcut supported plugin değerlendirilmelidir. Maintenance sahibi olmayan plugin production riskidir. Version compatibility upgrade testine eklenmelidir.

ECS Topluluğu

Ortak field schema farklı ekiplerin aynı telemetry dilini kullanmasını sağlar. Field semantic tartışmaları uygulama logging standardına katkı verebilir. Custom extension ECS anlamını bozmayacak şekilde tasarlanmalıdır. Yeni schema field için örnek log ve query kullanım senaryosu hazırlanabilir. Community standardını kör biçimde değil kendi domain ihtiyacına göre uygulamak gerekir.

GitHub Issue ve Pull Request

Issue gerçek bug ve feature context'ini gösterir. Parser veya documentation hatası küçük contribution için iyi başlangıçtır. Pull Request review code quality ve backward compatibility düşüncesini geliştirir. Production secret veya customer log sample public issue'ya eklenmemelidir. Minimal anonymized reproduction paylaşılmalıdır.

Dashboard Paylaşımı

Reusable Kibana dashboard export ekip içinde paylaşılabilir. Field ve data view dependency documentation eklenmelidir. Sensitive saved search veya connector credential export edilmemelidir. Dashboard screenshot yerine source object version control'de tutulabilir. Community project örnekleri generic synthetic data kullanmalıdır.

Detection Rule Paylaşımı

Security detection rule common attack davranışlarını ortaklaştırabilir. Threshold ve field dependency açıkça belgelenmelidir. Rule her environment'ta aynı false positive oranına sahip olmayabilir. Local baseline ile tuning gerekir. Detection sharing gerçek incident verisini ifşa etmeden yapılmalıdır.

OpenTelemetry Ekosistemi

OpenTelemetry ortak trace, metric ve log telemetry modelini geliştirir. Collector farklı backend'lere exporter sağlayabilir. Application instrumentation vendor-specific API bağımlılığını azaltabilir. ECS ile OTel field mapping bilinçli yapılmalıdır. Community instrumentation library'leri source ve security review'undan geçirilmelidir.

Topluluk İçinde Log Pipeline'ları Geliştirmek

Bir grup küçük demo uygulama, collector ve Elasticsearch cluster kurarak gerçek pipeline geliştirebilir. Bir kişi JSON schema, başka kişi Logstash ve başka biri dashboard üzerinde çalışabilir. Pull Request review ortak öğrenmeyi sağlar. Failure scenario eklenerek Elasticsearch kapanınca queue behavior gözlenebilir. Böyle proje yalnız kurulum komutundan çok production düşüncesi kazandırır.

Log Yönetimi İçin En İyi Programlama Dili Hangisidir?

Log yönetimi tek bir programlama diline bağlı değildir. Python automation ve data processing için kullanışlıdır, Go hafif collector veya tooling geliştirmede güçlüdür, Java Elastic ekosisteminin birçok bileşeninde doğal platformdur. Bash sistem bootstrap görevlerinde, YAML configuration tanımında kullanılır. Ancak production log sistemi kurmak için Linux, networking ve data engineering bilgisi dil seçiminin önüne geçer.

Python

Python API automation ve log transformation script'leri için hızlı geliştirme sağlar. Elasticsearch client library kullanılabilir. ETL script'lerinde large dataset memory behavior dikkate alınmalıdır. Production ingestion pipeline'ı tek-thread script'e bağlamak yerine resilient service architecture kullanılmalıdır. Python logging structured JSON output için kolayca yapılandırılabilir.

Go

Go düşük memory footprint ve kolay static binary dağıtımıyla infrastructure tooling için uygundur. Concurrent network collector yazmak kolay olabilir. OpenTelemetry ecosystem Go için güçlü instrumentation sağlar. Custom log shipper yazmadan önce mevcut agent seçenekleri değerlendirilmelidir. Binary security update ve dependency scan yine gereklidir.

Java

Elasticsearch ve Logstash JVM ekosistemine dayanır. Java application structured logger ve ECS encoder kullanabilir. JVM monitoring bilgisi Elasticsearch operations öğrenirken de faydalıdır. Custom plugin geliştirme özel uzmanlık gerektirir. Application logları MDC üzerinden trace context taşıyabilir.

Bash

Bash service health ve bootstrap script'i için pratiktir. Çok karmaşık state management Bash içinde zorlaşır. Error handling için set -e gibi seçeneklerin davranışı iyi anlaşılmalıdır. Secret command-line argument'te görünmemelidir. Uzun yaşayan automation Ansible veya programlama diline taşınabilir.

Logstash Configuration Language

Logstash pipeline DSL input, filter ve output bloklarını tanımlar. Conditional expression event routing sağlar. Kod benzeri görünse de general-purpose programming language değildir. Pipeline okunabilir küçük parçalara ayrılmalıdır. Fixture testing configuration değişikliklerinin güvenliğini artırır.

YAML

Elasticsearch, Kibana, Filebeat ve Kubernetes configuration'larında YAML sık kullanılır. Indentation hatası service startup'ını bozabilir. Schema veya config test tool kullanılmalıdır. Secret value normal YAML repository'sine yazılmamalıdır. Template automation environment farklarını kontrollü üretir.

Programlama Dilinden Daha Önemli Olan Linux, Networking ve Data Engineering Bilgisi

ELK problemlerinin büyük kısmı yalnız kod syntax'ıyla çözülmez. Disk I/O, TCP, TLS, DNS ve JVM memory bilgisi troubleshooting için gereklidir. Data schema ve cardinality anlayışı Elasticsearch mapping tasarımını belirler. Distributed system quorum ve failure davranışı HA kurulumunun temelidir. Bir programlama dili bu bilgileri otomatik olarak sağlamaz.

Yazılımcı Olmak İçin Ne Yapmalı? Observability ve DevOps Yol Haritası

Observability alanına girmek isteyen yazılımcı önce Linux ve networking temellerini öğrenmelidir. JSON, YAML ve Git günlük configuration işlerini kolaylaştırır. Docker servislerin izolasyonunu, Elasticsearch ve Logstash veri pipeline'ını öğretir. OpenTelemetry ve Kubernetes daha sonra distributed telemetry ve orchestration bilgisi kazandırır. En değerli adım gerçek bir merkezi log projesi kurup failure, backup ve alert senaryolarını bizzat uygulamaktır.

Linux

Process, permission, filesystem ve systemd temel konulardır. Log file rotation ve journal kullanımı öğrenilmelidir. Memory ve disk komutları troubleshooting pratiği sağlar. User ve group izinleri secret ile data path güvenliğini etkiler. Kernel parameter mantığı Elasticsearch bootstrap sorunlarını anlamayı kolaylaştırır.

Networking

IP, port, DNS ve TLS öğrenilmelidir. Connection refused ile timeout farkı anlaşılmalıdır. Reverse proxy ve firewall gerçek lab üzerinde kurulabilir. Certificate chain ve hostname validation pratiği yapılmalıdır. Private network segmentation production security'nin temelidir.

Git

Configuration file'lar version control'de tutulmalıdır. Branch ve Pull Request change review sağlar. Secret history'ye eklenmemelidir. Pipeline fixture testleri CI'da çalıştırılabilir. Release tag infrastructure değişiklikleriyle ilişkilendirilebilir.

JSON ve YAML

JSON log event formatını, YAML configuration dosyalarını anlamak için gereklidir. Nested structure ve type farkları mapping design'e yansır. Invalid JSON parser failure üretir. YAML indentation ve environment interpolation test edilmelidir. Schema validation veri kalitesini artırır.

Docker

Docker local Elasticsearch ve Logstash lab kurulumu için idealdir. Network ve volume kavramları öğrenilir. Resource limit Elasticsearch memory behavior'ını gösterir. Container logları centralized pipeline'a alınabilir. Production stateful deployment'ın container'dan daha geniş storage ve backup gerektirdiği görülür.

Elasticsearch

Index, document, mapping ve shard temelleri öğrenilmelidir. Query ve aggregation uygulamalı yapılmalıdır. Data stream ve lifecycle modern log management için önemlidir. Snapshot restore gerçek lab'da test edilmelidir. Cluster health ve allocation troubleshooting pratiği yapılmalıdır.

Logstash

Input, filter ve output pipeline kurulmalıdır. Grok ve JSON parsing farkı örneklerle görülür. Persistent Queue ve DLQ failure testleri yapılır. Elasticsearch output TLS ile bağlanır. Pipeline metric ve throughput ölçülür.

Kibana

Discover ile incident query çalıştırılır. Lens dashboard oluşturulur. KQL ve ES|QL temel sorgular denenir. Alert rule ve connector test edilir. Role ve Space yönetimiyle access control uygulanır.

OpenTelemetry

Trace ve context propagation öğrenilmelidir. Application instrumentation trace ID'yi loglara ekleyebilir. Collector receiver, processor ve exporter modeli incelenir. Vendor-neutral telemetry yaklaşımı anlaşılır. Log, trace ve metric korelasyonu demo proje üzerinde yapılır.

Kubernetes

Pod, Deployment ve DaemonSet temel resource'lardır. Node-level log collector kurulabilir. Persistent volume Elasticsearch stateful behavior'ını öğretir. Network policy ve secret management security pratiği sağlar. ECK ile operator-based deployment incelenebilir.

Monitoring ve Alerting

Metric yalnız grafikte gösterilmemeli SLO'ya bağlanmalıdır. Pipeline lag, queue ve disk alertleri kurulabilir. Alert false positive tuning yapılır. Notification connector failure test edilir. Incident sonrası dashboard ve rule iyileştirilir.

Gerçek Bir Merkezi Log Projesi Geliştirmek

Üç küçük application service ve Nginx ile demo sistem kurulabilir. JSON loglar Agent üzerinden Elasticsearch'e gönderilir. Dashboard ve alert oluşturulur. Elasticsearch kapatılarak queue ve recovery behavior gözlenir. Snapshot restore tamamlandığında proje gerçek production konularının büyük bölümünü öğretmiş olur.

Diyarbakır Yazılım Topluluğu ile Log Yönetimi ve Observability

Log Yönetimi: Elasticsearch, Logstash ve Kibana (ELK) Kurulumu konusu yalnız okuyarak değil, ortak laboratuvar ve gerçek proje üzerinde çok daha hızlı öğrenilir. Diyarbakır Yazılım Topluluğu içinde DevOps, container, CI/CD ve observability çalışmalarının aynı proje üzerinde birleştirilmesi mümkündür. Örneğin küçük bir mikroservis sistemi kurup logları merkezi Elasticsearch'e göndererek dashboard ve alert üretilebilir. Topluluk projelerini https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyebilirsiniz. Topluluğun amacı ve çalışma yaklaşımı hakkında bilgi için https://www.diyarbakiryazilim.com.tr/about adresini ziyaret edebilirsiniz.

Diyarbakır Yazılım Topluluğu İçinde DevOps Çalışmaları

DevOps çalışmaları application build'den production observability'ye kadar uçtan uca ele alınabilir. Bir proje Docker ile çalıştırılır ve CI/CD pipeline üzerinden deploy edilir. Ardından log, metric ve trace katmanı eklenir. Incident senaryosu oluşturularak alert ve rollback pratiği yapılabilir. Sıfır kesinti deployment yaklaşımıyla observability ilişkisini incelemek için https://www.diyarbakiryazilim.com.tr/posts/sifir-kesinti-zero-downtime-dagitim-stratejileri içeriği de kullanılabilir.

Elasticsearch ve Kibana Workshopları

Workshop'ta önce birkaç JSON event Elasticsearch'e indexlenebilir. Ardından mapping ve keyword ile text farkı gösterilebilir. Kibana Discover üzerinde KQL sorguları yazılır. Lens ile error dashboard hazırlanır. Son aşamada data stream ve retention policy eklenerek yalnız temel search değil gerçek lifecycle pratiği yapılır.

Merkezi Log Yönetimi Laboratuvarı

Laboratuvar üç Linux host ve tek log cluster ile başlayabilir. Elastic Agent veya Filebeat host loglarını toplar. Logstash legacy sample logları ECS formatına dönüştürür. Elasticsearch data stream ve lifecycle kullanır. Son bölümde bir Logstash node kapatılıp Persistent Queue davranışı gözlenerek failure senaryosu uygulanır.

Open Source ve İşbirliği

Katılımcılar ortak repository'de pipeline config ve dashboard export dosyalarını paylaşabilir. Issue üzerinden yeni parser ihtiyacı tanımlanabilir. Pull Request review schema ve security kontrolü sağlar. Synthetic log kullanıldığı için gerçek müşteri verisi paylaşılmaz. Böyle çalışma teknik bilgi kadar ekip içi documentation ve review alışkanlığı da kazandırır.

Diyarbakır'daki En İyi Yazılımcılarla Teknik Deneyim Paylaşımı

Teknik deneyim paylaşımı farklı deployment ve incident senaryolarını görmeyi sağlar. Bir katılımcı Docker loglarını, diğeri Linux authentication loglarını ele alabilir. Ortak Kibana dashboard farklı source'ların ECS sayesinde nasıl birleştiğini gösterir. Failure ve recovery senaryoları birlikte değerlendirilir. Amaç yalnız tool komutu paylaşmak değil, kararların nedenlerini ve trade-off'larını konuşmaktır.

Yerel Projeler İçin Log Yönetimi

Yerel web uygulaması veya kurumsal internal sistem büyüdükçe merkezi log ihtiyacı ortaya çıkabilir. İlk aşamada tek cluster ve kısa retention yeterli olabilir. Proje büyüdüğünde Agent, lifecycle ve alerting eklenebilir. Data privacy ve access role en baştan düşünülmelidir. Topluluk içinde benzer mimarilerin generic örneklerini paylaşmak öğrenme süresini kısaltır.

Web Uygulamaları

Web uygulaması request ve error loglarını JSON formatında üretebilir. Nginx access log ayrı data stream'e gönderilir. Correlation ID frontend gateway'den backend'e taşınır. Kibana dashboard response status ve latency gösterir. 5xx artışı alert ile service owner'a bildirilir.

Mikroservisler

Mikroservislerde trace ID ortak log correlation alanıdır. Her service aynı ECS naming standardını kullanır. Agent container metadata ekler. Elasticsearch query tek trace boyunca event'leri bulabilir. OpenTelemetry tracing log analizini daha güçlü hale getirir.

Docker Sistemleri

Docker stdout logları host collector tarafından toplanabilir. Container ID ve image version metadata eklenir. Compose service name stable application identity sağlar. Log rotation host diskinin dolmasını önler. Central Elasticsearch container recreate sonrasında historical logları korur.

Kubernetes Cluster'ları

DaemonSet collector node loglarını merkezi toplar. Namespace ve pod metadata event'e eklenir. Dynamic labels mapping explosion yaratmayacak şekilde sınırlandırılır. ECK Elastic cluster yönetimi için değerlendirilebilir. Pipeline ve cluster health birlikte izlenir.

Sık Sorulan Sorular

ELK Stack hakkında sorular genellikle kurulumdan çok production işletimine geçildiğinde artar. Java gereksinimi, Filebeat ve Agent seçimi veya Logstash'in zorunlu olup olmadığı sürüme göre farklı cevaplar gerektirebilir. Modern Elasticsearch data stream, LogsDB ve lifecycle özellikleri eski günlük index alışkanlıklarını değiştirmiştir. Security varsayılan olarak korunmalı ve snapshot backup temel süreç haline getirilmelidir. Aşağıdaki yanıtlar en sık karşılaşılan teknik karar noktalarını özetler.

ELK Stack nedir?

ELK Elasticsearch, Logstash ve Kibana bileşenlerinden oluşan klasik merkezi log yaklaşımını ifade eder. Elasticsearch veriyi saklar ve arar. Logstash isteğe bağlı ingestion ve transformation katmanıdır. Kibana query, dashboard ve alert arayüzü sunar. Modern Elastic Stack'te Elastic Agent, Fleet ve data stream'ler de yaygın olarak bu yapının parçasıdır.

Elasticsearch ne işe yarar?

Elasticsearch JSON document'leri indexleyerek hızlı search ve aggregation sağlar. Log event'leri field bazında filtrelenebilir. Data stream ile zaman serisi backing index'leri yönetilebilir. Shard ve replica distributed storage sağlar. Snapshot disaster recovery için kullanılır.

Logstash ne işe yarar?

Logstash farklı source'lardan event alır ve filter aşamasında dönüştürür. Grok legacy plaintext logları structured hale getirebilir. Persistent Queue temporary downstream kesintilerinde buffer sağlayabilir. Output event'i Elasticsearch veya başka sisteme gönderebilir. Basit structured loglarda Logstash kullanmak zorunlu değildir.

Kibana ne işe yarar?

Kibana Elasticsearch verisi üzerinde kullanıcı arayüzü sağlar. Discover ham log investigation için kullanılır. Lens dashboard ve visualization oluşturur. Alerting belirli koşullarda notification üretir. Role ve Spaces farklı kullanıcı gruplarını yönetmeye yardımcı olur.

ELK Stack ücretsiz mi?

Elastic dağıtımları free ve subscription özelliklerini aynı package içinde sunabilir. Hangi security, alerting veya advanced feature'ın hangi lisans seviyesinde bulunduğu kullanılan güncel sürüm ve deployment türüne göre kontrol edilmelidir. Self-managed infrastructure compute ve storage maliyeti lisans durumundan bağımsızdır. Operasyon ekibi zamanı da toplam maliyetin parçasıdır. Production planında resmi güncel subscription sayfası kontrol edilmelidir.

Elasticsearch Ubuntu'ya nasıl kurulur?

Elastic PGP key keyring'e eklenir. 9.x APT repository signed-by ile tanımlanır. Elasticsearch package apt üzerinden kurulur. systemd service başlatılır ve security auto-configuration tamamlanır. HTTPS curl testi CA certificate ve elastic credential ile yapılır.

Güncel Elasticsearch için Java kurmak gerekir mi?

Çoğu standart güncel package kurulumunda ayrıca Java kurmak gerekmez. Elasticsearch bundled OpenJDK ile gelir. Custom JVM yalnız özel kurumsal gereksinim varsa düşünülmelidir. Support matrix kontrol edilmelidir. Eski Java kurulum adımlarını içeren rehberler güncel 9.x davranışını yansıtmayabilir.

Elasticsearch için ne kadar RAM gerekir?

Tek sabit RAM değeri yoktur. Ingestion, query, mapping ve shard sayısı ihtiyaç üzerinde etkilidir. Lab birkaç GB ile çalışabilirken production data node çok daha fazla memory isteyebilir. Heap ve OS page cache birlikte planlanmalıdır. Gerçek workload benchmark sizing için en güvenilir yöntemdir.

Filebeat nedir?

Filebeat hafif log shipper'dır. Log dosyalarını takip edip Elasticsearch veya Logstash'e gönderebilir. Registry state offset devamlılığı sağlar. Module'ler yaygın servis loglarını parse edebilir. Yeni geniş ölçekli deployment'ta Elastic Agent seçeneği de değerlendirilmelidir.

Filebeat mi Elastic Agent mı kullanılmalı?

Existing basit Filebeat sistemi çalışıyorsa hemen migration zorunlu değildir. Merkezi Fleet policy ve çok sayıda integration gerekiyorsa Elastic Agent daha uygun olabilir. Elastic güncel dokümantasyonu Agent'ın merkezi yönetim avantajlarını vurgular. Feature compatibility kontrol edilmelidir. Migration küçük host grubuyla test edilmelidir.

Logstash kullanmak zorunlu mudur?

Hayır, Logstash zorunlu değildir. Structured log doğrudan Elasticsearch ingest pipeline'a gidebilir. Agent veya Filebeat Elasticsearch output kullanabilir. Complex parsing, enrichment veya persistent queue gerekiyorsa Logstash değerlidir. Gereksiz hop olarak eklenmemelidir.

Elasticsearch ile Logstash arasındaki fark nedir?

Elasticsearch storage, search ve analytics motorudur. Logstash ingestion ve event transformation aracıdır. Logstash event'i Elasticsearch'e gönderebilir. Elasticsearch kendi ingest pipeline'ıyla bazı dönüşümleri yapabilir. İki bileşen farklı problemlere çözüm sunar.

Elasticsearch ile Kibana arasındaki fark nedir?

Elasticsearch verinin saklandığı ve query edildiği backend'dir. Kibana bu backend üzerinde web UI sağlar. Dashboard ve Discover Kibana feature'ıdır. Kibana kendi primary log storage'ını tutmaz. Elasticsearch unavailable olduğunda Kibana log query işlevleri de etkilenir.

Data stream nedir?

Data stream timestamped append-only data'yı backing index'ler üzerinden yönetir. Yeni write current backing index'e gider. Rollover yeni backing index oluşturur. Lifecycle retention otomatik uygulanabilir. Loglar için modern Elasticsearch storage modelidir.

ECS nedir?

ECS ortak telemetry field schema'sıdır. Service, host, log level ve trace alanlarının aynı isimlerle kullanılmasını sağlar. Dashboard ve query reuse kolaylaşır. Custom field controlled namespace altında eklenebilir. Mapping standardizasyonuna yardım eder.

ILM nedir?

ILM index lifecycle management sistemidir. Hot, warm, cold, frozen ve delete phase'leri yönetebilir. Rollover ve retention automation sağlar. Data tier maliyetini optimize etmeye yardımcı olur. Policy cluster topology ve business retention'a göre tasarlanmalıdır.

Persistent Queue nedir?

Persistent Queue Logstash event queue'sunu disk üzerinde saklar. Process restart sırasında unacknowledged event'leri korumaya yardımcı olur. Default olarak kapalıdır. Host disk failure'a karşı replication sağlamaz. Queue size ve checkpoint behavior monitoring gerektirir.

Dead Letter Queue nedir?

DLQ bazı işlenemeyen event'leri geçici disk alanında tutar. Mapping error gibi document-level failure'lar burada saklanabilir. Default kapalıdır. Queue izlenmeli ve event'ler düzeltilerek yeniden işlenmelidir. DLQ tek başına bütün network veya output failure'larını çözmez.

ELK ile Docker logları toplanabilir mi?

Evet, Docker stdout ve stderr logları collector tarafından okunabilir. Filebeat veya Elastic Agent container metadata ekleyebilir. Structured JSON application logları ECS'e dönüştürülebilir. Container ID ve service name birlikte tutulur. Host log rotation ve central retention ayrı yönetilir.

ELK Kubernetes logları için kullanılabilir mi?

Evet, node-level DaemonSet collector Kubernetes loglarını merkezi olarak toplayabilir. Pod, namespace ve container metadata event'e eklenir. Elastic Agent veya başka collector kullanılabilir. Dynamic labels mapping explosion'a karşı sınırlandırılmalıdır. Elasticsearch cluster Kubernetes üzerinde ECK ile de yönetilebilir.

Elasticsearch logları ne kadar süre saklanmalıdır?

Tek doğru süre yoktur. Application operasyon logları kısa, security ve audit logları daha uzun tutulabilir. Retention mevzuat, investigation horizon ve maliyet üzerinden belirlenir. Lifecycle automatic deletion sağlar. Dataset bazında policy kullanmak en sağlıklı yaklaşımdır.

Elasticsearch backup nasıl alınır?

Supported yöntem snapshot'tır. Filesystem data directory copy güvenilir backup değildir. Snapshot repository cluster dışı storage üzerinde tutulmalıdır. SLM schedule ve retention'ı otomatikleştirebilir. Restore test düzenli yapılmalıdır.

ELK production ortamı için güvenli midir?

Doğru yapılandırıldığında güçlü security özellikleri sunar. TLS, authentication, RBAC ve private network uygulanmalıdır. Elasticsearch ve Kibana doğrudan public internete açılmamalıdır. Secret ve PII redaction zorunludur. Security patch ve audit logging düzenli yönetilmelidir.

ELK yerine OpenSearch veya Loki kullanılabilir mi?

Evet, farklı log platformları aynı merkezi logging problemine farklı storage ve query modelleriyle yaklaşabilir. Elasticsearch structured analytics ve full-text search açısından güçlüdür. Diğer araçların operasyon ve storage modeli farklıdır. Gerçek log sample ve incident query'leriyle proof of concept yapılmalıdır. Tool seçimi ekip deneyimi ve toplam maliyet üzerinden verilmelidir.

Log yönetimi için en iyi programlama dili hangisidir?

Tek bir en iyi dil yoktur. Python automation, Go infrastructure tooling ve Java application ekosistemi için faydalıdır. Bash ve YAML günlük operasyonlarda sık kullanılır. Linux ve networking bilgisi daha kritik temeldir. Veri şeması ve failure davranışını anlamak dil seçiminden daha önemlidir.

DevOps yazılımcısı olmak için ne yapmalı?

Linux, networking ve Git ile başlanmalıdır. Docker ve CI/CD gerçek proje üzerinde öğrenilmelidir. Elasticsearch ve observability pipeline kurulabilir. Infrastructure as Code ve cloud daha sonra eklenir. Production failure ve backup senaryosu uygulamak yalnız tutorial takip etmekten çok daha öğreticidir.

Open source ve işbirliği observability kariyerine nasıl katkı sağlar?

Gerçek issue ve parser problemleri üzerinde çalışmayı sağlar. Pull Request code review alışkanlığı kazandırır. Dashboard veya documentation contribution teknik anlatım becerisini geliştirir. OpenTelemetry gibi standard ekosistemlerini anlamayı kolaylaştırır. Gerçek customer data paylaşmadan synthetic project üretmek güvenli öğrenme yöntemidir.

Sonuç: Production-Ready ELK Stack Nasıl Kurulur?

Production-ready merkezi log platformu yalnız Elasticsearch, Logstash ve Kibana servislerini çalıştırmak değildir. Log Yönetimi: Elasticsearch, Logstash ve Kibana (ELK) Kurulumu sürecinde en kritik adım structured ve ortak şemalı event üretmek, ardından collector, storage ve visualization katmanlarını ihtiyaç kadar eklemektir. Elasticsearch private network ve TLS ile korunmalı, Kibana kontrollü proxy ve least privilege kullanıcılarla yayınlanmalıdır. Data stream ve lifecycle retention'ı otomatikleştirirken Persistent Queue, DLQ ve snapshot failure senaryolarındaki dayanıklılığı güçlendirir. Pipeline event count, lag ve delivery SLO üzerinden izlenirse merkezi log sistemi gerçekten güvenilir production altyapısına dönüşür.

Güncel ve Uyumlu Elastic Stack Sürümü Kullanın

Kurulum anında official repository current stable sürümü kontrol edilmelidir. Elasticsearch, Kibana ve Logstash aynı version politikasında tutulmalıdır. 25 Ağustos 2026 itibarıyla resmi 9.x Debian dokümantasyonu 9.5.2 paketini göstermektedir. Release note ve known issue kontrol edilmeden production update yapılmamalıdır. Version infrastructure code içinde açıkça kayıt altına alınmalıdır.

Structured ve ECS Uyumlu Loglarla Başlayın

Application JSON log üretirse Grok ihtiyacı ciddi biçimde azalır. Service, timestamp, level ve trace field'ları standardize edilir. Custom business field'lar controlled namespace altında tutulur. Dynamic user key mapping explosion oluşturmaz. Shared logging library bütün ekiplerde aynı schema'yı uygulayabilir.

İhtiyaç Yoksa Logstash'i Gereksiz Yere Eklemeyin

Elastic Agent veya Filebeat doğrudan Elasticsearch ingest pipeline kullanabilir. Basit structured event için ek Logstash node operasyon maliyeti yaratabilir. Legacy parser, external enrichment veya Persistent Queue gerekiyorsa Logstash değer üretir. Architecture kararı gerçek requirement listesine dayanmalıdır. Daha fazla bileşen otomatik olarak daha güvenilir sistem anlamına gelmez.

Elastic Agent, Filebeat ve OpenTelemetry Seçimini Bilinçli Yapın

Existing Filebeat sistemi basitse korunabilir. Fleet merkezi policy ve çok sayıda integration için Elastic Agent güçlü seçenektir. Vendor-neutral telemetry ve trace entegrasyonu için OpenTelemetry Collector değerlendirilebilir. Capability ve output desteği güncel sürümde doğrulanmalıdır. Collector migration duplicate event kontrolüyle kademeli yapılmalıdır.

Elasticsearch ve Kibana'yı Public Internet'e Doğrudan Açmayın

9200 ve 5601 portları private network üzerinde tutulmalıdır. Kibana reverse proxy ve SSO arkasında yayınlanabilir. Admin erişimi VPN üzerinden sağlanabilir. Firewall default deny policy kullanmalıdır. Public application request'leri Elasticsearch cluster API'sine doğrudan ulaşmamalıdır.

TLS ve Least Privilege Uygulayın

Her transport bağlantısı TLS kullanmalıdır. Certificate verification açık kalmalıdır. Logstash ve Agent scoped API key ile çalışmalıdır. Dashboard user yalnız read yetkisi almalıdır. Superuser yalnız gerekli yönetim işlemlerinde kullanılmalıdır.

Data Stream ve Lifecycle Politikalarıyla Retention'ı Otomatikleştirin

Append-only logs data stream'e yazılmalıdır. ILM veya Data Stream Lifecycle retention'ı otomatik yönetir. Rollover shard boyutunu kontrol eder. Security ve application dataset farklı süre kullanabilir. Lifecycle failure storage alert ile birlikte izlenmelidir.

Persistent Queue ve DLQ ile Pipeline Dayanıklılığını Tasarlayın

Critical Logstash pipeline Persistent Queue kullanabilir. Queue capacity downtime buffer ihtiyacına göre hesaplanmalıdır. DLQ mapping error'ların sessiz kaybını azaltır. İki queue da monitoring ve cleanup gerektirir. Queue özelliği source protocol ve host disk failure risklerini tek başına çözmez.

Snapshot Alın ve Restore'u Gerçekten Test Edin

Elasticsearch data directory copy backup değildir. Snapshot supported recovery mekanizmasıdır. Repository cluster dışındaki storage'da tutulmalıdır. SLM schedule ve retention sağlar. Isolated test cluster restore tatbikatı RTO ve gerçek backup güvenilirliğini doğrular.

Log Pipeline'ını Kendi Başına Bir Production Sistemi Gibi İzleyin

Collector, Logstash ve Elasticsearch event count'ları karşılaştırılmalıdır. Ingestion lag ve queue growth alarm üretmelidir. Synthetic log end-to-end delivery'yi test eder. Disk, heap ve snapshot health ayrı izlenir. Merkezi log sistemi unavailable olduğunda diğer sistemlerin incident investigation kapasitesi de düştüğü için platformun kendi SLO'su bulunmalıdır.

Kurumsal ELK Stack kurulum ve merkezi log yönetimi hizmeti değerlendirirken yalnız Elasticsearch'ün kurulmuş olmasına bakmayın. Security, structured logging, lifecycle, backup, restore, alerting ve pipeline monitoring aynı mimari içinde düşünülmelidir. Diyarbakır Yazılım Topluluğu'nun teknik çalışma ve proje örneklerini https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyebilirsiniz. Topluluğun çalışma yaklaşımı hakkında daha fazla bilgi için https://www.diyarbakiryazilim.com.tr/about adresini kullanabilirsiniz. Elasticsearch ELK Stack ve log yönetimi danışmanlığı yakınımda şeklinde araştırma yapıyorsanız, hedefiniz yalnız logları tek ekranda görmek değil, kayıpsız, güvenli, ölçülebilir ve geri yüklenebilir bir merkezi log sistemi kurmak olmalıdır.

ELK Stack Kurulumu ve Merkezi Log Yönetimi Hakkında Ek Sık Sorulan Sorular

ELK projesini uygulamaya geçirirken kurulum komutlarından sonra veri toplama, pipeline tuning, lifecycle ve danışmanlık konuları öne çıkar. Her sistemin günlük GB miktarı ve retention ihtiyacı farklı olduğu için tek configuration bütün projelerde doğru sonuç vermez. Logstash kullanımının gerekli olup olmadığı da event formatı ve buffering gereksinimine göre değişir. Elasticsearch index ve data stream tasarımı dashboard performansını doğrudan etkiler. Aşağıdaki sorular proje başlangıcında sık karşılaşılan beş karar alanına kısa fakat uygulanabilir cevaplar verir.

Elasticsearch, Logstash ve Kibana (ELK Stack) kurulumu nasıl yapılır?

Ubuntu üzerinde önce Elastic signing key ve 9.x APT repository güvenli keyring yöntemiyle eklenir. Elasticsearch kurulduktan sonra systemd service başlatılır ve security auto-configuration tarafından oluşturulan TLS yapısı korunur. Kibana aynı stack sürümünde kurularak enrollment token ile Elasticsearch'e bağlanır. Logstash yalnız parsing, enrichment veya buffering gerekiyorsa eklenir ve Elasticsearch'e TLS ile minimum yetkili API key üzerinden bağlanır. Son aşamada collector, data stream, retention, dashboard, alert ve snapshot süreçleri test edilerek kurulum production standardına taşınır.

ELK Stack ile merkezi log yönetimi ve gerçek zamanlı log analizi nasıl yapılandırılır?

Application ve sunucu logları önce Elastic Agent veya Filebeat ile merkezi pipeline'a gönderilir. Event'ler ECS benzeri ortak field yapısına dönüştürülerek Elasticsearch data stream'lerine yazılır. Kibana Discover yakın gerçek zamanlı event investigation sağlarken dashboard'lar error rate, status ve latency trendlerini gösterir. Alert rule belirli threshold veya exception pattern'ini periyodik olarak kontrol ederek notification üretebilir. Ingestion lag, collector health ve Elasticsearch indexing latency izlenmezse arayüz gerçek zamanlı görünse bile pipeline gerçekte geride kalabilir.

Logstash pipeline’larında input, filter ve output yapılandırmaları nasıl optimize edilir?

Önce parsing işinin gerçekten Logstash'e ihtiyaç duyup duymadığı belirlenmelidir. Input protocol acknowledgement ve backpressure davranışına göre seçilir, structured JSON varsa ağır Grok yerine JSON veya Dissect tercih edilir. Filter zinciri gereksiz enrichment'tan arındırılır ve sample fixture ile test edilir. Output bulk Elasticsearch bağlantısı TLS kullanır, Persistent Queue gerekiyorsa disk kapasitesi gerçek downtime hedefi üzerinden hesaplanır. Pipeline performansı worker sayısını rastgele artırarak değil events/saniye, filter duration, queue depth ve indexing latency birlikte ölçülerek optimize edilir.

Elasticsearch indeks yönetimi, Kibana dashboard’ları ve log saklama politikaları nasıl yönetilmelidir?

Yeni log sistemlerinde klasik günlük index yerine data stream kullanmak lifecycle ve rollover yönetimini kolaylaştırır. Index template mapping, LogsDB veya başka setting'leri merkezi tanımlar ve uncontrolled dynamic field sayısı sınırlandırılır. ILM hot, warm, cold, frozen ve delete phase'leriyle ayrıntılı tier yönetimi sunarken Data Stream Lifecycle daha sade retention modeli sağlayabilir. Kibana dashboard'ları source control ile environment'lar arasında promote edilmeli ve expensive high-cardinality aggregation'lardan kaçınmalıdır. Retention her dataset'in operasyonel ve hukuki değerine göre ayrı belirlenmeli, disk trend'i ve lifecycle error'ları sürekli izlenmelidir.

Elasticsearch, Logstash ve Kibana (ELK) kurulumu ve log yönetimi konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Danışmanlık veya eğitim seçerken yalnız Elasticsearch package kurulumu anlatan yaklaşım yerine gerçek production senaryolarını kapsayan çalışmaları tercih edin. Structured logging, ECS, Agent veya Filebeat, Logstash Persistent Queue, TLS, RBAC, lifecycle, dashboard, alert, snapshot ve restore aynı örnek proje içinde uygulanmalıdır. Diyarbakır Yazılım Topluluğu'nun proje çalışmalarını https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyebilirsiniz. Topluluk hakkında ayrıntılı bilgi için https://www.diyarbakiryazilim.com.tr/about adresini kullanabilirsiniz. Böylece Log Yönetimi: Elasticsearch, Logstash ve Kibana (ELK) Kurulumu konusunda yalnız teori değil, monitoring, güvenlik, hata senaryosu ve recovery adımlarını içeren uygulamalı çalışma modeli oluşturabilirsiniz.