LogQL ile Loki'de log sorgulamak: akış seçiciden metrik sorgusuna

Loki'nin yaklaşımı: logları etiketle, içeriği sorguda ara

Grafana Loki, log toplama için tasarlanmış bir sistemdir ve klasik log arama motorlarından temel bir noktada ayrılır: log satırının tamamını dizinlemek yerine yalnızca etiketleri dizinler. Log içeriği sıkıştırılmış parçalar hâlinde saklanır ve sorgu sırasında taranır. Bunun pratik sonucu iki yönlüdür: depolama ve işletme maliyeti düşer, ama iyi seçilmiş etiketler olmadan sorgu yavaşlar.

Bu yüzden Loki ile çalışmak iki beceriyi birleştirir. Birincisi, logları toplarken doğru etiketleri tasarlamak. İkincisi, LogQL ile bu etiketlerden başlayıp içeriği daraltarak sorgu yazmak. Kötü etiketlenmiş logu çok iyi yazılmış bir sorgu bile kurtaramaz; iyi etiketlenmiş logda ise çoğu soru birkaç satırlık sorguyla cevaplanır.

Grafana ile birlikte kullanıldığında Loki, metrik panolarındaki bir sıçramanın hemen yanında ilgili log satırlarını gösterir. Metrikten loga geçişteki bu bağlantı, olay anında teşhis süresini kısaltan asıl değerdir.

Log toplama ve etiket tasarımı

Loglar Loki'ye bir toplayıcı ajan aracılığıyla gelir; Promtail bu amaçla yaygın biçimde kullanılan ajanlardandır, güncel önerilen ajan için Loki'nin resmî dokümantasyonuna bakmalısınız. Ajan, dosyaları ya da konteyner çıktılarını okur, her akışa etiketler iliştirir ve Loki'ye gönderir.

Loki dokümantasyonuna göre etiket çiftlerinin benzersiz birleşimine akış (stream) denir. Etiket tasarımı bu yüzden önemlidir: her yeni etiket değeri yeni bir akış üretir. Uygulamada şu ilkeler işe yarar:

• Az sayıda, sınırlı değer alan etiketler seçin: uygulama, ortam, hizmet, ad alanı, sunucu grubu gibi.
• Kullanıcı kimliği, istek kimliği ya da işlem kimliği gibi her satırda değişen değerleri etiket yapmayın. Bunlar log satırının içinde kalmalı ve sorguda süzülmelidir.
• Etiket adlarını tüm hizmetlerde tutarlı kullanın. Bir yerde app, başka yerde uygulama yazarsanız sorgular parçalanır.
• Mümkünse logları JSON ya da logfmt gibi yapılandırılmış biçimde yazın; böylece sorguda alan çıkarmak kolaylaşır.

Örnek senaryo: bir e-ticaret platformunda her hizmetin logları hizmet adı ve ortam etiketleriyle gelir. Ödeme hizmetindeki hataları aramak için etiketler yeterlidir; siparişe özel kimlik ise satır içinde aranır.

LogQL sorgusunun yapısı: akış seçici

Loki dokümantasyonuna göre bir LogQL sorgusu şu biçimdedir: süslü parantez içinde bir akış seçici, ardından isteğe bağlı bir log boru hattı. Akış seçici zorunludur. Etiket çiftlerinden oluşur:

• {service_name="nginx"} etiketi tam eşleşen akışlar.
• = tam eşleşme, != eşit değil, =~ düzenli ifade eşleşmesi, !~ düzenli ifade eşleşmemesi için kullanılır.

Örnek: {app="odeme", env="prod"} ifadesi ödeme hizmetinin üretim ortamı loglarını seçer. Düzenli ifadeyle birden çok hizmet de seçilebilir: {env="prod", app=~"odeme|sepet"}.

Akış seçici sorgunun ilk filtresidir ve Loki'nin hangi veri parçalarını okuyacağını belirler. Seçiciyi ne kadar dar tutarsanız sorgu o kadar hızlıdır. Bu yüzden en sık yapılan hata, seçiciyi geniş bırakıp süzmeyi satır filtrelerine yüklemektir: tüm üretim loglarını tarayıp içinde "hata" arayan sorgu, hem yavaş hem pahalıdır.

Seçici yazarken iyi bir alışkanlık: önce yalnızca seçiciyi çalıştırıp doğru akışların geldiğini görün, sonra boru hattını ekleyin.

Satır filtreleri ve ayrıştırıcılar

Boru hattında ilk araç satır filtreleridir: |= satırda belirli metin geçsin, != geçmesin, |~ düzenli ifade eşleşsin, !~ eşleşmesin. Örnekler:

• {app="nginx"} |= "error" nginx loglarında error geçen satırları getirir.
• {app="nginx"} |~ "timeout|refused" zaman aşımı ya da bağlantı reddi geçen satırları tek filtrede yakalar.

Satır filtreleri hızlıdır ama metin tabanlıdır. Alan bazlı süzmek için ayrıştırıcı (parser) kullanılır; JSON ve logfmt biçimleri için ayrı ayrıştırıcılar vardır. Dokümantasyondaki örnek: {service_name="nginx"} | json | request_method="GET". Burada json ayrıştırıcısı log satırındaki alanları çıkarır, sonraki aşamada bu alanlar etiket gibi süzülür. Logfmt biçimindeki loglar için aynı yaklaşım logfmt ayrıştırıcısıyla yapılır.

Sıralama kuralı: önce en ucuz ve en seçici filtre. Satır filtresiyle satırları azaltın, sonra ayrıştırıcıyı çalıştırın; böylece ayrıştırma yalnızca kalan satırlara uygulanır. Ayrıştırıcıyı en başa koymak tüm satırları işleyeceğinden pahalıdır.

Örnek teşhis akışı: sorun bildirimi geldi. Önce {app="odeme", env="prod"} |= "error" ile hataların sıklığına bakılır. Sonra | json ile hata kodu alanına göre süzülür. Son adımda ilgili isteğin kimliğiyle aranıp tek bir işlemin tüm satırları görülür.

Loglardan metrik üretmek

LogQL yalnızca satır döndürmez; log sonuçlarından sayısal değer hesaplayan metrik sorguları da yazılabilir. Loki dokümantasyonu, metrik sorgularıyla loglardan metrik oluşturulabildiğini söyler. Yaygın iki işlev: rate, belirli bir zaman penceresindeki log satırı hızını verir; count_over_time ise pencere içindeki satır sayısını.

Örnek:

• rate({app="nginx"} |= "error" [$__interval])

Bu sorgu nginx loglarında error geçen satırların zaman içindeki hızını döndürür ve Grafana panelinde çizgi grafiği olarak gösterilebilir. Pencere süresi için Grafana'nın otomatik aralık değişkeni kullanılır. Bu işlevlerin ayrıntıları Loki dokümantasyonunun metrik sorguları sayfasındadır.

Bu yöntemle hata hızı, belirli olayların sıklığı ve yavaş istek yoğunluğu gibi göstergeleri, ayrıca metrik toplamadan loglardan türetebilirsiniz. Aynı sorgu bir uyarı kuralının temeli de olabilir: hata hızı eşiği aşarsa uyarı. Ancak log tabanlı metrik, doğrudan toplanan metrik kadar ucuz değildir; her hesaplama logu taradığından sık ve geniş pencereler yük bindirir.

Sık yapılan hatalar ve performans

Loki ile en çok görülen sorunlar:

• Yüksek kardinaliteli etiket. Her istek ya da kullanıcı için farklı değer alan etiketler akış sayısını patlatır ve sistemi yavaşlatır.
• Geniş seçici. Tüm akışları seçip ardından satır filtresi uygulamak yavaştır. Etiketlerle daraltın.
• Gereksiz uzun zaman aralığı. Sorgu yalnızca gereken pencereyi taramalıdır; olayın olduğu saatleri seçin.
• Ayrıştırıcıyı geniş sorguda erken kullanmak. Önce filtreyle satırı azaltın.
• Yapılandırılmamış log. Serbest metin loglarda alan çıkarmak düzenli ifadelere bağımlı olur ve kırılgandır. Uygulama tarafında yapılandırılmış log yazmak sorguları sadeleştirir.
• Etiket tutarsızlığı. Aynı kavramın farklı adlarla geçmesi sorguları çoğaltır.
• Saklama süresini düşünmemek. Logların ne kadar tutulacağı depolama maliyetini doğrudan etkiler.

Kontrol listesi: sorgu etiketle başlıyor mu, aralık dar mı, en seçici filtre önce mi, gerekmeyen ayrıştırıcı var mı? Bu dört soruyla çoğu yavaş sorgu düzeltilir.

Bu beceriyi Mindset programlarında çalışmak

Mindset kataloğundaki Grafana Loki ile Log Toplama ve Sorgulama eğitimi, log mimarisi ve Loki yaklaşımı, kurulum ve depolama yapılandırması, log toplama ve etiket tasarımı, LogQL ile sorgulama ve uyarı, panel ve korelasyon konularını ayrı modüllerde işler.

SRE, DevOps ve uygulama geliştirme ekipleri için uygundur; kurumsal ekiplerde logların dağınık sunucularda aranmak yerine ortak bir sorgu arayüzünde toplanmasını ve ortak etiket standardı oluşturmayı hedefleyenler için doğrudan uygulanabilir bir çerçevedir.