Olay günlüğü metrikleri için veri mimarisi?

Hizmetimin devam eden çok sayıda kullanıcı etkinliği var ve " D tarihinden bu yana T olay türünün oluşumunu say" gibi şeyler yapmak istiyoruz .

İki temel karar vermeye çalışıyoruz:

1. Ne saklanır? Her etkinliğin depolanması ve sadece agregaların depolanması

   • (Olay günlüğü stili) her olayı günlüğe kaydeder ve daha sonra sayar.
   • (Zaman serisi stili) her gün için tek bir toplu " D tarihi için E etkinliği sayısı" nı depolar

2. Veriler nerede saklanır?

   • İlişkisel bir veritabanında (özellikle MySQL)
   • İlişkisel olmayan (NoSQL) bir veritabanında
   • Düz günlük dosyalarında (üzerinden ağ üzerinden merkezi olarak toplanır syslog-ng)

Standart uygulama nedir / farklı sistem türlerini karşılaştırma hakkında daha fazla bilgiyi nerede bulabilirim?

Ek detaylar:

• Toplam etkinlik akışı büyüktür, günde potansiyel olarak yüz binlerce giriş
• Ancak şu andaki ihtiyacımız sadece içindeki belirli olayları saymak
• Ham verilere veya toplama sonuçlarına gerçek zamanlı erişime gerek yoktur.

IMHO, "tüm olayları dosyalara kaydet, akışı filtrelemek ve birleştirmek için daha sonra tara

Her zaman bağlıdır, size yeni bir bakış açısı sunmak için tavsiyemi vereceğim

Ne saklanır? Her etkinliğin depolanması ve sadece agregaların depolanması

(Olay günlüğü stili) her olayı günlüğe kaydeder ve daha sonra sayar.

Herhangi bir ayrıntıyı kaçırmamayı planlıyorsanız, şimdi alakalı olmasalar bile, gözlerimde en iyi yaklaşım budur, çünkü bazen, sonuçlar geldiğinde, X veya Y için alakalı olmadıkları başka olaylar bulursunuz , veya herhangi bir ekstra bilgi getirmediler, ancak bazı analizlerden sonra, basitçe yapar ve bunu da izlemeniz gerekir, o zaman kaydedilen ancak hesaplanmadığı için resme ekleyebilmeniz biraz zaman alacaktır. .

(Zaman serisi stili) her gün için tek bir toplu "D tarihi için E etkinliği sayısı" nı depolar

Yarın uygulamak ve kullanmak istiyorsanız, işe yarayabilir, ancak yeni bir gereksiniminiz varsa veya herhangi bir nedenle atladığınız başka bir etkinlikle bir korelasyon bulursanız, bu yeni etkinliği eklemeniz ve biraz beklemeniz gerekir. güzel toplama seviyelerine sahip olmak için uzun zaman

Veriler nerede saklanır?

İlişkisel bir veritabanında (özellikle MySQL)

Tüm seçenekleri kaydetmek için giderseniz ilk seçenek bir DB için ağır olabilir, bu yüzden korkarım MySQL çok küçük olabilir ve RDBMS çözümleri için gitmek istiyorsanız, PostgreSQL gibi daha büyük veya Oracle veya DB2 gibi tescilli düşünebilirsiniz .

Ancak toplama için iyi bir seçim olacaktır, üretilen yüke bağlı olarak kodda toplayabilir ve bu toplamaları DB'ye ekleyebilirsiniz.

İlişkisel olmayan (NoSQL) bir veritabanında

Bu çözüm için giderseniz , wikipedia'da güzel okumayı takip etmek istediğiniz yaklaşımı size yardımcı olabilir, bu konuda size çok yardımcı olamıyorum çünkü yeterli tecrübem yok, çoğunlukla rdbms kullanıyorum.

Düz günlük dosyalarında (sistem üzerinden ağ üzerinden merkezi olarak toplanır)

Şahsen bu seçenek için gitmenizi önermem, Dosya çok büyürse, ayrıştırmak daha zor olurdu, ama yine de asıl amacı bilmiyorum, bir sistemi takip etmek veya sadece bir günlüğü kontrol etmek dosya ...

Umarım yardımcı olur!

Günlükleri ayrıştırmak, saymak ve sonuçları bir DB'de saklamak için fikrinizin geçerli olduğunu düşünüyorum. Zaten DB tüm bu ham günlükleri istediğiniz emin değilim (Ben senin yurttaşların önerdiğini söylediğini düşünüyorum). Günlüklerde dosyalarınız zaten var, değil mi? Bunları arşivleyebilirsiniz. Bu bitin gerçekten kullanım durumunuza bağlı olduğunu düşünüyorum.

Ayrıca @ Thorbjørn Ravn Andersen ile "yorum cevabını" soruya taşıma konusunda hemfikir.

Kullanım amacınıza bağlıdır. Toplam değerleri gösteren standart bir grafiğiniz veya raporunuz varsa, olayları geldikçe filtrelemek ve bunları ilgili grupta toplamak istersiniz. Belirli olayları ayrıntılı bir şekilde incelemeniz gerekiyorsa veya daha sonra geri dönüp olayları daha sonra yeniden analiz etmek / yeniden kategorize etmek isteyebileceğinizi düşünüyorsanız, tek tek etkinlikleri depolamanız gerekir.

Zaman ve alanınız varsa, tipik olarak yapmaktan hoşlandığım veriler toplamaktır, ancak ayrıntıları (sıkıştırılmış) bir dosyada saklamaktır. Ayrıntılara kolayca erişilebilir olmak zorunda değilim, çünkü neredeyse hiç onlara ihtiyacım yok, ancak sınıflandırma kriterleri değişirse toplu yeniden işleme için kullanılabilirler.

Herhangi bir mimari karar, iş ihtiyaçları tarafından yönlendirilmelidir. Sizin durumunuzda, günlük sisteminizden hangi bilgileri almak istediğiniz hakkında daha net bir fikriniz olmalı ve nasıl saklanacağınıza, bu bilgileri ne sıklıkta isteyeceğinize ve sonucu almak için ne kadar bekleyebileceğinize karar vermelisiniz. . Günlük toplayıcıların, olay korelatörlerinin ve benzer uygulamaların tasarımını yönlendiren budur.

Size fikrimi vermek yerine, geliştirmeye çalıştığınız şeye benzer bazı uygulamalara bakmanızı öneririm. Bazıları, geliştirmeyi düşündüğünüzden çok daha güçlü olabilir, ancak takip edilen mimariye ve depolama politikalarına bakarsanız zarar vermez. Profesyonel tarafta, RSA ve Arcsight gibi SIEM uygulamalarınız var ve Açık Kaynak tarafında Kiwi veya OSSIM (aynı zamanda profesyonel bir cihaz tabanlı versiyona sahip) gibi girişimler var.

Dikkate alınması gereken başka bir şey, araç tarafından elde edilen sonuçları kullanmaya başladığınızda, daha fazla bilgi ve daha ayrıntılı bir bilgi için yönetiminizden çok fazla istek almaya başlayacağınızdır. Bu yüzden ... dikkatlice kullanın ve ufuktaki görüşünüzle planlayın. Size daha fazla iş verebilir, ancak kesinlikle çok fazla destek ve görünürlük elde edebilirsiniz (basınç pakete gelir).