Agregasi dan tampilan metrik Azure Monitor dijelaskan
Artikel ini menjelaskan agregasi metrik dalam database seri waktu Azure Monitor yang mendukung metrik platform Azure Monitor dan metrik kustom. Artikel ini juga berlaku untuk metrik Application Insights standar.
Ini adalah topik yang kompleks dan tidak perlu memahami semua informasi dalam artikel ini untuk menggunakan metrik Azure Monitor secara efektif.
Ringkasan dan istilah
Saat Anda menambahkan metrik ke bagan, penjelajah metrik secara otomatis memilih agregasi defaultnya. Defaultnya masuk akal dalam skenario dasar, tetapi Anda dapat menggunakan agregasi yang berbeda untuk mendapatkan lebih banyak wawasan tentang metrik. Menampilkan agregasi berbeda pada bagan mengharuskan Anda memahami cara penjelajah metrik menanganinya.
Mari kita mendefinisikan beberapa istilah dengan jelas terlebih dahulu:
- Nilai metrik – Nilai pengukuran tunggal yang dikumpulkan untuk sumber daya tertentu.
- Database Rangkaian Waktu – Database yang dioptimalkan untuk penyimpanan dan pengambilan titik data yang semuanya berisi nilai dan stempel waktu terkait.
- Periode waktu – Periode waktu generik.
- Interval waktu – Periode waktu antara pengumpulan dua nilai metrik.
- Rentang waktu – Periode waktu yang ditampilkan pada bagan. Defaultnya adalah 24 jam. Hanya rentang tertentu yang tersedia.
- Granularitas waktu atau butir waktu – Periode waktu yang digunakan untuk mengagregasi nilai bersama-sama untuk memungkinkan tampilan pada bagan. Hanya rentang tertentu yang tersedia. Minimum saat ini adalah 1 menit. Nilai granularitas waktu harus lebih kecil dari rentang waktu yang dipilih agar berguna, jika tidak, hanya satu nilai yang ditampilkan untuk seluruh bagan.
- Tipe agregasi – Tipe statistik yang dihitung dari beberapa nilai metrik.
- Agregat – Proses mengambil beberapa nilai input dan kemudian menggunakannya untuk menghasilkan satu nilai output melalui aturan yang ditentukan oleh jenis agregasi. Misalnya, mengambil rata-rata beberapa nilai.
Ringkasan proses
Metrik adalah serangkaian nilai yang disimpan dengan stempel waktu. Di Azure, sebagian besar metrik disimpan dalam database rangkaian waktu Azure Metrics. Saat Anda merencanakan bagan, nilai metrik yang dipilih diambil dari database lalu dikumpulkan secara terpisah berdasarkan granularitas waktu yang dipilih (juga dikenal sebagai butiran waktu). Anda memilih ukuran granularitas waktu menggunakan pemilih waktu penjelajah metrik. Jika Anda tidak membuat pilihan dengan jelas, granularitas waktu dipilih secara otomatis berdasarkan rentang waktu yang saat ini dipilih. Setelah dipilih, nilai metrik yang ditangkap selama setiap kali interval granularitas dikumpulkan dan ditempatkan ke bagan - satu titik data per interval.
Jenis agregasi
Ada lima jenis agregasi dasar yang tersedia di penjelajah metrik. Penjelajah metrik menyembunyikan agregasi yang tidak relevan dan tidak dapat digunakan untuk metrik tertentu.
- Sum – jumlah semua nilai yang diambil selama interval agregasi. Terkadang disebut sebagai Total agregasi.
- Count – jumlah pengukuran yang diambil selama interval agregasi. Count tidak melihat nilai pengukuran, hanya jumlah rekaman.
- Average – rata-rata nilai metrik yang diambil selama interval agregasi. Untuk sebagian besar metrik, nilai ini adalah Sum/Count.
- Min – nilai terkecil yang diambil selama interval agregasi.
- Max – nilai terbesar yang diambil selama interval agregasi.
Misalnya, bagan memperlihatkan metrik Total Jaringan Keluar untuk komputer virtual menggunakan agregasi SUM selama rentang waktu 24 jam terakhir. Rentang waktu dan granularitas dapat diubah dari kanan atas bagan seperti yang terlihat pada tangkapan layar berikut.
Untuk granularitas waktu = 30 menit dan rentang waktu = 24 jam:
- Bagan ditarik dari 48 titik data. Yaitu 24 jam x 2 titik data per jam (60min/30min) agregat titik data 1 menit.
- Diagram garis menyambungkan 48 titik di area plot bagan.
- Setiap titik data menunjukkan jumlah semua byte keluar jaringan yang dikirim selama setiap periode waktu 30 menit yang relevan.
Klik pada gambar di bagian ini untuk melihat versi yang lebih besar.
Jika Anda mengalihkan granularitas waktu ke 15 menit, bagan diambil dari 96 titik data agregat. Artinya, 60min/15min = 4 titik data per jam x 24 jam.
Untuk granularitas waktu 5 menit, Anda mendapatkan 24 x (60/5) = 288 poin.
Untuk granularitas waktu 1 menit (sekecil mungkin pada grafik), Anda mendapat 24 x 60/1 = 1.440 poin.
Bagan terlihat berbeda untuk jumlah ini seperti yang ditunjukkan pada tangkapan layar sebelumnya. Perhatikan bagaimana komputer virtual ini memiliki banyak output dalam periode waktu kecil relatif terhadap sisa jendela waktu.
Granularitas waktu memungkinkan Anda menyesuaikan rasio "sinyal-ke-gangguan" pada bagan. Agregasi yang lebih tinggi menghilangkan gangguan dan menghaluskan lonjakan. Perhatikan variasi di bawah bagan 1 menit dan bagaimana lonjakan semakin halus saat Anda menggunakan nilai granularitas yang lebih tinggi.
Perilaku yang membuat halus ini penting ketika Anda mengirim data ini ke sistem lain--misalnya, pemberitahuan. Biasanya, Anda tidak ingin diberi tahu saat ada lonjakan waktu CPU di atas 90% dalam waktu yang sangat singkat. Tetapi jika CPU tetap berada di 90% selama 5 menit, kemungkinan itu adalah hal yang penting. Jika Anda menyiapkan aturan pemberitahuan pada CPU (atau metrik apa pun), membuat granularitas waktu lebih besar dapat mengurangi jumlah pemberitahuan palsu yang Anda terima.
Penting untuk menetapkan apa yang "normal" bagi beban kerja Anda untuk mengetahui interval waktu apa yang terbaik. Ini adalah salah satu keuntungan pemberitahuan dinamis, yang merupakan topik yang berbeda yang tidak dibahas di sini.
Bagaimana sistem mengumpulkan metrik
Pengumpulan data bervariasi menurut metrik.
Frekuensi pengumpulan pengukuran
Ada dua jenis periode pengumpulan.
Reguler - Metrik dikumpulkan pada interval waktu yang konsisten yang tidak bervariasi.
Berbasis aktivitas - Metrik dikumpulkan berdasarkan kapan transaksi jenis tertentu terjadi. Setiap transaksi memiliki entri metrik dan stempel waktu. Mereka tidak dikumpulkan secara berkala sehingga ada berbagai jumlah rekaman selama periode waktu tertentu.
Granularitas
Granuralitas waktu minimal adalah 1 menit, tetapi sistem yang mendasarinya dapat menangkap data lebih cepat tergantung pada metrik. Misalnya, persentase CPU untuk komputer virtual Azure diterima pada interval waktu 15 detik. Karena kegagalan HTTP dilacak sebagai transaksi, mereka dapat dengan mudah melampaui lebih dari satu menit. Metrik lain seperti Penyimpanan SQL ditangkap setiap 20 menit. Pilihan ini terserah penyedia dan jenis sumber daya individu. Sebagian besar mencoba untuk menyediakan interval sekecil mungkin.
Dimensi, pemisahan, dan pemfilteran
Metrik ditangkap untuk setiap sumber daya individual. Namun, tingkat di mana metrik dikumpulkan, disimpan, dan dapat di-chart dapat bervariasi. Tingkat ini diwakili oleh metrik tambahan yang tersedia dalam dimensi metrik. Setiap penyedia sumber daya individu dapat menentukan seberapa detail data yang mereka kumpulkan. Azure Monitor hanya menentukan bagaimana detail tersebut harus ditampilkan dan disimpan.
Saat membuat bagan metrik di penjelajah metrik, Anda memiliki opsi untuk "memisahkan" bagan menurut dimensi. Memisahkan bagan berarti Anda mencari data yang mendasarinya untuk detail selengkapnya dan melihat data tersebut di-chart atau difilter dalam penjelajah metrik.
Misalnya, Microsoft.ApiManagement/service memiliki Lokasi sebagai dimensi untuk banyak metrik.
Kapasitas adalah salah satu metrik tersebut. Memiliki dimensi Lokasi menyiratkan bahwa sistem yang mendasarinya menyimpan rekaman metrik untuk kapasitas setiap lokasi, bukan hanya satu untuk jumlah agregat. Anda kemudian dapat mengambil atau memisahkan informasi tersebut dalam bagan metrik.
Jika dilihat dari Keseluruhan Durasi Permintaan Gateway, ada 2 dimensi Lokasi dan Nama Host, yang juga memberi tahu Anda lokasi durasi dan nama host asalnya.
Salah satu metrik yang lebih fleksibel, Permintaan, memiliki 7 dimensi yang berbeda.
Periksa artikel yang didukung metrik Azure Monitor untuk detail tentang setiap metrik dan dimensi yang tersedia. Selain itu, dokumentasi untuk setiap penyedia sumber daya dan jenis dapat memberikan informasi tambahan tentang dimensi dan apa yang mereka ukur.
Anda dapat menggunakan pemisahan dan pemfilteran bersama-sama untuk menggali masalah. Di bawah ini adalah contoh grafik yang memperlihatkan Rata-rata Byte Penulisan Disk untuk sekelompok komputer virtual dalam grup sumber daya. Kita memiliki rollup dari semua komputer virtual dengan metrik ini, tetapi kita mungkin ingin mencari tahu apa yang sebenarnya bertanggung jawab atas lonjakan sekitar jam 6 pagi. Apakah mereka mesin yang sama? Berapa banyak mesin yang terlibat?
Klik pada gambar di bagian ini untuk melihat versi yang lebih besar.
Ketika menerapkan pemisahan, kita dapat melihat data yang mendasarinya, tetapi data tersebut agak berantakan. Ternyata ada 20 komputer virtual yang dikumpulkan ke dalam grafik di atas. Dalam hal ini, kita mengarahkan mouse ke lonjakan besar pada jam 6 pagi yang memberi tahu bahwa CH-DCVM11 adalah penyebabnya. tetapi sulit untuk melihat sisa data yang terkait dengan komputer virtual itu karena komputer virtual lain mengacaukan bagan.
Menggunakan pemfilteran memungkinkan kita untuk membersihkan bagan dan melihat apa yang sebenarnya terjadi. Anda dapat memeriksa atau menghapus centang komputer virtual yang ingin Anda lihat. Perhatikan garis putus-putus. Itu disebutkan di bagian selanjutnya.
Untuk informasi selengkapnya tentang cara memperlihatkan data dimensi terpisah pada bagan penjelajah metrik, lihat Fitur lanjutan penjelajah metrik - filter dan pemisahan.
Nilai NULL dan nol
Ketika sistem mengharapkan data metrik dari sumber daya tetapi tidak menerimanya, sistem merekam nilai NULL. NULL berbeda dari nilai nol, yang merupakan hal penting dalam perhitungan agregasi dan pembuatan bagan. Nilai NULL tidak dihitung sebagai pengukuran yang valid.
NULLs muncul secara berbeda pada bagan yang berbeda. Plot yang tersebar tidak memperlihatkan titik pada bagan. Bagan batang tidak memperlihatkan bilah. Pada diagram garis, NULL dapat muncul sebagai garis putus-putus atau titik-titik seperti yang diperlihatkan di tangkapan layar di bagian sebelumnya. Saat menghitung rata-rata yang menyertakan NULL, titik data yang diambil untuk rata-rata lebih sedikit. Perilaku ini terkadang dapat mengakibatkan penurunan nilai yang tidak terduga pada bagan, meskipun biasanya kurang dari itu jika nilai dikonversi ke nol dan digunakan sebagai titik data yang valid.
Metrik kustom selalu menggunakan NULL saat tidak menerima data. Dengan metrik platform, setiap penyedia sumber daya memutuskan apakah akan menggunakan nol atau NULL berdasarkan apa yang paling masuk akal untuk metrik tertentu.
Pemberitahuan Azure Monitor menggunakan nilai yang ditulis penyedia sumber daya ke database metrik, jadi penting untuk mengetahui bagaimana penyedia sumber daya menangani NULL dengan melihat data terlebih dahulu.
Cara kerja agregasi
Bagan metrik di sistem sebelumnya memperlihatkan berbagai tipe data agregat. Sistem mengumpulkan data terlebih dahulu sehingga grafik yang diminta dapat ditampilkan lebih cepat tanpa banyak perhitungan berulang.
Dalam contoh ini:
- Kami mengumpulkan metrik transaksi fiktif yang disebut kegagalan HTTP
- Server adalah dimensi untuk metrik kegagalan HTTP.
- Kami memiliki 3 server - Server A, B, dan C.
Untuk menyederhanakan penjelasan, kita akan mulai dengan jenis agregasi SUM saja.
Agregasi sub menit ke 1 menit
Data metrik mentah pertama dikumpulkan dan disimpan dalam database metrik Azure Monitor. Dalam hal ini, setiap server memiliki rekaman transaksi yang disimpan dengan stempel waktu karena Server adalah dimensi. Mengingat bahwa periode waktu terkecil yang dapat Anda lihat sebagai pelanggan adalah 1 menit, stempel waktu tersebut pertama kali dikumpulkan ke dalam nilai metrik 1 menit untuk setiap server individu. Proses agregasi untuk Server B diperlihatkan dalam grafik di bawah ini. Server A dan C dilakukan dengan cara yang sama dan memiliki data yang berbeda.
Nilai agregat 1 menit yang dihasilkan disimpan sebagai entri baru dalam database metrik sehingga dapat dikumpulkan untuk penghitungan nanti.
Agregasi dimensi
Perhitungan 1 menit kemudian diciutkan berdasarkan dimensi dan kembali disimpan sebagai catatan individu. Dalam hal ini, semua data dari semua server individu dikumpulkan ke dalam metrik interval 1 menit dan disimpan dalam database metrik untuk digunakan dalam agregasi nanti.
Untuk kejelasannya, tabel berikut ini memperlihatkan metode agregasi.
| Titik | Server A | Server B | Server C | Sum (A+B+C) |
|---|---|---|---|---|
| Menit 1 | 1 | 1 | 1 | 3 |
| Menit 2 | 0 | 5 | 1 | 6 |
| Menit 3 | 0 | 5 | 1 | 6 |
| Menit 4 | 2 | 3 | 4 | 9 |
| Menit 5 | 1 | 0 | 3 | 4 |
| Menit 6 | 1 | 0 | 4 | 5 |
| Menit 7 | 1 | 2 | 4 | 7 |
| Menit 8 | 0 | 1 | 0 | 1 |
| Menit 9 | 1 | 1 | 4 | 6 |
| Menit 10 | 2 | 1 | 0 | 3 |
Hanya satu dimensi yang ditampilkan di atas, tetapi proses agregasi dan penyimpanan yang sama terjadi untuk semua dimensi yang didukung metrik.
- Kumpulkan nilai ke dalam kumpulan 1 menit berdasarkan dimensi tersebut. Simpan nilai-nilai tersebut.
- Ciutkan dimensi menjadi SUM gabungan 1 menit. Simpan nilai-nilai tersebut.
Mari kita perkenalkan dimensi lain dari kegagalan HTTP yang disebut NetworkAdapter. Katakanlah kita memiliki berbagai jumlah adapter per server.
- Server A memiliki 1 adapter
- Server B memiliki 2 adapter
- Server C memiliki 3 adapter
Kita mengumpulkan data untuk transaksi berikut secara terpisah. Mereka akan ditandai dengan:
- Waktu
- Nilai
- Server tempat transaksi berasal
- Adapter tempat transaksi berasal
Setiap aliran submenit tersebut kemudian akan dikumpulkan ke dalam nilai rangkaian waktu 1 menit dan disimpan dalam database metrik Azure Monitor:
- Server A, Adapter 1
- Server B, Adapter 1
- Server B, Adapter 2
- Server C, Adapter 1
- Server C, Adapter 2
- Server C, Adapter 3
Selain itu, agregasi yang diciutkan berikut ini juga akan disimpan:
- Server A, Adapter 1 (karena tidak ada yang diciutkan, ini akan disimpan lagi)
- Server B, Adapter 1+2
- Server C, Adapter 1+2+3
- Server SEMUA, Adaptor SEMUA
Ini menunjukkan bahwa metrik dengan dimensi dalam jumlah besar memiliki jumlah agregasi yang lebih besar. Tidak penting untuk mengetahui semua permutasi, hanya memahami alasannya. Sistem ingin memiliki data individu dan data agregat yang disimpan untuk pengambilan cepat untuk akses pada bagan apa pun. Sistem memilih agregasi tersimpan yang paling relevan atau data mentah yang mendasarinya tergantung apa yang Anda pilih untuk ditampilkan.
Agregasi tanpa dimensi
Karena metrik ini memiliki dimensi Server, Anda bisa mendapatkan data yang mendasari untuk server A, B, dan C di atas melalui pemisahan dan pemfilteran, seperti yang dijelaskan sebelumnya dalam artikel ini. Jika metrik tidak memiliki Server sebagai dimensi, Anda sebagai pelanggan hanya dapat mengakses jumlah agregat 1 menit yang ditampilkan dalam warna hitam pada diagram. Yaitu, nilai 3, 6, 6, 9, dll. Sistem juga tidak akan melakukan pekerjaan yang mendasari untuk mengagregasi nilai-nilai yang dibagi, sistem tidak akan pernah menggunakannya dalam penjelajah metrik atau mengirimkannya melalui API REST metrik.
Melihat granularitas waktu di atas 1 menit
Jika Anda meminta metrik pada granularitas yang lebih besar, sistem menggunakan jumlah agregat 1 menit untuk menghitung jumlah untuk granularitas waktu yang lebih besar. Di bawah ini, garis putus-putus menunjukkan metode penjumlahan untuk granularitas waktu 2 menit dan 5 menit. Sekali lagi, kami hanya menampilkan jenis agregasi SUM agar lebih sederhana.
Untuk granularitas waktu 2 menit.
| Titik | Jumlah |
|---|---|
| Menit 1 & 2 | (3 + 6) = 9 |
| Menit 3 & 4 | (6 + 9) = 15 |
| Menit 4 & 5 | (4 + 5) = 9 |
| Menit 6 & 7 | (7 + 1) = 8 |
| Menit 8 & 9 | (6 + 3) = 9 |
Untuk granularitas waktu 5 menit.
| Titik | Jumlah |
|---|---|
| Menit 1 sampai 5 | 3 + 6 + 6 + 9 + 4 = 28 |
| Menit 6 sampai 10 | 5 + 7 + 1 + 6 + 3 = 22 |
Sistem ini menggunakan data agregat tersimpan yang memberikan performa terbaik.
Di bawah ini adalah diagram yang lebih besar untuk proses agregasi di atas 1 menit, dengan beberapa panah yang ditinggalkan untuk meningkatkan keterbacaan.
Contoh yang lebih kompleks
Berikut ini adalah contoh yang lebih besar menggunakan nilai untuk metrik fiktif yang disebut waktu Respons HTTP dalam milidetik. Di sini kami memperkenalkan tingkat kompleksitas tambahan.
- Kami menampilkan agregasi untuk Sum, Count, Min, dan Max, dan perhitungan untuk Average.
- Kami menunjukkan nilai NULL dan pengaruhnya terhadap perhitungan.
Pertimbangkan contoh berikut. Kotak dan panah memperlihatkan contoh bagaimana nilai dikumpulkan dan dihitung.
Proses pra-agregasi 1 menit yang sama seperti yang dijelaskan di bagian sebelumnya terjadi untuk Sum, Count, Minimum, dan Maximum. Namun, Average TIDAK pra-agregat. Average dihitung ulang menggunakan data agregat untuk menghindari kesalahan perhitungan.
Pertimbangkan menit 6 untuk agregasi 1 menit seperti yang disorot di atas. Menit ini adalah titik di mana Server B offline dan berhenti melaporkan data, mungkin karena reboot.
Dari Menit 6 ke atas, tipe agregasi 1 menit yang dihitung adalah:
| Jenis agregasi | Value | Catatan |
|---|---|---|
| Jumlah | 53+20=73 | |
| Hitung | 2 | Memperlihatkan efek NULL. Nilainya akan menjadi 3 jika servernya online. |
| Minimum | 20 | |
| Maksimum | 53 | |
| Tengah | 73 / 2 | Sum selalu dibagi dengan Count. Ini tidak pernah disimpan dan selalu dihitung ulang untuk setiap kali granularitas menggunakan angka agregat untuk granularitas itu. Perhatikan penghitungan ulang untuk granularitas waktu 5 menit dan 10 menit seperti yang disorot di atas. |
Warna teks merah menunjukkan nilai yang mungkin dianggap di luar rentang normal dan menunjukkan bagaimana mereka merambat (atau gagal) saat granularitas waktu naik. Perhatikan bagaimana MinMax menunjukkan adanya anomali yang mendasarinya sementara Average dan Sum kehilangan informasi itu saat granularitas waktu Anda naik.
Anda juga dapat melihat bahwa NULL memberikan perhitungan rata-rata yang lebih baik dibandingkan dengan nol.
Catatan
Namun dalam contoh ini tidak demikian, Count sama dengan Sum dalam kasus ketika metrik selalu ditangkap dengan nilai 1. Merupakan hal yang umum ketika metrik melacak terjadinya peristiwa transaksional--misalnya, jumlah kegagalan HTTP yang disebutkan dalam contoh sebelumnya dalam artikel ini.