Günümüzün karmaşık sistemlerinde günlük yönetimi neden bu kadar kritik?

Grafana Alloy ve Loki ile Modern Günlük Yönetimi: Derinlemesine Bir Kılavuz

Günümüzün hızla gelişen ve sürekli büyüyen dijital dünyasında, sistemlerin karmaşıklığı da doğru orantılı olarak artıyor. Mikroservis mimarileri, bulut tabanlı altyapılar ve dağıtık uygulamalar, operasyonel görünürlüğü sağlamayı her zamankinden daha kritik hale getiriyor. Peki, yüzlerce hatta binlerce container’ın veya sunucunun aynı anda çalıştığı bir ortamda, bir sorun çıktığında “neden” sorusunun cevabını nasıl buluruz? İşte tam da bu noktada etkili bir günlük (log) yönetimi stratejisi devreye giriyor. Geleneksel günlükleme yaklaşımları genellikle verimsiz kalırken, modern araçlar sayesinde bu zorlukların üstesinden gelmek mümkün. Grafana Alloy ve Loki ikilisi, tam da bu ihtiyaca yönelik güçlü, ölçeklenebilir ve maliyet etkin bir çözüm sunarak, sistemlerinizin nabzını tutmanızı sağlıyor.

Modern yazılım mimarileri, özellikle mikroservisler ve bulut tabanlı altyapılar, beraberinde ciddi operasyonel zorluklar getiriyor. Monolitik bir uygulamanın aksine, mikroservis tabanlı bir yapıda bir iş akışı birden fazla servisin etkileşimiyle tamamlanır. Bu karmaşık etkileşim ağı içinde bir sorun ortaya çıktığında, hatanın kökenini bulmak adeta samanlıkta iğne aramaya benzer bir hale gelebilir. Geleneksel sunucu tabanlı günlük toplama yöntemleri, yani her sunucuya tek tek bağlanıp günlük dosyalarını incelemek, bu ölçekteki sistemlerde hem zaman alıcı hem de verimsizdir. Üstelik, her bir servisin farklı formatlarda günlük üretmesi, bu günlükleri standart bir şekilde analiz etmeyi daha da zorlaştırır.

Dağıtık sistemlerde yaşanan performans sorunları, ağ gecikmeleri, hatalı konfigürasyonlar veya yazılım hataları gibi durumlar, günlük dosyalarında değerli ipuçları barındırır. Ancak bu ipuçlarına hızlı ve etkin bir şekilde erişmek, işletmelerin arıza süresini (downtime) minimize etmesi ve müşteri memnuniyetini koruması için hayati öneme sahiptir. Görünürlük eksikliği, sorunların tespit edilmesini geciktirir, bu da doğrudan finansal kayıplara ve marka itibarı erozyonuna yol açabilir. Bu nedenle, merkezi, ölçeklenebilir ve kolayca sorgulanabilir bir günlük yönetimi çözümü, operasyonel mükemmelliğe ulaşmak isteyen her kuruluş için bir lüks değil, bir zorunluluktur. Ayrıca, güvenlik olaylarının tespiti ve uyumluluk denetimleri için de günlükler olmazsa olmaz bir veri kaynağıdır.

İşte tam bu noktada, modern günlükleme çözümleri devreye girer. Bu çözümler, farklı kaynaklardan gelen günlükleri tek bir merkezde toplar, standardize eder, etiketler ve hızlı sorgulamaya olanak tanır. Böylece, operasyon ekipleri, geliştiriciler ve güvenlik analistleri, ihtiyaç duydukları bilgilere anında ulaşabilir. Örneğin, bir kullanıcının sepetine ürün ekleyemediği bir senaryoda, ilgili servisin günlüklerini anında filtreleyip hatanın nerede ve neden oluştuğunu saniyeler içinde tespit etmek, modern bir günlükleme platformunun temel faydalarından biridir. Grafana Alloy ve Loki ikilisi, bu gereksinimleri karşılamak üzere tasarlanmış, performansı ve maliyet etkinliği ile öne çıkan güçlü bir kombinasyondur. Bu araçlar, günlük verilerini sadece bir depolama alanı olmaktan çıkarıp, değerli bir operasyonel zeka kaynağına dönüştürür. Loglarınızı anlamak ve onlardan eyleme dönüştürülebilir bilgiler çıkarmak, sistemlerinizin sağlığını korumanın ve proaktif bir şekilde yönetmenin anahtarıdır.

Peki, Grafana Loki ve Grafana Alloy Nedir ve Neden Birlikte Kullanmalıyız?

Günlük yönetiminin kritik önemini anladığımıza göre, şimdi bu sorunu çözmek için kullanacağımız temel araçlara, yani Grafana Loki ve Grafana Alloy’a daha yakından bakalım. Bu iki araç, Grafana ekosisteminin önemli parçalarıdır ve modern gözlemlenebilirlik (observability) stratejilerinin temel taşlarından birini oluştururlar. İkisi bir araya geldiğinde, günlük verilerini toplama, depolama ve sorgulama süreçlerini devrim niteliğinde basitleştirir ve hızlandırır.

Grafana Loki nedir? Loki, adından da anlaşılacağı gibi, Prometheus’un günlük eşdeğeri olmayı hedefleyen, ancak kendine özgü bir mimariye sahip olan, yatay ölçeklenebilir ve yüksek oranda erişilebilir bir günlük toplama sistemidir. Loki’nin en ayırt edici özelliği, günlük içeriğini doğrudan indekslememesi, bunun yerine Promtail gibi bir ajan tarafından günlük verilerine eklenen etiketleri (labels) indekslemesidir. Bu “sadece etiketle indeksleme” yaklaşımı, hem depolama maliyetlerini önemli ölçüde düşürür hem de sorgulama performansını artırır. Geleneksel günlükleme çözümleri, her bir günlük satırındaki her kelimeyi indeksleyerek devasa indeks boyutları oluştururken, Loki sadece meta verileri (etiketleri) indeksler. Bu, Loki’yi özellikle yüksek hacimli günlük verileri için maliyet etkin bir seçim haline getirir. Etiketler, bir günlük akışını (log stream) benzersiz şekilde tanımlayan anahtar-değer çiftleridir; örneğin, app=nginx, level=error, instance=web-01. Bu etiketler sayesinde, kullanıcılar belirli bir uygulamaya, hata seviyesine veya sunucuya ait günlükleri hızlıca filtreleyebilirler.

Grafana Alloy nedir? Daha önce Promtail adıyla bilinen ve Loki’nin günlük toplama ajanı olarak görev yapan araç, artık Grafana Alloy olarak karşımızda. Alloy, modern telemetri verilerini (metrikler, günlükler ve izler) Prometheus’tan ilham alan bir yapılandırma dili (River) kullanarak toplamak, işlemek ve yönlendirmek için tasarlanmış açık kaynaklı bir ajandır. Aslında, Alloy Prometheus’un scrape_config yapısına benzer bir şekilde günlükleri ve metrikleri toplama yeteneğine sahiptir. Promtail, yalnızca günlük toplamak için tasarlanmışken, Alloy çok daha fazlasını sunar. Modüler yapısı sayesinde, hem Prometheus metriklerini hem de Loki günlüklerini aynı ajan üzerinden, merkezi ve tutarlı bir yapılandırma ile toplamanıza olanak tanır. Bu, operasyonel karmaşıklığı azaltır ve gözlemlenebilirlik araç setinizi basitleştirir. Alloy’un River yapılandırma dili, kullanıcıların veri akışlarını deklaratif bir şekilde tanımlamasını sağlar; bu da karmaşık işleme adımlarını (parsing, filtreleme, etiketleme) son derece esnek hale getirir.

Neden Birlikte Kullanmalıyız? Grafana Alloy ve Loki, birbirini mükemmel şekilde tamamlayan bir ikilidir. Alloy, sistemlerinizden ve uygulamalarınızdan günlükleri toplayan, onları işleyen (etiketler ekleyen, formatı değiştiren) ve ardından Loki’ye gönderen “ön cephe” ajanıdır. Loki ise bu işlenmiş günlükleri etiketleyerek depolar ve güçlü LogQL sorgulama dili ile sorgulanabilir hale getirir. Bu entegrasyonun başlıca faydaları şunlardır:

1. Birleştirilmiş Gözlemlenebilirlik: Alloy, hem metrikleri hem de günlükleri tek bir ajanla toplama yeteneği sayesinde, gözlemlenebilirlik stratejinizi birleştirir. Bu, araç karmaşıklığını ve yönetim yükünü azaltır.
2. Maliyet Etkinliği: Loki’nin etiket tabanlı indeksleme yaklaşımı ve Alloy’un etkin veri işleme yetenekleri, depolama ve altyapı maliyetlerini geleneksel çözümlere kıyasla önemli ölçüde düşürür.
3. Esneklik ve Genişletilebilirlik: Alloy’un modüler yapısı ve River yapılandırma dili, neredeyse her türden günlük formatını ve veri kaynağını işlemek için üst düzey esneklik sunar. Regex, JSON, logfmt gibi birçok işlemciyi destekler.
4. Kolay Sorgulama ve Görselleştirme: Loki’nin LogQL’i ve Grafana ile mükemmel entegrasyonu sayesinde, günlük verilerini hızlıca sorgulayabilir, filtreleyebilir ve anlamlı panolar oluşturarak sistemlerinizin durumunu anlık olarak izleyebilirsiniz.
5. Operasyonel Basitlik: Tek bir ajanla hem metrik hem de günlük toplamak, dağıtık sistemlerde operasyonel basitliği artırır ve sorun giderme süreçlerini hızlandırır.

Kısacası, Grafana Alloy günlüklerinizi etkili bir şekilde toplayıp hazırlarken, Grafana Loki bu günlükleri düşük maliyetle depolar ve kolayca sorgulanabilir hale getirir. Bu sinerji, modern IT altyapılarında günlük yönetimini bambaşka bir boyuta taşıyor.

Grafana Alloy Kurulumu ve Temel Yapılandırması: Adım Adım Bir Kılavuz

Grafana Alloy ve Loki ikilisinin gücünü anladığımıza göre, şimdi sıra geldi bu araçları pratik olarak sistemlerimize entegre etmeye. Alloy’un kurulumu ve temel yapılandırması oldukça basittir, ancak River dilinin getirdiği esneklik sayesinde çok daha karmaşık senaryolara uyarlanabilir. Bu bölümde, Alloy’u bir sunucuya kurmayı ve ilk günlük toplama yapılandırmasını oluşturmayı adım adım inceleyeceğiz.

Adım 1: Grafana Alloy Kurulumu

Grafana Alloy’u çeşitli yollarla kurabilirsiniz: ikili dosyadan, Docker container olarak veya Kubernetes ortamında DaemonSet olarak. En basit yöntemlerden biri, doğrudan ikili dosyasını indirmektir. Linux tabanlı bir sistem için örnek:

# En son sürümü indirin (sürüm numarasını kontrol edin)
wget https://github.com/grafana/alloy/releases/download/v1.0.0/alloy-linux-amd64.zip
unzip alloy-linux-amd64.zip
mv alloy-linux-amd64 /usr/local/bin/alloy

# Çalıştırılabilir hale getirin
chmod +x /usr/local/bin/alloy

Eğer Docker kullanıyorsanız, durum daha da basittir:

docker pull grafana/alloy:latest

Adım 2: Temel Yapılandırma Dosyası Oluşturma (alloy.river)

Alloy, yapılandırmasını "River" adlı, Prometheus'tan esinlenilmiş bir DSL (Domain Specific Language) ile tanımlar. Bu dil, bileşenler (components) aracılığıyla veri akışlarını (pipelines) oluşturmanızı sağlar. Yeni bir dosya olan alloy.river oluşturalım ve içine temel bir günlük toplama yapılandırması ekleyelim:

// alloy.river

// Adım 1: Günlükleri okuyacağımız bir kaynak tanımlayalım.
// Bu örnekte, /var/log/myapp.log dosyasını izleyeceğiz.
loki.source.file "myapp_logs" {
    targets    = loki.source.file.find_targets(
        log_directory  = "/var/log/",
        log_file_name  = "myapp.log",
        labels         = {
            job = "myapp",
            env = "development",
        },
    )
    // Bu etiketler, her günlük satırına eklenecektir.
    forward_to = [loki.write.default.receiver] // Loki'ye gönderilecek
}

// Adım 2: Günlükleri işleyelim (isteğe bağlı, ama genelde gerekli).
// Bu örnekte, logfmt formatındaki günlükleri parse edip etiketler çıkaracağız.
loki.process "myapp_parser" {
    forward_to = [loki.write.default.receiver] // İşlenmiş günlükler Loki'ye gönderilecek

    stage {
        // Logfmt parser: key=value çiftlerini algılar ve etiket yapar
        logfmt {}
    }

    stage {
        // Regex parser: Karmaşık metinlerden etiket çıkarmak için kullanılır
        regex {
            expression = "level=(?P\\w+) msg=\"(?P.*)\""
        }
    }
    
    // myapp_logs'dan gelen günlükleri işlemek için bu işlemciyi kullan
    source_address = loki.source.file.myapp_logs.receiver
}

// Adım 3: Loki'ye günlükleri yazmak için bir hedef tanımlayalım.
// Burada Loki sunucunuzun adresini belirtmelisiniz.
loki.write "default" {
    endpoint {
        url = "http://localhost:3100/loki/api/v1/push" // Loki'nin push API adresi
    }
}

Yukarıdaki yapılandırma dosyasını inceleyelim:

• loki.source.file "myapp_logs": Bu blok, Alloy'a belirli bir dosyadan veya dizinden günlükleri nasıl alacağını söyler. find_targets fonksiyonu ile /var/log/myapp.log dosyasını hedef olarak belirledik. Ayrıca, tüm bu günlük akışına job=myapp ve env=development gibi temel etiketler ekledik. Bu etiketler, Loki'de sorgulama yaparken ana filtreleme noktalarınız olacaktır. forward_to ile bu günlüklerin loki.write.default.receiver'a, yani Loki'ye yazma bileşenimize gönderileceğini belirtiyoruz.
• loki.process "myapp_parser": Bu kısım isteğe bağlıdır ancak günlüklerinizi daha anlamlı hale getirmek için çok önemlidir. Alloy, stage blokları aracılığıyla günlükler üzerinde çeşitli işlemler yapabilir.
  • logfmt {}: Günlük satırı key=value formatındaysa (örneğin, level=info msg="User logged in"), bu işlemci level ve msg gibi alanları otomatik olarak yeni etiketlere dönüştürecektir.
  • regex {}: Daha karmaşık formatlar için düzenli ifadeler (regex) kullanabilirsiniz. Örnekte, level ve message alanlarını yakalayıp bunlara log_level ve message adlarını veriyoruz. Bu, daha sonra Loki'de bu alanlar üzerinde filtreleme yapmanızı sağlar. source_address ile hangi günlük kaynağının bu işlemciye yönlendirileceğini belirtiyoruz.
• loki.write "default": Bu blok, işlenmiş günlüklerin nereye gönderileceğini tanımlar. url alanı, Loki sunucunuzun push API adresini gösterir. Varsayılan olarak, Loki 3100 portunda çalışır. Eğer Loki farklı bir sunucuda çalışıyorsa, localhost yerine o sunucunun IP adresi veya hostname'ini kullanmalısınız.

Adım 3: Grafana Alloy'u Çalıştırma

Yapılandırma dosyasını kaydettikten sonra, Alloy'u basitçe çalıştırabilirsiniz:

./alloy -config.file=./alloy.river

Eğer Docker kullanıyorsanız:

docker run -d -v /var/log:/var/log:ro -v $(pwd)/alloy.river:/etc/alloy/config.river \
    grafana/alloy:latest -config.file=/etc/alloy/config.river

Bu komut, Alloy'u arka planda çalıştırır, yerel günlük dizininizi container'a bağlar ve yapılandırma dosyanızı kullanmasını sağlar. Alloy başarılı bir şekilde çalıştığında, belirtilen günlük dosyasındaki yeni satırları okuyacak, işleyecek ve Loki'ye göndermeye başlayacaktır. Artık günlükleriniz merkezi bir noktada toplanmaya hazır!

Gerçek Dünya Senaryosu: Mikroservis Günlüklerini Grafana Alloy ile Toplama ve Loki'ye Gönderme Nasıl Yapılır?

Şimdiye kadar Alloy'un temel kurulumunu ve basit bir günlük dosyasını nasıl işleyeceğini öğrendik. Ancak modern uygulamaların çoğu tek bir monolitik dosyadan günlük üretmez. Genellikle, çeşitli mikroservisler, farklı formatlarda (JSON, Apache access log, özel metin formatları vb.) günlükler üretir ve bu günlükler farklı dizinlerde veya stdout/stderr'e yazılır. Bu bölümde, bir e-ticaret uygulamasının mikroservis mimarisindeki günlüklerini Grafana Alloy ile nasıl toplayacağımızı ve Loki'ye nasıl göndereceğimizi detaylı bir vaka analiziyle inceleyelim.

Senaryo: E-ticaret Uygulaması Mikroservis Günlükleri

Hayali e-ticaret uygulamamızın üç ana mikroservisi olduğunu varsayalım:

1. Sipariş Servisi (Order Service): JSON formatında günlükler üretir. Örneğin, /var/log/orders/order-service.json dosyasına yazar.
2. Kullanıcı Servisi (User Service): Apache benzeri erişim günlükleri formatında (common log format) günlükler üretir. /var/log/users/access.log dosyasına yazar.
3. Ödeme Servisi (Payment Service): Standart metin formatında, logfmt benzeri günlükler üretir. /var/log/payments/payment.log dosyasına yazar.

Amacımız, bu üç farklı kaynaktan gelen günlükleri Alloy ile toplayıp işlemek, doğru etiketleri atamak ve ardından Loki'ye göndermektir. Bu sayede, Grafana üzerinden belirli bir servise, HTTP durum koduna, kullanıcı kimliğine veya hata seviyesine göre kolayca sorgulama yapabileceğiz.

Grafana Alloy Yapılandırması (alloy.river):

Öncelikle, her servis için ayrı bir loki.source.file bileşeni tanımlayarak günlük dosyalarını izlemeye başlayacağız. Ardından, her bir kaynak için uygun loki.process bileşenlerini kullanarak günlükleri formatlarına göre ayrıştırıp etiketler çıkaracağız.

// alloy.river - Mikroservis Günlük Toplama Yapılandırması

// Loki'ye günlükleri yazmak için merkezi hedef
loki.write "default_loki_writer" {
    endpoint {
        url = "http://loki:3100/loki/api/v1/push" // Loki servisi genellikle Kubernetes'te 'loki' adıyla çalışır
        // Kubernetes içindeyseniz, bu URL'yi uygun şekilde yapılandırın
    }
}

// ----------------------------------------------------
// Sipariş Servisi Günlükleri (JSON Formatı)
// ----------------------------------------------------
loki.source.file "order_service_logs" {
    targets = loki.source.file.find_targets(
        log_directory  = "/var/log/orders/",
        log_file_name  = "order-service.json",
        labels         = {
            job         = "ecommerce-order-service",
            environment = "production",
            service     = "order-service",
        },
    )
    forward_to = [loki.process.order_parser.receiver]
}

loki.process "order_parser" {
    forward_to = [loki.write.default_loki_writer.receiver]

    stage {
        json {
            expressions = {
                "level"      = "level",
                "message"    = "msg",
                "order_id"   = "orderId",
                "customer_id"= "customerId"
            }
        }
    }
    stage {
        // level değerini Loki etiketine dönüştür
        labels {
            level = json.level
        }
    }
    stage {
        // Hata seviyesi günlüklere özel bir etiket ekleyelim
        match {
            selector = "{level=\"error\"}"
            stage {
                labels {
                    error_type = "application_error"
                }
            }
        }
    }
    source_address = loki.source.file.order_service_logs.receiver
}

// ----------------------------------------------------
// Kullanıcı Servisi Günlükleri (Apache Access Log Formatı)
// ----------------------------------------------------
loki.source.file "user_service_access_logs" {
    targets = loki.source.file.find_targets(
        log_directory  = "/var/log/users/",
        log_file_name  = "access.log",
        labels         = {
            job         = "ecommerce-user-service",
            environment = "production",
            service     = "user-service",
        },
    )
    forward_to = [loki.process.user_access_parser.receiver]
}

loki.process "user_access_parser" {
    forward_to = [loki.write.default_loki_writer.receiver]

    stage {
        // Apache Common Log Format için Regex
        regex {
            expression = "(?P\\S+) \\S+ (?P\\S+) \\[(?P[\\w:/]+\\s[+\\-]\\d{4})\\] \"(?P\\S+)\\s(?P\\S+)\\s(?P\\S+)\" (?P\\d{3}) (?P\\d+)"
        }
    }
    stage {
        // Regex ile yakalanan alanları Loki etiketlerine dönüştür
        labels {
            ip          = regex.ip,
            user        = regex.user,
            method      = regex.method,
            path        = regex.path,
            status_code = regex.status_code
        }
    }
    stage {
        // HTTP durum koduna göre hata seviyesi etiketi ekle
        match {
            selector = "{status_code=~\"[45]\\d{2}\"}" // 4xx veya 5xx hataları
            stage {
                labels {
                    level = "error"
                }
            }
            else_stage {
                labels {
                    level = "info"
                }
            }
        }
    }
    source_address = loki.source.file.user_service_access_logs.receiver
}

// ----------------------------------------------------
// Ödeme Servisi Günlükleri (Logfmt Benzeri Metin Formatı)
// ----------------------------------------------------
loki.source.file "payment_service_logs" {
    targets = loki.source.file.find_targets(
        log_directory  = "/var/log/payments/",
        log_file_name  = "payment.log",
        labels         = {
            job         = "ecommerce-payment-service",
            environment = "production",
            service     = "payment-service",
        },
    )
    forward_to = [loki.process.payment_parser.receiver]
}

loki.process "payment_parser" {
    forward_to = [loki.write.default_loki_writer.receiver]

    stage {
        logfmt {} // key=value çiftlerini otomatik yakalar
    }
    stage {
        // logfmt tarafından yakalanan 'level' alanını Loki etiketine dönüştür
        labels {
            level = logfmt.level
        }
    }
    stage {
        // 'transaction_id' alanını da etiket olarak ekleyelim
        labels {
            transaction_id = logfmt.transaction_id
        }
    }
    source_address = loki.source.file.payment_service_logs.receiver
}

Yapılandırma Detayları ve Açıklamalar:

• Her bir mikroservis için loki.source.file bloğu, ilgili günlük dosyasını ve bu günlük akışına atanacak job, environment, service gibi temel etiketleri tanımlar. Bu etiketler, daha sonra Loki'de tüm günlükleri filtrelemek için kullanılacak anahtar-değer çiftleridir.
• Her bir loki.source.file bileşeninin çıktısı, ilgili loki.process bileşenine forward_to ile yönlendirilir. Bu, her servisin günlüklerinin kendi formatına özel işlemden geçmesini sağlar.
• Sipariş Servisi (order_parser): json {} aşaması, JSON formatındaki günlükleri ayrıştırır. expressions ile JSON içindeki alanları Alloy'un dahili alanlarına nasıl eşleştireceğimizi belirtiriz. Ardından, labels {} aşaması, bu ayrıştırılmış alanlardan (json.level, json.order_id vb.) Loki etiketleri oluşturur. Son olarak, match {} aşamasıyla, günlükteki level alanı "error" ise, ek olarak error_type=application_error etiketini ekleyerek daha derinlemesine bir sınıflandırma yaparız.
• Kullanıcı Servisi (user_access_parser): Bu kısım biraz daha karmaşıktır çünkü Apache erişim günlükleri özel bir regex deseni gerektirir. regex {} aşaması, belirtilen düzenli ifadeyle günlük satırını ayrıştırır ve yakaladığı grupları (ip, user, status_code vb.) Alloy'un dahili alanları olarak kaydeder. Yine labels {} aşamasıyla bu alanlar Loki etiketlerine dönüştürülür. match {} aşaması, HTTP status_code 4xx veya 5xx ise level=error etiketi eklerken, diğer durumlarda level=info etiketi ekleyerek günlük seviyesini otomatik olarak belirler.
• Ödeme Servisi (payment_parser): Bu servis için logfmt {} işlemcisi yeterlidir, çünkü günlükler key=value çiftleri içerir. Bu işlemci, bu çiftleri otomatik olarak ayrıştırır ve ardından labels {} aşamasıyla istediğimiz alanları (örneğin level, transaction_id) etiketlere dönüştürür.

Bu yapılandırma sayesinde, farklı formatlardaki mikroservis günlüklerinizi merkezi bir şekilde toplayabilir, anlamlı etiketlerle zenginleştirebilir ve Loki'ye göndererek güçlü sorgulama ve görselleştirme yeteneklerinden faydalanabilirsiniz. Her bir servisin günlük akışı, kendine özgü etiket setleriyle Loki'de kolayca ayırt edilebilir ve izlenebilir hale gelir.

Loki'de Log Sorgulama ve Grafana ile Görselleştirme: Günlüklerinizden Değer Çıkarma

Günlükleri Alloy ile başarıyla topladık ve Loki'ye gönderdik. Şimdi asıl önemli kısım: Bu günlüklerden anlamlı bilgiler çıkarmak. Loki'nin kalbinde, Prometheus'un PromQL sorgulama dilinden esinlenerek geliştirilmiş güçlü bir günlük sorgulama dili olan LogQL bulunur. Grafana ise, Loki veri kaynağını kullanarak bu sorguları çalıştırır ve günlükleri hem metin olarak göstermenin hem de görselleştirmelerin kapısını aralar. Bu bölümde, LogQL'in temellerini, Grafana ile nasıl entegre edileceğini ve günlük verilerinden nasıl değer çıkarılacağını adım adım inceleyeceğiz.

LogQL Temelleri: Günlüklerinizi Nasıl Sorgularsınız?

LogQL, temelde iki ana bileşenden oluşur: Günlük Akışı Seçicileri (Log Stream Selectors) ve Günlük Boruları (Log Pipelines). Günlük Akışı Seçicileri, hangi günlük akışlarını sorgulamak istediğinizi etiketler aracılığıyla belirlerken, Günlük Boruları bu akışlar üzerinde metin filtreleme ve işleme işlemleri yapar.

1. Günlük Akışı Seçicileri:
Etiketler, LogQL'in temelidir. Bir günlük akışı seçicisi, süslü parantezler {} içinde bir veya daha fazla etiket anahtar-değer çifti ile tanımlanır. Örneğin, daha önceki örneğimizdeki tüm Sipariş Servisi günlüklerini seçmek için:

{job="ecommerce-order-service"}

Birden fazla etiketle filtreleme yapabilirsiniz:

{job="ecommerce-order-service", level="error"}

Etiket değerleri için eşleşme operatörleri:

• = (eşittir)
• != (eşit değildir)
• =~ (regex eşleşir)
• !~ (regex eşleşmez)

Örnek:

// Tüm production ortamındaki servislerin günlükleri
{environment="production"}

// user-service ve payment-service dışındaki tüm servislerin günlükleri
{service!="user-service", service!="payment-service"}

// path etiketi '/api/v1/orders' ile başlayan tüm günlükler
{path=~"/api/v1/orders.*"}

2. Günlük Boruları (Log Pipelines):
Günlük akışı seçicisinden sonra gelen boru operatörü |, günlük içeriği üzerinde işlem yapmanızı sağlar. Bu işlemler şunları içerebilir:

• Metin Filtreleme: Günlük içeriğinde belirli bir metni aramak için.
  • |= "hata": "hata" kelimesini içeren satırları seç.
  • !~ "başarılı": "başarılı" kelimesini içermeyen satırları seç.
  • |~ "userId=\\d+": "userId=" ile başlayan ve rakam içeren satırları seç.
• Ayrıştırma (Parsing): Günlük içeriğindeki yapılandırılmış verileri (JSON, regex, logfmt) ayrıştırmak ve geçici alanlar oluşturmak için.
  • | json: Günlük satırını JSON olarak ayrıştır.
  • | logfmt: Günlük satırını logfmt olarak ayrıştır.
  • | regexp "duration=(?P\\d+)": Özel bir regex ile 'duration' alanını yakala.
• Etiket Oluşturma/Yeniden Etiketleme: Ayrıştırılmış alanlardan yeni etiketler oluşturmak için.
  • | label_format duration_ms="{{.duration}}": duration alanını yeni bir etiket olarak ekle.

Örnek bir LogQL sorgusu:

// Sipariş servisi günlüklerinde "ERROR" içeren ve customer_id etiketi olanları bul
{service="order-service", level="error"} |= "ödeme başarısız" | json customer_id="customerId"

Agregasyon Fonksiyonları (Metrics from Logs):
LogQL, günlük akışlarından metrikler türetmek için de güçlü fonksiyonlar sunar. Bunlar, günlük hacmini, hata oranlarını veya belirli olayların sıklığını görselleştirmek için idealdir.

• count_over_time(): Belirli bir zaman aralığında günlük satırı sayısını döndürür.
• rate(): Belirli bir zaman aralığındaki günlük satırlarının ortalama oranını döndürür.
• sum by(): Etiketlere göre gruplayarak toplam alma.

Örnek:

// Son 5 dakikadaki tüm hata günlüklerinin sayısını 1 dakikalık aralıklarla göster
sum by (service) (count_over_time({level="error"}[5m]))

Grafana ile Görselleştirme: Günlüklerinizi Canlı Tutun

Grafana, Loki'den gelen günlük verilerini keşfetmek, sorgulamak ve görselleştirmek için en ideal arayüzdür. Grafana'yı Loki ile entegre etmek oldukça basittir.

1. Loki'yi Grafana Veri Kaynağı Olarak Ekleme:
Grafana web arayüzünde "Configuration" -> "Data Sources" -> "Add data source" yolunu izleyin ve "Loki"yi seçin. Ardından Loki sunucunuzun URL'sini (örneğin, http://loki:3100) girin ve kaydedin.

2. Grafana Explore ile Günlükleri Keşfetme:
Grafana'nın "Explore" özelliği, LogQL sorgularınızı canlı olarak test etmek ve günlük akışlarını doğrudan görmek için mükemmeldir. Veri kaynağı olarak Loki'yi seçtikten sonra, sorgu çubuğuna LogQL ifadenizi yazın. Grafana, etiketler için otomatik tamamlama önerileri sunarak işinizi kolaylaştırır. Sorgunuzu çalıştırdığınızda, günlük satırlarını ve onlara ait etiketleri göreceksiniz. Ayrıca, Log volume grafiği ile günlük hacmini zaman içinde görselleştirebilirsiniz.

3. Panolar (Dashboards) Oluşturma:
Anlamlı panolar oluşturarak sistemlerinizin sağlığını ve performansını anlık olarak izleyebilirsiniz. Örneğin:

• Günlük Hacmi Paneli: sum by (job) (count_over_time({job=~".+"}[1m])) sorgusuyla her bir servisin dakikalık günlük hacmini gösteren bir grafik oluşturabilirsiniz.
• Hata Oranı Paneli: sum by (service) (rate({level="error"}[5m])) / sum by (service) (rate({job=~".+"}[5m])) * 100 sorgusuyla servis bazında hata oranlarını yüzde olarak gösteren bir panel oluşturabilirsiniz.
• Belirli Günlükleri Gösteren Panel: Logs panel türünü kullanarak, {service="order-service", level="error"} gibi bir sorguyla sadece belirli günlükleri gösteren bir tablo oluşturabilirsiniz. Bu panel, canlı günlük akışını izlemek için idealdir.

Her bir panelde, LogQL sorgusunun yanı sıra zaman aralığı, görselleştirme türü (grafik, tablo, tek değer) gibi ayarları da yapılandırabilirsiniz. Grafana, metrikleri günlüklerle ilişkilendirme yeteneği sayesinde, bir metrik grafiğindeki anormal bir artış gördüğünüzde, aynı zaman aralığındaki günlükleri hızlıca filtreleyerek sorunun kökenine inmenizi sağlar.

Bu entegrasyon sayesinde, operasyon ekipleri ve geliştiriciler, günlüklerden sadece metin yığınları olarak değil, sistemlerinin davranışını anlamak için değerli bir telemetri kaynağı olarak faydalanabilirler. Loki ve Grafana, gözlemlenebilirlik stratejinizin merkezinde yer alarak, arıza tespiti ve sorun giderme süreçlerinizi radikal bir şekilde hızlandırır.

İleri Düzey Kullanım İpuçları ve En İyi Uygulamalar: Büyük Ölçekli Sistemler İçin Optimizasyon Nasıl Sağlanır?

Grafana Alloy ve Loki, küçük ölçekli projelerden kurumsal seviyedeki karmaşık altyapılara kadar geniş bir yelpazede kullanılabilir. Ancak büyük ölçekli sistemlerde, günlük hacmi ve performansı yönetmek için bazı ileri düzey teknikler ve en iyi uygulamalar devreye girer. Bu bölümde, Alloy ve Loki kurulumunuzu optimize etmek, güvenliğini sağlamak ve daha etkin kullanmak için ipuçları ve püf noktalarını ele alacağız.

1. Performans ve Ölçeklenebilirlik İçin Optimizasyon

• Alloy'da Batchleme ve Sıkıştırma: Alloy, günlükleri Loki'ye gönderirken toplu (batch) halde gönderme ve sıkıştırma (gzip) yeteneklerine sahiptir. Bu, ağ trafiğini ve Loki'nin ingest yükünü azaltır. Varsayılan değerler genellikle iyi olsa da, yoğun günlük hacimlerinde bu ayarları optimize edebilirsiniz:

  
  loki.write "default" {
      endpoint {
          url = "http://loki:3100/loki/api/v1/push"
          batch {
              max_size    = 4 * 1024 * 1024 // 4MB
              max_entries = 10000
              delay       = "5s"
          }
          headers = {
              "X-Scope-OrgID" = "production" // Multi-tenancy için
          }
      }
      compression = "gzip"
  }
      

  
  delay parametresi, Alloy'un günlükleri göndermeden önce ne kadar bekleyeceğini kontrol eder; daha uzun gecikme, daha büyük toplu işlemler anlamına gelir ancak günlüklerin Loki'ye ulaşma süresini artırır.

• Etkin Etiket Kullanımı: Loki'nin maliyet etkinliği ve performansı, doğru etiketleme stratejisine bağlıdır. Yüksek kardinaliteli (çok sayıda benzersiz değere sahip) etiketlerden kaçının. Örneğin, her günlük satırı için benzersiz bir request_id etiketi eklemek, Loki indeksini şişirebilir. Bunun yerine, request_id'yi günlük mesajı içinde bırakın ve gerektiğinde LogQL'in logfmt veya regexp işlemcileriyle ayrıştırın. Genellikle job, service, environment, level, instance, namespace gibi düşük kardinaliteli etiketler tercih edilir.
• Alloy'u Sidecar veya DaemonSet Olarak Dağıtma: Kubernetes gibi konteynerize ortamlarda, Alloy'u her bir pod'un yanında bir sidecar konteyner olarak veya her bir düğümde bir DaemonSet olarak çalıştırmak en iyi uygulamadır. Sidecar modeli, her uygulamanın kendi günlüklerini toplamasını sağlarken, DaemonSet modeli düğüm seviyesindeki günlükleri (örneğin, /var/log/containers) toplamak için idealdir.

2. Güvenlik ve Kimlik Doğrulama

• TLS Kullanımı: Alloy ve Loki arasındaki iletişimi güvence altına almak için TLS (HTTPS) kullanın. Loki'niz bir HTTPS uç noktası sağlıyorsa, Alloy yapılandırmanızda http:// yerine https:// kullanın ve uygun sertifika doğrulaması yapın.

  
  loki.write "default" {
      endpoint {
          url = "https://loki.example.com/loki/api/v1/push"
          tls {
              ca_pem_file = "/etc/ssl/certs/ca-certificates.crt"
              # Sertifika doğrulamasını kapatmak için insecure_skip_verify = true kullanmayın, sadece geliştirme ortamında kullanın.
          }
      }
  }
      

• API Anahtarları veya Temel Kimlik Doğrulama: Loki, API anahtarları veya temel kimlik doğrulama ile güvence altına alınabilir. Alloy, bu kimlik bilgilerini yapılandırma dosyasında tutabilir:

  
  loki.write "default" {
      endpoint {
          url = "https://loki.example.com/loki/api/v1/push"
          basic_auth {
              username = "admin"
              password = env("LOKI_PASSWORD") // Ortam değişkeninden almak daha güvenlidir
          }
      }
  }
      

  
  Hassas bilgileri doğrudan yapılandırma dosyasında tutmak yerine, Kubernetes Secrets veya ortam değişkenleri gibi güvenli yöntemler kullanmak önemlidir.

• Multi-Tenancy (Çok Kiracılılık): Loki, X-Scope-OrgID başlığı aracılığıyla çok kiracılılığı destekler. Bu, farklı ekiplerin veya müşterilerin günlüklerini aynı Loki kümesinde izole etmenizi sağlar. Alloy yapılandırmanızda bu başlığı ayarlayabilirsiniz.

3. Yapılandırma Yönetimi ve Hata Ayıklama

• River'ın Modüler Yapısı: Alloy'un River yapılandırma dili, modüler bir yapı sunar. Büyük ve karmaşık yapılandırmaları daha yönetilebilir hale getirmek için ayrı dosyalarda bileşenler tanımlayıp bunları ana yapılandırma dosyanızda içe aktarabilirsiniz. Örneğin:

  
  // components/order_service.river
  loki.source.file "order_service_logs" { ... }
  loki.process "order_parser" { ... }
  
  // alloy.river
  import "components/order_service.river"
  import "components/user_service.river"
  ...
      

• Alloy'un Dahili Metrikleri: Alloy'un kendisi Prometheus formatında metrikler sunar (varsayılan olarak 12345 portunda). Bu metrikler, Alloy'un sağlık durumunu, günlük toplama hızını, hata oranlarını ve gönderilmemiş günlük sayısını izlemek için kullanılabilir. Bu metrikleri bir Prometheus sunucusuyla toplayıp Grafana'da görselleştirerek Alloy ajanlarınızın performansını denetleyebilirsiniz.
• alloy debug Komutları: Alloy CLI, hata ayıklama için kullanışlı komutlar sunar. Örneğin, alloy debug config-check yapılandırma dosyanızdaki hataları kontrol ederken, alloy debug component komutları çalışan bileşenlerin durumunu incelemenizi sağlar.

4. Mobil Uyumlu HTML için Örnek (Bir Tablo için CSS)

Her ne kadar günlük verisi doğrudan HTML çıktısıyla ilgili olmasa da, teknik makalelerde verilen HTML kod örneklerinin veya tabloların mobil uyumlu olması genel bir best practice'tir. Aşağıda, bir tablonun mobil cihazlarda daha iyi görünmesini sağlayan basit bir CSS medya sorgusu örneği verilmiştir. Bu tür CSS kodları, ana HTML çıktınızda yer almaz ancak etiketine eklenerek sayfa düzenini optimize eder.

Bu CSS ile, örneğin bir