Izinkan saya membahas topik yang secara inheren tidak spesifik untuk PostgreSQL, tetapi yang sering saya temui saat menyelidiki masalah pada sistem pelanggan, mengevaluasi "daya dukung" sistem tersebut, dll. Pentingnya memiliki solusi pemantauan untuk metrik sistem, mengonfigurasinya secara wajar , dan mengapa sar sejauh ini masih merupakan alat favorit saya (setidaknya di Linux).
Tentang pentingnya pemantauan
Pertama, pemantauan metrik sistem dasar (CPU, I/O, memori) sangat penting. Agak aneh harus menunjukkan ini dalam diskusi dengan insinyur lain, tetapi saya akan mengatakan 1 dari 10 insinyur berpikir mereka tidak benar-benar membutuhkan pemantauan. Alasannya biasanya mengikuti baris berikut:
Memang pemantauan benar menambah overhead, tidak diragukan lagi. Tetapi kemungkinan dapat diabaikan dibandingkan dengan apa yang dilakukan aplikasi. Sebenarnya, sar tidak benar-benar menambahkan instrumentasi tambahan, itu hanya membaca counter dari nernel, menghitung delta dan menulisnya ke disk. Mungkin memerlukan beberapa ruang disk dan I/O (bergantung pada jumlah CPU dan disk) tetapi hanya itu.
Misalnya, mengumpulkan statistik per detik pada mesin dengan 32 inti dan banyak disk akan menghasilkan ~5GB data mentah per hari, tetapi dikompresi dengan sangat baik, seringkali hingga ~5-10%). Dan itu hampir tidak terlihat di top . Resolusi per detik agak ekstrim, dan menggunakan 5 atau 10 detik akan semakin mengurangi overhead.
Jadi tidak, ternyata overhead sebenarnya bukan alasan yang sah untuk tidak mengaktifkan pemantauan.
Biaya vs. manfaat
Lebih penting lagi, "Berapa banyak overhead yang saya hilangkan dengan tidak mengaktifkan pemantauan?" adalah pertanyaan yang salah untuk ditanyakan. Alih-alih, Anda harus bertanya, “Manfaat apa yang saya dapatkan dari pemantauan? Apakah manfaatnya lebih besar daripada biayanya?”
Kita sudah tahu biaya (overhead) cukup kecil atau sama sekali diabaikan. Apa manfaatnya? Menurut pengalaman saya, memiliki data pemantauan secara efektif sangat berharga.
Pertama, ini memungkinkan Anda untuk menyelidiki masalah – melihat sekumpulan grafik dan mencari perubahan mendadak ternyata sangat efektif, dan sering kali mengarahkan Anda langsung ke masalah yang tepat. Demikian pula, membandingkan data saat ini (yang dikumpulkan selama penerbitan) dengan data dasar (dikumpulkan saat semuanya baik-baik saja) sangat berguna, dan tidak mungkin jika Anda hanya mengaktifkan pemantauan saat ada masalah.
Kedua, ini memungkinkan Anda untuk mengevaluasi tren dan mengidentifikasi potensi masalah sebelum benar-benar menimpa Anda. Berapa banyak CPU yang Anda gunakan? Apakah penggunaan CPU tumbuh dari waktu ke waktu? Apakah ada pola yang mencurigakan dalam penggunaan memori? Anda hanya dapat menjawab pertanyaan tersebut jika Anda memiliki pemantauan.
Mengapa sar adalah alat favorit saya
Mari kita asumsikan saya yakin Anda memantau itu penting dan Anda pasti harus melakukannya. Tapi kenapa sar alat favorit kami, ketika ada berbagai alternatif mewah, baik di tempat maupun berbasis cloud?
- Termasuk dalam semua distribusi, dan tidak sulit untuk menginstal/mengatur. Ini membuatnya cukup mudah untuk meyakinkan orang agar mengaktifkannya.
- Tepat di mesin. Jadi jika Anda SSH ke mesin, Anda juga bisa mendapatkan data pemantauan.
- Ini menggunakan output teks sederhana. Proses sepele data – impor ke database, analisis, lampirkan ke tiket dukungan. Itu cukup sulit dengan alat lain yang umumnya tidak memungkinkan Anda mengekspor data dengan mudah, hanya menampilkan bagan dan/atau secara signifikan membatasi analisis yang dapat Anda lakukan, dll.
Saya akui beberapa di antaranya berasal dari fakta bahwa saya bekerja untuk perusahaan yang menyediakan layanan PostgreSQL ke perusahaan lain (baik itu dukungan 24×7 atau DBA Jarak Jauh. Jadi kami biasanya hanya mendapatkan akses yang sangat terbatas ke sistem pelanggan (kebanyakan hanya server database dan tidak lebih). Itu berarti memiliki semua data penting di server database itu sendiri, dapat diakses melalui SSH biasa, sangat nyaman dan menghilangkan bolak-balik yang tidak perlu hanya untuk meminta bagian data lain dari beberapa sistem lain. Yang menghemat waktu dan kewarasan di kedua sisi.
Jika Anda memiliki banyak sistem untuk dikelola, Anda mungkin akan lebih memilih solusi pemantauan yang mengumpulkan data dari banyak mesin ke satu tempat. Tapi bagi saya, sar tetap menang.
Jadi, bagaimana cara mengkonfigurasinya?
Saya menyebutkan menginstal dan mengaktifkan sar (atau lebih tepatnya sysstat , yang merupakan paket termasuk sar ) sangat sederhana. Sayangnya, konfigurasi defaultnya agak buruk. Setelah menginstal sysstat , Anda akan menemukan sesuatu seperti ini di /etc/cron.d/sysstat (atau di mana pun distribusi Anda menyimpan cron konfigurasi):
*/10 * * * * root /usr/lib64/sa/sa1 1 1
Ini secara efektif mengatakan sa1 perintah akan dieksekusi setiap 10 menit, dan itu akan mengumpulkan satu sampel selama 1 detik. Ada dua masalah di sini. Pertama, 10 menit adalah resolusi yang cukup rendah. Kedua, sampel hanya mencakup 1 detik dari 600, sehingga 9:59 sisanya tidak benar-benar termasuk di dalamnya. Ini agak OK untuk tren jangka panjang, di mana pengambilan sampel acak resolusi rendah sudah cukup. Untuk tujuan lain, Anda mungkin perlu melakukan sesuatu seperti ini:
* * * * * root /usr/lib64/sa/sa1 -S XALL 60 1
Yang mengumpulkan satu sampel per menit, dan setiap sampel mencakup satu menit. -S XALL berarti semua statistik harus dikumpulkan, termasuk interupsi, perangkat blok individu dan partisi, dll. Lihat man sadc untuk lebih jelasnya.
Ringkasan
Jadi, untuk meringkas posting ini menjadi beberapa poin sederhana:
- Anda harus memiliki pemantauan, bahkan jika Anda merasa tidak membutuhkannya. Setelah Anda mengalami masalah, sudah terlambat.
- Biaya pemantauan mungkin dapat diabaikan, tetapi tentu saja jauh lebih rendah daripada manfaat memiliki data pemantauan.
sarnyaman dan sangat efisien. Mungkin Anda akan menggunakan sesuatu yang lain di masa mendatang, tetapi ini adalah langkah pertama yang baik.- Konfigurasi default tidak terlalu bagus (resolusi rendah, sampel 1 detik). Pertimbangkan untuk meningkatkan resolusi.
Satu hal yang belum saya sebutkan adalah sar hanya berurusan dengan metrik sistem – CPU, disk, memori, proses, bukan dengan statistik PostgreSQL. Anda juga harus memantau bagian tumpukan itu, tentu saja.
