Sejumlah besar sistem pembalakan disajikan di pasar - baik yang terbuka maupun kepemilikan. Masing-masing memiliki fungsi sendiri, kelebihan dan kekurangannya sendiri.
Hari ini kami memutuskan untuk berbagi pengalaman dalam memilih sistem logging dan memberi tahu kami mengapa kami berhenti di ELK di
1cloud .
/ Pixabay / picupyourphoto / PDTeori menit
Saat beralih ke produksi, aplikasi berubah menjadi semacam "kotak hitam". Pekerjaan mereka perlu terus-menerus dipantau untuk mencegah dan menanggapi potensi situasi darurat, untuk menangkap kemacetan.
Sistem penebangan adalah alat yang sangat diperlukan yang tidak dapat dihindari dalam proses ini. Dengan melakukan analisis terperinci terhadap data yang dikumpulkan, dimungkinkan untuk mengidentifikasi "intrusi" dalam jaringan, mengidentifikasi peralatan yang tidak terkonfigurasi dengan benar, dan mengambil tindakan segera. Selain itu, pencatatan merupakan persyaratan wajib ketika melewati berbagai jenis sertifikasi, seperti PCI DSS.
Ada kerangka kerja khusus untuk otomatisasi proses logging: log4j, log4net, Retrace, Logback, Logstash dan lain-lain - ada banyak dari mereka. Alat logging mereka memiliki alat pengembangan yang terpisah, misalnya JDK -
ada java.util.logging . Tentu saja, fungsi berbagai alat logging berbeda, dan serangkaian fungsi yang diperlukan harus dipilih berdasarkan persyaratan bisnis. Namun, ada sejumlah poin umum yang harus diperhatikan ketika memilih sistem untuk menganalisis log.
Kemudahan penggunaan dan ukuran komunitas
Kesederhanaan adalah salah satu komponen kunci ketika memilih sistem logging. Semua pengembang dalam tim bekerja dengan kerangka kerja log, oleh karena itu pengalaman menggunakan alat ini harus positif dan tidak mengubah analisis log menjadi mimpi buruk. Kerangka kerja API harus intuitif sehingga setiap orang yang belum bekerja dengan sistem sebelumnya dapat dengan cepat mengetahui bagaimana ia diatur dan dikonfigurasikan.
Jika kita mempertimbangkan sistem logging sumber terbuka, maka masuk akal untuk mengevaluasi komunitas yang telah terbentuk di sekitarnya. Untuk melakukan ini, Anda dapat mempelajari seberapa sering disebutkan pada platform khusus (
Stack Overflow ), serta di utas khusus,
misalnya, di Reddit . Sebagai pilihan, lihat popularitas proyek di GitHub (jumlah bintang) dan lihat seberapa sering itu dimasukkan ke dalam berbagai koleksi alat di jaringan (
seperti ini ). Jelas, semakin besar komunitas, semakin tinggi kemungkinan Anda akan dibantu jika terjadi kesulitan yang tidak terduga.
Sedangkan untuk pilihan sistem logging berpemilik, di sini pertama-tama layak untuk melihat kecepatan jawaban dan kecukupan layanan dukungan dari solusi yang dipilih, serta harganya.
Kemampuan untuk mengumpulkan log "lain-lain"
Tidak semua platform logging mampu memproses sejumlah besar data dan memberikan informasi lengkap tentang sistem yang digunakan.
Sebelum memilih solusi, ada baiknya memutuskan log mana yang Anda rencanakan untuk kumpulkan: HTTP logs (akan membantu untuk memahami perilaku pengguna di situs), log API (akan memungkinkan untuk mengevaluasi layanan mana yang paling sering diminta oleh API), log kesalahan dan hanya merekam perubahan ke sistem (menunjukkan kemacetan, jika ada).
Skalabilitas
Alat logging harus mengumpulkan log dari setiap komponen sistem dan menyediakan akses ke sana di satu tempat. Jika sistem tidak cocok untuk penskalaan, kualitas analisis log akan turun.
Kami di 1cloud awalnya menggunakan MS SQL untuk login. Namun, dengan peningkatan jumlah klien dan layanan (misalnya, baru-baru ini
kami mengerahkan peralatan di pusat data Minsk dan
menambahkan dukungan untuk IPv6 ), kami mengembangkan komponen infrastruktur yang tersebar secara geografis yang tidak memiliki akses ke database. Dan salah satu tugas utama kami adalah menjaga kemampuan menganalisis log dari satu tempat.
1 sistem logging keras
Seperti yang telah kita catat, MS SQL digunakan untuk menyimpan log dalam 1cloud, dan log4net digunakan untuk merekamnya. Dan ini mulai menciptakan kesulitan-kesulitan tertentu bagi kita. Karena komponen yang tersebar secara geografis, menjadi tidak mungkin untuk mempertahankan konektivitas jaringan dengan database dan menyediakan satu titik untuk analisis.
Pada saat yang sama, sejumlah besar log dan ketidakmampuan untuk membangun indeks pada semua bidang yang perlu kita cari mengarah pada penyederhanaan yang berlebihan dari analisis log - kita harus meninggalkan fungsionalitas demi kinerja.
Untuk mengatasi masalah ini dan memberikan skalabilitas, kami memperkenalkan sistem logging yang baru. Secara total, kami mempelajari lebih dari lima puluh solusi berbeda dan mengidentifikasi empat yang sepenuhnya memenuhi persyaratan kami:
- satu tempat untuk menyimpan log;
- penskalaan horizontal sistem jika perlu;
- memproses sejumlah besar data;
- sistem analisis log yang kuat.
Keempat solusi tersebut adalah: Fluentd, Graylog, Logalyse, dan Logstash.
Solusinya memiliki 9,2 ribu bintang di
GitHub . Logstash dilisensikan di bawah lisensi Apache 2.0 dan merupakan bagian dari tumpukan ELK. Ini memiliki sejumlah besar plugin (
ada sekitar 250 di GitHub). Ia bekerja di bawah Windows dan Linux dan memiliki kinerja tinggi, yang praktis independen dari volume data.
Sistem ini
memungkinkan Anda untuk meninjau dan menganalisis acara
dengan cepat dari workstation, firewall, router dan switch. Hal ini disebabkan oleh kenyataan bahwa tidak ada kebutuhan untuk "normalisasi" peristiwa.
Namun, harus dipahami bahwa ini adalah mesin "telanjang", karena tidak menyediakan visualisasi yang sudah jadi. Di antara kekurangan lainnya, kami mencatat perlunya menginstal Java di semua server, karena Logstash ditulis dalam Ruby (JRuby).
Solusinya memiliki komunitas yang cukup besar: ada
saluran IRC dan
forum terpisah. Ada contoh di jaringan untuk
konfigurasi seluruh sistem dan
API . Organisasi berikut
menggunakan Logstash: Pusat Kontrol CERN, GitHub, SoundCloud.
6,6 ribu bintang di
GitHub . Didistribusikan di bawah lisensi Apache 2.0 oleh
CNCF (Cloud Native Computing Foundation) -
didirikan oleh Google dan The Linux Foundation untuk mempromosikan teknologi wadah.
Fluentd berjalan di Linux, Windows, dan Mac dan ditulis dalam Ruby (CRuby). Fluentd memiliki
sistem plugin yang fleksibel yang memperluas fungsinya.
Solusinya memiliki format logging terpadu: Fluentd mencoba untuk mengkonversi data yang diterima ke format JSON. Untuk memastikan operasi yang andal, solusi pihak ketiga tidak diperlukan, namun untuk ini perlu dilakukan konfigurasi tambahan. Juga tidak disarankan untuk menginstalnya di server yang menghasilkan log.
Komunitasnya besar: ada
saluran di Slack , serta
utas di Grup Google . Di situs web resmi proyek
terdapat contoh konfigurasi dan
API . Perusahaan seperti Microsoft, Amazon, change.org, dan Nintendo menggunakan Fluentd.
4,3 ribu bintang di
GitHub . Didistribusikan di bawah lisensi GNU GPL v3. Ini hanya berfungsi di Linux.
Ekosistem plugin yang tersentralisasi dan sistem penyangga khusus. Untuk kenyamanan, ini memungkinkan kata kunci untuk menggabungkan pesan masuk ke aliran dan kelompok aliran ini dari host yang berbeda.
Sistem ini menggunakan fungsi Elasticsearch, tetapi terlepas dari pembaruan yang sering dari Graylog dan komunitas yang dikembangkan (ada
forum ,
saluran IRC ,
ada contoh konfigurasi dan
API di situs web proyek resmi), integrasi versi Elasticsearch saat ini ke dalam proyek membutuhkan waktu lama. Misalnya, tahun lalu muncul situasi di mana Graylog 2.2.1 (yang terakhir pada waktu itu)
hanya bekerja dengan Elasticsearch versi 2.4.4, yang dianggap usang.
Dalam pekerjaannya, Graylog
menggunakan Badan Lingkungan Eropa, Dial Once, Stockopedia, dan lainnya.
Ini bekerja di Linux dan Windows. Sistem ini memiliki kinerja tinggi dan dapat menghasilkan laporan rinci tentang kata kunci. Ada kelemahan serius - LOGalyze mengumpulkan log ke dalam database file-nya, di mana ia kemudian mengindeksnya, mengambil sejumlah besar ruang disk.
Pengembang LOGalyze
memiliki blog sendiri , dan pembahasan solusinya dilakukan dalam
grup Google . Ada panduan
untuk konfigurasi sistem dan
migrasi data, serta
CLI .
Setelah mengevaluasi keempat opsi ini, kami memilih untuk Logstash dan memutuskan untuk mengatur tumpukan ELK (ElasticSearch, Logstash, Kibana). Dari jumlah tersebut, Elasticsearch adalah mesin pencari, Logstash adalah mekanisme untuk mengumpulkan dan menganalisis log, dan Kibana terlibat dalam analitik dan visualisasi data.
Kami memilih ELK, karena ketiga komponen dikembangkan oleh satu "pabrikan", oleh karena itu mereka terintegrasi dengan baik satu sama lain. Jika perlu, kita dapat menggunakan masing-masing alat ini secara individual untuk menyelesaikan masalah lain.
Pendekatan ini membuat produk fleksibel dan fleksibel. Semua ini akan memungkinkan pemrosesan volume data yang ada lebih efisien dan implementasi layanan baru yang lebih cepat - akan lebih mudah untuk terhubung.
Sekarang lingkungan uji siap. Ini “mencakup” semua layanan yang lognya akan kami analisis. Kami sedang menyelesaikan proses debugging terakhir dan merencanakan peluncuran solusi lengkap dalam waktu dekat.
Ngomong-ngomong, terlepas dari kenyataan bahwa kami menganalisis berbagai opsi secara terperinci dan memilih yang terbaik untuk kebutuhan kami, pada akhirnya itu bukan tanpa lalat dalam salep. Saat menguji solusi, kami dihadapkan pada situasi di mana Kibana menjatuhkan permintaan Elasticsearch - yang dianggap sebagai kasus yang sangat langka dan merosot. Juga selama "perakitan" sistem sejumlah pertanyaan muncul, terutama terkait dengan keamanan. Dalam versi dasar, Elasticsearch tidak dilindungi oleh apa pun - perlu mengadaptasi perangkat lunak pihak ketiga untuk tujuan ini.
Setelah peluncuran, kami akan menyiapkan sistem pemantauan untuk merespons secepatnya terhadap kegagalan dalam layanan log. Kami berharap bahwa tumpukan teknologi baru akan meningkatkan pengalaman pengguna pelanggan kami dan lebih lanjut mengembangkan layanan kami.
Materi dari blog perusahaan kami: