Mikro Hizmetlerde Günlükleri İşleme

Loglama, yazılım sistemlerinin en önemli parçalarından biridir. İster yeni bir yazılım parçası üzerinde çalışmaya başlamış olun, ister sisteminiz büyük ölçekli bir üretim ortamında çalışıyor olsun, kendinizi her zaman günlük dosyalarından yardım ararken bulacaksınız.

Bu nedenle, günlükler, bir şeyler ters gittiğinde veya bir şeyler beklendiği gibi çalışmadığında geliştiricilerin aradığı ilk şeydir.

Doğru bilgileri doğru şekilde kaydetmek, bir geliştiricinin hayatını çok daha kolay hale getirir. Günlüğe kaydetmede daha iyi olmak için neyi ve nasıl günlüğe kaydedeceğinizi bilmeniz gerekir.

Bu makalede, günlüklerinizden en iyi şekilde yararlanmanıza yardımcı olabilecek bazı temel günlük tutma kurallarına bir göz atacağız.

Ne Günlüğe Kaydedilir ve Günlük Nasıl Çalışır?

Bir e-ticaret sistemi örneğiyle başlayalım ve Sipariş Yönetimi Hizmetinde (OMS) oturum açmaya bir göz atalım.

Bir müşteri siparişinin, OMS'nin mevcut envanteri doğrulamak için kullandığı bir aşağı akış hizmeti olan Envanter Yönetimi Hizmetinden (IMS) kaynaklanan bir hata nedeniyle başarısız olduğunu varsayalım.

OMS'nin zaten bir siparişi kabul ettiğini varsayalım. Ancak son doğrulama adımı sırasında, ürün artık envanterde bulunmadığından IMS aşağıdaki hatayı verir.

404 Product Not Available

Ne Günlüğe Kaydedilir

Normalde, hatayı şu şekilde günlüğe kaydedersiniz:

log.error(“Exception in fetching product information - {}”, ex.getResponseBodyAsString())

Bu, aşağıdaki formatta bir günlük oluşturur:

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in fetching product information - Product Not Available

Bu günlük ifadesinde pek fazla bilgi yok, değil mi? Bunun gibi bir günlük, hata hakkında herhangi bir bağlamsal bilgiden yoksun olduğu için pek bir amaca hizmet etmez.

Hata ayıklamayla daha alakalı hale getirmek için bu günlüğe daha fazla bilgi ekleyebilir miyiz? Sipariş Kimliği ve Ürün Kimliği eklemeye ne dersiniz?

log.error("Exception in processing Order #{} for Product #{} due to exception - {}", orderId, productId, ex.getResponseBodyAsString())

Bu, aşağıdaki formatta bir günlük oluşturur:

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #182726 for Product #21 due to exception - Product Not Available

Şimdi bu çok mantıklı! Günlüklere baktığımızda, 182726 numaralı Siparişi işlerken bir hata oluştuğunu anlayabiliriz çünkü Ürün # 21 mevcut değildi.

Nasıl Oturum Açılır

Yukarıdaki kayıt biz insanlar için çok mantıklı olsa da, makineler için en iyi format olmayabilir. Nedenini anlamak için bir örneğe bakalım.

Belirli bir ürünün mevcudiyetinde (örneğin Ürün # 21) o ürünü içeren tüm siparişlerin başarısız olmasından dolayı bazı sorunlar olduğunu varsayalım. Bu ürün için başarısız olan tüm siparişleri bulma görevi size atandı.

grepGünlüklerinizde Ürün # 21 için mutlu bir şekilde bir yapıyorsunuz ve heyecanla sonuçları bekliyorsunuz. Arama tamamlandığında böyle bir şey elde edersiniz

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #182726 for Product #21 due to exception - Product Not Available [2020-09-27T18:53:29,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #972526 for Product #217 due to exception - Product Not Available [2020-09-27T18:52:34,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #46675754 for Product #21 due to exception - Product Not Available [2020-09-27T18:52:13,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing Order #332254 for Product #2109 due to exception - Product Not Available

Beklediğiniz gibi değil mi? Peki bunu nasıl geliştirebilirsiniz? Kurtarma için yapılandırılmış kayıt.

Yapılandırılmış Günlük Kaydı nedir?

Yapılandırılmış günlük kaydı, bu yaygın sorunları çözer ve günlük analiz araçlarının ek özellikler sağlamasına izin verir. Yapılandırılmış bir biçimde yazılan günlükler daha makine dostudur, yani bir makine tarafından kolayca ayrıştırılabilirler.

Bu, aşağıdaki senaryolarda yardımcı olabilir:

  • Geliştiriciler, hem geliştirme sırasında hem de üretim sorunlarını gidermek için çok değerli olan günlükleri arayabilir ve olayları ilişkilendirebilir.
  • İş ekipleri bu günlükleri ayrıştırabilir ve bu alanları ayıklayıp özetleyerek belirli alanlar üzerinde analizler (örneğin, günlük benzersiz ürün sayısı) gerçekleştirebilir.
  • Günlükleri ayrıştırarak ve ilgili alanlar üzerinde toplamalar gerçekleştirerek gösterge tabloları (hem ticari hem de teknik) oluşturabilirsiniz.

Önceki log ifademizi kullanalım ve onu yapılandırmak için küçük bir değişiklik yapalım.

log.error("Exception in processing OrderId={} for ProductId={} due to Error={}", orderId, productId, ex.getResponseBodyAsString())

Bu, aşağıdaki formatta bir günlük oluşturur:

[2020-09-27T18:54:41,500+0530]-[ERROR]-[InventoryValidator]-[13] Exception in processing OrderId=182726 for ProductId=21 due to Error=Product Not Available

Artık bu günlük mesajı OrderId, ProductIdve Erroralanlarını çıkarmak için sınırlayıcı olarak "=" kullanılarak makine tarafından kolayca ayrıştırılabilir . Artık ProductId=21görevimizi gerçekleştirmek için tam bir arama yapabiliriz .

Bu aynı zamanda, bu tür hatalarla başarısız olan tüm siparişlerin bir raporunu hazırlamak gibi, günlükler üzerinde daha gelişmiş analizler gerçekleştirmemize olanak tanır.

Splunk gibi bir günlük yönetim sistemi kullanıyorsanız, sorgu Error=”Product Not Available” | stats count by ProductIdartık aşağıdaki sonucu üretebilir:

+-----------+-------+ | ProductId | count | +-----------+-------+ | 21 | 5 | | 27 | 12 | +-----------+-------+

Günlüklerimizi JSON biçiminde yazdırmak için bir JSON düzeni de kullanabiliriz:

{ "timestamp":"2020-09-27T18:54:41,500+0530" "level":"ERROR" "class":"InventoryValidator" "line":"13" "OrderId":"182726" "ProductId":"21" "Error":"Product Not Available" }

Yapılandırılmış günlük kaydının arkasındaki yaklaşımı anlamak önemlidir. Sabit bir standart yoktur ve birçok farklı şekilde yapılabilir.

Sonuç

Bu makalede, yapılandırılmamış günlük kaydının tuzaklarını ve yapılandırılmış günlüklemenin sunduğu avantaj ve avantajları gördük.

Splunk gibi günlük yönetim sistemleri, iyi yapılandırılmış bir günlük mesajından büyük ölçüde yararlanır ve günlük olaylarında kolay arama ve analiz sunabilir.

The biggest challenge however, when it comes to structured logging, is establishing a standard set of fields for your software. This can be achieved by following a custom logging model or centralised logging which ensures that all developers use the same fields in their log messages.

Thank you for staying with me so far. Hope you liked the article. You can connect with me on LinkedIn where I regularly discuss technology and life. Also take a look at some of my other articles. Happy reading. ?