ELK ile Merkezi Log Analizi: Toplama, Ayrıştırma ve Görselleştirme

Merkezi log analizi hangi sorunu çözer?

Birkaç sunucudan oluşan bir sistemde bir hata araştırılırken tek tek makinelere bağlanıp dosya okumak mümkündür. Uygulama sayısı ve sunucu sayısı büyüdüğünde, hatta konteynerler her dağıtımda yok olup yeniden doğduğunda, bu yöntem çöker. Bir müşterinin yaşadığı hata birden fazla servisin kaydına dağılmış olabilir ve bu kayıtlar zaman damgası, biçim ve ayrıntı düzeyi bakımından birbirinden farklıdır.

Merkezi log analizi, tüm kaynaklardan gelen kayıtları tek bir yerde toplar, ortak bir yapıya sokar ve aranabilir hale getirir. ELK yığını bu iş için yaygın kullanılan bir çözümdür: Elasticsearch kayıtları saklar ve arar, Logstash kayıtları ayrıştırıp zenginleştirir, Kibana arama ve görselleştirme arayüzünü sağlar. Kayıtları kaynak makinelerden toplayan hafif ajanlar ise Beats ailesindendir.

Bu becerinin amacı sadece kayıtları bir yere yığmak değildir. Amaç, bir olay olduğunda neyin ne zaman bozulduğunu dakikalar içinde bulabilmek, tekrar eden hataları fark etmek ve sistemin sağlığını sürekli izleyebilmek için bir işleyiş kurmaktır.

Mimari: kayıt kaynaktan ekrana nasıl akar?

Tipik akış şu sırayı izler: • Uygulamalar ve işletim sistemi kayıt üretir: erişim logları, uygulama logları, denetim kayıtları. • Her sunucuda çalışan bir Beats ajanı, örneğin dosya okuyan Filebeat, bu kayıtları izler ve ağ üzerinden iletir. • Logstash gelen kaydı alır, alanlara ayırır, zaman damgasını düzeltir, gerekirse zenginleştirir ve Elasticsearch'e yazar. • Elasticsearch kayıtları indeksler ve aranabilir tutar. • Kibana, bu indeksler üzerinde arama, pano ve uyarı arayüzü sunar.

Her parçanın sorumluluğu bilinçli olarak ayrıdır. Ajan hafif kalır ve sunucuyu yormaz. Ağır dönüştürme işi merkezde yapılır. Yoğun trafikte kayıtların kaybolmaması için ajan ile ayrıştırıcı arasına bir tampon katmanı, örneğin bir kuyruk, koymak yaygın bir tasarım tercihidir. Küçük bir kurulumda ajan doğrudan Elasticsearch'e yazabilir; ayrıştırma ihtiyacı büyüdükçe Logstash devreye girer.

Kurulum planı yapılırken önce hangi kaynakların izleneceği, günlük kayıt hacminin yaklaşık ne kadar olacağı ve kayıtların ne kadar süre erişilebilir tutulacağı belirlenir. Küme boyutlandırması bu soruların cevabına dayanır.

Kayıtları toplama ve ayrıştırma

Ham bir kayıt satırı insan için okunaklıdır ama makine için yapılandırılmamış bir metindir. Analiz yapabilmek için satırdan zaman damgası, seviye, servis adı, istek kimliği, kullanıcı kimliği, yanıt süresi gibi alanları çıkarmak gerekir. Logstash'te bu iş filtre aşamasında yapılır. Düzenli ifadelere dayanan ayrıştırma desenleri, anahtar-değer ayırıcılar ve JSON çözücüler sık kullanılan araçlardır.

En sağlam yaklaşım, uygulamanın en baştan JSON biçiminde yapılandırılmış kayıt üretmesidir. Bu durumda ayrıştırma neredeyse hiç iş gerektirmez ve desenlerin sessizce bozulma riski ortadan kalkar. Uygulamayı değiştirmek mümkün değilse, örneğin hazır bir web sunucusunun erişim logu söz konusuysa, ayrıştırma deseni test edilerek yazılır.

Zenginleştirme adımında kayıtlara anlam katılır: IP adresinden coğrafi bilgi, kullanıcı ajanı metninden tarayıcı ve cihaz türü, servis adından sahip ekip bilgisi eklenebilir. Kişisel veri içeren alanların bu aşamada maskelenmesi ya da silinmesi de ayrıştırma hattının görevlerindendir. Ayrıştırılamayan kayıtlar atılmaz; ayrı bir alana ya da indekse yönlendirilerek sonra incelenir, çünkü desen hatalarının ilk işareti genellikle budur.

İndeks yönetimi ve yaşam döngüsü

Log verisi sürekli akar ve hızla büyür. Tek bir devasa indeks yerine kayıtlar zamana göre bölünmüş indekslere ya da veri akışlarına (data stream) yazılır. Böylece eski veriyi silmek, tek tek kayıtları aramak yerine bütün bir indeksi kaldırmak anlamına gelir; bu hem hızlı hem ucuzdur.

Index lifecycle management (ILM) ile verinin yaşam döngüsü politikaya bağlanır. Taze veri hızlı disklerde ve sık sorgulanan katmanda tutulur, zaman geçtikçe daha ucuz katmanlara taşınır, saklama süresi dolunca silinir. Politikayı belirlerken iş ve mevzuat gereksinimleri birlikte düşünülür: güvenlik olayı incelemesi için ne kadar geriye bakmak gerekir, denetim kayıtlarını saklama yükümlülüğü var mı, kişisel veri içeren kayıtlar ne kadar tutulabilir?

Bu aşamada sık yapılan hata, her alanı otomatik tahmine bırakmaktır. Yanlış tip atanmış alan ya da çok sayıda farklı değer alan bir alan, indeksi şişirir ve sorguları yavaşlatır. Mapping'in kayıt şemasına göre önceden tanımlanması, alanların ne için kullanılacağına karar verilmesi gerekir.

Kibana'da arama, pano ve uyarı

Kibana'nın keşif ekranı, olay anında ilk bakılan yerdir. Zaman aralığı seçilir, bir servis adı ya da hata seviyesi ile süzülür, ilgili istek kimliği aranır ve bir isteğin servisler arasında izlediği yol kayıtlar üzerinden sıraya dizilir. Zaman damgalarının doğru ayrıştırılmış olması burada kritik bir koşuldur; aksi halde olaylar yanlış sırada görünür.

Panolar tekrar eden soruları hızlı yanıtlamak için kurulur. Örneğin hata seviyesindeki kayıtların zaman içindeki seyri, servis başına yanıt süresi dağılımı, en çok hata üreten uç noktalar, sistem kaynaklarını kullanan süreçler. İyi bir pano kalabalık değildir; her grafik bir karar sorusuna bağlanır.

Uyarılar ise analizi pasif izlemeden aktif müdahaleye taşır. "Bir servis belli bir süre içinde olağandışı çok hata ürettiğinde ilgili ekibe haber ver" gibi kurallar tanımlanır. Her gürültüye uyarı kurmak, ekibin uyarıları görmezden gelmesine yol açar; bu yüzden uyarı eşikleri gerçek olay geçmişi üzerinden ayarlanır ve düzenli olarak gözden geçirilir.

Güvenlik, performans ve işletim

Log verisi çoğu zaman hassas bilgi içerir: kullanıcı adları, IP adresleri, bazen yanlışlıkla kaydedilmiş parolalar ya da anahtarlar. Bu yüzden kümeye erişim kimlik doğrulama ve rol bazlı yetkiyle sınırlandırılır, ekiplerin yalnızca kendi servislerinin kayıtlarını görmesi sağlanır, iletim ve saklama şifrelenir. Kayıtlara kimin eriştiğinin denetlenmesi uyum gereksinimlerinde sıklıkla istenir.

Performans tarafında kayıt hacmi arttıkça ayrıştırma hattı, indeks hızı ve sorgu süreleri izlenmesi gereken göstergelerdir. Ajan tarafında geri basınç, yani hedefin kayıtları yetiştirememesi, kayıp riskini artırır; tampon katmanı ve yeniden deneme ayarı bu durumda devreye girer. Kümenin kendisi de izlenmelidir: disk doluluğu, yavaş sorgular, shard dağılımı ve kullanılabilirlik.

İşletim planı unutulan bir konudur. Sürüm yükseltmeleri, yedekleme ve geri yükleme denemeleri, yeni bir uygulama eklendiğinde izlenecek adımlar ve ekip içindeki sorumluluk dağılımı yazılı olmalıdır. Log sistemi bozulduğunda diğer tüm sorunların teşhisi de zorlaşır; bu yüzden bu sistem de izlenen bir sistem olmalıdır.

Mindset programında bu beceri

"Elastic Stack (ELK) ile Merkezi Log Analizi" eğitiminin modül başlıkları bu becerinin akışını izliyor: merkezi log mimarisi ve Elastic Stack bileşenleri, Elasticsearch küme tasarımı, log toplama ve Beats yapılandırması, Logstash ile ayrıştırma ve zenginleştirme, indeks yönetimi ve yaşam döngüsü, Kibana ile arama ve görselleştirme, güvenlik, erişim ve uyum, performans, izleme ve işletim planı.

Aynı motoru uygulama içi arama için kullanmak isteyenler için "Full-Text Search ve Arama Motoru Entegrasyonu (Elasticsearch)" eğitimi ayrı bir yol sunuyor.