David O'Brien baru-baru ini meluncurkan perusahaannya sendiri, Xirus (https://xirus.com.au), dengan fokus pada produk cloud Microsoft Azure Stack. Mereka dirancang untuk secara konsisten membangun dan menjalankan aplikasi hybrid di pusat data, lokasi edge, kantor jarak jauh, dan cloud.
David melatih individu dan perusahaan tentang segala hal tentang Microsoft Azure dan Azure DevOps (sebelumnya VSTS) dan masih melakukan konsultasi langsung dan infracoding. Dia telah menjadi pemenang Penghargaan Microsoft MVP (Microsoft Most Valuable Professional) selama 5 tahun dan baru-baru ini menerima Penghargaan Azure MVP. Sebagai salah satu penyelenggara Melbourne Microsoft Cloud dan Datacentre Meetup, O'Brien secara rutin menjadi pembicara di konferensi internasional, menggabungkan minatnya untuk berkeliling dunia dengan hasrat untuk berbagi kisah TI dengan komunitas. Blog David terletak di , dia juga menerbitkan pelatihan online-nya di Pluralsight.
Pembicaraan tersebut membahas tentang pentingnya metrik dalam memahami apa yang terjadi di lingkungan Anda dan bagaimana kinerja aplikasi Anda. Microsoft Azure memiliki cara yang ampuh dan mudah untuk menampilkan metrik untuk semua jenis beban kerja, dan kuliah ini menjelaskan bagaimana Anda dapat menggunakan semuanya.
Pada jam 3 pagi di hari Minggu, saat Anda sedang tidur, Anda tiba-tiba dibangunkan oleh pesan teks: βaplikasi superkritis tidak merespons lagi.β Apa yang sedang terjadi? Di mana dan apa alasan βremβ? Dalam pembicaraan ini, Anda akan mempelajari tentang layanan yang ditawarkan Microsoft Azure kepada pelanggan untuk mengumpulkan log dan, khususnya, metrik dari beban kerja cloud Anda. David akan memberi tahu Anda metrik apa yang harus Anda minati saat bekerja di platform cloud dan cara mencapainya. Anda akan belajar tentang alat sumber terbuka dan pembuatan dasbor, dan mendapatkan pengetahuan yang cukup untuk membuat dasbor Anda sendiri.
Dan jika Anda terbangun lagi pada jam 3 pagi karena pesan bahwa aplikasi penting mogok, Anda dapat dengan cepat mengetahui penyebabnya.
Selamat siang, hari ini kita akan membahas tentang metrik. Nama saya David O'Brien, saya adalah salah satu pendiri dan pemilik perusahaan konsultan kecil Australia, Xirus. Sekali lagi terima kasih telah datang ke sini untuk menghabiskan waktu Anda bersama saya. Jadi mengapa kita ada di sini? Untuk berbicara tentang metrik, atau lebih tepatnya, saya akan memberi tahu Anda tentang metrik, dan sebelum melakukan apa pun, mari kita mulai dengan teorinya.
Saya akan memberi tahu Anda apa itu metrik, apa yang dapat Anda lakukan dengannya, apa yang perlu Anda perhatikan, cara mengumpulkan dan mengaktifkan pengumpulan metrik di Azure, dan apa itu visualisasi metrik. Saya akan menunjukkan kepada Anda seperti apa tampilannya di cloud Microsoft dan cara bekerja dengan cloud ini.
Sebelum kita mulai, saya akan meminta angkat tangan dari mereka yang menggunakan Microsoft Azure. Siapa yang bekerja dengan AWS? Saya melihat sedikit. Bagaimana dengan Google? ALI Awan? Satu orang! Besar. Jadi apa itu metrik? Definisi resmi Institut Standar dan Teknologi Nasional AS adalah: βMetrik adalah standar pengukuran yang menggambarkan kondisi dan aturan pengukuran suatu properti dan berfungsi untuk memahami hasil pengukuran.β Apa artinya?
Mari kita ambil contoh metrik untuk mengubah ruang disk kosong mesin virtual. Misalnya kita diberi angka 90, dan angka ini berarti persentase, yaitu jumlah ruang disk kosong adalah 90%. Saya perhatikan bahwa tidak terlalu menarik untuk membaca deskripsi definisi metrik, yang memakan waktu 40 halaman dalam format pdf.
Namun metrik tidak menyebutkan bagaimana hasil pengukuran diperoleh, hanya menampilkan hasil ini. Apa yang kita lakukan dengan metrik?
Pertama kita mengukur nilai sesuatu untuk kemudian digunakan hasil pengukurannya.
Misalnya, kami mengetahui jumlah ruang disk kosong dan sekarang kami dapat menggunakannya, menggunakan memori ini, dll. Setelah kami menerima hasil metrik, kami harus menafsirkannya. Misalnya, metrik mengembalikan hasil 90. Kita perlu mengetahui arti angka ini: jumlah ruang kosong atau jumlah ruang disk yang digunakan dalam persen atau gigabyte, latensi jaringan sama dengan 90 ms, dan seterusnya, yaitu , kita perlu menafsirkan arti dari nilai metrik. Agar metrik menjadi bermakna, setelah menafsirkan satu nilai metrik, kita perlu memastikan bahwa beberapa nilai dikumpulkan. Hal ini sangat penting karena banyak orang tidak menyadari perlunya mengumpulkan metrik. Microsoft telah mempermudah pengumpulan metrik, namun terserah Anda untuk memastikan metrik dikumpulkan. Metrik ini hanya disimpan selama 41 hari dan hilang pada hari ke-42. Oleh karena itu, bergantung pada properti peralatan eksternal atau internal Anda, Anda harus memperhatikan cara menyimpan metrik selama lebih dari 41 hari - dalam bentuk log, log, dll. Jadi, setelah pengumpulan, Anda harus menempatkannya di tempat yang memungkinkan Anda mengambil semua statistik perubahan hasil metrik jika perlu. Setelah Anda meletakkannya di sana, Anda dapat mulai mengerjakannya secara efektif.
Hanya setelah Anda mendapatkan metrik, menafsirkannya, dan mengumpulkannya, Anda dapat membuat perjanjian tingkat layanan SLA. SLA ini mungkin tidak terlalu penting bagi pelanggan Anda; ini lebih penting bagi kolega Anda, manajer, mereka yang memelihara sistem dan peduli dengan fungsinya. Metrik ini dapat mengukur jumlah tiket - misalnya, Anda menerima 5 tiket per hari, dan dalam hal ini metrik menunjukkan kecepatan respons terhadap permintaan pengguna dan kecepatan pemecahan masalah. Metrik tidak boleh hanya menyatakan bahwa situs Anda dimuat dalam 20 md atau kecepatan respons Anda adalah 20 md, metrik lebih dari sekadar satu indikator teknis.
Oleh karena itu, tugas percakapan kita adalah memberi Anda gambaran mendetail tentang esensi metrik. Metrik berfungsi agar dengan melihatnya Anda bisa mendapatkan gambaran lengkap tentang prosesnya.
Setelah kami memiliki metriknya, kami dapat menjamin 99% bahwa sistem berfungsi, karena tidak hanya melihat file log yang menyatakan bahwa sistem berfungsi. Jaminan uptime 99% berarti, misalnya, 99% waktu API merespons pada kecepatan normal 30 ms. Inilah yang menarik minat pengguna, kolega, dan manajer Anda. Banyak klien kami memantau log server web, tetapi mereka tidak melihat adanya kesalahan di dalamnya dan berpikir bahwa semuanya baik-baik saja. Misalnya, mereka melihat kecepatan jaringan 200 Mb/s dan berpikir: βoke, semuanya bagus!β Namun untuk mencapai 200 tersebut, pengguna memerlukan kecepatan respons 30 milidetik, dan ini justru merupakan indikator yang tidak diukur dan tidak dikumpulkan dalam file log. Pada saat yang sama, pengguna terkejut bahwa situs dimuat dengan sangat lambat, karena, karena tidak memiliki metrik yang diperlukan, mereka tidak mengetahui alasan perilaku ini.
Namun karena kami memiliki SLA uptime 100%, pelanggan mulai mengeluh karena situs ini sebenarnya sangat sulit untuk digunakan. Oleh karena itu, untuk membuat SLA yang obyektif, perlu melihat gambaran lengkap tentang proses yang dibuat oleh metrik yang dikumpulkan. Ini adalah masalah berkelanjutan yang saya hadapi dengan beberapa penyedia yang, ketika membuat SLA, tidak tahu apa arti istilah βuptimeβ dan dalam banyak kasus tidak menjelaskan kepada klien mereka cara kerja API mereka.
Jika Anda membuat layanan, misalnya, API untuk orang ketiga, Anda harus memahami arti dari metrik yang dihasilkan sebesar 39,5 - respons, respons berhasil, respons pada kecepatan 20 mdtk atau pada kecepatan 5 mdtk. Anda bebas menyesuaikan SLA mereka dengan SLA Anda sendiri, dengan metrik Anda sendiri.
Setelah Anda mengetahui semua ini, Anda dapat mulai membuat dasbor yang menakjubkan. Beritahu saya, apakah ada yang sudah menggunakan aplikasi visualisasi interaktif Grafana? Besar! Saya penggemar berat open source ini karena gratis dan mudah digunakan.
Jika Anda belum pernah menggunakan Grafana, saya akan memberi tahu Anda cara menggunakannya. Siapa pun yang lahir di tahun 80an dan 90an mungkin ingat CareBears? Saya tidak tahu seberapa populer beruang-beruang ini di Rusia, tetapi jika menyangkut metrik, kita harus menjadi βberuang perawatanβ yang sama. Seperti yang saya katakan, Anda memerlukan gambaran besar tentang cara kerja keseluruhan sistem, dan itu tidak hanya tentang API Anda, situs web Anda, atau layanan yang berjalan di mesin virtual.
Anda harus mengatur kumpulan metrik yang paling mencerminkan pengoperasian keseluruhan sistem. Sebagian besar dari Anda adalah pengembang perangkat lunak, jadi hidup Anda terus berubah, beradaptasi dengan persyaratan produk baru, dan sama seperti Anda memikirkan proses pengkodean, Anda juga harus memperhatikan metrik. Anda perlu mengetahui bagaimana metrik berhubungan dengan setiap baris kode yang Anda tulis. Misalnya, minggu depan Anda memulai kampanye pemasaran baru dan mengharapkan banyak pengguna mengunjungi situs Anda. Untuk menganalisis peristiwa ini, Anda memerlukan metrik, dan Anda mungkin memerlukan seluruh dasbor untuk melacak aktivitas orang-orang ini. Anda memerlukan metrik untuk memahami seberapa sukses kampanye pemasaran Anda dan bagaimana kinerjanya sebenarnya. Mereka akan membantu Anda, misalnya, mengembangkan CRM - sistem manajemen hubungan pelanggan yang efektif.
Jadi mari kita mulai dengan layanan cloud Azure kami. Sangat mudah untuk menemukan dan mengatur pengumpulan metrik karena memiliki Azure Monitor. Monitor ini memusatkan manajemen konfigurasi sistem Anda. Setiap elemen Azure yang ingin Anda terapkan ke sistem Anda memiliki banyak metrik yang diaktifkan secara default. Ini adalah aplikasi gratis yang langsung berfungsi dan tidak memerlukan pengaturan awal apa pun; Anda tidak perlu menulis atau "menyekrup" apa pun ke sistem Anda. Kami akan memverifikasi ini dengan melihat demo berikut.
Selain itu, metrik ini dapat dikirim ke aplikasi pihak ketiga, seperti sistem penyimpanan dan analisis log Splunk, aplikasi manajemen log berbasis cloud SumoLogic, alat pemrosesan log ELK, dan IBM Radar. Benar, ada sedikit perbedaan yang bergantung pada sumber daya yang Anda gunakan - mesin virtual, layanan jaringan, database Azure SQL, yaitu penggunaan metrik berbeda-beda bergantung pada fungsi lingkungan kerja Anda. Saya tidak akan mengatakan bahwa perbedaan-perbedaan ini serius, namun sayangnya, perbedaan-perbedaan tersebut masih ada, dan hal ini harus diperhitungkan. Mengaktifkan dan mengirim metrik dapat dilakukan dengan beberapa cara: melalui Portal, CLI/Power Shell, atau menggunakan templat ARM.
Sebelum saya memulai demo pertama saya, saya akan menjawab pertanyaan apa pun yang Anda miliki. Jika tidak ada pertanyaan, mari kita mulai. Layar memperlihatkan seperti apa halaman Azure Monitor. Adakah di antara Anda yang mengatakan bahwa monitor ini tidak berfungsi?
Jadi sekarang semuanya baik-baik saja, Anda bisa melihat seperti apa layanan monitornya. Saya dapat mengatakan bahwa ini adalah alat yang luar biasa dan sangat sederhana untuk pekerjaan sehari-hari. Ini dapat digunakan untuk memantau aplikasi, jaringan, dan infrastruktur. Baru-baru ini, antarmuka pemantauan telah ditingkatkan, dan jika sebelumnya layanan berlokasi di tempat yang berbeda, kini semua informasi tentang layanan digabungkan di halaman beranda monitor.
Tabel metrik adalah tab di sepanjang jalur HomeMonitorMetrics, yang dapat Anda buka untuk melihat semua metrik yang tersedia dan memilih metrik yang Anda perlukan. Namun jika Anda perlu mengaktifkan pengumpulan metrik, Anda perlu menggunakan jalur direktori pengaturan HomeMonitorDiagnostic dan mencentang kotak metrik Diaktifkan/Dinonaktifkan. Secara default, hampir semua metrik diaktifkan, namun jika Anda perlu mengaktifkan sesuatu yang tambahan, Anda perlu mengubah status diagnostik dari Dinonaktifkan menjadi Diaktifkan.
Untuk melakukan ini, klik pada baris metrik yang dipilih dan pada tab yang terbuka, aktifkan mode diagnostik. Jika Anda akan menganalisis metrik yang dipilih, maka setelah mengklik tautan Aktifkan diagnostik, Anda perlu mencentang kotak Kirim ke Log Analytics di jendela yang muncul.
Log Analytics sedikit mirip dengan Splunk, tetapi biayanya lebih murah. Layanan ini memungkinkan Anda mengumpulkan semua metrik, log, dan semua hal lain yang Anda butuhkan dan menempatkannya di ruang kerja Log Analytics. Layanan ini menggunakan bahasa pemrosesan kueri KQL khusus - Bahasa Kusto Quarry, kita akan melihat cara kerjanya di demo berikutnya. Untuk saat ini, saya perhatikan bahwa dengan bantuannya Anda dapat membuat kueri mengenai metrik, log, istilah, tren, pola, dll. dan membuat dasbor.
Jadi, kami mencentang kotak Kirim ke Log Analytics dan kotak centang panel LOG: DataPlaneRequests, MongoRequests dan QueryRuntimeStatistics, dan di bawah panel METRIC β kotak centang Permintaan. Kemudian kami menetapkan nama dan menyimpan pengaturannya. Pada baris perintah, ini mewakili dua baris kode. Omong-omong, shell Azure Cloud dalam hal ini mirip dengan Google, yang juga memungkinkan Anda menggunakan baris perintah di browser web Anda. AWS tidak memiliki hal seperti itu, jadi Azure jauh lebih nyaman dalam hal ini.
Misalnya, saya dapat menjalankan demo melalui antarmuka web tanpa menggunakan kode apa pun di laptop saya. Untuk melakukan ini, saya harus mengautentikasi dengan akun Azure saya. Kemudian Anda dapat menggunakan, misalnya, terrafon, jika Anda sudah menggunakannya, tunggu koneksi ke layanan dan dapatkan lingkungan kerja Linux yang digunakan Microsoft secara default.
Selanjutnya, saya menggunakan Bash, yang dibangun di Azure Cloud Shell. Hal yang sangat berguna adalah IDE yang terpasang di browser, versi ringan dari VS Code. Selanjutnya, saya dapat masuk ke template metrik kesalahan, mengeditnya, dan menyesuaikannya agar sesuai dengan kebutuhan saya.
Setelah menyiapkan pengumpulan metrik di templat ini, Anda dapat menggunakannya untuk membuat metrik untuk seluruh infrastruktur Anda. Setelah kita menerapkan metrik, mengumpulkannya, dan menyimpannya, kita perlu memvisualisasikannya.
Azure Monitor hanya menangani metrik dan tidak memberikan gambaran keseluruhan tentang kesehatan sistem Anda. Anda mungkin memiliki sejumlah aplikasi lain yang berjalan di luar lingkungan Azure. Jadi jika Anda perlu memantau semua proses, memvisualisasikan semua metrik yang dikumpulkan di satu tempat, Azure Monitor tidak cocok untuk ini.
Untuk mengatasi masalah ini, Microsoft menawarkan alat Power BI, perangkat lunak komprehensif untuk analisis bisnis yang mencakup visualisasi berbagai macam data. Ini adalah produk yang cukup mahal, yang biayanya tergantung pada serangkaian fungsi yang Anda perlukan. Secara default, ini menawarkan 48 jenis data untuk diproses dan ditautkan ke Azure SQL Data Warehouses, Azure Data Lake Storage, Azure Machine Learning Services, dan Azure Databricks. Dengan menggunakan skalabilitas, Anda dapat menerima data baru setiap 30 menit. Ini mungkin cukup atau mungkin tidak cukup untuk kebutuhan Anda jika Anda memerlukan visualisasi pemantauan waktu nyata. Dalam hal ini disarankan menggunakan aplikasi seperti Grafana yang saya sebutkan. Selain itu, dokumentasi Microsoft menjelaskan kemampuan untuk mengirim metrik, log, dan tabel peristiwa menggunakan alat SIEM ke sistem visualisasi radar Splunk, SumoLogic, ELK, dan IBM.
23:40 menit
Akan segera dilanjutkan...
Beberapa iklan π
Terima kasih untuk tetap bersama kami. Apakah Anda menyukai artikel kami? Ingin melihat konten yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman, , analog unik dari server level awal, yang kami temukan untuk Anda: (tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2x lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai $99! Membaca tentang
Sumber: www.habr.com