Cara kami untuk penyimpanan log terpusat

Salam untuk semuanya! Saya bekerja sebagai insinyur sistem di Onlanta . Di salah satu proyek kami, saya terlibat dalam implementasi dan pemeliharaan Elastic Stack. Kami beralih dari mengumpulkan kayu secara virtual ke proses terpusat dan otomatis. Selama dua tahun sekarang, kami praktis tidak mengubah arsitektur solusi dan berencana untuk menggunakan alat yang mudah digunakan dalam proyek lain. Saya berbagi dengan Anda sejarah penerapannya, serta beberapa kekuatan dan kelemahan dalam pos ini.

Sumber

Pada awal 2016, log dari administrator dan pengembang kami, sehingga untuk berbicara, "di ujung jari Anda", yaitu, seorang insinyur untuk bekerja dengan mereka terhubung melalui SSH ke host di mana layanan yang ia minati, menemukan set universal dari tail / grep / sed Saya awk dan berharap akan ada kemungkinan untuk menemukan data yang diperlukan pada host ini.

Sumber

Kami juga memiliki server terpisah, di mana semua direktori dengan log dari semua server dipasang melalui NFS, dan yang kadang-kadang dipikirkan lama tentang apa yang semua orang ingin lakukan dengan log di dalamnya. Nah, tmux dengan beberapa panel menjalankan ekor pada beberapa log yang diperbarui secara aktif tampak sangat mengesankan bagi orang luar pada monitor besar dan menciptakan suasana keterlibatan yang menarik dalam sakramen produksi.

Semua ini bahkan berhasil, tetapi tepat sampai diperlukan untuk dengan cepat memproses sejumlah besar data, dan ini paling sering diperlukan pada saat-saat ketika sesuatu telah jatuh di prod.

Terkadang butuh waktu yang tidak senonoh untuk menyelidiki insiden. Sebagian besar dari itu dihabiskan untuk agregasi log secara manual, meluncurkan kruk berbagai skrip dalam Bash dan Python, menunggu log diunggah di suatu tempat untuk analisis, dll.

Singkatnya, semua ini sangat lambat, diilhami oleh kesedihan dan dengan tegas mengisyaratkan bahwa sudah waktunya untuk mengurus penyimpanan kayu secara terpusat.

Sejujurnya, tidak ada proses yang rumit dalam memilih kandidat untuk peran tumpukan teknologi yang akan memberi kita hal ini: maka bundel ELK sudah populer pada waktu itu, memiliki dokumentasi yang baik, ada sejumlah besar artikel di Internet untuk semua komponen. Keputusan itu langsung: Anda perlu mencoba.

Sumber

Instalasi stack pertama kali dilakukan setelah menonton webinar "Logstash: 0-60 in 60" pada tiga mesin virtual, masing-masing meluncurkan instance Elasticsearch, Logstash dan Kibana.

Selanjutnya, kami mengalami beberapa masalah dengan pengiriman log dari host akhir ke server Logstash. Faktanya adalah bahwa pada saat itu Filebeat (solusi tumpukan standar untuk mengirimkan log dari file teks) bekerja jauh lebih buruk dengan file besar dan cepat diperbarui, secara teratur bocor dalam RAM dan dalam kasus kami secara keseluruhan tidak dapat mengatasi tugasnya.

Untuk ini ditambahkan kebutuhan untuk menemukan cara untuk mengirimkan log server aplikasi dari mesin yang menjalankan IBM AIX: sebagian besar aplikasi kami kemudian diluncurkan di WebSphere Application Server, yang bekerja secara khusus di bawah OS ini. Filebeat ditulis dalam Go, tidak ada kompiler Go yang lebih atau kurang efisien untuk AIX pada tahun 2016, dan saya benar-benar tidak ingin menggunakan Logstash sebagai agen untuk pengiriman.

Kami menguji beberapa agen pengiriman log: Filebeat, logstash-forwarder-java, log-kurir , python-beaver dan NXLog. Dari agen, kami mengharapkan kinerja tinggi, konsumsi sumber daya sistem yang rendah, integrasi yang mudah dengan Logstash, dan kemampuan untuk melakukan manipulasi data dasar dengan kekuatan agen (misalnya, perakitan acara multi-line).

Tentang perakitan acara multiline, perlu disebutkan secara terpisah. Secara efektif, itu hanya dapat dieksekusi di sisi agen yang membaca file tertentu. Terlepas dari kenyataan bahwa Logstash pernah memiliki filter multiline dan sekarang memiliki multiline codec, semua upaya kami untuk menggabungkan penyeimbangan acara di beberapa server Logstash dengan pemrosesan multiline gagal. Konfigurasi ini membuat penyeimbangan acara yang efisien hampir tidak mungkin, oleh karena itu, bagi kami, faktor terpenting ketika memilih agen adalah dukungan multiline.

Pemenangnya adalah sebagai berikut: kurir log untuk mesin dengan Linux, NXLog untuk mesin dengan AIX. Dengan konfigurasi ini, kami hidup selama hampir setahun tanpa masalah: log dikirimkan, agen tidak jatuh (well, hampir), semua orang senang.

Pada Oktober 2016, versi kelima komponen Elastic Stack dirilis, termasuk Beats 5.0. Banyak pekerjaan yang dilakukan pada semua agen Beats dalam versi ini, dan kami dapat mengganti kurir-log (yang pada saat itu memiliki masalah sendiri) dengan Filebeat, yang masih kami gunakan.

Ketika bermigrasi ke versi 5.0, kami mulai mengumpulkan tidak hanya log, tetapi juga beberapa metrik: Packetbeat mulai digunakan di sana-sini sebagai alternatif untuk menulis log permintaan HTTP ke file, dan Metricbeat mengumpulkan metrik sistem dan metrik beberapa layanan.

Pada titik ini, pekerjaan teknisi kami dengan log menjadi lebih sederhana: sekarang tidak perlu tahu server mana yang harus dikunjungi untuk melihat log yang Anda minati, pertukaran informasi yang ditemukan disederhanakan dengan hanya mentransfer tautan ke Kibana di ruang obrolan atau surat, dan laporan yang sebelumnya dibuat dalam beberapa jam, mulai dibuat dalam beberapa detik. Ini tidak dapat dikatakan bahwa itu hanya masalah kenyamanan: kami melihat perubahan dalam kualitas pekerjaan kami, dalam jumlah dan kualitas tugas tertutup, dalam kecepatan respon terhadap masalah di stan kami.

Pada titik tertentu, kami mulai menggunakan utilitas ElastAlert Yelp untuk mengirim peringatan kepada para insinyur. Dan kemudian kami berpikir: mengapa tidak mengintegrasikannya dengan Zabbix kami sehingga semua peringatan memiliki format standar dan dikirim secara terpusat? Solusinya ditemukan cukup cepat: ElastAlert memungkinkan Anda untuk menjalankan perintah daripada mengirim peringatan, yang kami gunakan.

Sekarang aturan ElastAlert kami, ketika dipicu, mengeksekusi skrip bash pada beberapa baris, di mana data yang diperlukan diteruskan dalam argumen dari peristiwa yang memicu aturan, dan zabbix_sender dipanggil dari skrip, yang mengirimkan data ke Zabbix untuk simpul yang diinginkan.

Karena semua informasi tentang siapa yang membuat acara dan di mana selalu tersedia di Elasticsearch, tidak ada kesulitan dengan integrasi. Sebagai contoh, kami sebelumnya memiliki mekanisme untuk secara otomatis mendeteksi server aplikasi WAS, dan dalam kejadian yang mereka hasilkan, nama server, cluster, sel, dll selalu ditulis. Ini memungkinkan kami untuk menggunakan opsi query_key dalam aturan ElastAlert sehingga kondisi aturan diproses untuk setiap server secara terpisah. Script dengan zabbix_sender kemudian mendapatkan "koordinat" server dan data dikirim ke Zabbix untuk node yang sesuai.

Solusi lain yang benar-benar kita sukai dan yang dimungkinkan berkat kumpulan log yang terpusat adalah sebuah skrip untuk secara otomatis membuat tugas di JIRA: sekali sehari ia mengambil semua kesalahan dari log dan, jika belum ada tugas, mulai saja. Pada saat yang sama, dari berbagai indeks dengan ID permintaan unik, semua informasi yang dapat berguna dalam penyelidikan ditarik ke dalam tugas. Hasilnya adalah semacam benda kerja standar dengan informasi minimum yang diperlukan, yang kemudian dapat ditambahkan insinyur jika perlu.

Tentu saja, kami dihadapkan dengan masalah pemantauan tumpukan itu sendiri. Ini sebagian diimplementasikan menggunakan Zabbix, sebagian menggunakan ElastAlert yang sama, dan kami mendapatkan metrik kinerja utama untuk Elasticsearch, Logstash dan Kibana menggunakan pemantauan standar yang dibangun ke dalam tumpukan (komponen Pemantauan dalam X-Pack). Juga, pada server dengan layanan stack sendiri, kami telah menginstal netdata dari Firehol. Ini berguna ketika Anda perlu melihat apa yang terjadi pada simpul tertentu saat ini, secara real time dan dengan resolusi tinggi.

Sekali waktu, modul pemantauan Elasticsearch sedikit rusak di dalamnya, kami menemukannya, memperbaikinya, menambahkan semua jenis metrik yang berguna dan membuat permintaan tarik. Jadi sekarang netdata dapat memonitor versi terbaru dari Elasticsearch, termasuk metrik dasar JVM, pengindeksan, indikator kinerja pencarian, statistik log transaksi, segmen indeks, dan sebagainya. Kami menyukai Netdata, dan kami senang bahwa kami dapat memberikan sedikit kontribusi untuk itu.

Hari ini, setelah hampir tiga tahun, Elastic Stack kami terlihat seperti ini:


Insinyur bekerja dengan tumpukan dalam tiga cara utama:

• melihat dan menganalisis log dan metrik di Kibana;
• dasbor di Grafana dan Kibana;
• mengarahkan kueri ke Elasticsearch menggunakan SQL atau DSL kueri bawaan.

Secara total, semua sumber daya ini dialokasikan: 146 CPU, 484GB RAM, 17TB dialokasikan untuk gudang data Elasticsearch.

Secara total, kami memiliki 13 mesin virtual yang berfungsi sebagai bagian dari Elastic Stack: 4 mesin untuk node "hot" Elasticsearch, 4 untuk node "warm", 4 mesin dengan Logstash dan satu mesin balancing. Pada setiap hot node, Elasticsearch menjalankan instance Kibana. Itu terjadi sejak awal, dan sejauh ini kami tidak harus memindahkan Kibana ke mobil yang terpisah.

Tetapi keputusan untuk membawa Logstash ke mesin terpisah ternyata menjadi salah satu yang paling benar dan efektif selama operasi stack: persaingan tinggi untuk waktu prosesor antara JVM Elasticsearch dan Logstash menyebabkan efek khusus yang tidak terlalu menyenangkan selama semburan beban. Pengumpul sampah paling menderita.

Sumber

Kami menyimpan data selama 30 hari terakhir di cluster: sekarang sekitar 12 miliar peristiwa. Setiap hari, hot node menulis ke data baru disk 400-500 GB dengan rasio kompresi maksimum (termasuk data shard-replica). Cluster Elasticsearch kami memiliki arsitektur panas / hangat, tetapi kami baru-baru ini beralih ke arsitektur itu, sehingga lebih sedikit data yang disimpan di node "hangat" daripada di "panas".

Beban kerja khas kami:

• indeksasi - rata-rata 13.000 rps dengan puncak hingga 30.000 (tidak termasuk indeks ke dalam pecahan replika);
• Cari - 5200 rps.

Kami mencoba mempertahankan margin CPU 40-50% pada hot node Elasticsearch sehingga kami dapat dengan mudah mengalami lonjakan mendadak dalam jumlah acara yang diindeks dan permintaan berat dari Kibana / Grafana atau sistem pemantauan eksternal. Sekitar 50% RAM pada host dengan simpul Elasticsearch selalu tersedia untuk cache halaman dan kebutuhan non-tumpukan JVM.

Selama waktu berlalu sejak peluncuran cluster pertama, kami berhasil mengidentifikasi sendiri beberapa sisi positif dan negatif dari Elastic Stack sebagai sarana pengumpulan log dan platform pencarian dan analisis.

Apa yang kami sukai tentang tumpukan:

• Satu ekosistem produk terintegrasi dengan baik satu sama lain, yang memiliki hampir semua yang Anda butuhkan. Detaknya dulu tidak terlalu bagus, tapi sekarang kami tidak punya keluhan tentang mereka.
• Logstash, dengan segala keburukannya, adalah preprosesor yang sangat fleksibel dan kuat dan memungkinkan Anda melakukan banyak hal dengan data mentah (dan jika sesuatu tidak memungkinkannya, Anda selalu dapat menulis cuplikan di Ruby).
• Elasticsearch dengan plugins (dan baru-baru ini di luar kotak) mendukung SQL sebagai bahasa query, yang menyederhanakan integrasinya dengan perangkat lunak lain dan orang-orang yang lebih dekat dengan SQL sebagai bahasa query.
• Dokumentasi berkualitas tinggi yang memungkinkan Anda untuk dengan cepat memperkenalkan karyawan baru ke proyek yang Anda kenal. Oleh karena itu, pengoperasian tumpukan tidak menjadi urusan satu orang yang memiliki pengalaman khusus dan "pengetahuan rahasia".
• Tidak perlu mengetahui terlebih dahulu tentang struktur data yang diterima untuk mulai mengumpulkannya: Anda dapat mulai mengagregasi peristiwa sebagaimana adanya, dan kemudian, saat Anda memahami informasi bermanfaat apa yang dapat Anda ekstrak darinya, ubah pendekatan untuk memprosesnya tanpa kehilangan “kompatibilitas mundur”. Ada banyak alat praktis di stack untuk ini: alias bidang dalam indeks, bidang skrip, dll.

Sumber

Apa yang tidak kita sukai:

• Komponen X-Pack didistribusikan hanya sesuai dengan model berlangganan dan tidak ada yang lain: jika dari Gold, misalnya, hanya mendukung untuk laporan RBAC atau PDF, maka Anda harus membayar semua yang dimiliki Gold. Ini sangat menyebalkan ketika, misalnya, Anda hanya perlu Grafik dari Platinum, dan Machine Learning dan satu bundel fungsi lainnya yang mungkin tidak benar-benar Anda perlukan tersedia untuk dibeli. Upaya kami untuk berkomunikasi dengan departemen penjualan Elastis tentang perizinan komponen X-Pack individu sekitar setahun yang lalu tidak mengarah pada apa pun, tetapi mungkin ada sesuatu yang berubah sejak itu.
• Rilis yang cukup sering di mana entah bagaimana (setiap kali baru) istirahat kompatibilitas. Anda harus membaca changelog dengan sangat hati-hati dan mempersiapkan pembaruan terlebih dahulu. Setiap kali Anda harus memilih: tetap di versi lama, yang bekerja dengan stabil, atau coba tingkatkan untuk fitur baru dan peningkatan kinerja.

Secara umum, kami sangat senang dengan pilihan yang kami buat di tahun 2016, dan kami berencana untuk mentransfer pengalaman pengoperasian Elastic Stack ke proyek kami yang lain: alat yang disediakan oleh stack terintegrasi sangat erat ke dalam alur kerja kami dan akan sangat sulit untuk menolaknya sekarang.