SLF4J / Logback'te İşaretleyicileri kullanmak için en iyi uygulamalar

Bir süredir projemizde SLF4J + Logback kombinasyonunu kullanıyoruz ve bundan oldukça memnunuz, ancak günlükleme stratejimiz oldukça basit, basit sınıf tabanlı kaydediciler kullanıyor ve MDC veya Marker gibi süslü şeyler kullanmıyoruz.

Bilmek istediğim şey, topluluktaki herhangi birinin bu özellikleri gerçekten kullanıp kullanmadığı ve bunların günlük kaydı / filtrelemeyi iyileştirmek için nasıl kullanıldığı.

Günlük kaydı için ^[1] Markerlerin nerede, neden ve nasıl kullanılacağıyla özellikle ilgileniyorum . Günlüğe anlamsal bağlam eklemek için oldukça düzgün bir özellik olarak dikkatimi çekiyorlar - örneğin, bir sınıf birden fazla endişeyi ele alırken, günlük ifadelerini ayırt etmek için göreve / endişeye özgü işaretler kullanılabilir.

Günlüğe kaydetmede işaretçiler oluşturmak ve kullanmak için en iyi uygulamalar, kurallar veya stratejiler neler olabilir.

Güncelleme: Sanırım, asıl peşinde olduğum şey işaretçileri neden kullanmam gerektiğinden ziyade bunun ne kadar kısmıdır - işaretçileri adlandırmanın bazı iyi uygulamaları var mı (örneğin, boşluklarla veya kısa çizgi / alt çizgi / noktalama işaretiyle ayrılmış anahtar kelime stili adlarıyla düz metin kullanma) ), bir tür "standart isimler" havuzu olmalı, iş işlevlerine göre öğeleri adlandırmalı. Muhtemelen kendim için çözebileceğim sorular, ancak bu özellikleri sistematik bir şekilde kullanmak ve onları bir geliştirici ekibine tanıtmak istersem, etrafında resmileştirilebilir bir dizi yönergeye sahip olmak mantıklı ...

^[1] - İşaretçileri nasıl kullanacağımı sorarak, API'yi nasıl kullanacağımı gerçekten sormuyorum (gerçekten oldukça basittir) - İşaretçileri tutarlı bir şekilde kullanarak nasıl bir günlük oluşturmanın daha genel düzeyine atıfta bulunuyorum

İlk olarak @ darioo'nun dediği gibi:

• MDC, birden çok olayı birkaç "varlık" ile ilişkilendirmek için kullanılır
• [İşaretçiler], normal olanlardan filtrelemek istediğiniz "özel" olaylar için kullanılır

Öyleyse, bunun için MDC kullanmak istediğiniz iddianız. İşaretçiler, "dilimleme" yerine "özel" olayları vurgulamak içindir - isterseniz filtreleme. Örneğin, belirli bir kullanıcıya göre dilimleme yapabilir, ancak beklenmedik istisnalara göre filtre uygulayabilirsiniz. Bu durumda, bir Kullanıcı MDC boyutu ve Beklenmedik Özel Durum İşaretleyicisi oluşturursunuz.

Ancak bu görünüşe göre aklınızdaki soruyu ele almıyor. Siz "daha çok, tutarlı bir şekilde işaretçileri kullanarak oturum açmanın nasıl kurulacağına dair daha genel bir düzeye atıfta bulunuyorsunuz." Öyleyse şunu ele alalım:

MDC dilimleme ve dilimleme içindir ve İşaretleyiciler filtreleme içindir . Bu faaliyetler test sırasında ve üretimde gerçekleştirilir . Bu nedenle, günlük verilerini dilimlemek için hangi boyutların yararlı olacağını beklediğinize ve test / üretim ortaya çıktığında hangi durumlarda filtrelemenin yararlı olabileceğine karar vermeniz gerekir. Her boyut bir MDC boyutu alır. Her vaka bir Marker alır. Bu kadar basit.

Geliştiricilerin burada herhangi bir karar vermesine gerek yok. Tek bir kişi veya ekip , tasarım zamanında , ne tür dilimleme, dilimleme ve filtrelemenin desteklenmesi gerektiğine karar vermelidir . Bu, kendilerinden ne tür analiz görevlerinin gerçekleştirilmesinin istenebileceğini beklediğini hayal ederek bilgilendirilmelidir.

Adlandırma kuralına aynı kişi veya ekip karar vermelidir. Tamamen keyfi . Estetik açıdan hoşa giden, kendi kendini tanımlayan (en önemlisi) ve sonraki eklemelerle çelişmesi olası olmayacak kadar spesifik bir şey seçin . Kısa çizgiler ve alt çizgiler son derece titiz ve endişe verici bir şekilde konunun yanında, ancak ESL çalışanlarının alt çizgileri okumasının daha az kafa karıştırıcı olabileceğini unutmayın (en azından CamelCase ile karşılaştırıldığında); Aynı zamanda, gerekli anahtarlara ulaşmanın garipliği nedeniyle bazı geliştiricileri rahatsız ettiği bildiriliyor.

Bir politikaya karar verirken, bu sadece belirli bir Marker veya MDC boyutunun hangi durumlarda kullanılması gerektiğini tanımlamak anlamına gelir . Bunu sıkı tutun (merkezileştirilmiş, kasıtlı), ancak geliştiricilerin eldeki görev için boyut kümesinin ve işaretleyicilerin yetersiz olduğunu düşünmeleri durumunda geri bildirim almalarına izin verin. Boyutları ve / veya özellikleri uygun şekilde revize edin / ekleyin.

Bu politikanın neredeyse zorunlu olarak projeye özgü olacağını anlayın . Her projenin aynı tür bir günlük kaydı analizine ihtiyacı yoktur. Bazı kabus senaryolarını hayal edin. Sonra bu senaryodaki günlükleri nasıl analiz edebilmek istediğinizi hayal edin. Muhtemelen hangi mesajın hangi bağlama ait olduğunu ve hangi durumun hangi zamanda hangi durumda olduğunu denemek ve izlemek için karmaşık bir komut dosyası yazmak zorunda kalmayacaksınız, değil mi? Bu tür bilgileri gerekli olan her şeyi boyutlar ve İşaretçiler olarak kodlayın ve bir şeyler ters giderse zorluklardan kurtulun.

İlk olarak, MDC.

MDC, bazı davranışlarla ilişkili bir "varlık" a sahip olduğunuz bir ortamda gerçekten yararlıdır. Tipik bir örnek: bir web uygulamasıyla etkileşimde bulunan kullanıcı. Diyelim ki web uygulamanızla uğraşan birçok kullanıcınız var. MDC'yi kullanarak, çok fazla güçlük çekmeden bunları kolayca takip edebilirsiniz. Basitleştirilmiş örnek:

...[Sandy][abcd] clicked on "change profile"
...[Joe][1234] clicked on "weather reports"
...[Joe][1234] clicked on "Europe"
...[Sandy][abcd] clicked on "logout"
...[Joe][1234] clicked on "logout"
...[Sandy][efgh] logged in

Burada MDC'yi iki yerde kullanıyorsunuz: kullanıcı adı ve oturum kimliği için. Bu şekilde, yaptıkları her şeyi görmek için bir kullanıcının oturumunu kolayca grep edebilirsiniz.

İkincisi, işaretçiler.

İşaretçiler genellikle bazı ciddi kritik hatalar için bir yöneticiye e-posta göndermek gibi "özel" durumlar için kullanılır. Tüm hatalar her zaman aynı kategoriye girmez; bazılarının uygun bir şekilde ele alınması gerekir.

Veya, bir kullanıcı hizmetinizden çıktığında, genellikle bir BİLGİ günlüğüne gider, ancak bu gibi olayların ayrı bir günlük dosyasına gitmesini istiyorsanız, bu tür durumlar için bir işaretçi de kullanabilirsiniz, böylece onu izleyebilirsiniz. bırakan kullanıcıların istatistiksel olarak toplanması için daha kolay.

Temel kural:

• MDC, birden çok olayı birkaç "varlık" ile ilişkilendirmek için kullanılır
• işaretçiler, normal olanlardan filtrelemek istediğiniz "özel" olaylar için kullanılır

İşaretleyiciler, tek bir günlük ifadesini renklendirmek veya işaretlemek için kullanılabilir . Bu renklerle, yani markörlerle ne yapacağınız tamamen size kalmış. Bununla birlikte, marker kullanımı için iki model yaygın (ilki ikinciden daha yaygın) görünmektedir.

1. Tetikleme : Bazı ekleyicilere, belirli bir işaretleyicinin varlığında bir işlem yapması talimatı verilebilir. Örneğin, SMTPAppenderbir günlüğe kaydetme olayı, NOTIFY_ADMINgünlük düzeyinden bağımsız olarak işaretleyiciyle işaretlendiğinde bir e-posta gönderecek şekilde yapılandırılabilir . Logback belgelerinde işaretçi tabanlı tetiklemeye bakın . Tetikleme için günlük seviyelerini ve işaretçileri de birleştirebilirsiniz.

2. Filtreleme : Örneğin kalıcılıkla ilgili tüm günlüklerinizi (çeşitli ve çoklu sınıf dosyalarında) "DB" rengiyle renklendirebilir / işaretleyebilirsiniz. Daha sonra "DB" için filtre uygulayabilirsiniz: DB ile işaretlenmiş günlük ifadeleri dışında günlüğe kaydetmeyi devre dışı bırakabilirsiniz. Daha fazla bilgi için yeniden oturum açma belgelerindeki filtreler bölümüne bakın (MarkerFilter'ı arayın).

Bir ek olarak, logstash kullanıyorsanız ve json günlüğünü etkinleştirdiyseniz, belirli bir günlük mesajıyla ilişkilendirilecek değişkenleri günlüğe kaydetmek için Marker'ın başka bir olası kullanımı vardır. Bu, mesaj gövdesine eklemekten daha tutarlı ve ayrıştırılması daha kolaydır. Kullanım durumunuza uygunsa çok kullanışlıdır.

Ayrıntıları burada görün:

https://github.com/logstash/logstash-logback-encoder#loggingevent_custom_event