TL; DR : penulis telah mengumpulkan kolektor NetFlow / sFlow dari GoFlow , Kafka , ClickHouse , Grafana dan kruk di Go.
Halo, saya seorang pengeksploitasi dan sangat senang mengetahui apa yang terjadi di infrastruktur. Dan saya juga suka masuk ke urusan orang lain, dan kali ini saya naik ke jaringan.
Misalkan Anda memiliki peralatan jaringan Anda sendiri dan sekantong monolit, layanan microser, dan monolit layanan microser yang menempel di Internet dengan dependensi mereka dalam bentuk basis data, cache, dan server FTP. Dan terkadang beberapa penghuni tas ini mulai bermain nakal di jaringan.
Berikut adalah beberapa contoh lelucon seperti itu:
- cadangan di luar jendela yang ditentukan dalam 40 aliran;
- kesalahan konfigurasi mengirim aplikasi dalam satu DC ke cache DC lain;
- pertanyaan aplikasi di rak berikutnya ke cache yang sama "beri saya objek setengah megabyte ini dari cache" dua ratus kali per detik.
Penghitung SNMP dari switch ports atau VMs hanya akan memberikan perkiraan pemahaman tentang apa yang terjadi, tetapi saya ingin akurasi dan kecepatan analisis masalah. Protokol NetFlow / IPFIX dan sFlow datang untuk menyelamatkan, yang menghasilkan informasi lalu lintas kaya langsung dari peralatan jaringan. Masih menyimpannya di suatu tempat dan entah bagaimana memprosesnya.
Dari kolektor NetFlow yang tersedia, berikut ini telah dipertimbangkan:
- flow-tools - Saya tidak suka penyimpanan dalam file (butuh waktu lama untuk memilih, terutama yang operasional selama reaksi terhadap insiden tersebut) atau MySQL (memiliki miliaran tabel baris sepertinya ide yang cukup suram);
- Elasticsearch + Logstash + Kibana adalah kumpulan sumber daya yang sangat intensif, hingga 6 core CPU 2.2 GHz lansia untuk menerima 5.000 aliran per detik. Namun, Kibana memungkinkan Anda untuk menempelkan segala jenis filter di browser, yang berharga;
- vflow - tidak menyukai format output (JSON, yang tanpa modifikasi tidak dapat ditambahkan ke Elasticsearch yang sama);
- solusi kemas - tidak suka harga tinggi atau perbedaan kecil dari yang dipilih.
Dan itu dipilih dijelaskan dalam presentasi Louis Poinsignon pada RIPE 75 . Skema umum kolektor sederhana adalah sebagai berikut:
GoFlow mem-parsing paket NetFlow / sFlow dan menempatkannya dalam Kafka lokal dalam format protobuf. "Shovel" goflow2ch yang ditulis sendiri mengambil pesan dari Kafka dan mentransfernya ke Clickhouse dalam batch untuk produktivitas yang lebih besar. Skema sama sekali tidak membahas masalah ketersediaan tinggi, tetapi untuk setiap komponen ada cara eksternal reguler atau lebih atau kurang sederhana untuk menyediakannya.
Pengujian telah menunjukkan bahwa biaya CPU untuk penguraian dan pemeliharaan 5.000 utas yang sama menghasilkan sekitar seperempat inti CPU, dan ruang disk yang dikonsumsi rata-rata 11-14 byte per aliran yang sedikit terpotong.
Untuk menampilkan informasi, digunakan UI Web untuk ClickHouse yang disebut Tabix atau plugin untuk Grafana .
Keuntungan dari skema ini:
- kemampuan untuk mengajukan pertanyaan sewenang-wenang tentang keadaan jaringan menggunakan dialek SQL;
- kebutuhan sumber daya yang rendah dan skalabilitas horisontal. Prosesor lama / lambat dan hard disk magnetik akan berfungsi;
- jika perlu, pipa data lengkap dikumpulkan untuk menganalisis peristiwa jaringan, termasuk secara real time menggunakan Kafka Streams, Flink atau analog;
- kemampuan untuk mengubah penyimpanan ke sarana minimum apa pun.
Minusnya juga layak:
- untuk mengajukan pertanyaan, Anda harus tahu SQL dengan baik dan dialek ClickHouse-nya, tidak ada laporan dan grafik yang siap pakai;
- banyak bagian bergerak baru dalam bentuk Kafka, Zookeeper dan ClickHouse. Dua yang pertama berada di Jawa, yang dapat menyebabkan penolakan agama. Bagi saya pribadi, ini bukan masalah, karena semua ini entah bagaimana sudah digunakan dalam organisasi;
- harus menulis kode. Entah "sekop" mentransfer data dari Kafka ke ClickHouse, atau adaptor untuk merekam langsung dari GoFlow.
Fitur bertemu:
- Pastikan untuk menyesuaikan rotasi sesuai dengan ukuran data di Kafka dan ClickHouse, dan kemudian periksa apakah itu benar-benar berfungsi. Di Kafka ada batasan pada ukuran partisi log, dan di ClickHouse - partisi dengan kunci sewenang-wenang. Partisi baru setiap jam dan penghapusan partisi yang tidak perlu setiap 10 menit bekerja dengan baik untuk pemantauan operasional dan dibuat skrip hanya dari beberapa baris;
- "Shovel" mendapat manfaat dari penggunaan kelompok konsumen , memungkinkan Anda untuk menambahkan lebih banyak "shovels" untuk skala dan toleransi kesalahan;
- Kafka memungkinkan Anda untuk tidak kehilangan data saat "shovel" atau ClickHouse mogok (misalnya, karena permintaan yang banyak dan / atau sumber daya terbatas yang tidak benar), tetapi tentu saja, lebih baik, untuk mengkonfigurasi basis data dengan cermat;
- jika Anda akan mengumpulkan sFlow, ingatlah bahwa beberapa sakelar secara default mengubah laju pengambilan sampel paket saat bepergian, dan ini ditunjukkan untuk setiap aliran.
Akibatnya, alat untuk memantau situasi jaringan baik dalam plus atau minus waktu nyata, dan dalam perspektif sejarah, diperoleh dari komponen open source dan pita listrik biru. Terlepas dari kedalaman lututnya, ia telah membantu mengurangi waktu untuk menyelesaikan beberapa insiden.