Azure Management Series: Monitoring Practice Part 2

Part ini merupakan kelanjutan bagian sebelumnya yaitu Azure Management Series: Monitoring Practice Part 1. Jika anda belum membaca artikel tersebut, silahkan dibaca artikel tersebut terlebih dahulu.

Network Watcher

Network Watcher merupakan service khusus untuk monitoring jaringan di Azure secara lebih detail, termasuk troubleshooting jika ada masalah. Lebih lengkap tentang Network Watcher dapat dilihat pada https://docs.microsoft.com/en-us/azure/network-watcher. Pada Azure Monitor versi terdahulu Network Watcher merupakan bagian dari Azure Monitor, namun pada versi yang terbaru tidak ada fitur Network Watcher di Azure Monitor.

Berikut beberapa fitur penting dari Network Watcher yang sudah dapat digunakan:

1. Monitoring > Topology, fitur ini digunakan untuk melihat network topology pada sebuah resource group sehingga terlihat hubungan antar komponen.

Topologi network vnetHub

2. Network Diagnostic Tools > IP Flow Verify, digunakan untuk melihat apakah koneksi dapat dilakukan berdasarkan rule network yang berlaku di Azure dari informasi 5 tuple (IP address source, Port source, IP address destination, Port destination, Protocol TCP/UDP). Fitur ini digunakan untuk mendeteksi apakah dari sumber ke target ada rules yang menghalangi seperti deny di NSG.

Tampilan fitur IP Flow Verify

3. Network Diagnostic Tools > Next Hop, berfungsi untuk melihat hop berikutnya jika sebuah koneksi dari sumber ke target dilakukan. Hop yang dihasilkan sama seperti proses traceroute namun berhenti jika ditemukan IP diantara sumber dan target yang pertama kali.

Tampilan fitur Next Hop

4. Network Diagnostic Tools > Effective Security Rules, digunakan untuk melihat aturan network apa saja yang berlaku pada spesifik VM. Berikut contohnya:

Tampilan masukan untuk mengecek Effective Security Rules

Tampilan di atas adalah isian untuk menentukan spesifik VM yang akan ditinjau terkait rules yang berdampak pada VM. Hasil dari pengecekan tersebut adalah sebagai berikut:

Hasil Effective Security Rules

5. Network Diagnostic Tools > VPN Troubleshooting, melihat status dan network koneksi tunneling VPN dari Azure.

Status VPN

6. Network Diagnostic Tools > Packet Capture, sesuai dengan namanya berfungsi seperti tools wireshark yaitu bertindak sebagai perantara pada suatu jaringan dan merekam lalu lintas jaringan tersebut menjadi sebuah paket ber-ekstensi “.cap”.

Tampilan isian untuk meng-capture paket

7. Network Diagnostic Tools > Connection Troubleshooting, fungsinya adalah mencoba koneksi antara dari sumber ke tujuan melalui port tertentu atau dengan melakukan PING.

Tampilan fitur

Terkait Network Watcher bisa lebih lengkap ditemukan di dokumentasi resmi.

Custom Dashboard

Tampilan Custom Dashboard

Dashboard adalah tampilan pada Azure Portal, kita bisa menambahkannya sebagai tampilan default ketika pertama kali berhasil masuk ke Azure Portal. Fiturnya ada di:

1. Menu garis di sebelah tulisan Microsoft Azure

2. Menu tersebut di-klik maka akan muncul Dashboard, ini akan menampilkan dashboard apa yang sudah kita punya.

3. Kita bisa membuat dashboard baru dengan memilih menu “new dashboard”

Tampilan fitur “new dashboard”

Cara membuat dashboard cukup mudah, yang pertama adalah dengan cara di atas yaitu dengan membuat dashboard baru dan memberikan nama judul untuk dashboard tersebut. Kemudian untuk menambahkan chart atau grafik pada dashboard bisa dilakukan dengan:

1. Klik edit

Pilih Edit

2. Buka “Tile gallery” dan pilih “Tile” yang ingin digunakan

Tile Gallery

3. Rapikan ukuran dan penempatan “Tile” tersebut dengan menarik garis pinggir tile dan disesuaikan dengan dimensi kotak yang kita perlukan.

contoh dengan dimensi 2x6

4. Lalu klik “Done Customizing” jika sudah selesai. Tulisan ini ada di bagian paling atas.

Done Customizing

Cara lain untuk menambahkan ke dashboard adalah dengan meng-klik “Pin To Dashboard” pada setiap chart yang kita temukan di Azure Resource. Misal pada Azure Kubernetes Cluster:

Tampilan visualisasi chart di AKS

Ada logo “Pin” di kanan atas grafik, apabila di-hover akan muncul tulisan “Pin to dashboard”.

Pin to dashboard

Apabila logo tersebut di-klik, maka akan muncul blade untuk memilih menyimpan ke dashboard yang mana.

Apabila sudah di-pin ke dashboard yang dipilih, kita hanya perlu kembali ke dashbord tersebut dan merapikan tampilan dashboard dengan drag-and-drop.

Untuk contoh dashboard yang sudah ada shared akan masuk ke Resource Group “dashboards”, hanya owner subscription dan contributor pada tenant yang bisa akses.

Berikut tampilannya:

Tampilan hasil pin to dashboard

Alerts

Ada 3 aksi yang dapat dilakukan menggunakan hasil monitoring metrics, yaitu autoscale, alerts, dan automation. Autoscale merupakan fitur yang ada pada beberapa service PaaS di Azure, untuk IaaS autoscale dapat dilakukan menggunakan Virtual Machine Scale Set.

Saat ini akan dibahas mengenai alerts, sementara automation akan dibahas pada artikel lain karena lebih banyak berhubungan dengan topik configuration daripada monitoring.

Cost driver untuk alerts ada 2 yaitu:

• Alert Rule, cara menghitung alert rule adalah sebagai berikut. Jika kita memiliki 10 VM dan akan dimonitor penggunaan CPU dan memori (2 metrik), maka akan ada 20 alert rule yang digunakan tiap bulan. Setiap bulannya ada 10 alert rule gratis, sehingga berdasarkan hitungan di atas ada 10 alert rule yang akan terkena biaya.
• Dynamic Threshold, ini hanya berlaku jika membuat alert dengan dynamic condition (ditentukan berdasarkan algoritma machine learning).

Untuk membuat alert rule disarankan menggunakan static condition untuk menghindari cost driver yang kedua.

Cara membuat alert bisa dari tampilan masing-masing resource di portal atau dari monitoring service yang ada.

Ada dua jenis alert berdasarkan sumber:

• Metrics Alert, membuat alert berdasarkan metrics lebih mudah dikarenakan variable yang digunakan bertipe numerik. Misalkan apabila CPU performance di atas 90%, maka kirim notifikasi ke Administrator lewat email. CPU performance ini adalah tipe numerik sehingga lebih mudah untuk dijandikan kondisi untuk men-trigger alert.
• Logs Alert, membuat alert berdasarkan logs akan lebih rumit dikarenalan tipe data pada log sangat beragam. Cara paling mudah membuat alert pada logs adalah dengan melakukan query rutin tiap rentang tertentu.

Untuk membuat alert yang pertama kali perlu dilakukan adalah membuat action group dengan cara sebagai berikut:

1. Dari blade Monitoring pada service yang digunakan, pilih Alerts

Blade monitoring

2. Pada menu bagian atas, pilih Manage actions

Manage actions

3. Setelah muncul tampilan daftar action groups, pilih Add action group untuk menambahkan action group baru

Add action group

4. Akan ada prompt seperti dibawah ini:

• Isi subscription dan resource group untuk menempatkan lokasi action group.

Isian untuk membuat action group

5. Setelah memilih Next akan muncul form untuk Notifications, kita bisa menentukan untuk memberikan notifikasi kepada siapa dengan cara apa. Pilih Email/SMS message/Push/Voice sebagai pilihan.

Notifications

6. Apabila kita meng-klik kolom “Name” maka akan muncul tampilan lagi untuk mengisi lebih detail mulai dari cara notifikasi-nya, serta alamat tujuannya. Disarankan untuk membuat alamat Mailing Group agar memudahkan dalam proses notifikasi ke semua stakeholder dalam hal monitoring.

Detail informasi notifikasi

7. Setelah, klik OK kemudian pilih Review+ Create dilanjutkan Create untuk menyelesaikan proses.

Create

8. Apabila sudah selesai dibuat, maka akan ada email masuk ke alamat email yang terdaftar pada action group.

Berikut ini adalah cara membuat static alert berdasarkan metrics:

1. Pilih “Alerts” pada blade monitoring

Blade Monitoring

2. Pilih “New alert rule” untuk membuat alert baru

New alert rule

3. Pada tampilan “Create alert rule”, yang ditentukan dalam membuat alert rule adalah:

• Scope, karena kita membuat alert rule dari blade resource maka otomatis scope yang ditampilkan adalah resource tersebut.
• Condition, ini digunakan untuk menjadi trigger terhadap alert. Terdapat beberapa tipe signal. Kita bisa memilih antara sumbernya dari metrics atau dari logs.
• Action Group, ini berisi apa yang akan dilakukan bila status di Condition bernilai true. Aksi yang digunakan bisa berupa notification ke email, sms, dll atau berupa automation.

Create Alert Rule

4. Berikutnya adalah menentukan sinyal yang akan digunakan sebagai trigger, di sini pilih “Number of pods in ready state”

signal logic

5. Seluruh metrics disimpan dalam bentuk time series data, karena itu kita harus menentukan:

• Rentang waktu data dikumpulan
• Filter kondisi pod (bisa disesuaikan)

Memilih kondisi signal

6. Setelah itu tentukan alert logic yang terdiri dari:

• Treshold, static atau dynamic. Di sini pilih static.
• Operator, ini menentukan nilai yang dicocokkan lebih besar, kurang dari, atau sama dengan.
• Tipe agregasi, fungsi untuk menentukan nilai apa yang diambil dari keseluruhan data, bisa berupa rata-rata(average), total, max, min, dll.
• Treshold value, nilai menjadi acuan kapan alert akan terjadi.
• Aggregation granularity, seperti frame window, seluruh data selama waktu ini digunakan untuk fungsi agregasi.
• Frequency of evaluation, berapa rutin perhitungan akan dilakukan. Pada contoh ini setiap satu menit akan dihitung ulang.

Alert Logic

7. Lalu pilih create, dan setelah itu lanjutkan untuk menentukan action group. Karena sudah ada action group yang dibuat sebelumnya kita pilih Admin Notif.

Pilih action group

8. Kemudian paling akhir adalah memberikan nama dan deskripsi terkait alert yang dibuat. Severity bisa dipilih dari 0–4 (dipilih 0 karena hanya bersifat informational)

Isu Alert Detail

9. Pilih Create Alert Rule untuk selesai membuat alert.

Demikian, artikel terkait Azure Management Series: Monitoring Practice. Berikutnya akan diikuti dengan series untuk proses management lainnya.

Thank You!!!