Soru başlığından net olmalıdır. Örneğin Apache, ne kadar büyük veya küçük ölçekli kullanıldığına bakılmaksızın erişim ve hata günlüklerini RDBMS yerine dosyalara kaydeder.
RDMS için sadece SQL sorguları yazmak zorundayız ve dosyalar için belirli bir biçime karar vermeliyiz ve daha sonra regex yazmalıyız veya bunları işlemek için ayrıştırıcılar olabilir. Ve eğer büyük özen gösterilmediyse, bunlar belirli durumlarda bile başarısız olabilir.
Yine de herkes günlükleri korumak için dosya sistemini tercih ediyor gibi görünüyor. Bu yöntemlerin hiçbirine karşı önyargılı değilim ama neden böyle uygulandığını bilmek istiyorum. Hız mı, sürdürülebilirlik mi yoksa başka bir şey mi?
Veritabanında çok fazla şey başarısız olabilir ve bu hataların kaydedilmesi de önemlidir.
Otonom işlemlere izin veren (veya hiç işlem yapmayan) bir veritabanı sisteminiz yoksa, günlük kaydı ayrı bir bağlantı gerektirir, bu nedenle günlük kaydını geri alma veya kaydetme, uygulamada geri almayı veya kesinleştirmeyi engellemez.
Günlüğe kaydetmeye değer birçok şey başlatma sırasında, yani veritabanı bağlantısı kurulmadan önce gerçekleşir.
Tipik bir kurulumda, her gün yeni bir günlük dosyası oluşturulur, eski günlük dosyaları sıkıştırılır ve sonunda silinmeden önce 2 hafta boyunca saklanır. Aynı işlemi bir RDBMS'de yapmak kolay değildir.
Daha önce DB yazılan günlükleri gördüm (ve bazen izleme dosyası, DB hataları, Windows Olay günlüğüne ölümler) nereye, günlük yapılandırma için yapılandırılabilir seçenekler olsun.
Ana nedenler, hız ve boyuttur, bazı izlemenin günlüğe kaydetmenin geniş, büyük miktarlarda üretilmesine olanak tanır - Günlük dosyaları gigabayt boyutunda dolaştım. Diğer ana neden, günlükleri okumanın ardışık olması gerektiğidir, belirli bir hata veya giriş bulmak dışında günlüğü sorgulamak için gerçek bir ihtiyaç yoktur ve dosyada bul, bunun için mükemmel şekilde çalışır.
Hız bir nedendir; diğerleri:
İlki.
Ve eğer büyük özen gösterilmediyse, bunlar belirli durumlarda bile başarısız olabilir.
Dikkatli olmadığınızda veritabanı işlemleri başarısız olamaz mı?
Bir metin dosyasına yazmanın birçok yararı vardır, en önemlisi
Apache'yi özellikle yükseltiyorsunuz, bu yüzden bunu ayrıntılı olarak tartışacağım.
Apache, veritabanına oturum açmak için yapılandırılabilir, ancak bunun için harici bir plugin gerekir. Böyle bir eklenti kullanmak günlük analizini kolaylaştırabilir, ancak yalnızca kendi günlük analiz yazılımınızı yazmak istiyorsanız. Standart kullanıma hazır günlük analizörleri, günlüklerinizin dosyalarda olduğunu varsayar, bu nedenle bunları kullanamazsınız.
Bunu yaparken, güvenilirlik sorunları da yaşadım: veritabanı sunucusunun yazma arabelleği doldurulursa (altında çalıştığı kullanıcı için dosya sistemi kotanızı kullanırsanız mysql ile gerçekleşebilir) sorguları mümkün olana kadar sıraya koymaya başlar devam etmek için, bu noktada Apache bitmesini beklemeye başlar ve web sitenize asılı isteklerle sonuçlanır.
(Bu sorun şimdi giderilebilir, elbette - yıllar önce bunu yaptım)
Bir dosya sistemi bir veritabanıdır. Aslında ilişkisel bir DBMS yerine daha basit, hiyerarşik bir veritabanıdır, ancak yine de bir veritabanıdır.
Bir dosya sisteminde oturum açmanın popüler olmasının nedeni, metin günlüklerinin Unix felsefesine iyi uymasıdır: "Metin, evrensel arabirimdir."
Unix, metin günlükleriyle iyi çalışabilen birçok genel amaçlı araçla geliştirilmişti. Metin günlüklerinin mysql, Apache, özel uygulamanız, uzun süredir desteklenmeyen üçüncü taraf yazılım tarafından üretilip üretilmemesi önemli değildir, sysadmin grep, sed, awk, sıralama, uniq, kes, kuyruk gibi standart Unix araçlarını kullanabilir , vb, günlükleri aynı trol.
Her uygulama kendi veritabanına, biri MySQL'e, diğeri Postgres'e, diğeri Elasticsearch'e, diğeri ELK'a giriş yapmak istiyorsa, diğeri sadece MongoDB'ye giriş yapabilir, o zaman her birinin günlüklerini trol etmek için yirmi farklı araç öğrenmeniz gerekir uygulama. Metin, herkesin giriş yapabileceği evrensel bir araçtır.
Tüm günlüklerin MySQL gibi tek bir veritabanına gitmesini sağlasanız bile, her uygulamanın farklı tablo şemalarıyla oturum açmak isteyebileceğini görebilirsiniz, bu nedenle yine de her biri için günlükleri sorgulamak için özelleştirilmiş bir araç yazmanız gerekir uygulama. Ve bir şekilde her uygulamayı tek bir şemada oturum açmak için tıkıştırdıysanız, genel şemanın size her uygulamanın tam hikayesini gerçekten anlatamadığını muhtemelen göreceksiniz, bu yüzden yine de günlük metinlerini ayrıştırmanız gerekir.
Bir veritabanına giriş yapmak genellikle pratikte işleri önemli ölçüde kolaylaştırmaz.
Bir veritabanında oturum açmak, aklınızda bulunduğunuz belirli bir analize sahip olduğunuzda veya yalnızca belirli amaçlar için verileri toplamak üzere belirli bir veritabanı şeması tasarlayabileceğiniz belirli denetim kurtarma gereksinimi için yararlı olabilir. Ancak adli ve hata ayıklama için ve belirli bir amaç göz önünde bulundurulmadan günlük topladığınızda, metin günlükleri genellikle özel araçları öğrenme veya oluşturma maliyetinin buna değmeyeceği kadar iyidir.
Buna birkaç katmanda bakalım:
Kısaca:
O zaman kullanım-vaka tabanlı yaklaşımımız var:
Düğüme özgü hataları, yalnızca bir düğüm için kaputu açıp orada görebildiğinizde belirli bir düğümün hatasını bulmak için fazladan çalışmanız gereken yatay olarak ölçeklendirilmiş bir RDBMS'ye kaydetmek istiyor musunuz? Öte yandan, uygulamanızın uygulama düzeyinde hataları ve bildirimleri toplamak için bir RDBMS'ye oturum açması gerekir.
Veritabanı yazılamadığından RDBMS'nin günlüğe kaydetmesi gerektiğinde ne olur?