Selamat hari Jumat semuanya! Teman-teman, hari ini kami melanjutkan rangkaian publikasi yang didedikasikan untuk kursus ini , karena kelas di grup baru untuk kursus tersebut akan dimulai pada akhir minggu depan. Jadi, mari kita mulai!
Pemantauan adalah hanya. Ini adalah fakta yang diketahui. Buka Nagios, jalankan NRPE pada sistem jarak jauh, konfigurasikan Nagios pada NRPE TCP port 5666 dan Anda memiliki pemantauan.
Sangat mudah sehingga tidak menarik. Sekarang Anda memiliki metrik dasar untuk waktu CPU, subsistem disk, RAM, yang disediakan secara default ke Nagios dan NRPE. Namun hal ini sebenarnya bukanlah “pemantauan”. Ini baru permulaan.
(Biasanya mereka menginstal PNP4Nagios, RRDtool dan Thruk, mengatur notifikasi di Slack dan langsung menuju nagiosexchange, tapi biarkan saja dulu).
Pemantauan yang bagus sebenarnya cukup kompleks, Anda sangat perlu mengetahui internal aplikasi yang Anda pantau.
Apakah pemantauannya sulit?
Server apa pun, baik Linux atau Windows, menurut definisinya akan memiliki tujuan tertentu. Apache, Samba, Tomcat, penyimpanan file, LDAP - semua layanan ini kurang lebih unik dalam satu atau lebih hal. Masing-masing memiliki fungsinya sendiri, ciri khasnya masing-masing. Ada berbagai cara untuk mendapatkan metrik, KPI (indikator kinerja utama), yang menarik bagi Anda saat server sedang dimuat.
Penulis foto pada
(Saya berharap dasbor saya berwarna biru neon - mendesah sambil melamun -... hmm...)
Perangkat lunak apa pun yang menyediakan layanan harus memiliki mekanisme untuk mengumpulkan metrik. Apache memiliki modul mod-status, menampilkan halaman status server. Nginx memiliki - stub_status. Tomcat memiliki JMX atau aplikasi web khusus yang menampilkan metrik utama. MySQL memiliki perintah "tampilkan status global" dll.
Jadi mengapa pengembang tidak membangun mekanisme serupa ke dalam aplikasi yang mereka buat?
Apakah hanya pengembang yang melakukan hal ini?
Tingkat ketidakpedulian tertentu terhadap penyematan metrik tidak terbatas pada pengembang. Saya bekerja di perusahaan tempat mereka mengembangkan aplikasi menggunakan Tomcat dan tidak menyediakan metrik mereka sendiri, tidak ada log aktivitas layanan, kecuali log kesalahan Tomcat umum. Beberapa pengembang menghasilkan banyak log yang tidak berarti apa pun bagi administrator sistem yang kurang beruntung untuk membacanya pada pukul 3:15 pagi.
Penulis foto pada
Insinyur sistem yang memungkinkan produk tersebut dirilis juga harus memikul tanggung jawab atas situasi tersebut. Hanya sedikit insinyur sistem yang memiliki waktu atau perhatian untuk mencoba mengekstrak metrik yang bermakna dari log, tanpa konteks metrik tersebut dan kemampuan untuk menafsirkannya berdasarkan aktivitas aplikasi. Beberapa orang tidak memahami bagaimana mereka dapat memperoleh manfaat dari hal ini, selain dari indikator "ada sesuatu yang saat ini (atau akan segera) salah".
Perubahan pemikiran mengenai perlunya metrik harus terjadi tidak hanya di kalangan pengembang, tetapi juga di kalangan insinyur sistem.
Bagi setiap insinyur sistem yang tidak hanya perlu merespons peristiwa kritis, namun juga memastikan bahwa peristiwa tersebut tidak terjadi, kurangnya metrik biasanya menjadi penghalang untuk melakukan hal tersebut.
Namun, insinyur sistem biasanya tidak mengutak-atik kode untuk menghasilkan uang bagi perusahaan mereka. Mereka membutuhkan pengembang utama yang memahami pentingnya tanggung jawab insinyur sistem dalam mengidentifikasi masalah, meningkatkan kesadaran akan masalah kinerja, dan sejenisnya.
Ini hal yang merugikan
Mentalitas devops menggambarkan sinergi antara pemikiran pengembangan (dev) dan operasi (ops). Perusahaan mana pun yang mengaku "melakukan devops" harus:
- mengatakan hal-hal yang mungkin tidak mereka lakukan (mengacu pada meme The Princess Bride - "Menurutku maksudnya tidak seperti yang kamu pikirkan!")
- Mendorong sikap perbaikan produk yang berkelanjutan.
Anda tidak dapat meningkatkan suatu produk dan mengetahui bahwa produk tersebut telah diperbaiki jika Anda tidak mengetahui cara kerjanya saat ini. Anda tidak dapat mengetahui cara kerja suatu produk jika Anda tidak memahami cara kerja komponen-komponennya, layanan yang bergantung padanya, titik-titik permasalahan utama dan hambatannya.
Jika Anda tidak memperhatikan potensi hambatan, Anda tidak akan bisa mengikuti teknik Lima Mengapa saat menulis Postmortem. Anda tidak akan bisa menampilkan semuanya dalam satu layar untuk melihat cara kerja suatu produk atau mengetahui seperti apa produk itu "normal dan bahagia".
Geser ke kiri, KIRI, SAYA BILANG LEEEE—
Bagi saya, salah satu prinsip utama Devops adalah “bergeser ke kiri”. Shift ke kiri dalam konteks ini berarti menggeser kemungkinan (tidak ada tanggung jawab, tetapi hanya kemampuan) untuk melakukan hal-hal yang biasanya menjadi perhatian para insinyur sistem, seperti membuat metrik kinerja, menggunakan log dengan lebih efisien, dll., di sebelah kiri Siklus Hidup Pengiriman Perangkat Lunak.
Penulis foto pada
Pengembang perangkat lunak harus dapat menggunakan dan mengetahui alat pemantauan yang digunakan perusahaan untuk melakukan pemantauan dalam segala bentuk, metrik, logging, antarmuka pemantauan dan yang paling penting, perhatikan bagaimana produk mereka bekerja dalam produksi. Anda tidak bisa membuat pengembang menginvestasikan tenaga dan waktu dalam pemantauan sampai mereka dapat melihat metrik dan memengaruhi tampilannya, bagaimana pemilik produk menyajikannya kepada CTO pada pengarahan berikutnya, dll.
Berbicara singkat
- Pimpin kudamu ke air. Tunjukkan kepada pengembang seberapa besar masalah yang dapat mereka hindari, bantu mereka mengidentifikasi KPI dan metrik yang tepat untuk aplikasi mereka sehingga tidak ada lagi teriakan dari pemilik produk yang dimarahi oleh CTO. Bawa mereka ke dalam terang, dengan lembut dan tenang. Jika cara tersebut tidak berhasil, suap, ancam, dan bujuk mereka atau pemilik produk untuk menerapkan metrik ini dari aplikasi secepat mungkin, lalu buatlah diagramnya. Hal ini akan sulit karena tidak akan dilihat sebagai prioritas dan peta jalan produk akan memiliki banyak proyek yang menghasilkan pendapatan yang tertunda. Oleh karena itu, Anda memerlukan kasus bisnis untuk membenarkan waktu dan biaya yang dikeluarkan untuk menerapkan pemantauan ke dalam produk.
- Membantu teknisi sistem mendapatkan tidur malam yang nyenyak. Tunjukkan kepada mereka bahwa menggunakan daftar periksa “ayo rilis” untuk setiap produk yang dirilis adalah hal yang baik. Dan memastikan semua aplikasi dalam produksi tercakup dalam metrik akan membantu Anda tidur lebih nyenyak di malam hari dengan memungkinkan pengembang melihat apa yang salah dan di mana. Namun, cara yang tepat untuk membuat jengkel dan frustrasi pengembang, pemilik produk, atau CTO mana pun adalah dengan bertahan dan menolak. Perilaku ini akan berdampak pada tanggal rilis produk apa pun jika Anda menunggu lagi hingga menit terakhir, jadi geser ke kiri lagi dan masukkan masalah ini ke dalam rencana proyek Anda sesegera mungkin. Jika perlu, hadiri rapat produk. Pakai kumis palsu dan kain flanel atau semacamnya, tidak akan pernah gagal. Komunikasikan kekhawatiran Anda, tunjukkan manfaat yang jelas, dan evangelisasi.
- Pastikan pengembangan (pengembangan) dan operasi (operasi) memahami arti dan konsekuensi metrik produk yang masuk ke zona merah. Jangan biarkan Ops sebagai satu-satunya penjaga kesehatan produk, pastikan pengembang juga terlibat (#productsquads).
- Log adalah hal yang hebat, begitu pula metrik. Gabungkan keduanya dan jangan biarkan batang kayu Anda menjadi sampah dalam bola api besar yang tidak berguna. Jelaskan dan tunjukkan kepada pengembang mengapa tidak ada orang lain yang memahami log mereka, tunjukkan kepada mereka bagaimana rasanya melihat log yang tidak berguna pada pukul 3:15 pagi.
Penulis foto pada
Itu saja. Materi baru akan dirilis minggu depan. Jika Anda ingin mempelajari lebih lanjut tentang kursus ini, kami mengundang Anda untuk melakukannya , yang akan berlangsung pada hari Senin. Dan sekarang kami secara tradisional menunggu komentar Anda.
Sumber: www.habr.com