David O'Brien (Xirus): Metrik! Metrik! Metrik! Bagian 2

David O'Brien baru-baru ini membuka perusahaannya sendiri, Xirus (https://xirus.com.au), dengan fokus pada produk cloud Microsoft Azure Stack. Mereka dimaksudkan untuk pembuatan terkoordinasi dan peluncuran aplikasi hybrid di pusat data, di lokasi perbatasan, kantor jauh dan cloud.

David mengajarkan individu dan perusahaan segala sesuatu yang berkaitan dengan Microsoft Azure dan Azure DevOps (sebelumnya VSTS) dan masih terlibat dalam konsultasi praktis dan infra-coding. Dia telah menjadi pemenang Microsoft MVP Award (Microsoft Most Valuable Professional) selama 5 tahun, dan baru-baru ini menerima MVP Azure Award. Sebagai co-organizer Melbourne Microsoft Cloud dan Datacentre Meetup, O'Brien secara teratur berbicara di konferensi internasional, memadukan minatnya dalam perjalanan dunia dengan hasrat untuk berbagi kisah-kisah TI dengan masyarakat. Blog David terletak di david-obrien.net , dan ia juga menerbitkan pelatihan Pluralsight online-nya.

Presentasi berbicara tentang pentingnya metrik untuk memahami apa yang terjadi di lingkungan Anda dan cara kerja aplikasi Anda. Microsoft Azure memiliki cara yang ampuh dan mudah untuk menampilkan metrik untuk semua jenis beban kerja, dan ceramah memberi tahu bagaimana Anda dapat menggunakannya semua.

Pada jam 3 pagi, Minggu, saat tidur, Anda tiba-tiba bangun dengan pesan teks: "Aplikasi superkritis tidak merespons lagi". Apa yang sedang terjadi? Di mana dan apa penyebab "rem"? Dalam pembicaraan ini, Anda akan belajar tentang layanan yang ditawarkan Microsoft Azure kepada pelanggan untuk mengumpulkan log dan, khususnya, metrik untuk beban kerja cloud Anda. David akan memberi tahu Anda metrik mana yang menarik minat Anda saat bekerja di platform cloud dan bagaimana mencapainya. Anda akan belajar tentang alat sumber terbuka dan membuat dasbor, dan sebagai hasilnya, Anda akan memperoleh pengetahuan yang cukup untuk membuat dasbor Anda sendiri.

Dan jika pada jam 3 pagi Anda kembali membangunkan pesan tentang jatuhnya aplikasi penting, Anda dapat dengan cepat mengetahui penyebabnya.

David O'Brien (Xirus): Metrik! Metrik! Metrik! Bagian 1

Karena slide akan terlalu tebal, saya lebih suka demo. Pertimbangkan bagaimana Anda dapat memvisualisasikan pemantauan, dan mulai dengan tab Monitor-Metrik. Seperti yang saya sebutkan, ini cukup mudah. Yang perlu Anda lakukan adalah menentukan sumber daya yang digunakan di menu turun bawah grup sumber daya dan jenis sumber daya di menu tipe sumber daya. Dalam kasus kami, saya memilih semua 72 jenis metrik.



Untungnya atau sayangnya, sebagian besar layanan cloud berjalan di mesin virtual, dan saya melakukan hal yang sama. Di mesin virtual ini, secara default, Microsoft menunjukkan kepada kami metrik host. Secara khusus, kita dapat melihat jumlah lalu lintas yang melewati VM ini selama 24 jam terakhir dengan interval pengukuran 15 menit. Anda tahu bahwa kami memiliki dasbor yang bagus untuk metrik ini. Ini bukan metrik yang sangat canggih, dan kami tidak dapat melakukan apa pun dengannya, kecuali untuk melihat jumlah lalu lintas keluar dalam megabita. Alat di sini adalah: kemampuan untuk menambahkan aturan baru tentang batasan dan kemampuan untuk melampirkan metrik ini ke dasbor.
Mereka yang menggunakan mesin virtual harus tahu apa itu Telegraf, yang ditunjukkan pada baris RESORCE. Ini adalah plugin TING open source yang ditulis dalam Go, yang dirancang untuk mengumpulkan metrik atau data dari sistem di mana ia diinstal. Telegraf meneruskan metrik yang dikumpulkan ke basis data InfluxDB. Plugin lintas platform ini berfungsi pada Windows dan Linux.



Seperti yang saya katakan, secara default, Microsoft Azure Monitor menggunakan metrik hypervisor untuk mesin virtual, ini ditunjukkan pada baris METRIC NAMESPACE. Demikian pula yang terjadi di AWS. Saya tidak bisa mengatakan apa-apa tentang platform cloud GSP, karena saya belum pernah menggunakannya. Jadi, saya memilih Telegraf sebagai sumber daya dan menginstruksikannya untuk mentransfer metrik ini ke monitor Sum.



Saya dapat pergi ke daftar METRIC dan memilih lebih banyak metrik yang ditampilkan. Sebagai contoh, sekarang saya memilih metrik use_steal (menggunakan intersepsi). Adakah yang tahu apa itu?



Berapa banyak dari Anda yang tinggal di apartemen dengan tetangga yang suka mendengarkan musik dengan sangat keras? Oke, jadi use_steal adalah metrik yang menunjukkan bagaimana tetangga cloud dapat memengaruhi sistem operasi Anda. Banyak orang lupa bahwa mereka menjalankan aplikasi mereka di lingkungan cloud publik. Baik di GCP, AWS, dan Azure, penyedia menempatkan Anda di infrastruktur bersama. Anda berbagi infrastruktur Anda - mesin virtual, aplikasi, API - dengan pengguna lain. Ini tidak berarti bahwa mereka memiliki akses ke data Anda, tetapi mereka dapat mempengaruhi aplikasi Anda, dan Anda harus mengetahui hal ini. Jika Anda tidak tahu tentang efek ini, maka aplikasi Anda mungkin mengalami kesulitan dalam bekerja. Jika Anda tidak mengumpulkan metrik use_steal, Anda tidak akan tahu bahwa aplikasi Anda mungkin terpengaruh oleh dampak yang berbeda. SeharusnyaAnda meluncurkan program, semuanya berfungsi dengan baik, tanpa kesalahan, tetapi tiba-tiba sesuatu terjadi, dan aplikasi macet. Ini cukup sering terjadi dan tergantung pada jenis mesin virtual apa yang Anda gunakan, dan berapa banyak VM dengan jenis yang sama yang ditempatkan penyedia Anda di setiap host. Kemungkinan program Anda akan terkena dampak buruk dari infrastruktur ini.

Satu-satunya cara untuk mencegah hal ini terjadi adalah dalam dua cara: yang pertama adalah menunggu sampai semuanya berjalan dengan sendirinya, dan yang kedua adalah menggunakan mesin virtual Anda pada sejumlah hypervisor lain. Namun, untuk membuat keputusan, Anda harus mengetahui hal ini dengan mengumpulkan metrik yang sesuai. Seperti yang Anda lihat, ketika menggunakan metrik use_steal, monitor tidak menunjukkan aktivitas apa pun, mungkin karena saya tidak menjalankan sejumlah besar aplikasi.

Jadi, kita dapat membuat dasbor sendiri dengan menempatkan monitor metrik yang dipilih di atasnya. Panel ini dapat dibagikan dengan pengguna lain, dan saya biasanya menyarankan klien saya untuk membuat panel seperti ini, menempatkannya di layar besar di kantor sehingga dapat dilihat oleh semua karyawan.



Setiap pagi, datang bekerja, siapa pun dapat melihat layar seperti itu dan mencari tahu apa yang terjadi dengan sistem. Misalnya, Anda dapat melihat bahwa 500 kesalahan koneksi HTTP telah diperbaiki dan tidak menunggu klien memberi tahu Anda tentang hal ini, tetapi cari tahu alasan terjadinya mereka dan perbaiki masalah dengan situs Anda.

Pemantauan yang lebih maju adalah mengumpulkan persentil. Misalnya, mengetahui kinerja rata-rata CPU Anda mungkin tidak cukup, karena aplikasi yang berbeda memuat prosesor secara berbeda.



Persentil memberi Anda pemahaman tentang apa yang terjadi secara global. Misalkan 99 persentil adalah 200 ms. Ini berarti bahwa 99% dari semua permintaan Anda memiliki waktu respons hingga 200 ms, dan ini juga berarti bahwa 1% pelanggan Anda menerima respons dengan penundaan melebihi 200 ms.

Bergantung pada konten SLA Anda, ingat apa yang kami bicarakan di awal, Anda harus mempertimbangkan fakta ini. Bahkan, paling sering Anda memperhatikan nilai rata-rata, alih-alih memperhitungkan persentil akun. Dan nilai rata-rata “menyembunyikan” penyimpangan semacam itu sendiri.

Pertimbangkan bagaimana kita mendapatkan nilai-nilai ini. Faktanya adalah Azure Monitor tidak menghitung apa pun. Anda bisa mendapatkan nilai rata-rata, maksimum atau minimum, tetapi jika Anda membutuhkan metrik lebih lanjut yang diperoleh sebagai hasil perhitungan, Anda harus menggunakan analisis log. Analisis log menggunakan bahasa KQL, ini adalah fitur yang sangat berguna dari Azure "di luar kotak."



Jika Anda melihat metrik ini, Anda dapat melihat bahwa penyedia sumber daya adalah Microsoft.SQL, itu sendiri disebut "dtu_consumption_percent" dan terlibat dalam pembuatan persentil. Ini mungkin tidak berlaku untuk alur kerja Anda, tetapi Anda harus tahu bahwa modul Log Analytics menyediakan kemampuan ini. Jadi, Anda dapat menggunakan analitik jika Anda membutuhkan perhitungan metrik lebih lanjut. Benar, Anda harus membayarnya. Secara default, alat ini memungkinkan Anda untuk memproses data hingga 5 GB per bulan secara gratis, namun, saya tahu klien yang menggunakan 5 GB per menit. Jadi 5 GB per bulan mungkin tidak cukup.

Di layar Anda melihat metrik yang menunjukkan bahwa saya saat ini menggunakan 20 MB. Karena ini adalah lingkungan demo, jumlah data yang diperoleh sangat kecil. Seperti yang saya katakan, langsung dari kotak, Logs Analytic memungkinkan Anda untuk memproses hingga 5 GB data per bulan secara gratis, menyimpannya selama 41 hari. Perlu membayar melebihi volume ini, namun, dalam pengalaman saya, layanan ini masih lebih murah daripada produk pihak ketiga yang serupa, seperti Splunk atau Sumo.

Mari beralih ke Grafana, yang memiliki plugin untuk Azure Monitor. Ini dirilis beberapa minggu lalu dalam versi 0.2. Berkat plugin ini, Anda dapat menggunakan Grafana untuk metrik Anda. Saya lebih suka menggunakan Grafana di Layanan Aplikasi, karena dimungkinkan untuk menggunakan kontainer di sini. Ini memungkinkan saya untuk menjalankan aplikasi di laptop. Untuk melakukan ini, saya menjalankan baris perintah ini:



setelah itu saya dapat dengan cepat menguji sesuatu atau menunjukkan sesuatu kepada klien saya.
Menyebarkan Grafana di lingkungan Azure juga membutuhkan satu baris, saya hanya membaginya menjadi 4 sehingga saya bisa melihatnya di satu layar.



Azure memiliki apa yang disebut "struktur wadah" seperti AWS, setara dengan struktur Google serupa. Ini adalah salah satu gambar kontainer yang dapat didistribusikan di beberapa kontainer. Tim yang saya soroti meluncurkan Grafana bersamaan dengan Azure Monitor. Menyebarkan Grafana di lingkungan monitor membutuhkan waktu sekitar 30 detik.



Saya dapat melakukan hal yang sama melalui kode infrastruktur:



Detail dapat ditemukan di Twitter saya, nanti saya akan memberikan kontak saya. File dengan ekstensi .yaml menunjukkan cara menggunakan gambar kontainer dan apa yang harus dilakukan dengannya. Ada banyak baris kode di sini, dan saya perlu menggulirkan jendela ke bawah sehingga Anda dapat melihatnya. File ini digunakan oleh Grafana di platform Azure.





Jadi, saya pergi ke Grafana di laptop saya dan menunjukkan dashboard yang saya buat. Satu hal yang masih belum bisa saya lakukan adalah memberikan metrik Telegraf ke Grafana. Sayangnya, metrik berguna ini yang dijalankan di mesin virtual belum ditampilkan di Grafana. Microsoft sedang memecahkan masalah ini, dan kami mungkin akan melihat hasilnya dalam versi baru Telegraf dan Grafana. Untuk saat ini, kita dapat menggunakan metrik hypervisor yang ditawarkan Telegraf secara default di menu tarik-turun dari garis Metrik. Di mesin virtual, dimungkinkan untuk membuat berbagai metrik khusus yang tidak dimiliki Grafana, lalu menempelkannya ke dalam aplikasi ini. Ini dapat dilakukan jika metrik khusus dapat ditempatkan di rangkaian metrik Azure.





Pelanggan sering bertanya kepada saya apa yang harus mereka gunakan? Grafana secara visual menampilkan metrik dari berbagai proses, dan Azure memungkinkan Anda melakukan perhitungan metrik yang lebih kompleks. Dalam kasus terakhir, Anda mendapatkan satu set metrik besar "di luar kotak," tetapi Azure hanya menampilkan metrik Azure. Jadi, pilihannya tergantung pada tugas yang Anda lakukan. Anda dapat membuat metrik untuk situs Anda, untuk database, untuk aplikasi yang dapat digunakan, mengintegrasikannya ke dalam Grafana dan membuat satu panel informatif yang banyak. Sayangnya, Anda tidak akan dapat melakukan ini dengan Azure, dan saya tidak berpikir bahwa Microsoft bermaksud untuk memperluas fungsionalitas Azure sedemikian rupa.

Namun, saya sarankan Anda mulai membuat dasbor khusus dengan Azure, karena hari ini, bekerja dengan sejumlah kecil aplikasi, Anda sudah dapat bekerja dengan metrik Azure, yang lebih baik daripada tidak melakukan apa-apa sama sekali.

Jadi, kenalan kami dengan metrik Monitor Azure mendekati akhir, dan saya ingin menceritakan tentang diri saya. Nama saya David O'Brien, dan status saya sebagai Microsoft MVP mengatakan bahwa saya menghabiskan banyak waktu berbicara tentang Azure dan pelatihan dalam bekerja dengan layanan ini.



Saya memiliki perusahaan sendiri, kami menyelenggarakan kursus pelatihan di seluruh dunia, berbicara tentang berbagai produk Microsoft, termasuk layanan cloud. Anda melihat kontak saya di Twitter, di mana saya sangat aktif dengan blogging. Anda tidak perlu memotret slide ini, hanya ingat alamat situs web Xirus. Anda dapat mengajukan pertanyaan Anda!

Pertanyaan: Metrik sangat penting, tetapi apa yang dapat Anda katakan tentang manajemen log?

Jawab: pada prinsipnya, mengelola log di Azure mirip dengan mengelola metrik. Anda juga dapat menempatkannya di repositori, lalu mengirimkannya ke Log Analytics dan kemudian menggunakan aplikasi ini untuk memproses log dengan cara yang sama seperti metrik. Anda dapat mengumpulkan kayu dan menyimpannya di luar mesin, menempatkannya dalam wadah dan kemudian menempatkannya secara terpusat di tempat yang tepat.

Pertanyaan: dapatkah ini dilakukan secara otomatis atau terprogram?

Jawab: dengan cara apa pun. Mari kita kembali ke Azure Cloud Shell - Anda melihat bahwa di sini di bagian metrik ada layanan yang dapat menyajikan metrik sebagai log. Misalnya, saya dapat membuat templat kesalahan dan memberi tahu layanan ini: "silakan kirim log ini di sini". Selama demo ini, saya menunjukkan kepada Anda opsi sederhana untuk bekerja dengan Azure, namun, dalam kondisi dunia nyata, silakan gunakan template ini. Anda dapat menggunakan metode ini melalui antarmuka baris perintah CLI atau dengan cara lain yang nyaman. Jika Anda tidak ingin menulis templat dan JSON, Anda dapat menggunakan mesin terbuka untuk menulis templat HTTL, Microsoft mengizinkan ini.



Tidak ada pertanyaan lagi? Terima kasih telah menghabiskan waktu bersama saya!

Sedikit iklan :)

Terima kasih untuk tetap bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman Anda, cloud VPS untuk pengembang dari $ 4,99 , analog unik dari server entry-level yang diciptakan oleh kami untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps mulai dari $ 19 atau cara membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya kami yang memiliki 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV dari $ 199 di Belanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai dari $ 99! Baca tentang Cara Membangun Infrastruktur Bldg. kelas c menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?