Sistem pemantauan aplikasi / host host yang terdistribusi secara geografis, toleran terhadap kesalahan dan “cerdas”


12

Salam pembuka,

Saya ingin bertanya pendapat kolektif dan pandangan tentang sistem pemantauan terdistribusi, apa yang Anda gunakan dan apa yang Anda ketahui yang mungkin mencentang kotak saya?

Persyaratannya cukup kompleks;

  • Tidak ada titik kegagalan. Betulkah. Aku benar-benar serius! Harus dapat mentolerir kegagalan simpul tunggal / ganda, baik 'master' dan 'pekerja' dan Anda dapat berasumsi bahwa tidak ada lokasi pemantauan ("situs") yang memiliki banyak node di dalamnya, atau berada di jaringan yang sama. Oleh karena itu ini mungkin mengesampingkan teknik HA tradisional seperti DRBD atau Keepalive.

  • Logika terdistribusi, saya ingin menggunakan 5+ node di beberapa jaringan, dalam banyak pusat data dan di beberapa benua. Saya ingin tampilan "Mata Burung" dari jaringan dan aplikasi saya dari perspektif pelanggan saya, poin bonus untuk logika pemantauan tidak menjadi macet ketika Anda memiliki 50+ node, atau bahkan 500+ node.

  • Kebutuhan untuk dapat menangani sejumlah pemeriksaan host / layanan yang cukup masuk akal, ala Nagios, untuk angka rata-rata mengasumsikan 1500-2500 host dan 30 layanan per host. Akan sangat bagus jika menambahkan lebih banyak node pemantauan memungkinkan Anda untuk skala relatif linier, mungkin dalam 5 tahun ke depan saya mungkin ingin memantau 5000 host dan 40 layanan per host! Menambahkan dari catatan saya di atas tentang 'logika terdistribusi' akan menyenangkan untuk mengatakan:

    • Dalam keadaan normal, pemeriksaan ini harus dijalankan pada $ n atau n% dari node pemantauan.
    • Jika kegagalan terdeteksi, jalankan pemeriksaan pada $ n atau n% dari node lainnya, korelasikan hasilnya dan kemudian gunakan untuk memutuskan apakah kriteria telah dipenuhi untuk mengeluarkan peringatan.
  • Grafik dan fitur ramah manajemen. Kami perlu melacak SLA kami dan mengetahui apakah aplikasi 'sangat tersedia' kami naik 24x7 agak berguna. Idealnya solusi yang Anda usulkan harus melaporkan "out of the box" dengan minimal faff.

  • Harus memiliki API atau sistem plugin yang solid untuk mengembangkan pemeriksaan pesanan khusus.

  • Perlu masuk akal tentang peringatan. Saya tidak ingin selalu tahu (via SMS, jam 3 pagi!) Bahwa satu node pemantauan memperhitungkan router inti saya sedang down. Saya tidak ingin tahu apakah persentase didefinisikan dari mereka setuju bahwa sesuatu yang funky yang terjadi;) Pada dasarnya apa yang saya bicarakan di sini adalah "kuorum" logika, atau penerapan kewarasan kegilaan didistribusikan!

Saya bersedia mempertimbangkan opsi komersial dan open source, meskipun saya lebih suka menghindari perangkat lunak yang harganya jutaan poundsterling :-) Saya juga bersedia menerima mungkin tidak ada yang ada di luar sana yang menandai semua kotak itu, tetapi ingin bertanya kepada kolektif itu.

Ketika berpikir tentang memonitor node dan penempatannya, ingatlah bahwa sebagian besar dari ini akan didedikasikan server pada jaringan ISP acak dan dengan demikian sebagian besar di luar kendali saya. Solusi yang mengandalkan umpan BGP dan kejenakaan jejaring kompleks lainnya sepertinya tidak cocok.

Saya juga harus menunjukkan bahwa saya telah mengevaluasi, menyebarkan atau banyak menggunakan / menyesuaikan sebagian besar rasa open source di masa lalu termasuk Nagios, Zabbix dan teman-teman - mereka benar-benar bukan alat yang buruk tetapi mereka gagal secara keseluruhan " didistribusikan "aspek, terutama berkaitan dengan logika yang dibahas dalam pertanyaan saya dan peringatan 'cerdas'.

Senang mengklarifikasi poin yang diperlukan. Ceria cowok dan cewek :-)


2
Itu benar-benar aneh, saya akan mengajukan pertanyaan serupa. Minggu ini kami memiliki beberapa keluhan pelanggan tentang pemadaman situs, tetapi hanya dari lokasi tertentu. Sistem peringatan kami tidak mendeteksi masalah ini. Kami menghubungi penyedia kami dan mereka mengkonfirmasi bahwa beberapa dari mereka memiliki masalah tulang punggung. Jadi saya juga tertarik dengan solusi. Terima kasih!
splattne

Dan apa solusi terakhirnya?
ewwhite

Jawaban:


4

bukan jawaban sebenarnya, tetapi beberapa petunjuk:

  • Lihat presentasi tentang nagios @ goldman sachs . mereka menghadapi masalah yang Anda sebutkan - redundansi, skalabilitas: ribuan host, juga pembuatan konfigurasi otomatis.

  • saya memiliki pengaturan nagios yang berlebihan tetapi pada skala yang jauh lebih kecil - 80 server, ~ total 1k layanan. satu server master khusus, satu server slave yang menarik konfigurasi dari master secara berkala beberapa kali sehari. kedua server mencakup pemantauan mesin yang sama, mereka melakukan pemeriksaan silang kesehatan satu sama lain. saya menggunakan nagios sebagian besar sebagai kerangka kerja untuk memohon pemeriksaan khusus produk khusus [sekelompok pekerjaan cron yang menjalankan skrip yang melakukan 'kontrol aliran buatan', hasil log masuk ke sql, nrpe plugins ware memeriksa untuk keberhasilan / kegagalan eksekusi dari mereka dalam x menit terakhir]. semua bekerja dengan sangat baik.

  • logika kuorum Anda kedengarannya bagus - sedikit mirip dengan 'aliran buatan' saya - pada dasarnya berjalan, ipmplement diri Anda; -]. dan minta nrpe memeriksa beberapa jenis flag [atau sql db dengan timestamp-status] bagaimana keadaannya.

  • Anda mungkin ingin membangun beberapa hierarki ke skala - Anda akan memiliki beberapa node yang mengumpulkan ikhtisar dari node lain, jangan melihat presentasi dari titik pertama. forging nagios standar untuk setiap pemeriksaan tunggal adalah jumlah yang terlalu banyak pada layanan yang dipantau yang lebih banyak.

untuk menjawab beberapa pertanyaan:

  • dalam lingkungan kasus saya yang dipantau adalah pengaturan master-slave [sql primer atau server aplikasi + siaga panas], tidak ada master-master.
  • setup saya melibatkan 'faktor penyaringan manusia' - kelompok penyelesai yang merupakan 'cadangan' untuk notifikasi sms. sudah ada kelompok teknisi berbayar yang karena alasan lain memiliki shift 24/5, mereka mendapat 'memeriksa surat nagios' sebagai tugas tambahan yang tidak terlalu banyak memuatnya. dan mereka bertugas memastikan bahwa perangkat db-admin / it-ops / app-admin benar-benar bangun dan memperbaiki masalah; -]
  • Saya telah mendengar banyak hal baik tentang zabbix - untuk mengingatkan dan merencanakan tren, tetapi tidak pernah menggunakannya. bagi saya munin melakukan triknya, saya telah meretas plugin nagios sederhana memeriksa apakah ada warna 'kritis' pada daftar server munin - hanya pemeriksaan tambahan. Anda juga dapat membaca nilai-nilai dari file-file Munin untuk mengurangi jumlah permintaan yang Anda kirim ke mesin yang dipantau.

1
@astinus - baik untuk peringatan masuk akal saya menggunakan skrip pemberitahuan kustom. alih-alih mengandalkan nagios yang diberitahukan melalui surat / pager, saya menyimpan pesan ke fifo que dan meminta pelanggan yang mengirim pesan berdasarkan logika kustom [berdasarkan jadwal panggilan yang cukup fleksibel, dll], juga ada beberapa batasan pesan terkirim per jam, jadi satu tidak mendapatkan 50 SMS dalam waktu singkat. saya melihat pendekatan serupa dalam skala yang lebih besar - nagios hanyalah kerangka dan skrip orang di sekitarnya dan benar-benar menggunakan fitur yang semakin sedikit.
pQd

1
Sehubungan dengan hierarki, apa yang saya miliki saat ini adalah pengaturan nagios "modular" seluruhnya di mana direktori etc / Anda berisi konfigurasi 'core' yang dibagikan (dan identik) pada semua host dan kemudian etc / modules / $ NAME (yaitu : Mail, Web, Jaringan, DNS) yang 100% portabel antar server. Sertakan dengan cfg_dir =) Anda memasukkan perintah, plugin, dan segala sesuatu yang spesifik modul ke direktori itu. Membuat> 1 server menjalankan pemeriksaan mereka cukup mudah karena Anda hanya menyalin modul sebagai banyak kotak nagios yang diperlukan, namun sekali lagi, logika peringatan menyebabkan masalah :-)
nixgeek

1
@ astinus # 2. dalam kasus saya konfigurasi replikasi master-> slave terjadi setiap 6 jam. jika master mati [power padam dll] - slave akan memberi tahu semua orang tentang master mati [crosscheck antar server]. orang dapat membayangkan skenario lain - ketika master mati karena kesalahan konfigurasi. jika itu terjadi hingga 5 menit sebelum config sync to slave - akan ada notifikasi. jika sebelum konfigurasi sinkronisasi - sayangnya kami akhirnya tidak memiliki sistem pemantauan. 'Siapa yang akan menonton penjaga'? Yah, mungkin nagios lain yang sangat sederhana.
pQd

1
@ pQd - menarik, saya setuju bahwa menerapkan logika dalam skrip notifikasi khusus mungkin adalah cara yang harus dilakukan. Namun itu menjadi sangat sulit untuk menghindari pemberitahuan duplikat dari 2+ host, ketika Anda telah mengatakan 50 host pemantauan, dan saya belum melihat siapa pun (di depan umum) memasukkan logika mereka bersama ke dalam sistem passing 'pesan' yang tepat seperti Rabbit atau Amazon SQS.
nixgeek

1
@ astinus # 3 dalam kasus saya ini adalah solusi 'Level 8' [model iso osi]: nagios primer mengirim sms ke orang-orang melalui telepon + email ke 24/5 'grup penyelesai', sementara nagios ke-2 hanya berkirim surat ' kelompok penyelesai '. tergantung pada kelompok itu untuk memfilter duplikat sebelum meningkat;
pQd

1

Apa yang Anda minta terdengar sangat mirip dengan apa yang telah dilakukan Shinken untuk Nagios.

Shinken adalah penulisan ulang Nagios.

  • Bahasa modern (Python)
  • Kerangka kerja pemrograman terdistribusi modern (Pyro)
  • Monitoring Realms (multi-tenancy), HA, suku cadang
  • API Livestatus
  • Kompatibel dengan plugin nagios
  • Eksekusi NRPE asli
  • Kekritisan bisnis terhadap objek
  • Aturan bisnis dapat diterapkan pada keadaan objek (mengelola ketersediaan cluster atau kumpulan)
  • Grafik dapat menggunakan PNP4nagios berbasis Graphite atau RRDtool
  • Stabil dan digunakan di lingkungan besar
  • Penempatan besar dapat mempertimbangkan memasangkannya dengan Splunk untuk pelaporan atau melihat ke Graphite di mana RRDtool tidak cocok.

Ini harus menjadi bahan pertimbangan.

Bersulang

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.