Agregasi dan tampilan metrik Azure Monitor dijelaskan

Artikel ini menjelaskan agregasi metrik dalam database rangkaian waktu yang mendukung metrik platform Azure Monitor dan metrik kustom. Artikel ini juga berlaku untuk metrik Application Insights standar.

Informasi dalam artikel ini rumit dan disediakan bagi mereka yang ingin menggali lebih dalam ke dalam sistem metrik. Anda tidak perlu memahaminya untuk menggunakan metrik Azure Monitor secara efektif.

Ringkasan dan istilah

Saat Anda menambahkan metrik ke bagan, penjelajah metrik secara otomatis memilih agregasi defaultnya. Pengaturan awal masuk akal dalam skenario dasar, tetapi Anda dapat menggunakan agregasi yang berbeda untuk mendapatkan lebih banyak wawasan atas 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 pada penjelajah metrik. Jika Anda tidak membuat pilihan eksplisit, granularitas waktu secara otomatis dipilih berdasarkan rentang waktu yang dipilih saat ini. Setelah dipilih, nilai metrik yang ditangkap selama setiap interval granularitas waktu dikumpulkan dan ditempatkan pada 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 memperhatikan nilai pengukuran, melainkan hanya jumlah catatan.
• 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 (60menit/30menit) yang digabungkan menjadi titik data 1 menit.
• Grafik garis menghubungkan 48 titik di bidang 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 untuk penjumlahan ini terlihat berbeda seperti yang diperlihatkan pada tangkapan layar sebelumnya. Perhatikan bagaimana VM 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 mengurangi gangguan dan meratakan lonjakan. Perhatikan variasi pada bagan 1 menit dan bagaimana variasi tersebut semakin halus saat beralih ke 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 tentang lonjakan singkat dalam waktu CPU yang lebih dari 90%. 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.

Nota

Contoh di bawah ini disederhanakan untuk ilustrasi, dan data metrik aktual yang disertakan dalam setiap agregasi dipengaruhi oleh data yang tersedia saat evaluasi terjadi.

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. Rekaman 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 dicatat pada interval waktu 15 detik. Karena kegagalan HTTP dilacak sebagai transaksi, kegagalan tersebut dapat dengan mudah melampaui lebih dari satu transaksi per menit. Metrik lain seperti Penyimpanan SQL ditangkap setiap 20 menit. Pilihan ini terserah penyedia dan jenis sumber daya individu. Sebagian besar mencoba menyediakan interval sekecil mungkin.

Dimensi, pemisahan, dan pemfilteran

Metrik dikumpulkan untuk setiap sumber daya individual. Namun, tingkat di mana metrik dikumpulkan, disimpan, dan dapat di-chart dapat bervariasi. Tingkat ini diwakili oleh metrik lain 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. Memecah bagan berarti Anda meneliti data yang mendasari untuk mendapatkan detail lebih lanjut dan melihat data tersebut dipetakan 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 Metrik yang didukung dengan 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 VM dalam sebuah grup sumber daya. Kami memiliki rollup semua VM dengan metrik ini, tetapi kami mungkin ingin mencari tahu mana yang bertanggung jawab atas puncaknya sekitar pukul 06.00. 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 puncak besar pada jam 6 pagi yang menunjukkan bahwa CH-DCVM11 adalah penyebabnya. Tetapi sulit untuk melihat sisa data yang terkait dengan VM tersebut karena VM lain yang mengacaukan bagan.

Menggunakan pemfilteran memungkinkan kita untuk membersihkan bagan dan melihat apa yang sebenarnya terjadi. Anda dapat menandai atau menghapus tanda centang VM yang ingin Anda lihat. Perhatikan garis putus-putus. Itu disebutkan di bagian selanjutnya.

Untuk informasi selengkapnya tentang cara menampilkan data dimensi terpisah pada bagan penjelajah metrik, lihat Menggunakan filter dimensi 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 ditampilkan dengan cara yang berbeda pada berbagai bagan. Plot yang tersebar tidak memperlihatkan titik pada bagan. Bagan batang tidak memperlihatkan bilah. Pada diagram garis, NULL dapat muncul sebagai garis titik-titik atau putus-putus 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 kurang dari jika nilai dikonversi menjadi 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 melakukan pra-agregasi data sehingga bagan yang diminta dapat ditampilkan lebih cepat tanpa banyak komputasi 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 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 diringkas 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.

Periode	Server A	Server B	Server C	Jumlah (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 setiap 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 jumlah adapter yang bervariasi 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:

• Suatu waktu
• Nilai
• Server tempat transaksi berasal
• Adapter asal transaksi

Setiap aliran submenit tersebut kemudian akan dikumpulkan ke dalam nilai rangkaian waktu 1 menit dan disimpan dalam database metrik Azure Monitor:

• Server A, Adaptor 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 dipadatkan berikut ini juga akan disimpan.

• Server A, Adapter 1 (karena tidak ada yang perlu diciutkan, itu akan disimpan lagi)
• Server B, Adapter 1+2
• Server C, Adaptor 1+2+3
• Semua Server, Semua Adaptor

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. Artinya, nilai 3, 6, 6, 9, dan seterusnya. Sistem juga tidak akan melakukan pekerjaan mendasar untuk mengagregasi nilai yang terpisah, dan 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 menunjukkan jenis agregasi SUM untuk kesederhanaan.

Untuk tingkat granularitas waktu 2 menit.

Periode	Jumlah
Menit 1 & 2	(3 + 6) = 9
Menit 3 & 4	(6 + 9) = 15
Menit 4 & 5	(4 + 5) = 9
Menit 6 dan 7	(7 + 1) = 8
Menit 8 & 9	(6 + 3) = 9

Untuk granularitas waktu 5 menit.

Periode	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 1 menit di atas, dengan beberapa panah yang dihilangkan 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 lainnya.

1. Kami menampilkan agregasi untuk Sum, Count, Min, dan Max, dan perhitungan untuk Average.
2. 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, Rata-rata TIDAK dipra-agregasi. Ini dihitung ulang menggunakan data agregat untuk menghindari kesalahan perhitungan.

Pertimbangkan menit ke-6 untuk agregasi selama 1 menit sebagaimana yang telah disorot di atas. Menit ini adalah titik di mana Server B offline dan berhenti melaporkan data, mungkin karena reboot.

Setelah Menit 6 di atas, jenis agregasi 1 menit yang dihitung adalah:

Jenis agregasi	Nilai	Catatan
Jumlah total	53+20=73
Jumlah	2	Memperlihatkan efek dari NULL. Nilainya akan menjadi 3 jika servernya online.
Sekurang-kurangnya	20
Maksimum	53
Tengah	73 / 2	Selalu Jumlah dibagi dengan Hitungan. Ini tidak pernah disimpan dan selalu dihitung ulang setiap kali sesuai dengan granularitas, dengan menggunakan angka agregat untuk granularitas tersebut. 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.

Nota

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.

Langkah selanjutnya

• Menganalisis metrik dengan penjelajah metrik Azure Monitor