Ini adalah Pertanyaan Canonical tentang Perangkat Lunak Pemantauan.
Juga Terkait: Alat apa yang Anda gunakan untuk memonitor server Anda?
Saya perlu memonitor server saya; apa yang harus saya pertimbangkan ketika memutuskan solusi pemantauan?
Jawaban:
Ada banyak solusi pemantauan di luar sana. Setiap orang memiliki preferensi masing-masing dan setiap bisnis memiliki kebutuhannya sendiri, sehingga tidak ada jawaban yang benar. Namun, saya dapat membantu Anda mencari tahu apa yang mungkin ingin Anda cari dalam memilih solusi pemantauan.
Secara umum sistem pemantauan melayani dua tujuan utama. Yang pertama adalah mengumpulkan dan menyimpan data dari waktu ke waktu. Misalnya, Anda mungkin ingin mengumpulkan pemanfaatan CPU dan membuat grafik dari waktu ke waktu. Tujuan kedua adalah untuk mengingatkan ketika segala sesuatu tidak merespons atau tidak dalam ambang batas tertentu. Misalnya, Anda mungkin ingin memberi peringatan jika server tertentu tidak dapat dijangkau oleh ping atau jika pemanfaatan CPU di atas persentase tertentu. Ada juga sistem pemantauan log seperti Splunk tetapi saya memperlakukannya sebagai terpisah untuk ini.
Dua peran utama ini kadang-kadang datang dalam satu produk, di waktu lain dan yang lebih umum adalah memiliki produk yang didedikasikan untuk setiap tujuan.
Poller :
Semua sistem pemantauan membutuhkan semacam poller untuk mengumpulkan data. Tidak semua data dikumpulkan dengan cara yang sama. Anda harus melihat lingkungan Anda dan memutuskan data apa yang Anda butuhkan dan bagaimana pengumpulannya. Kemudian pastikan sistem pemantauan yang Anda pilih mendukung apa yang Anda butuhkan. Beberapa metode umum meliputi:
Jika Anda memiliki sebagian besar satu OS di lingkungan Anda atau OS utama, sistem tertentu mungkin memiliki lebih banyak opsi daripada yang lain.
Konfigurasi :
Dalam sistem pemantauan cenderung ada banyak objek yang digunakan kembali. Misalnya, Anda ingin memantau aplikasi tertentu seperti Apache atau IIS di banyak server. Atau Anda ingin ambang tertentu berlaku untuk grup server. Anda mungkin juga memiliki kelompok orang tertentu yang "siap dipanggil". Karena itu sistem templating yang baik sangat penting untuk sistem monitor.
Konfigurasi umumnya dilakukan melalui antarmuka pengguna atau file teks. Opsi antarmuka pengguna umumnya akan lebih mudah, tetapi file teks cenderung lebih baik untuk digunakan kembali dan variabel. Jadi tergantung pada staf TI Anda, Anda mungkin lebih suka kesederhanaan daripada kekuasaan.
Antarmuka Pengguna : Antarmuka yang
paling umum untuk sistem pemantauan saat ini adalah antarmuka web. Beberapa hal untuk dievaluasi sehubungan dengan antarmuka web adalah:
Alerting Engine : Mesin
peringatan harus fleksibel dan dapat diandalkan. Ada banyak cara berbeda untuk diberi tahu termasuk:
Fitur lain yang harus dicari adalah:
Penting untuk percaya bahwa ketika terjadi kesalahan, Anda akan mendapatkan peringatan. Ini bermuara pada dua hal:
Penyimpanan Data :
Jika sistem mengumpulkan dan menyimpan data (yaitu sistem yang menyertakan grafik) daripada sistem menyimpan data. Contoh implementasi yang sangat umum untuk store dan grafik adalah RRD.
Beberapa fitur yang harus dicari dari penyimpanan data adalah:
Graphing Library :
Grafik dapat berguna untuk mengidentifikasi tren dengan cepat dan memberikan konteks pada keadaan saat ini dari sesuatu berdasarkan sejarahnya. Beberapa termasuk tren yang dapat membantu untuk memprediksi hal-hal sebelum terjadi (yaitu kehabisan ruang disk). Pastikan bahwa grafik akan memberi Anda informasi yang menurut Anda akan dibutuhkan dengan cara yang jelas.
Kontrol Akses :
Jika Anda memiliki organisasi besar, Anda mungkin memerlukan kontrol akses karena admin tertentu hanya dapat menyesuaikan hal-hal tertentu. Anda mungkin juga ingin dashboard menghadap publik. Jika ini penting, Anda harus memastikan sistem pemantauan memiliki kontrol yang Anda butuhkan.
Pelaporan :
Suatu sistem yang menyediakan laporan yang baik dapat membantu Anda mengidentifikasi apa yang perlu diperbaiki dalam jangka waktu yang lama. Misalnya itu dapat memberikan jawaban yang baik untuk hal-hal seperti "sistem apa yang paling turun?". Ini bisa menjadi penting ketika Anda mencoba meyakinkan manajemen untuk membelanjakan uang untuk hal-hal tertentu - bisnis seperti bukti keras.
Fitur Khusus :
Beberapa sistem pemantauan ditargetkan pada produk tertentu atau memiliki lebih banyak dukungan daripada yang lain. Sebagai contoh jika hal utama yang perlu Anda monitor adalah SQL server, atau jika Anda menggunakan banyak produk VMWare Anda harus melihat seberapa baik ini didukung.
Templat Pemantauan Yang Telah Ditentukan :
Suatu sistem yang datang dengan banyak templat yang telah ditentukan sebelumnya (atau memiliki basis pengguna yang telah membuat banyak templat) dapat menjadi penghemat waktu yang sangat besar.
Penemuan :
Jika Anda memiliki lingkungan yang besar atau berubah. Beberapa sistem menyediakan kemampuan untuk menambahkan sistem baru melalui API atau menjalankan pemindaian untuk menemukan server atau komponen baru.
Pemantauan Terdistribusi:
Jika Anda memiliki beberapa lokasi untuk dipantau, akan sangat membantu jika Anda memiliki pemantau pemantau di setiap lokasi alih-alih banyak sistem independen yang memantau melalui WAN.
Ada banyak sistem pemantauan di luar sana. Kami memiliki daftar dengan ringkasan tentang pertanyaan lama ini . Untuk referensi cepat, beberapa yang paling saya dengar adalah:
Alasan saya tidak dapat memberi tahu Anda apa yang harus digunakan adalah karena setiap organisasi memiliki kebutuhannya sendiri. Jika Anda ingin membuat pilihan yang tepat, Anda harus memikirkan semua komponen di atas dan mencari tahu fitur apa yang penting bagi organisasi Anda. Kemudian temukan sistem atau sistem yang mengklaim menyediakan apa yang Anda butuhkan dan mencobanya. Beberapa di antaranya harganya sedikit, banyak, atau gratis. Dengan mempertimbangkan semua itu, Anda dapat menentukan pilihan. Dari apa yang saya gunakan, mereka semua jauh dari sempurna, tetapi setidaknya Anda dapat mencoba untuk mendapatkan sesuatu yang cocok.
Sangat membantu untuk membedakan antara pemantauan dan peringatan. Pemantauan berarti mengumpulkan data dan membuat grafik. Peringatan berarti mengirim saya SMS ketika server turun di tengah malam.
Nagios untuk memperingatkan. Cacti dan Munin untuk pemantauan. Produk lain menggabungkan dua fungsi. Zenoss dan Zabbix adalah contohnya.
Saya akan mulai dengan menjawab beberapa pertanyaan:
Apakah Anda perlu memonitor server, perangkat jaringan, aplikasi, atau ketiganya?
Apakah ada batasan pada metode apa yang dapat Anda gunakan untuk memantau? Bisakah Anda menginstal klien pemantauan seperti NRPE di server, atau Anda akan menggunakan SNMP, atau mungkin keduanya?
Siapa yang akan menggunakan grafik, dan siapa yang akan menggunakan lansiran? Seperti apa hasil akhir yang Anda inginkan? Apakah tampilan dan nuansa antarmuka penting (apakah pebisnis akan menggunakan ini, atau hanya staf teknologi?)
Apa sumber daya Anda, baik dari segi waktu, keterampilan, dan perangkat keras? Apakah Anda memiliki setidaknya kemampuan skrip yang sederhana? Apakah Anda memerlukan solusi out-of-the-box?
Menurut pendapat saya, aturan pertama untuk menyiagakan dan memantau harus tetap sederhana! Suatu organisasi dapat hidup atau mati tentang bagaimana peringatan dan pengumpulan data, dan sebagian besar waktu itu akan menjadi rumit dengan sendirinya. Mulailah dengan dasar-dasar dan bangun dari sana.
Pikirkan tentang layanan yang disediakan oleh perangkat lunak Anda , kirim peringatan ketika layanan ini gagal, atau ketika risiko kegagalan layanan ini meningkat.
Teori di balik strategi pemantauan adalah untuk mengikat pemantauan dan peringatan untuk semacam perjanjian tingkat layanan . Lagi pula, Anda ingin diberitahu tentang fakta bahwa Anda kehilangan uang, tidak harus berarti ada lonjakan jumlah koneksi TCP ke nji0019.myserver.com. Ada berbagai alat yang akan memberi Anda banyak peringatan, menentukan ketergantungan antar peringatan, tetapi banyak dari pemeriksaan ini tidak secara langsung relevan dengan layanan yang Anda berikan kepada seseorang.
Identifikasi layanan penting yang Anda berikan, seperti kemampuan untuk melayani situs web, dan kemampuan untuk memodifikasi situs web itu (misalnya CMS dari beberapa jenis). Itu harus diperiksa (mis. Dengan memonitor bahwa Anda bisa mendapatkan halaman web, dan Anda bisa). Kegagalan kedua Layanan ini (digunakan di sini dengan huruf kapital S) akan memicu peringatan untuk memberi tahu Anda.
Jika penting bahwa situs merespons dalam jumlah waktu yang wajar, itu juga akan memicu peringatan. Semacam "pelanggaran SLA" jika Anda mau.
Biasanya ada risiko inheren dari Layanan yang gagal, dan cukup sering risiko itu dimitigasi oleh fakta bahwa Anda memperkenalkan redundansi, misalnya server kedua, atau database budak, atau kartu jaringan tambahan ...
Ketika redundansi itu hilang, Layanan masih baik-baik saja, tetapi risiko kegagalan Layanan baru saja naik.
Ini adalah alasan utama kedua untuk memicu peringatan; bahwa redundansi hilang (mis. bahwa server kedua mati), atau bahwa ada risiko yang akan segera meningkat (mis. disk hanya memiliki 500MB tersisa, atau tren disk menunjukkan bahwa disk akan penuh dalam waktu sekitar 5 jam).
Tapi check_mk memberi saya 50-60 cek per host, apakah ini semua tidak berharga?
Tidak. Semua ini tidak berarti Anda ingin membuang sebagian besar pemeriksaan otomatis yang Anda dapatkan dengan mis. Check_mk, tetapi itu berarti Anda harus mencoba mengelompokkan setiap cek ke dalam Layanan apa yang mungkin terpengaruh jika ada sesuatu yang gagal.
Layanan apa yang akan terpengaruh jika partisi / var terisi? Layanan apa yang akan terpengaruh jika antarmuka eth0 turun? ... jika koneksi TCP keluar diblokir oleh beberapa firewall? ... jika jumlah utas melebihi 800? ... jika database turun?
Anda memiliki 2 server web, dan server basis data yang melayani situs di belakang penyeimbang beban yang bukan milik Anda (mis. ISP). Layanan yang Anda berikan adalah port 80 pada dua server, dan mereka memiliki cache yang sangat besar yang dapat bertahan hidup mis. Downtime basis data (database pada server ketiga).
Dalam skenario ini, kegagalan total server web tidak akan menyebabkan situs menjadi turun. Apa yang terjadi adalah bahwa redundansi hilang sehingga risiko kegagalan naik. Itu seharusnya memicu peringatan.
Kegagalan total dari database mungkin tidak mempengaruhi kemampuan untuk melayani situs sama sekali, karena cache yang disetel dengan baik di tempat; Ini kemudian tidak mempengaruhi Layanan melayani situs web, tetapi mungkin mempengaruhi Layanan yang berbeda, yaitu memperbarui situs web, atau menerima pesanan ...
Setiap Layanan akan memiliki tingkat layanannya sendiri yang menunjukkan betapa pentingnya mengembalikan layanan atau untuk menghindari pemadaman
Setiap kali Anda menerima peringatan, Anda harus melakukan salah satu dari yang berikut: - ubah sistem yang dipantau untuk memperbaiki masalah yang menyebabkan peringatan (mis. Ganti drive atau konfigurasi ulang logrotate atau semacamnya) - ubah sistem pemantauan untuk menghindari peringatan tersebut. dikirim pada waktu berikutnya situasi muncul. (mis. ubah level untuk "disk bebas" sehingga disk dapat mengisi hingga 90%, bukan hanya 80%)
Saya sebagian besar terbiasa dengan Nagios dan konfigurasi verbose-nya, dan sejak itu telah terhubung pada multisite Check-mk. Baru-baru ini saya mengetahui bahwa check_mk memiliki konsep Business Intelligence (sejak 1.11) yang tampaknya cocok dengan pemikiran ini. Anda dapat menentukan bahwa pemeriksaan dalam nagios adalah bagian dari layanan yang lebih besar dan memiliki aturan yang mendefinisikan status "Layanan" sebagai fungsi dari keadaan banyak pemeriksaan, yang dikumpulkan ke kondisi terburuk atau terbaik .
Salah satu poin paling penting yang dilupakan oleh perusahaan ketika memilih solusi pemantauan adalah bahwa ini bukan tentang menyelesaikan masalah operasional langsung, ini tentang masalah besok yang tak terduga! Maksud saya, tentu saja menyelesaikan masalah langsung adalah penting, tetapi percayalah, dalam banyak kasus, strategi jangka pendek ini tidak akan menjamin kelangsungan hidup perusahaan.
Ada puluhan solusi pemantauan hebat di pasar. Membuat daftar pendek sejumlah kecil solusi yang memenuhi kebutuhan Anda adalah tugas yang sulit dan panjang, apalagi, menemukan solusi yang sesuai dengan anggaran Anda bahkan lebih sulit. Bagian yang menarik adalah menemukan yang selaras dengan masa kini dan masa depan Anda . Dan tidak ada proses evaluasi untuk mendeteksi itu, ini adalah masalah pengalaman + intuisi + faktor yang sangat penting: Kepercayaan , yang bukan hal yang mudah untuk diretas .
Sebagai aturan praktis, cari dan gali kisah sukses dari serangkaian solusi pemantauan terpilih Anda, khususnya jika itu memengaruhi perusahaan dari sektor Anda. Minta vendor untuk kisah sukses mereka, dan bahkan minta izin untuk berbicara dengan salah satu pelanggan mereka. Perusahaan yang tidak takut dengan pertunjukan ini mereka memiliki hubungan nyata dengan pelanggan mereka, dan mereka tidak menyembunyikannya, dan ini adalah hal yang sangat langka untuk ditemukan saat ini.
Zabbix, Icinga, Pandora FMS, op5, Datadog, New Relic ... mereka semua mengalami pasang surut, tetapi masalah sebenarnya adalah menemukan mana yang beradaptasi lebih baik untuk masa depan Anda.
Jika Anda mempertimbangkan pemantauan sistem jarak jauh, maka mungkin ide yang baik untuk mencari lokasi sebenarnya dari tes yang dilakukan. Masalah konektivitas bukan hal yang lalu dan jika perangkat keras Anda melayani grup di wilayah tertentu, Anda mungkin ingin memastikan bahwa sumber daya Anda tersedia di lokasi tertentu.