Sebelum Anda mulai melihat alat pemantauan server SQL, pikirkan tentang lingkungan spesifik Anda:
- Berapa banyak kejadian yang ingin Anda pantau?
- Apakah ini di satu lokasi atau tersebar?
- Apakah Anda perlu memantau sistem operasi dan/atau hypervisor?
- Berapa banyak riwayat yang Anda perlukan untuk mendapatkan gambaran yang akurat tentang batas operasi instans Anda?
- Apakah semuanya lokal atau sebagian di cloud?
- Apakah tim Anda didistribusikan?
- Apakah Anda membeli perangkat lunak dengan anggaran belanja modal atau belanja operasional?
- Dapatkah Anda menginvestasikan sejumlah uang di muka untuk infrastruktur dan lisensi atau Anda lebih suka membagi biaya seiring waktu?
- Apakah Anda memiliki infrastruktur dan instans database yang tersedia untuk digunakan sebagai alat pemantauan?
- Apakah Anda punya waktu untuk membangun infrastruktur pemantauan?
- Apakah Anda memiliki keahlian tinggi yang konsisten di seluruh tim Anda?
- Apakah Anda menggunakan sumber daya junior untuk triase awal atau bergantung pada ahli Anda untuk semuanya?
- Apakah Anda memiliki waktu atau sumber daya secara internal untuk memelihara infrastruktur pemantauan?
Haruskah Saya Menggulung Sendiri?
Saya dapat menyatakan bias kami di sini. Quest Software telah membangun alat pemantauan kinerja selama 20 tahun terakhir. Ada alasan bagus mengapa kami dan banyak orang lain seperti kami tetap berada di segmen ini begitu lama dan mengapa kami memiliki basis pelanggan yang berkembang. Pemantauan kinerja yang dilakukan dengan baik tidak mudah!
Memang ada beberapa cara hebat untuk mengumpulkan metrik dari SQL Server menggunakan PerfMon, traces, DMVs, dan XEvents, untuk menyebutkan beberapa. Melakukan ini satu kali untuk satu masalah adalah baik dan bagus—jika Anda punya waktu untuk berinvestasi dalam meneliti di mana dan bagaimana mengumpulkan data untuk masalah itu. Setelah masalah mulai meningkat dan jumlah instance meningkat, ini dengan cepat menjadi tidak dapat diskalakan.
Ada beberapa ratus metrik yang tersedia yang layak dilacak untuk mendapatkan gambaran lengkap tentang kesehatan kinerja SQL Server Anda. Selain itu, ada kode SQL yang berjalan dan rencana kueri yang terkait dengan setiap eksekusi yang sama. Beberapa metrik harus dikumpulkan setiap detik, beberapa setiap jam, dan beberapa berdasarkan kapan kode dijalankan. Beberapa metode pengumpulan dapat memengaruhi instans yang dipantau dan harus dihindari.
Setiap metrik akan memiliki ambang batas yang berbeda yang akan menentukan statusnya. Instance tertentu mungkin memiliki level yang tidak standar. Maka Anda harus menyimpan semua ini. Volume data bertambah SANGAT cepat. Anda perlu menerapkan strategi untuk membersihkan data mendetail secara teratur, lalu, jika diperlukan untuk tren, menggabungkan data ini untuk pelaporan.
Ini BANYAK pekerjaan ... dan tentu saja, setiap kali versi SQL Server baru keluar, Anda memiliki sakit kepala regresi yang harus dihadapi. Kecuali jika Anda benar-benar ingin menjual alat pemantauan, saya sangat menyarankan untuk tidak menggulirkan sendiri kecuali volume masalah rendah dan masalah yang harus Anda pecahkan sangat spesifik.
Bagaimana Dengan Alat Gratis?
Alat gratis sering kali layak dipertimbangkan, terutama untuk tim yang lebih kecil dengan instance yang kurang kritis. Anggap saja sebagai langkah berikutnya dalam tangga skalabilitas setelah "menggulung milik Anda sendiri." Banyak alat pemantauan server SQL komersial tingkat pemula harus memiliki pertimbangan yang sama. Pertimbangkan hal berikut:
- Apakah alat ini mencakup metrik yang cukup luas untuk memberi Anda cakupan yang memadai untuk semua kasus penggunaan di seluruh instans yang dipantau? Banyak alat gratis akan memberikan semacam "penyesuaian" untuk menambahkan metrik Anda sendiri. Saat "penyesuaian" digunakan untuk mengisi celah dalam fungsionalitas, Anda akan segera menemukan tim Anda berakhir "menggulung sendiri" dengan gangguan yang diperlukan dan sakit kepala pemeliharaan.
- Apakah alat ini mendukung peringatan? Apakah sudah dikonfigurasi sebelumnya? Mengonfigurasi peringatan bisa sangat memakan waktu. Peringatan out-of-box adalah suatu keharusan untuk mencegah banyak jam kerja yang hilang untuk mengonfigurasi alat orang lain. Ini juga harus memfasilitasi penyesuaian peringatan untuk kasus tepi yang tidak sesuai dengan default.
- Bagaimana dan di mana data disimpan? Sebagian besar alat gratis menyerahkan kepada Anda untuk mengelola penyimpanan data kinerja. Berhati-hatilah dengan pemantauan "gratis" dari vendor cloud. Mereka mengenakan biaya untuk penyimpanan, dan ini bisa menjadi besar dan mahal dengan cepat!
Jadi, tentu saja, manfaatkan alat gratis yang ada di luar sana. Sadarilah keterbatasan mereka dan cari anti-pola klasik dalam tim Anda, seperti:
- Lebih banyak waktu yang dihabiskan untuk memperbaiki atau memelihara alat yang digunakan untuk memperbaiki masalah
- Lebih banyak uang yang dihabiskan untuk infrastruktur dan penyimpanan
- Banyak data tapi tidak ada wawasan
- Tidak cukup kedalaman diagnostik untuk memecahkan masalah
- Tidak cukup skalabel untuk memenuhi kebutuhan Anda
Jika Anda melihat salah satu hal di atas, itu harus menunjukkan kebutuhan untuk meningkatkan ke solusi yang lebih kuat.
Arsitektur Tipikal Sistem Pemantauan SQL Server
Saat mempertimbangkan apakah akan menggunakan solusi lokal tradisional atau solusi perangkat lunak yang dihosting sebagai layanan (SaaS), akan sangat membantu untuk mempertimbangkan arsitektur aplikasi pemantauan. Berikut adalah ringkasan komponen arsitektur utama.
Penyimpangan utama antara SaaS dan lokal berkaitan dengan tempat data kinerja disimpan dan siapa yang mengelola repositori ini. Untuk solusi lokal, ini adalah tanggung jawab pengguna akhir. Repositori ini bisa menjadi besar dengan cepat, jadi mereka harus dikelola dengan hati-hati. Infrastruktur perlu direncanakan dan dianggarkan (selengkapnya di bawah).
Dalam solusi SaaS untuk pemantauan server SQL, komponen infrastruktur utama ini dihosting dan dikelola untuk Anda.
| Solusi Lokal Tradisional | Solusi SaaS |
|
|
Untuk detail lebih lanjut, lihat blog kami, Arsitektur Sistem Pemantauan Basis Data.
