Günlüğe kaydetme: Neden ve Ne? [kapalı]


39

Günlükleri önemli ölçüde kullanan programlar yazmamıştım. En çok yaptığım istisnalar olduğunda yığın izlerini yakalamak.

Merak ediyordum, başkaları ne kadar giriş yapar? Ne tür bir başvuru yaptığınıza bağlı mı? Günlükleri gerçekten yararlı buluyor musun?

Yanıtlar:


24

İşim için büyük ölçüde gömülü uygulamalar yaptım, paha biçilmez bir araca giriş yaptım. En azından hataların kod satırını gösterecek kadar bilgiyle kaydedilmesi gerekir. Daha sonra, uygulama genelinde önemli fonksiyon noktaları olacaktır. Yönetici gibi şeyler makineye erişti. Daha ayrıntılı günlük kaydı yapmamızı sağlayan bir sistem kullanıyoruz. Bu genellikle geliştiriciye özgüdür. Özelliğin test edilmesi sırasında geliştiriciye yardım etmek için kullanılabilir veya bir müşteri probleminin teşhisine yardımcı olabilir.

Kişisel olarak, geliştirdiğim tüm uygulamalarda günlük kaydını kullandım. Her zaman bir uygulamanın akışının daha iyi anlaşılmasını sağlamıştır. Özellikle bir müşterinin elinde olduğunda. Asla (nadiren) kullanım durumlarını, test ettiğiniz davalarla sınırlandırmazlar.


19

Bunun uygulamanın türüne bağlı olduğunu sanmıyorum: Tüm (önemsiz) uygulamalarda günlük kaydı kullanışlıdır . Tabii ki, bazı uygulamalarda diğerlerinden daha yararlı olabileceğini düşünüyorum, ama bunun hiç işe yaramaz olduğunu sanmıyorum .

Özellikle, bir hata durumunda, bir yığın izlemesi size programın kesin hata noktasında durumunu söyleyecektir , ancak hatadan hemen önce durum hakkında çok az ipucunuz var . Bu bilgi sorunu takip etmede çok yararlı olabilir ve kayıt tutma bu konuda faydalı bir fikir verebilir. Bunun en önemsiz programlardan faydalanabileceği bir şey olduğunu düşünüyorum.

Tüm programlar için yararlı olmayabilecek bir diğer kayıt kullanımı, istatistik analizindedir. Örneğin, web sunucunuz gelen her isteği genellikle kaydeder ve daha sonra bu günlükleri analiz edip en yoğun zamanlarınızda, en popüler sayfalarınızda vb. Grafikler üreten birçok araç vardır. Bu verileri kapasite planlaması yapmak için kullanabilirsiniz ("daha büyük bir sunucuya ihtiyacım var mı?") Vb.


9

Günlüğe kaydetmenin gerçekleştirilmesinin iki nedeni vardır:

  1. Tanı
  2. Denetim

Tanılama günlüğü zaten başkaları tarafından tartışıldı ve bu konuya daha fazla dikkat etmem. Sadece bir günlük hatası olursa ne olacağını düşünmeniz gerektiğini söyleyeceğim. Uygulamada bir istisna oluşturmak veya başka bir yolla yönetmek için yeterince önemsiyor musunuz? Bu bir "bağlıdır" dır, ancak bilgi seviyesi mesajlarının kaydedilmesi muhtemelen atlanmalıdır.

Denetim günlüğü bir iş gereksinimidir. Denetim günlüğü, sistemdeki önemli olayları yakalar ve yönetim ile yasal kartalların ilgilendiği şeydir. Bu, bir şeyi kimin imzaladığını, kimin ne düzenlemeyi yaptığını vb. Şeyleri ifade eder. bunlara sadece hafifçe ilgi duyuyorum. Ancak, çoğu durumda bu tür bir kayıt işlemi kesinlikle işlemin bir parçasıdır ve tamamlanamıyorsa işlemin tamamında başarısız olması gerekir.

İkisini ayrı ayrı düşünmek benim için sadece biri “isteğe bağlı” ve diğeri zorunlu olduğu için değil, aynı zamanda gereksinimlere bağlı olarak, onları ayrı ayrı uygulamam gerekebilir. Her ikisinin de meyve olduğu bir durum olabilir (bazen), ancak bir tanesi elma, diğeri de portakal. Genellikle, tek bir günlük kaydı çerçevesi her ikisiyle de başa çıkabilir.


Günlük tutmak ve kiracılık sözleşmelerinizin kopyalarını almak arasındaki fark gibi görünüyor.
shuhalo

8

Çoğu sunucu görevinde, günlüğe kaydetme çok önemlidir, çünkü yönetici genellikle işler olduğunda orada olmaz, bu yüzden durumu kontrol etmek zorundadır.

Ancak Google’daki bir adam bir keresinde bana sunucu işlemlerinin günlüğe kaydetmediğini söyledi; bunun yerine, 'araç' vardır; Bu, her işlemin, diğer işlemlerin parametre ve istatistik isteyip istemediği kancaları veya bağlantı noktalarının (mekaniği belirlemediği) olduğu anlamına gelir. Bu, kayıtlara çok şey depolayan izleme süreçleridir, avantajı, elde ettikleri bilgilerin "bir dosya açma", "bunu yaz", "alma"; "45.453 dosya açık", "653 hizmet X istemcisi", "sorgu Y için 344 ms ortalama yanıt" gibi şeyler alıyorlar

Kesinlikle farklı bir yaklaşım, ve bazı sistemler daha küçük olsalar bile, sistemlerime bakarken aklımda tutma eğilimindeyim.


4

Her şeyi kaydeden bir winforms N-Tiered uygulamasından geldim.

Çok kullanışlı değildi.

Tabi, günlüğe kaydetme istisnaları harika; peki istisnayı geliştirme ekibine e-postayla gönderebiliyorken neden müşterinin makinesine giriş yapmalısınız?

Bilgiyi kolayca kaydetmek, değeri nadiren haklı çıkaran bir bağımlılığa dönüşür. Dikkatlice giriş yapabileceğiniz her durum için, hedeflenmiş bilgileri toplamak ve gitmesi gereken yere göndermek daha iyidir.


1
Uygulamanız çökerse hala onlara e-posta gönderebilir misiniz?
Pemdas

2
Ya e-posta kapalıysa?

3
Üzerinde çalıştığı makinenin internet bağlantısı yoksa ne olacak?
Pemdas

2
Buna inanmıyorum, bu yüzden sana zor zamanlar veriyorum. Temel olarak, tüm kayıtların sık sık mümkün olmayan geliştirici ekibine e-postayla gönderilmesi gerektiğini söylediniz.
Pemdas

3
@Pemdas Çok basit: Nerede yapabilirsin, sadece willy-nilly her şeyi günlüğe kaydetmesi ve kimseye göndermemesi tercih edilir. Kayıtlar yalnızca birileri düzenli olarak kontrol ederse bir şey ifade eder ve yalnızca yararlı olması için yeterli miktarda kayıt yapıyorlarsa. Sık sık geliştiricilerin her şeyi kaydettiğini görüyorum, hatta bakmıyor bile. Utanç verici, gerçekten.
George Stocker,

4

İstisna bilgisini yakalamak bir zorunluluktur çünkü bir dereceye kadar çok faydalı olabilir. Ancak, özellikle uygulama kullanıcısı / müşterisi doğru bilgiyle bir hata bildiremiyorsa, istisna bilgileri bazen yeterli olmamaktadır.

Günlük kaydı yalnızca hata bilgilerini yakalamakla sınırlı mı?

Benim durumumda (web uygulaması), hangi sayfanın ziyaret edildiğini, ne zaman, ne tıkladıklarında, ip ve tarayıcının vb. Yerlerde her zaman oturum açarım. Hatta her sayfanın ziyareti için toplam yükleme süresini bile günlüğe kaydederim. ve optimizasyona ihtiyaç var. bu yüzden mümkün olduğunca giriş yaptığımı söyleyebilirim.

ilk başta, ne kadar önemli olacağı hakkında hiçbir fikrim yoktu. ama görünüşe göre birçok konuda çok yardımcı oluyor (hata ayıklama dışında):

  • kullanıcının davranışını anlamak
  • yeni özelliğin kabulünün değerlendirilmesi
  • erken evlat edinenler, dolandırıcıların veya potansiyel müşterilerin arasındaki farkı ayırt etmek

Bence, istatistiki bilgileri kazmayı seviyorsak, günlüğe kaydetme daha önemli hale gelebilir.


2

Ürünleri yurtdışında dağıtılan bir şirkette geliştiriciyim. Bir destek ekibi bir sorun tanımı hakkında soru sormaya başladığında, teşhis için tek araçlarım günlük dosyalarım ve müşterinin veritabanının bir kopyası. Veritabanını ve geliştirme ortamımı kullanarak hatalı durumu yeniden oluşturma fırsatım var çünkü gelen verileri modülüme ve ilgili işlemlere kaydederim. Hatayı, topladığım veriler yardımıyla yeniden oluşturabilirsem, hata ayıklama ile düzeltebilirim. Kayıt dosyam olmasaydı, müşterinin ya da destek ekibinin hangi durumda ne olacağına (büyük bir yanıltıcılık olasılığı var) açıklamasına bağlı kalmam gerekirdi.

İkincisi, günlüğe kaydetme, belirli eylemlerin tarihini ve saatini günlüğe kaydettiğim ve ardından hangi eylemin ne kadar zaman harcadığına bir göz atabildiğim için, modülümün yayılma alanındaki darboğazlarını saptama şansı veriyor.

Buna ek olarak, çözümümüzün 6 modülden oluştuğunu ve günlük dosyalarımda veritabanı zaman aşımları ile ilgili hata günlükleri görüyorum. Bu hatalar diğer modüllerin 5'inde de kaydedilmişse, bunun SQL server ile ilgili bir sorun olma olasılığı artar. Bu sadece benim modülüme kaydedilirse, sorgularımın buggy olma olasılığı artar. Bu tür şeylerin faydalı göstergeler olduğunu düşünüyorum.

Günlük dosyalarımda ne tür veriler gördüğüm hakkında, günlük düzeyinin yapılandırmasına bağlıdır. Eğer bu yeni bir ürün ise, mümkün olduğunca çok veri toplamak için log seviyesini "All" olarak ayarladık. Ancak ürünü iyileştirdiğimizde, sadece hatayı günlüğe kaydetmek için günlük seviyesini "Hata" da tutmayı tercih edebiliriz, ancak bilgi düzeyi günlüklerini vb.


2

Günlük kaydı, diğer programlar tarafından alamadığınız bilgiler için kullanışlıdır:

  • Yığın izlerini yakala (bunu elde ettin)
  • Uygulamanız kilitlendiğinde hangi verilerin işlendiğini yakalayın. Unutmayın, hata ayıklayıcılar yalnızca kilitlenme olduğunda mevcutsa yardımcı olur.
  • Profil bilgileri Bir profil oluşturucuyu üretim ortamında çalıştıramazsanız, zaman damgalarını içeren kapsamlı günlük kaydı , zamanın nereye gittiğini bulmanıza yardımcı olabilir. Söyleyememek bile, bunun programınızın dışında olduğunu belirlemenize yardımcı olabilir (örn. Çöp toplama çalışmaları).
  • Program yazarken istatistik beklenmiyor. Diğer nedenlerle ilginç aralıklarla zaman içinde davranış grafikleri vermem istendi. Gerekli veriler, bir miktar grep + awk + perl ninja numarası içeren günlük dosyalarından çıkarılabilir.

Not: En az İKİ günlük dosyası istiyorsunuz.

  • DEBUG seviyesinde bir - ihtiyacınız olan ve muhtemelen ihtiyaç duyacağınız tüm bilgileri (INFO ve üstü dahil) sağlar. Bu çok fazla ise, ek bir İZLEME seviyesine sahip düşünün.
  • Bir INFO düzeyinde - sisteme 10000 metreye genel bakış sağlar. Önemli kilometre taşları buraya geliyor.

BİLGİ biri her zaman açık. DEBUG olanı gerektiğinde açıktır.

Bir gün, TÜM sahip olduğunuz günlük dosyasının bulunduğu bir hatayı ayıklamak zorunda kalacağınızı ve bu işlemi doğru yapmaktan kovulmakla terfi etmek arasındaki fark olabilir.

Ekstra mil için, tüm işlev çağrılarının parametrelerini herhangi bir yığın izlemesine, Java ile

public void sendEmail(String sender, String recipient) {
try { 
...
} catch (Exception e) {
  throw new RuntimeException("sendEmail(sender="+sender+", recipient="+recipient+")");
}

Bu yaklaşım temelde çağrı yığınınızı parametre değerleri ile geliştirir ve durumu sadece yığın izi ile analiz etmenize ve günlük dosyalarını görmenize gerek kalmamasına izin verebilir.


"Bir gün içinde TÜM sahip olduğunuz günlük dosyasının bulunduğu bir durumda hata ayıklamak zorunda kalacağınızı öngören günlük kaydı kodunu yazın ve doğru şekilde yapmak, kovulma ile terfi ettirme arasındaki fark olabilir."
Marcie

1

Ayrıca tüm önemsiz olmayan uygulamaların çok seviyeli günlük kaydı yapmasını tavsiye ederim.

Diğerlerinin belirttiği nedenlerden dolayı, uygulama ile ilgili sorunları çözmek için paha biçilmez bir araçtır.

Bazı durumlarda, günlüğe kaydetme, örneğin finansal uygulamalarda ve etkinlik günlüğü gerektiren diğer alanlarda güvenlik, kullanım ölçümleri ve denetim için önemlidir.


1

Bu kesinlikle sizin kurduğunuz sistem tipine bağlıdır.

Kelime işlemci gibi tek başına bir masaüstü uygulaması yazıyorsanız, muhtemelen herhangi bir günlüğe kaydetmenize gerek yoktur.

Gömülü bir sistem yazıyorsanız, giriş yapmadan yaşayamazsınız. Aksi halde, gömülü cihazınız donduğunda, bunun nedenini bilemezsiniz. Ayrıca, sisteminiz birbiriyle iletişim kuran birden fazla işlem veya birden fazla fiziksel makine içerdiğinde günlük kaydı yapmanız gerekir. Yine, sistem kilitlendiğinde, hangi bölümün ne zaman ve neden öldüğünü bilmeniz gerekir. Verilerin bir işlemden diğerine geçip geçmediğini belirlemek için günlükleri karşılaştırabilmeniz gerekir. Aynı şekilde, sisteminizin çok fazla doğrudan kullanıcı etkileşimi olmadan uzun süre boyunca çalışması gerektiğinde günlüğe kaydetmeniz gerekir.


1

Günlük kaydı her zaman yararlıdır. Ancak uygulama bilincinde olunca, mutlaka günlükleri okuyacak olan siz değilsinizdir. Belki bir tür yönetici, bir son kullanıcı, bir müşteri, bir destek ekibidir ...

Bu yüzden sadece yığınları değil, geliştiriciler tarafından yorumlanabilecek bazı ek bilgileri de kaydetmeyin. Başvurunuz diğer bazı gruplar tarafından yapıldığında, günlüklerinize bazı benzersiz hata kodları yazmanız da yararlı olur. Bu destek, otomasyon, kolaylaştırabilir ...

Yönetici perspektifinden bir başka nokta: Günlük dönüşünü düşünün.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.