Arsitektur data untuk metrik log peristiwa?


17

Layanan saya memiliki sejumlah besar peristiwa pengguna yang sedang berlangsung, dan kami ingin melakukan hal-hal seperti "menghitung kemunculan tipe peristiwa T sejak tanggal D. "

Kami mencoba membuat dua keputusan dasar:

  1. Apa yang harus disimpan? Menyimpan setiap acara vs. hanya menyimpan agregat

    • (Gaya log peristiwa) mencatat setiap peristiwa dan menghitungnya nanti, vs.
    • (Gaya seri waktu) menyimpan "hitungan acara E agregat tunggal untuk tanggal D " setiap hari
  2. Tempat menyimpan data

    • Dalam basis data relasional (khususnya MySQL)
    • Dalam database non-relasional (NoSQL)
    • Dalam file log datar (dikumpulkan secara terpusat melalui jaringan melalui syslog-ng)

Apa itu praktik standar / di mana saya dapat membaca lebih lanjut tentang membandingkan berbagai jenis sistem?


Detil tambahan:

  • Total arus peristiwa besar, berpotensi ratusan ribu entri per hari
  • Tetapi kebutuhan kita saat ini hanya untuk menghitung jenis peristiwa tertentu di dalamnya
  • Kami tidak perlu membutuhkan akses waktu nyata ke data mentah atau hasil agregasi

IMHO, "catat semua peristiwa ke file, perayapan mereka di lain waktu untuk memfilter dan mengagregasikan aliran" adalah cara UNIX yang cukup standar, tetapi rekan senegaranya Rails-y tampaknya berpikir bahwa tidak ada yang nyata kecuali di MySQL.


1
Keberuntungan di proyek ini?
hiwaylon

2
@hiwaylon Kami akhirnya menggunakan sistem hybrid: 1) MySQL jika memungkinkan (volume rendah) (membuat agregasi mudah digunakan SELECT...GROUP BY, dapat dengan mudah menyimpan hasil SELECTs), 2) menggunakan Graphite untuk agregasi dan visualisasi skala besar yang sederhana, dan 3) mencatat peristiwa lengkap untuk referensi, dan untuk menonton detail aliran data secara real time. Masing-masing sebenarnya berharga dalam cara yang berbeda.
elliot42

Itu terdengar seperti solusi yang hebat, sangat mirip dengan apa yang kami lakukan juga.
hiwaylon

1
MEMPERBARUI lebih dari setahun kemudian kami membangun sistem yang mencatat semuanya, dan secara berkala mengulangi hal-hal yang dicatat dalam log, dan kemudian menyimpan angka-angka yang dihitung ke dalam basis data (bisa / seharusnya menjadi basis data deret waktu, tetapi MySQL mencukupi). Ini adalah beberapa minggu kerja tetapi akhirnya menjadi pendekatan yang sangat kuat / cepat - ketika itu hanya kode Anda berulang di atas JSON yang dicatat, mudah untuk menambahkan banyak metadata, dan mudah bagi kode Anda untuk memiliki aturan fleksibel untuk apa ia ingin menghitung.
elliot42

1
Pembaruan 2016: Kafka dapat melakukan hal-hal seperti ini hari ini, setidaknya untuk penyimpanan mentah. Kemudian Anda bisa memasukkannya ke pekerjaan MapReduce atau Spark yang besar, atau gudang besar seperti Vertica dll. Jika Anda ingin menanyakan / mengagregasi mereka.
elliot42

Jawaban:


4

Itu selalu tergantung, saya akan memberi Anda saran saya untuk menawarkan Anda perspektif baru

Apa yang harus disimpan? Menyimpan setiap acara vs. hanya menyimpan agregat

(Gaya log peristiwa) mencatat setiap peristiwa dan menghitungnya nanti, vs.

Jika Anda berencana untuk tidak melewatkan detail, meskipun sekarang mereka tidak relevan, di mata saya itulah pendekatan terbaik, karena kadang-kadang, ketika hasilnya datang, maka Anda menemukan beberapa peristiwa lain yang untuk X atau Y mereka tidak relevan , atau mereka tidak membawa informasi tambahan apa pun, tetapi setelah beberapa analisis, itu benar-benar berhasil, dan Anda perlu juga melacaknya, kemudian karena itu dicatat tetapi tidak dicatat, Anda perlu waktu sebelum Anda dapat menambahkannya ke gambar .

(Gaya seri waktu) menyimpan "hitungan acara E agregat tunggal untuk tanggal D" setiap hari

Jika Anda ingin menerapkan dan menggunakannya besok, itu bisa berfungsi, tetapi jika Anda memiliki persyaratan baru, atau Anda menemukan korelasi dengan acara lain yang dihilangkan karena alasan apa pun, maka Anda perlu menambahkan acara baru ini dan kemudian menunggu beberapa lama untuk memiliki level agregasi yang bagus

Tempat menyimpan data

Dalam basis data relasional (khususnya MySQL)

Opsi pertama bisa menjadi berat untuk DB jika Anda pergi untuk merekam semua acara, jadi MySQL saya khawatir bisa menjadi terlalu kecil, dan jika Anda ingin mencari solusi RDBMS Anda mungkin berpikir lebih besar, seperti PostgreSQL atau berpemilik seperti Oracle atau DB2 .

Tetapi untuk agregasi akan menjadi pilihan yang baik, tergantung dari beban yang dihasilkan Anda dapat menggabungkan dalam kode dan memasukkan agregasi tersebut ke dalam DB.

Dalam database non-relasional (NoSQL)

Jika Anda mencari solusi ini, Anda perlu melihat pendekatan mana yang Anda ingin baca dengan baik di wikipedia yang dapat membantu Anda, saya tidak dapat banyak membantu Anda tentang topik itu karena saya tidak punya cukup pengalaman, saya kebanyakan menggunakan rdbms.

Dalam file log datar (dikumpulkan secara terpusat melalui jaringan melalui syslog-ng)

Saya pribadi akan mengecilkan hati Anda untuk mencari opsi itu, Jika file tumbuh terlalu banyak, akan lebih sulit untuk diuraikan, tetapi tetap saya tidak tahu tujuan utamanya, untuk menindaklanjuti suatu sistem, atau cukup memeriksa log mengajukan ...

Semoga ini bisa membantu!


1
File log harus diputar pada ukuran atau panjangnya. Saya kira kekhawatiran terakhir tidak akan menjadi masalah.
hiwaylon

1

Saya pikir ide Anda untuk menguraikan log, menghitung dan menyimpan hasil dalam DB adalah valid. Tidak yakin Anda ingin semua log mentah di DB tetap (saya pikir itulah yang Anda katakan rekan Anda menyarankan). Anda sudah mendapatkan log dalam file, benar? Anda bisa mengarsipkannya. Saya kira bit itu sangat tergantung pada use case Anda.

Setuju juga dengan @ Thorbjørn Ravn Andersen tentang memindahkan "jawaban komentar" Anda ke pertanyaan.


1

Tergantung pada penggunaan yang Anda maksudkan. Jika Anda memiliki grafik atau laporan standar yang menunjukkan nilai agregat, maka Anda hanya perlu memfilter peristiwa saat mereka masuk dan menggabungkannya ke dalam ember yang sesuai. Jika Anda perlu menelusuri ke acara tertentu, atau jika Anda pikir Anda mungkin ingin kembali dan menganalisis kembali / mengategorikan kembali acara nanti, maka Anda harus menyimpan masing-masing acara.

Jika Anda punya waktu dan ruang, yang biasanya saya suka lakukan adalah menggabungkan data, tetapi menyimpan detail dalam file (terkompresi). Detailnya tidak harus mudah diakses, karena saya hampir tidak pernah membutuhkannya, tetapi mereka tersedia untuk diproses ulang secara massal jika kriteria klasifikasi berubah.


+ msgstr "agregat data, tetapi simpan detail dalam file (terkompresi)". Pikiran besar khususnya, terima kasih!
elliot42

Apakah ada masalah dengan volume penebangan OP yang disebutkan dan melakukan penyaringan + agregasi saat mereka masuk? Sepertinya ini bisa menjadi hambatan yang berbahaya jika volume log tinggi dan / atau agregasi tidak sepele.
hiwaylon

OP menyebutkan volume "ratusan ribu acara sehari". Satu juta peristiwa sehari kurang dari tujuh ratus menit, atau sekitar sebelas detik. Kecuali jika inputnya adalah XML yang panjang, server rata-rata Anda harus dapat mengatasinya tanpa berkeringat. Ini jelas sesuatu yang harus dipertimbangkan ketika merancang (dan menggunakan) solusinya.
TMN

1

Setiap keputusan arsitektur harus didorong oleh kebutuhan bisnis. Dalam kasus Anda, Anda harus memiliki gagasan yang lebih jelas tentang informasi apa yang ingin Anda peroleh dari sistem log Anda dan untuk memutuskan bagaimana cara menyimpan, seberapa sering Anda akan memerlukan info ini dan berapa lama Anda bisa menunggu untuk mendapatkan hasilnya . Inilah yang mendorong desain pengumpul log, korelasi peristiwa dan aplikasi serupa.

Daripada memberi Anda pendapat saya, saya sarankan Anda melihat beberapa aplikasi yang mirip dengan apa yang Anda coba kembangkan. Beberapa dari mereka mungkin jauh lebih kuat daripada apa yang Anda pura-pura kembangkan tetapi tidak ada salahnya jika Anda melihat arsitektur dan kebijakan penyimpanan yang diikuti. Di sisi profesional, Anda memiliki aplikasi SIEM seperti RSA dan Arcsight dan di sisi Sumber Terbuka Anda memiliki inisiatif seperti Kiwi atau OSSIM (yang juga memiliki versi berbasis alat profesional).

Hal lain yang perlu dipertimbangkan adalah bahwa ketika Anda mulai menggunakan hasil yang diperoleh oleh alat ini, Anda akan mulai menerima kemungkinan besar banyak permintaan dari manajemen Anda untuk informasi lebih lanjut dan lebih rinci. Jadi ... gunakan dengan hati-hati dan rencanakan dengan pandangan Anda di cakrawala. Ini mungkin memberi Anda lebih banyak pekerjaan, tetapi pasti Anda mungkin mendapatkan banyak dukungan dan visibilitas (tekanan datang dalam paket) ....

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.