Salam Jumaat semua! Rakan-rakan, hari ini kita meneruskan siri penerbitan khusus untuk kursus ini , kerana kelas dalam kumpulan baru untuk kursus akan bermula pada penghujung minggu hadapan. Jadi, mari kita mulakan!
Pemantauan adalah hanya. Ini adalah fakta yang diketahui. Bawa Nagios, jalankan NRPE pada sistem jauh, konfigurasikan Nagios pada port NRPE TCP 5666 dan anda mempunyai pemantauan.
Ia sangat mudah ia tidak menarik. Kini anda mempunyai metrik asas untuk masa CPU, subsistem cakera, RAM, dibekalkan secara lalai kepada Nagios dan NRPE. Tetapi ini sebenarnya bukan "pemantauan" seperti itu. Ini hanya permulaan.
(Biasanya mereka memasang PNP4Nagios, RRDtool dan Thruk, menyediakan pemberitahuan dalam Slack dan pergi terus ke nagiosexchange, tetapi mari kita biarkan perkara itu buat masa ini).
Pemantauan yang baik sebenarnya agak kompleks, anda benar-benar perlu mengetahui dalaman aplikasi yang anda pantau.
Adakah pemantauan sukar?
Mana-mana pelayan, sama ada Linux atau Windows, mengikut definisi akan mempunyai beberapa tujuan. Apache, Samba, Tomcat, storan fail, LDAP - semua perkhidmatan ini lebih kurang unik dalam satu atau lebih aspek. Masing-masing ada fungsi sendiri, ciri-ciri tersendiri. Terdapat pelbagai cara untuk mendapatkan metrik, KPI (penunjuk prestasi utama), yang menarik kepada anda apabila pelayan sedang dimuatkan.
Pengarang foto pada
(Saya harap papan pemuka saya berwarna biru neon - mengeluh termenung -... hmm...)
Mana-mana perisian yang menyediakan perkhidmatan mesti mempunyai mekanisme untuk mengumpul metrik. Apache mempunyai modul mod-status, memaparkan halaman status pelayan. Nginx mempunyai - stub_status. Tomcat mempunyai JMX atau aplikasi web tersuai yang menunjukkan metrik utama. MySQL mempunyai arahan "tunjukkan status global" dsb.
Jadi mengapa pembangun tidak membina mekanisme serupa ke dalam aplikasi yang mereka cipta?
Adakah hanya pemaju yang melakukan ini?
Tahap ketidakpedulian tertentu terhadap pembenaman metrik tidak terhad kepada pembangun. Saya bekerja di syarikat di mana mereka membangunkan aplikasi menggunakan Tomcat dan tidak menyediakan sebarang metrik mereka sendiri, tiada log aktiviti perkhidmatan, kecuali log ralat Tomcat am. Sesetengah pembangun menjana banyak log yang tidak bermakna kepada pentadbir sistem yang tidak bernasib baik untuk membacanya pada pukul 3:15 pagi.
Pengarang foto pada
Jurutera sistem yang membolehkan produk tersebut dikeluarkan juga mesti memikul sedikit tanggungjawab untuk situasi tersebut. Beberapa jurutera sistem mempunyai masa atau penjagaan untuk cuba mengekstrak metrik yang bermakna daripada log, tanpa konteks metrik tersebut dan keupayaan untuk mentafsirnya berdasarkan aktiviti aplikasi. Ada yang tidak memahami cara mereka boleh mendapat manfaat daripadanya, selain daripada penunjuk "sesuatu pada masa ini (atau akan menjadi) salah" tidak lama lagi.
Perubahan dalam pemikiran mengenai keperluan untuk metrik mesti berlaku bukan sahaja dalam kalangan pembangun, tetapi juga dalam kalangan jurutera sistem.
Bagi mana-mana jurutera sistem yang bukan sahaja perlu bertindak balas terhadap peristiwa kritikal, tetapi juga memastikan bahawa ia tidak berlaku, kekurangan metrik biasanya menjadi penghalang untuk berbuat demikian.
Walau bagaimanapun, jurutera sistem biasanya tidak bermain-main dengan kod untuk membuat wang bagi syarikat mereka. Mereka memerlukan pembangun utama yang memahami kepentingan tanggungjawab jurutera sistem dalam mengenal pasti masalah, meningkatkan kesedaran tentang isu prestasi dan sebagainya.
Ini memusnahkan perkara
Mentaliti devops menerangkan sinergi antara pemikiran pembangunan (dev) dan operasi (ops). Mana-mana syarikat yang mendakwa "melakukan devops" mesti:
- mengatakan perkara yang mereka mungkin tidak (merujuk kepada meme The Princess Bride - "Saya tidak fikir ia bermakna apa yang anda fikir maksudnya!")
- Galakkan sikap penambahbaikan produk yang berterusan.
Anda tidak boleh menambah baik produk dan mengetahui bahawa ia telah dipertingkatkan jika anda tidak tahu cara produk itu berfungsi pada masa ini. Anda tidak boleh mengetahui cara sesuatu produk berfungsi jika anda tidak memahami cara komponennya berfungsi, perkhidmatan yang bergantung kepada produk tersebut, titik kesakitan dan kesesakan utamanya.
Jika anda tidak melihat kemungkinan kesesakan, anda tidak akan dapat mengikuti teknik Five Whys semasa menulis Postmortem. Anda tidak akan dapat meletakkan segala-galanya pada satu skrin untuk melihat cara produk berfungsi atau mengetahui rupa produk itu "biasa dan gembira".
Shift kiri, KIRI, SAYA KATA LEEEEβ
Bagi saya, salah satu prinsip utama Devops ialah "anjakan ke kiri". Beralih ke kiri dalam konteks ini bermakna mengalihkan kemungkinan (tiada tanggungjawab, tetapi hanya keupayaan) untuk melakukan perkara yang biasanya diambil berat oleh jurutera sistem, seperti mencipta metrik prestasi, menggunakan log dengan lebih cekap, dsb., di sebelah kiri dalam Kitaran Hayat Penghantaran Perisian.
Pengarang foto pada
Pembangun perisian mesti boleh menggunakan dan mengetahui alat pemantauan yang digunakan oleh syarikat untuk menjalankan pemantauan dalam semua bentuk, metrik, pembalakan, antara muka pemantauan dan, yang paling penting, tonton bagaimana produk mereka berfungsi dalam pengeluaran. Anda tidak boleh meminta pembangun untuk melaburkan usaha dan masa dalam pemantauan sehingga mereka dapat melihat metrik dan mempengaruhi penampilan mereka, cara pemilik produk membentangkannya kepada CTO pada taklimat seterusnya, dsb.
Bercakap pendek
- Pimpin kuda anda ke air. Tunjukkan kepada pembangun betapa banyak masalah yang boleh mereka elakkan untuk diri mereka sendiri, bantu mereka mengenal pasti KPI dan metrik yang betul untuk aplikasi mereka supaya kurang jeritan daripada pemilik produk yang dijerit oleh CTO. Bawa mereka ke dalam cahaya, dengan lembut dan tenang. Jika itu tidak berjaya, sogok, ugut dan pujuk sama ada mereka atau pemilik produk untuk melaksanakan mendapatkan metrik ini daripada aplikasi secepat mungkin, dan kemudian lukis gambar rajah. Ini akan menjadi sukar kerana ia tidak akan dilihat sebagai keutamaan dan pelan hala tuju produk akan mempunyai banyak projek penjanaan hasil yang belum selesai. Oleh itu, anda memerlukan kes perniagaan untuk mewajarkan masa dan perbelanjaan yang dibelanjakan untuk melaksanakan pemantauan ke dalam produk.
- Bantu jurutera sistem mendapat tidur yang nyenyak. Tunjukkan kepada mereka bahawa menggunakan senarai semak "mari keluarkan" untuk mana-mana produk yang dikeluarkan adalah perkara yang baik. Dan memastikan semua aplikasi dalam pengeluaran diliputi dengan metrik akan membantu anda tidur lebih lena pada waktu malam dengan membenarkan pembangun melihat perkara yang tidak kena dan di mana. Walau bagaimanapun, cara yang betul untuk menjengkelkan dan mengecewakan mana-mana pembangun, pemilik produk atau CTO adalah dengan terus bertahan dan menentang. Tingkah laku ini akan memberi kesan kepada tarikh keluaran mana-mana produk jika anda menunggu sehingga saat akhir sekali lagi, jadi beralih ke kiri sekali lagi dan masukkan isu ini ke dalam rancangan projek anda secepat mungkin. Jika perlu, pergi ke mesyuarat produk. Pakai misai palsu dan felt atau sesuatu, ia tidak akan gagal. Sampaikan kebimbangan anda, tunjukkan faedah yang jelas, dan menginjil.
- Pastikan kedua-dua pembangunan (dev) dan operasi (ops) memahami maksud dan akibat metrik produk yang bergerak ke zon merah. Jangan biarkan Ops sebagai penjaga tunggal kesihatan produk, pastikan pembangun turut terlibat (#productsquads).
- Log adalah perkara yang hebat, tetapi begitu juga metrik. Gabungkan mereka dan jangan biarkan kayu balak anda menjadi sampah dalam bola besar yang tidak berguna. Terangkan dan tunjukkan kepada pembangun mengapa tiada orang lain akan memahami log mereka, tunjukkan kepada mereka bagaimana rasanya melihat log tidak berguna pada pukul 3:15 pagi.
Pengarang foto pada
Itu sahaja. Bahan baru akan dikeluarkan minggu hadapan. Jika anda ingin mengetahui lebih lanjut tentang kursus, kami menjemput anda untuk , yang akan berlangsung pada hari Isnin. Dan kini kami secara tradisinya menunggu komen anda.
Sumber: www.habr.com