Uji ketersediaan Application Insights

Artikel
10/25/2024

Application Insights memungkinkan Anda menyiapkan pengujian web berulang yang memantau ketersediaan dan respons situs web atau aplikasi Anda dari berbagai titik di seluruh dunia. Pengujian ketersediaan ini mengirim permintaan web ke aplikasi Anda secara berkala dan memberi tahu Anda jika aplikasi Anda tidak merespons atau jika waktu respons terlalu lambat.

Pengujian ketersediaan tidak memerlukan modifikasi apa pun pada situs web atau aplikasi yang Anda uji. Mereka bekerja untuk titik akhir HTTP atau HTTPS apa pun yang dapat diakses dari internet publik, termasuk REST API yang bergantung pada layanan Anda. Ini berarti Anda dapat memantau tidak hanya aplikasi Anda sendiri tetapi juga layanan eksternal yang penting untuk fungsionalitas aplikasi Anda. Anda dapat membuat hingga 100 pengujian ketersediaan per sumber daya Application Insights.

Catatan

Pengujian ketersediaan disimpan dienkripsi, sesuai dengan kebijakan enkripsi data Azure saat tidak aktif .

Jenis pengujian ketersediaan

Ada empat jenis pengujian ketersediaan:

Pengujian standar: Jenis uji ketersediaan yang memeriksa ketersediaan situs web dengan mengirim satu permintaan, mirip dengan pengujian ping URL yang tidak digunakan lagi. Selain memvalidasi apakah titik akhir merespons dan mengukur performa, pengujian Standar juga mencakup validitas sertifikat TLS/SSL, pemeriksaan masa pakai proaktif, kata kerja permintaan HTTP (misalnya, ,HEAD, GETdan POST), header kustom, dan data kustom yang terkait dengan permintaan HTTP Anda.

Pelajari cara membuat pengujian standar.
Pengujian TrackAvailability Kustom: Jika Anda memutuskan untuk membuat aplikasi kustom untuk menjalankan pengujian ketersediaan, Anda dapat menggunakan metode TrackAvailability() untuk mengirim hasil ke Application Insights.

Pelajari cara membuat pengujian TrackAvailability kustom.
(Tidak digunakan lagi) Pengujian web multi-langkah: Anda dapat memutar kembali rekaman ini dari urutan permintaan web untuk menguji skenario yang lebih kompleks. Pengujian web multi-langkah dibuat di Visual Studio Enterprise dan diunggah ke portal, saat Anda menjalankannya.
(Tidak digunakan lagi) Pengujian ping URL: Anda dapat membuat pengujian ini melalui portal Azure untuk memvalidasi apakah titik akhir merespons dan mengukur performa yang terkait dengan respons tersebut. Anda juga dapat menetapkan kriteria keberhasilan khusus yang digabungkan dengan fitur yang lebih canggih, seperti menguraikan permintaan yang bergantung dan memungkinkan percobaan ulang.

Penting

Ada dua penghentian pengujian ketersediaan yang akan datang:

Pengujian web multi-langkah: Pada 31 Agustus 2024, pengujian web multi-langkah di Application Insights akan dihentikan. Kami menyarankan pengguna tes ini untuk beralih ke pengujian ketersediaan alternatif sebelum tanggal pensiun. Setelah tanggal ini, kami akan menurunkan infrastruktur yang mendasar yang akan memecah sisa pengujian multi-langkah.
Pengujian ping URL: Pada 30 September 2026, pengujian ping URL di Application Insights akan dihentikan. Pengujian ping URL yang ada akan dihapus dari sumber daya Anda. Tinjau harga untuk pengujian standar dan transisi untuk menggunakannya sebelum 30 September 2026 untuk memastikan Anda dapat terus menjalankan pengujian ketersediaan satu langkah di sumber daya Application Insights Anda.

Prasyarat

Sumber daya Application Insights berbasis ruang kerja

Memulai

Buka sumber daya Application Insights Anda dan buka pengalaman Ketersediaan .
Pilih Tambahkan pengujian Standar dari bilah navigasi atas.

Masukkan nama pengujian, URL, dan pengaturan lain yang dijelaskan dalam tabel berikut, lalu pilih Buat.

Bagian	Pengaturan	Deskripsi
Informasi Dasar
	URL	URL dapat berupa halaman web apa pun yang ingin Anda uji, tetapi harus terlihat dari internet publik. URL dapat menyertakan string kueri. Sehingga, misalkan, Anda dapat menjalankan database Anda sedikit. Jika URL diselesaikan ke pengalihan, kami menindaklanjutinya hingga 10 pengalihan.
	Mengurai permintaan dependen	Menguji permintaan gambar, skrip, file gaya, dan file lain yang merupakan bagian dari halaman web di bawah pengujian. Waktu respons yang direkam mencakup waktu yang diperlukan untuk mendapatkan file-file ini. Pengujian gagal jika salah satu sumber daya ini tidak dapat berhasil diunduh dalam batas waktu untuk seluruh pengujian. Jika opsi tidak dipilih, pengujian hanya meminta file di URL yang Anda tentukan. Pengaktifan opsi ini menyebabkan pemeriksaan yang lebih ketat. Pengujian dapat gagal untuk kasus, yang mungkin tidak terlihat ketika Anda menelusuri situs secara manual. Kami hanya mengurai hingga 15 permintaan dependen.
	Mengaktifkan percobaan ulang untuk kegagalan pengujian ketersediaan	Ketika pengujian gagal, pengujian akan mencoba kembali setelah interval singkat. Kegagalan hanya dilaporkan jika terjadi kegagalan dalam tiga upaya berturut-turut. Pengujian berikutnya kemudian dilakukan pada frekuensi pengujian biasa. Percobaan kembali untuk sementara dihentikan hingga keberhasilan berikutnya. Aturan ini diterapkan secara independen di setiap lokasi pengujian. Kami merekomendasikan opsi ini. Rata-rata, sekitar 80% kegagalan hilang saat percobaan kembali.
	Mengaktifkan validitas sertifikat SSL	Anda dapat memverifikasi sertifikat SSL di situs web Anda untuk memastikannya dipasang dengan benar, valid, tepercaya, dan tidak memberikan kesalahan apa pun kepada pengguna Anda.
	Pemeriksaan masa hidup proaktif	Pengaturan ini memungkinkan Anda untuk menentukan periode waktu tertentu sebelum sertifikat SSL Anda berakhir. Setelah kedaluwarsa, pengujian Anda akan gagal.
	Frekuensi pengujian	Atur seberapa sering pengujian dijalankan dari setiap lokasi pengujian. Dengan frekuensi default lima menit dan lima lokasi pengujian, situs Anda diuji rata-rata setiap menit.
	Lokasi pengujian	Server kami mengirim permintaan web ke URL Anda dari lokasi ini. Jumlah minimum lokasi pengujian yang kami rekomendasikan adalah lima untuk memastikan bahwa Anda dapat membedakan masalah di situs web Anda dari masalah jaringan. Anda dapat memilih hingga 16 lokasi.
Info pengujian standar
	Kata kerja permintaan HTTP	Tunjukkan tindakan apa yang ingin Anda ambil dengan permintaan Anda.
	Badan permintaan	Data kustom yang terkait dengan permintaan HTTP Anda. Anda dapat mengunggah file Anda sendiri, memasukkan konten Anda, atau menonaktifkan fitur ini.
	Menambahkan header kustom	Pasangan nilai kunci yang menentukan parameter operasi.
Kriteria keberhasilan
	Batas Waktu Pengujian	Kurangi nilai ini untuk mendapatkan pemberitahuan tentang respons lambat. Pengujian dihitung sebagai kegagalan jika respons dari situs Anda tidak diterima dalam periode ini. Jika Anda memilih Uraikan permintaan dependen, semua gambar, file gaya, skrip, dan sumber daya dependen lainnya harus diterima dalam periode ini.
	Respons HTTP	Kode status yang dikembalikan dihitung sebagai berhasil. Angka 200 adalah kode yang menunjukkan bahwa halaman web normal dikembalikan.
	Kecocokan konten	String, seperti "Selamat datang!" Kami menguji bahwa kecocokan peka huruf besar/kecil yang tepat muncul di setiap respons. Ini harus berupa string polos, tanpa kartubebas. Ingatlah jika konten halaman berubah, Anda mungkin perlu memperbaruinya. Hanya karakter bahasa Inggris yang didukung dengan kecocokan konten.

Penting

TrackAvailability() mengharuskan melakukan investasi pengembang secara tertulis dan maintanining kode kustom yang berpotensi kompleks.

Pengujian standar harus selalu digunakan jika memungkinkan, karena membutuhkan sedikit investasi, tidak ada pemeliharaan, dan memiliki beberapa prasyarat.

Contoh ini dirancang hanya untuk menunjukkan kepada Anda mekanisme cara TrackAvailability() kerja panggilan API dalam aplikasi Azure Functions. Ini tidak menunjukkan cara menulis kode pengujian HTTP yang mendasar atau logika bisnis yang diperlukan untuk mengubah contoh ini menjadi pengujian ketersediaan yang berfungsi penuh.

Prasyarat

Sumber daya Application Insights berbasis ruang kerja
Akses ke kode sumber aplikasi Azure Functions
Keahlian pengembang untuk menulis kode kustom untuk TrackAvailability(), disesuaikan dengan kebutuhan bisnis spesifik Anda

Memulai

Catatan

Untuk mengikuti instruksi ini, Anda harus menggunakan paket App Service atau paket Functions Premium untuk mengizinkan pengeditan kode di Editor App Service.

Jika Anda menguji di belakang jaringan virtual atau menguji titik akhir nonpublik, Anda harus menggunakan paket Functions Premium.

Membuat fungsi pemicu timer

Buat sumber daya Azure Functions dengan pertimbangan berikut:
- Jika Anda belum memiliki sumber daya Application Insights untuk fungsi yang dipicu timer, sumber daya tersebut dibuat secara default saat Anda membuat aplikasi Azure Functions.
- Jika Anda sudah memiliki sumber daya Application Insights, buka tab Pemantauan saat membuat aplikasi Azure Functions, dan pilih atau masukkan nama sumber daya yang ada di menu dropdown Application Insights:
Ikuti instruksi untuk membuat fungsi yang dipicu timer.

Menambahkan dan mengedit kode di Editor App Service

Buka aplikasi Azure Functions anda yang disebarkan, dan di bawah Alat Pengembangan, pilih tab Editor App Service.

Untuk membuat file baru, klik kanan di bawah fungsi pemicu timer Anda (misalnya, TimerTrigger1) dan pilih File Baru. Kemudian masukkan nama file dan pilih Enter.

Buat file baru yang disebut function.proj dan tempelkan kode berikut:

<Project Sdk="Microsoft.NET.Sdk"> 
    <PropertyGroup> 
        <TargetFramework>netstandard2.0</TargetFramework> 
    </PropertyGroup> 
    <ItemGroup> 
        <PackageReference Include="Microsoft.ApplicationInsights" Version="2.15.0" /> <!-- Ensure you’re using the latest version --> 
    </ItemGroup> 
</Project>

Buat file baru bernama runAvailabilityTest.csx dan tempelkan kode berikut:

using System.Net.Http; 

public async static Task RunAvailabilityTestAsync(ILogger log) 
{ 
    using (var httpClient = new HttpClient()) 
    { 
        // TODO: Replace with your business logic 
        await httpClient.GetStringAsync("https://www.bing.com/"); 
    } 
}

Ganti kode yang ada di run.csx dengan yang berikut ini:

#load "runAvailabilityTest.csx" 

using System; 

using System.Diagnostics; 

using Microsoft.ApplicationInsights; 

using Microsoft.ApplicationInsights.Channel; 

using Microsoft.ApplicationInsights.DataContracts; 

using Microsoft.ApplicationInsights.Extensibility; 

private static TelemetryClient telemetryClient; 

// ============================================================= 

// ****************** DO NOT MODIFY THIS FILE ****************** 

// Business logic must be implemented in RunAvailabilityTestAsync function in runAvailabilityTest.csx 

// If this file does not exist, add it first 

// ============================================================= 

public async static Task Run(TimerInfo myTimer, ILogger log, ExecutionContext executionContext) 

{ 
    if (telemetryClient == null) 
    { 
        // Initializing a telemetry configuration for Application Insights based on connection string 

        var telemetryConfiguration = new TelemetryConfiguration(); 
        telemetryConfiguration.ConnectionString = Environment.GetEnvironmentVariable("APPLICATIONINSIGHTS_CONNECTION_STRING"); 
        telemetryConfiguration.TelemetryChannel = new InMemoryChannel(); 
        telemetryClient = new TelemetryClient(telemetryConfiguration); 
    } 

    string testName = executionContext.FunctionName; 
    string location = Environment.GetEnvironmentVariable("REGION_NAME"); 
    var availability = new AvailabilityTelemetry 
    { 
        Name = testName, 

        RunLocation = location, 

        Success = false, 
    }; 

    availability.Context.Operation.ParentId = Activity.Current.SpanId.ToString(); 
    availability.Context.Operation.Id = Activity.Current.RootId; 
    var stopwatch = new Stopwatch(); 
    stopwatch.Start(); 

    try 
    { 
        using (var activity = new Activity("AvailabilityContext")) 
        { 
            activity.Start(); 
            availability.Id = Activity.Current.SpanId.ToString(); 
            // Run business logic 
            await RunAvailabilityTestAsync(log); 
        } 
        availability.Success = true; 
    } 

    catch (Exception ex) 
    { 
        availability.Message = ex.Message; 
        throw; 
    } 

    finally 
    { 
        stopwatch.Stop(); 
        availability.Duration = stopwatch.Elapsed; 
        availability.Timestamp = DateTimeOffset.UtcNow; 
        telemetryClient.TrackAvailability(availability); 
        telemetryClient.Flush(); 
    } 
}

Catatan

Pengujian yang dibuat dengan TrackAvailability() akan muncul dengan CUSTOM di samping nama pengujian.

Cuplikan layar memperlihatkan pengalaman Ketersediaan dengan dua pengujian berbeda yang tercantum.

Pemberitahuan ketersediaan

Pemberitahuan diaktifkan secara otomatis secara default, tetapi untuk mengonfigurasi pemberitahuan sepenuhnya, Anda awalnya harus membuat pengujian ketersediaan Anda.

Pengaturan	Deskripsi
Mendekati real time	Sebaiknya gunakan pemberitahuan hampir real time. Mengonfigurasi jenis pemberitahuan ini dilakukan setelah pengujian ketersediaan Anda dibuat.
Ambang lokasi pemberitahuan	Kami merekomendasikan minimal 3/5 lokasi. Hubungan optimal antara ambang lokasi pemberitahuan dan jumlah lokasi pengujian adalah ambang lokasi pemberitahuan = jumlah lokasi pengujian - 2, dengan minimal lima lokasi pengujian.

Tag populasi lokasi

Anda dapat menggunakan tag populasi berikut untuk atribut lokasi geografis saat Anda menyebarkan pengujian standar atau pengujian ping URL dengan menggunakan Azure Resource Manager.

Penyedia	Nama tampilan	Nama populasi
Azure
	Australia Timur	emea-au-syd-edge
	Brasil Selatan	latam-br-gru-edge
	AS Tengah	us-fl-mia-edge
	Asia Timur	apac-hk-hkn-azr
	AS Timur	us-va-ash-azr
	Prancis Selatan (Dulu Prancis Tengah)	emea-ch-zrh-edge
	Prancis Tengah	emea-fr-pra-edge
	Jepang Timur	apac-jp-kaw-edge
	Eropa Utara	emea-gb-db3-azr
	AS Tengah Bagian Utara	us-il-ch1-azr
	US Tengah Selatan	us-tx-sn1-azr
	Asia Tenggara	apac-sg-sin-azr
	UK Barat	emea-se-sto-edge
	Eropa Barat	emea-nl-ams-azr
	US Barat	us-ca-sjc-azr
	UK Selatan	emea-ru-msa-edge
Azure Government
	Virginia Gov (US)	usgov-va-azr
	Gov (US) Arizona	usgov-phx-azr
	Gov (US) Texas	usgov-tx-azr
	USDoD Timur	usgov-ddeast-azr
	USDoD Pusat	usgov-ddcentral-azr
Microsoft Azure dioperasikan oleh 21Vianet
	Tiongkok Timur	mc-cne-azr
	Tiongkok Timur 2	mc-cne2-azr
	Tiongkok Utara	mc-cnn-azr
	Tiongkok Utara 2	mc-cnn2-azr

Fungsikan pemberitahuan

Catatan

Dengan peringatan terpadu yang baru, keparahan aturan peringatan dan preferensi pemberitahuan dengan grup tindakanharus dikonfigurasi dalam pengalaman peringatan. Tanpa langkah-langkah berikut, Anda hanya akan menerima pemberitahuan di portal.

Setelah Anda menyimpan uji ketersediaan, buka menu konteks berdasarkan pengujian yang Anda buat, lalu pilih halaman Buka Aturan (Pemberitahuan).
Pada halaman Aturan pemberitahuan, buka pemberitahuan Anda, lalu pilih Edit di bilah navigasi atas. Di sini Anda dapat mengatur tingkat keparahan, deskripsi aturan, dan grup tindakan yang memiliki preferensi pemberitahuan yang ingin Anda gunakan untuk aturan pemberitahuan ini.

Kriteria pemberitahuan

Pemberitahuan ketersediaan yang diaktifkan secara otomatis memicu satu email saat titik akhir menjadi tidak tersedia, dan email lain saat tersedia lagi. Pemberitahuan ketersediaan yang dibuat melalui pengalaman ini berbasis status. Ketika kriteria pemberitahuan terpenuhi, satu pemberitahuan akan dihasilkan ketika situs web terdeteksi tidak tersedia. Jika situs web masih tidak berfungsi saat kriteria pemberitahuan dievaluasi, situs web tersebut tidak akan menghasilkan pemberitahuan baru.

Misalnya, situs web Anda tidak berfungsi selama satu jam dan Anda menyiapkan pemberitahuan email dengan frekuensi evaluasi 15 menit. Anda hanya menerima email ketika situs web tidak berfungsi dan email lain saat kembali online. Anda tidak menerima pemberitahuan berkelanjutan setiap 15 menit untuk mengingatkan Anda bahwa situs web masih tidak tersedia.

Mengubah kriteria pemberitahuan

Anda mungkin tidak ingin menerima pemberitahuan ketika situs web Anda tidak berfungsi hanya untuk waktu yang singkat, misalnya, selama pemeliharaan. Anda dapat mengubah frekuensi evaluasi ke nilai yang lebih tinggi dari waktu henti yang diharapkan, hingga 15 menit. Anda juga dapat meningkatkan ambang lokasi pemberitahuan sehingga hanya memicu pemberitahuan jika situs web tidak berfungsi untuk sejumlah wilayah tertentu.

Tip

Untuk waktu henti terjadwal yang lebih lama, nonaktifkan aturan pemberitahuan untuk sementara waktu atau buat aturan kustom. Ini memberi Anda lebih banyak opsi untuk memperhitungkan waktu henti.

Untuk membuat perubahan pada ambang lokasi, periode agregasi, dan frekuensi pengujian, buka halaman Edit aturan pemberitahuan (lihat langkah 2 di bawah Aktifkan pemberitahuan), lalu pilih kondisi untuk membuka jendela Konfigurasikan logika sinyal.

Membuat aturan pemberitahuan kustom

Jika Anda memerlukan kapabilitas tingkat lanjut, Anda dapat membuat aturan pemberitahuan kustom pada tab Pemberitahuan . Pilih Buat>aturan Pemberitahuan. Pilih Metrik untuk Jenis sinyal untuk menampilkan semua sinyal yang tersedia dan pilih Ketersediaan.

Aturan pemberitahuan kustom menawarkan nilai yang lebih tinggi untuk periode agregasi (hingga 24 jam, bukan 6 jam) dan frekuensi pengujian (hingga 1 jam, bukan 15 menit). Ini juga menambahkan opsi untuk menentukan logika lebih lanjut dengan memilih operator, jenis agregasi, dan nilai ambang yang berbeda.

Pemberitahuan tentang X dari lokasi Y yang melaporkan kegagalan: Aturan pemberitahuan X di luar lokasi Y diaktifkan secara default dalam pengalaman pemberitahuan terpadu baru saat Anda membuat pengujian ketersediaan baru. Anda dapat memilih keluar dengan memilih opsi "klasik" atau dengan memilih untuk menonaktifkan aturan pemberitahuan. Konfigurasikan grup tindakan untuk menerima pemberitahuan saat pemberitahuan memicu dengan mengikuti langkah-langkah sebelumnya. Tanpa langkah ini, Anda hanya menerima pemberitahuan di portal saat aturan memicu.
Pemberitahuan tentang metrik ketersediaan: Dengan menggunakan pemberitahuan terpadu baru, Anda juga dapat memberi tahu tentang ketersediaan agregat tersegmentasi dan metrik durasi pengujian:
1. Pilih sumber daya Application Insights dalam pengalaman Metrik , dan pilih metrik Ketersediaan .
2. Opsi Konfigurasi pemberitahuan dari menu akan membawa Anda ke pengalaman baru tempat Anda dapat memilih pengujian atau lokasi tertentu untuk menyiapkan aturan pemberitahuan. Anda juga dapat mengonfigurasi grup tindakan untuk aturan pemberitahuan ini di sini.
Pemberitahuan tentang kueri analitik kustom: Dengan menggunakan pemberitahuan terpadu baru, Anda dapat memberi tahu kueri log kustom. Dengan kueri kustom, Anda dapat memberi tahu syarat arbitrer apa pun yang membantu Anda mendapatkan sinyal masalah ketersediaan yang paling dapat diandalkan. Ini juga berlaku jika Anda mengirim hasil ketersediaan kustom dengan menggunakan TrackAvailability SDK.

Metrik pada data ketersediaan mencakup hasil ketersediaan kustom apa pun yang mungkin Anda kirimkan dengan memanggil TrackAvailability SDK. Anda dapat menggunakan pemberitahuan tentang dukungan metrik untuk memberi tahu hasil ketersediaan kustom.

Mengotomatiskan pemberitahuan

Untuk mengotomatiskan proses ini dengan templat Azure Resource Manager, lihat Membuat pemberitahuan metrik dengan templat Azure Resource Manager.

Melihat hasil uji ketersediaan Anda

Bagian ini menjelaskan cara meninjau hasil pengujian ketersediaan di portal Azure dan mengkueri data menggunakan Analitik Log. Hasil pengujian ketersediaan dapat divisualisasikan dengan tampilan Plot Garis dan Sebar.

Memeriksa ketersediaan

Mulailah dengan meninjau grafik dalam pengalaman Ketersediaan di portal Azure.

Secara default, pengalaman Ketersediaan memperlihatkan grafik baris. Ubah tampilan menjadi Scatter Plot (alihkan di atas grafik) untuk melihat sampel hasil pengujian yang memiliki detail langkah pengujian diagnostik di dalamnya. Mesin pengujian menyimpan detail diagnostik untuk pengujian yang mengalami kegagalan. Untuk pengujian yang berhasil, detail diagnostik disimpan untuk subset eksekusi. Untuk melihat pengujian, nama pengujian, dan lokasi, arahkan mouse ke salah satu titik hijau atau salib merah.

Pilih pengujian atau lokasi tertentu. Atau Anda dapat mengurangi periode waktu untuk melihat lebih banyak hasil sekeliling periode waktu yang diinginkan. Gunakan Search Explorer untuk melihat hasil dari semua eksekusi. Atau Anda dapat menggunakan kueri Analitik Log untuk menjalankan laporan kustom pada data ini.

Untuk melihat detail transaksi end-to-end, di bawah Telusuri, pilih Berhasil atau Gagal. Kemudian pilih sampel. Anda juga dapat sampai ke detail transaksi ujung ke ujung dengan memilih poin data pada grafik.

Cuplikan layar memperlihatkan pemilihan uji ketersediaan sampel.

Memeriksa dan mengedit pengujian

Untuk mengedit, menonaktifkan sementara, atau menghapus pengujian, buka menu konteks (elipsis) oleh pengujian, lalu pilih Edit. Mungkin perlu waktu hingga 20 menit agar perubahan konfigurasi disebarluaskan ke semua agen pengujian setelah perubahan dilakukan.

Tip

Anda mungkin ingin menonaktifkan pengujian ketersediaan atau aturan pemberitahuan yang terkait dengannya saat melakukan pemeliharaan pada layanan Anda.

Jika Anda melihat kegagalan

Buka tampilan Detail transaksi end-to-end dengan memilih salib merah pada Plot Sebar.

Di sini Anda dapat:

Tinjau Laporan Pemecahan Masalah untuk menentukan apa yang berpotensi menyebabkan pengujian Anda gagal.
Memeriksa respons yang diterima dari server Anda.
Mendiagnosis kegagalan dengan telemetri pihak server terkait yang dikumpulkan saat memproses uji ketersediaan yang gagal.
Lacak masalah dengan mencatat masalah atau item kerja di Git atau Azure Boards. Bug berisi tautan ke peristiwa di portal Azure.
Membuka hasil pengujian web di Visual Studio.

Untuk mempelajari selengkapnya tentang pengalaman diagnostik transaksi end-to-end, lihat dokumentasi diagnostik transaksi.

Pilih baris pengecualian untuk melihat detail pengecualian sisi server yang menyebabkan pengujian ketersediaan sintetis gagal. Anda juga bisa mendapatkan rekam jepret debug untuk diagnostik tingkat kode yang lebih lengkap.

Selain hasil mentah, Anda juga dapat melihat dua metrik ketersediaan utama di penjelajah metrik:

Ketersediaan: Persentase pengujian yang berhasil, di semua eksekusi pengujian.
Durasi Pengujian: Durasi pengujian rata-rata di semua eksekusi pengujian.

Kueri di Analitik Log

Anda dapat menggunakan Analitik Log untuk melihat hasil ketersediaan (availabilityResults), dependensi (dependencies), dan lainnya. Untuk mempelajari selengkapnya tentang Analitik Log, lihat Gambaran umum kueri log.

Memigrasikan pengujian ping URL klasik ke pengujian standar

Langkah-langkah berikut memandu Anda melalui proses pembuatan pengujian standar yang mereplikasi fungsionalitas pengujian ping URL Anda. Ini memungkinkan Anda untuk lebih mudah mulai menggunakan fitur lanjutan pengujian standar menggunakan pengujian ping URL yang dibuat sebelumnya.

Penting

Biaya dikaitkan dengan menjalankan pengujian standar. Setelah membuat pengujian standar, Anda akan dikenakan biaya untuk eksekusi pengujian. Lihat harga Azure Monitor sebelum memulai proses ini.

Prasyarat

Pengujian ping URL apa pun dalam Application Insights
Akses Azure PowerShell

Memulai

Sambungkan ke langganan Anda dengan Azure PowerShell (Connect-AzAccount + Set-AzContext).

Cantumkan semua pengujian ping URL dalam langganan saat ini:

Get-AzApplicationInsightsWebTest | `
Where-Object { $_.WebTestKind -eq "ping" } | `
Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;

Temukan pengujian ping URL yang ingin Anda migrasikan dan rekam grup dan nama sumber dayanya.

Buat pengujian standar dengan logika yang sama dengan pengujian ping URL menggunakan perintah berikut, yang berfungsi untuk titik akhir HTTP dan HTTPS.

$resourceGroup = "pingTestResourceGroup";
$appInsightsComponent = "componentName";
$pingTestName = "pingTestName";
$newStandardTestName = "newStandardTestName";

$componentId = (Get-AzApplicationInsights -ResourceGroupName $resourceGroup -Name $appInsightsComponent).Id;
$pingTest = Get-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
$pingTestRequest = ([xml]$pingTest.ConfigurationWebTest).WebTest.Items.Request;
$pingTestValidationRule = ([xml]$pingTest.ConfigurationWebTest).WebTest.ValidationRules.ValidationRule;

$dynamicParameters = @{};

if ($pingTestRequest.IgnoreHttpStatusCode -eq [bool]::FalseString) {
$dynamicParameters["RuleExpectedHttpStatusCode"] = [convert]::ToInt32($pingTestRequest.ExpectedHttpStatusCode, 10);
}

if ($pingTestValidationRule -and $pingTestValidationRule.DisplayName -eq "Find Text" `
-and $pingTestValidationRule.RuleParameters.RuleParameter[0].Name -eq "FindText" `
-and $pingTestValidationRule.RuleParameters.RuleParameter[0].Value) {
$dynamicParameters["ContentMatch"] = $pingTestValidationRule.RuleParameters.RuleParameter[0].Value;
$dynamicParameters["ContentPassIfTextFound"] = $true;
}

New-AzApplicationInsightsWebTest @dynamicParameters -ResourceGroupName $resourceGroup -Name $newStandardTestName `
-Location $pingTest.Location -Kind 'standard' -Tag @{ "hidden-link:$componentId" = "Resource" } -TestName $newStandardTestName `
-RequestUrl $pingTestRequest.Url -RequestHttpVerb "GET" -GeoLocation $pingTest.PropertiesLocations -Frequency $pingTest.Frequency `
-Timeout $pingTest.Timeout -RetryEnabled:$pingTest.RetryEnabled -Enabled:$pingTest.Enabled `
-RequestParseDependent:($pingTestRequest.ParseDependentRequests -eq [bool]::TrueString);

Pengujian standar baru tidak memiliki aturan pemberitahuan secara default, sehingga tidak membuat pemberitahuan yang bising. Tidak ada perubahan yang dilakukan pada pengujian ping URL Anda sehingga Anda dapat terus mengandalkannya untuk pemberitahuan.

Validasi fungsionalitas pengujian standar baru, lalu perbarui aturan pemberitahuan Anda yang mereferensikan pengujian ping URL untuk mereferensikan pengujian standar sebagai gantinya.
Nonaktifkan atau hapus pengujian ping URL. Untuk melakukannya dengan Azure PowerShell, Anda dapat menggunakan perintah ini:
```
Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
```

Menguji di balik firewall

Untuk memastikan ketersediaan titik akhir di balik firewall, aktifkan pengujian ketersediaan publik atau jalankan pengujian ketersediaan dalam skenario yang terputus atau tidak ada ingress.

Pengaktifan uji ketersediaan publik

Pastikan situs web internal Anda memiliki catatan Sistem Nama Domain (DNS) publik. Pengujian ketersediaan gagal jika DNS tidak dapat diselesaikan. Untuk informasi selengkapnya, lihat Membuat nama domain kustom untuk aplikasi internal.

Peringatan

Alamat IP yang digunakan oleh layanan pengujian ketersediaan dibagikan dan dapat mengekspos titik akhir layanan yang dilindungi firewall Anda ke pengujian lain. Pemfilteran alamat IP saja tidak mengamankan lalu lintas layanan Anda, jadi disarankan untuk menambahkan header kustom tambahan untuk memverifikasi asal permintaan web. Untuk informasi selengkapnya, lihat Tag layanan jaringan virtual.

Mengautentikasi lalu lintas

Atur header kustom dalam pengujian standar untuk memvalidasi lalu lintas.

Buat string alfanumerik tanpa spasi untuk mengidentifikasi pengujian ketersediaan ini (misalnya, MyAppAvailabilityTest). Dari sini, kami menyebut string ini sebagai pengidentifikasi string uji ketersediaan.
Tambahkan header kustom X-Customer-InstanceId dengan nilai ApplicationInsightsAvailability:<your availability test string identifier> di bawah bagian Info pengujian standar saat membuat atau memperbarui pengujian ketersediaan Anda.
Pastikan layanan Anda memeriksa apakah lalu lintas masuk menyertakan header dan nilai yang ditentukan dalam langkah-langkah sebelumnya.

Atau, atur pengidentifikasi string uji ketersediaan sebagai parameter kueri.

Contoh: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your availability test string identifier>

Mengonfigurasi firewall Anda untuk mengizinkan permintaan masuk dari pengujian ketersediaan

Catatan

Contoh ini khusus untuk penggunaan tag layanan kelompok keamanan jaringan. Banyak layanan Azure menerima tag layanan, masing-masing memerlukan langkah-langkah konfigurasi yang berbeda.

Untuk menyederhanakan pengaktifan layanan Azure tanpa mengotorisasi IP individual atau mempertahankan daftar IP terbaru, gunakan Tag layanan. Terapkan tag ini di seluruh Azure Firewall dan grup keamanan jaringan, memungkinkan akses layanan uji ketersediaan ke titik akhir Anda. Tag ApplicationInsightsAvailability layanan berlaku untuk semua pengujian ketersediaan.

Jika Anda menggunakan grup keamanan jaringan Azure, buka sumber daya grup keamanan jaringan Anda dan di bawah Pengaturan, buka pengalaman Aturan keamanan masuk, lalu pilih Tambahkan.
Selanjutnya, pilih Tag Layanan sebagai Sumber dan ApplicationInsightsAvailability sebagai tag layanan Sumber. Gunakan port terbuka 80 (http) dan 443 (https) untuk lalu lintas masuk dari tag layanan.

Untuk mengelola akses saat titik akhir Anda berada di luar Azure atau saat tag layanan bukan opsi, izinkan alamat IP agen pengujian web kami. Anda dapat mengkueri rentang IP menggunakan PowerShell, Azure CLI, atau panggilan REST dengan API Tag Layanan. Untuk daftar komprehensif tag layanan saat ini dan detail IP-nya, unduh file JSON.

Di sumber daya grup keamanan jaringan Anda, di bawah Pengaturan, buka pengalaman Aturan keamanan masuk, lalu pilih Tambahkan.
Selanjutnya, pilih Alamat IP sebagai Sumber Anda. Kemudian tambahkan alamat IP Anda dalam daftar yang dibatasi koma di alamat IP Sumber/rentang CIRD.

Skenario pemutusan atau tanpa ingress

Sambungkan sumber daya Application Insights Anda ke titik akhir layanan internal Anda menggunakan Azure Private Link.
Tulis kode kustom untuk menguji server internal atau titik akhir Anda secara berkala. Kirim hasilnya ke Application Insights menggunakan API TrackAvailability() dalam paket SDK inti.

Konfigurasi TLS yang didukung

Untuk memberikan enkripsi terbaik di kelasnya, semua pengujian ketersediaan menggunakan Transport Layer Security (TLS) 1.2 dan 1.3 sebagai mekanisme enkripsi pilihan. Selain itu, suite Cipher dan kurva Elips berikut juga didukung dalam setiap versi.

TLS 1.3 saat ini hanya tersedia di wilayah uji ketersediaan NorthCentralUS, CentralUS, EastUS, SouthCentralUS, dan WestUS.

Versi	Cipher suite	Kurva elips
TLS 1.2	• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256	• NistP384 • NistP256
TLS 1.3	• TLS_AES_256_GCM_SHA384 • TLS_AES_128_GCM_SHA256	• NistP384 • NistP256

Menghentikan konfigurasi TLS

Penting

Pada 1 Maret 2025, selaras dengan penghentian TLS warisan luas Azure, versi protokol TLS 1.0/1.1 dan suite warisan TLS 1.2/1.3 dan kurva Elips akan dihentikan untuk pengujian ketersediaan Application Insights.

TLS 1.0 dan TLS 1.1

TLS 1.0 dan TLS 1.1 sedang dihentikan.

TLS 1.2 dan TLS 1.3

Versi	Cipher suite	Kurva elips
TLS 1.2	• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA • TLS_RSA_WITH_AES_256_GCM_SHA384 • TLS_RSA_WITH_AES_128_GCM_SHA256 • TLS_RSA_WITH_AES_256_CBC_SHA256 • TLS_RSA_WITH_AES_128_CBC_SHA256 • TLS_RSA_WITH_AES_256_CBC_SHA • TLS_RSA_WITH_AES_128_CBC_SHA	• kurva25519
TLS 1.3		• kurva25519

Pemecahan Masalah

Peringatan

Kami baru-baru ini mengaktifkan TLS 1.3 dalam pengujian ketersediaan. Jika Anda melihat pesan kesalahan baru sebagai hasilnya, pastikan bahwa klien yang berjalan di Windows Server 2022 dengan TLS 1.3 diaktifkan dapat tersambung ke titik akhir Anda. Jika Anda tidak dapat melakukan ini, Anda dapat mempertimbangkan untuk menonaktifkan TLS 1.3 untuk sementara pada titik akhir Anda sehingga pengujian ketersediaan akan kembali ke versi TLS yang lebih lama.

Untuk informasi tambahan, periksa artikel pemecahan masalah.

Buku kerja Waktu Henti & Pemadaman

Bagian ini memperkenalkan cara sederhana untuk menghitung dan melaporkan perjanjian tingkat layanan (SLA) untuk pengujian web melalui satu panel kaca di seluruh sumber daya Application Insights dan langganan Azure Anda. Laporan pemadaman dan waktu henti menyediakan kueri dan visualisasi data bawaan yang dapat diandalkan untuk meningkatkan pemahaman Anda tentang konektivitas pelanggan, waktu respons aplikasi yang khas, dan waktu henti yang sering terjadi.

Templat buku kerja SLA dapat diakses dari sumber daya Application Insights Anda dengan dua cara:

Buka Pengalaman ketersediaan, lalu pilih Laporan SLA dari bilah navigasi atas.
Buka pengalaman Buku Kerja, lalu pilih Templat Waktu Henti & Pemadaman.

Fleksibilitas parameter

Parameter yang diatur dalam buku kerja memengaruhi sisa laporan.

Subscriptions, App Insights Resources, dan Web Test: Parameter ini menentukan opsi sumber daya tingkat tinggi Anda. Mereka didasarkan pada kueri Analitik Log dan digunakan dalam setiap kueri laporan.
Failure Threshold dan Outage Window: Anda dapat menggunakan parameter ini untuk menentukan kriteria Anda sendiri untuk pemadaman layanan. Contohnya adalah kriteria pemberitahuan ketersediaan Application Insights berdasarkan penghitung lokasi yang gagal selama periode yang dipilih. Ambang batas khas adalah tiga lokasi selama lima menit.
Maintenance Period: Anda dapat menggunakan parameter ini untuk memilih frekuensi pemeliharaan umum Anda. Maintenance Window adalah pemilih tanggalwaktu untuk contoh periode pemeliharaan. Semua data yang terjadi selama periode yang diidentifikasi diabaikan dalam hasil Anda.
Availability Target %: Parameter ini menentukan tujuan target Anda dan mengambil nilai kustom.

Halaman gambaran umum

Halaman gambaran umum berisi informasi tingkat tinggi tentang Anda:

Total SLA (tidak termasuk periode pemeliharaan, jika ditentukan)
Instans pemadaman end-to-end
Waktu henti aplikasi

Instans pemadaman ditentukan sejak pengujian mulai gagal sampai berhasil lolos lagi, sesuai dengan parameter pemadaman Anda. Jika pengujian mulai gagal pada pukul 08.00 dan berhasil lagi pada pukul 10.00, seluruh periode data tersebut dianggap sebagai pemadaman yang sama. Anda juga dapat menyelidiki pemadaman terpanjang yang terjadi selama periode pelaporan Anda.

Beberapa pengujian dapat ditautkan kembali ke sumber daya Application Insights mereka untuk penyelidikan lebih lanjut. Tetapi itu hanya mungkin di sumber daya Application Insights berbasis ruang kerja.

Waktu henti, pemadaman, dan kegagalan

Ada dua tab lagi di samping halaman Gambaran Umum :

Tab Pemadaman & Waktu Henti memiliki informasi tentang total instans pemadaman dan total waktu henti yang dipecah berdasarkan pengujian.
Tab Kegagalan berdasarkan Lokasi memiliki peta geografis lokasi pengujian yang gagal untuk membantu mengidentifikasi area koneksi potensial masalah.

Fitur lainnya

Kustomisasi: Anda dapat mengedit laporan seperti buku kerja Azure Monitor lainnya dan mengkustomisasi kueri atau visualisasi berdasarkan kebutuhan tim Anda.
Analitik Log: Semua kueri dapat dijalankan di Analitik Log dan digunakan di laporan atau dasbor lain. Hapus pembatasan parameter dan gunakan kembali kueri inti.
Akses dan berbagi: Laporan dapat dibagikan dengan tim dan kepemimpinan Anda atau disematkan ke dasbor untuk digunakan lebih lanjut. Pengguna memerlukan izin baca dan akses ke sumber daya Application Insights tempat buku kerja aktual disimpan.

Tanya jawab umum

Bagian ini menyediakan jawaban atas pertanyaan umum.

Umum

Dapatkah saya menjalankan pengujian ketersediaan pada server intranet?

Pengujian ketersediaan berjalan pada titik kehadiran yang didistribusikan di seluruh dunia. Ada dua solusi:

Pintu firewall: Izinkan permintaan ke server Anda dari daftar agen pengujian web yang panjang dan dapat diubah.
Kode kustom: Tulis kode Anda sendiri untuk mengirim permintaan berkala ke server Anda dari dalam intranet Anda. Anda dapat menjalankan pengujian web Visual Studio untuk tujuan ini. Penguji dapat mengirim hasilnya ke Application Insights dengan menggunakan TrackAvailability() API.

Apa string agen pengguna untuk pengujian ketersediaan?

String agen pengguna adalah Mozilla/5.0 (kompatibel; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

Dukungan TLS

Bagaimana penghentian ini memengaruhi perilaku pengujian web saya?

Pengujian ketersediaan bertindak sebagai klien terdistribusi di setiap lokasi pengujian web yang didukung. Setiap kali pengujian web dijalankan, layanan uji ketersediaan mencoba menjangkau titik akhir jarak jauh yang ditentukan dalam konfigurasi pengujian web. Pesan Halo Klien TLS dikirim yang berisi semua konfigurasi TLS yang saat ini didukung. Jika titik akhir jarak jauh berbagi konfigurasi TLS umum dengan klien uji ketersediaan, maka jabat tangan TLS berhasil. Jika tidak, pengujian web gagal dengan kegagalan jabat tangan TLS.

Bagaimana cara memastikan pengujian web saya tidak terpengaruh?

Untuk menghindari dampak apa pun, setiap titik akhir jarak jauh (termasuk permintaan dependen) pengujian web Anda berinteraksi dengan kebutuhan untuk mendukung setidaknya satu kombinasi Versi Protokol, Cipher Suite, dan Kurva Elips yang sama dengan yang dilakukan pengujian ketersediaan. Jika titik akhir jarak jauh tidak mendukung konfigurasi TLS yang diperlukan, titik akhir perlu diperbarui dengan dukungan untuk beberapa kombinasi konfigurasi TLS pasca-penghentian yang disebutkan di atas. Titik akhir ini dapat ditemukan melalui melihat Detail Transaksi pengujian web Anda (idealnya untuk eksekusi pengujian web yang berhasil).

Bagaimana cara memvalidasi konfigurasi TLS apa yang didukung titik akhir jarak jauh?

Ada beberapa alat yang tersedia untuk menguji konfigurasi TLS apa yang didukung titik akhir. Salah satu caranya adalah dengan mengikuti contoh yang dirinci di halaman ini. Jika titik akhir jarak jauh Anda tidak tersedia melalui internet Publik, Anda perlu memastikan Anda memvalidasi konfigurasi TLS yang didukung pada titik akhir jarak jauh dari komputer yang memiliki akses untuk memanggil titik akhir Anda.

Catatan

Untuk langkah-langkah untuk mengaktifkan konfigurasi TLS yang diperlukan di server web Anda, yang terbaik adalah menjangkau tim yang memiliki platform hosting tempat server web Anda berjalan jika prosesnya tidak diketahui.

Setelah 1 Maret 2025, apa perilaku pengujian web untuk tes yang terkena dampak?

Tidak ada satu jenis pengecualian bahwa semua kegagalan jabat tangan TLS yang terpengaruh oleh penghentian ini akan hadir dengan diri mereka sendiri. Namun, pengecualian paling umum yang akan gagal dengan pengujian web Anda adalah The request was aborted: Couldn't create SSL/TLS secure channel. Anda juga akan dapat melihat kegagalan terkait TLS di Langkah Pemecahan Masalah Transportasi TLS untuk hasil pengujian web yang berpotensi terpengaruh.

Dapatkah saya melihat konfigurasi TLS apa yang saat ini digunakan oleh pengujian web saya?

Konfigurasi TLS yang dinegosiasikan selama eksekusi pengujian web tidak dapat dilihat. Selama titik akhir jarak jauh mendukung konfigurasi TLS umum dengan pengujian ketersediaan, tidak ada dampak yang harus dilihat pasca-penghentian.

Komponen mana yang memengaruhi penghentian dalam layanan uji ketersediaan?

Penghentian TLS yang dirinci dalam dokumen ini hanya boleh memengaruhi perilaku eksekusi pengujian web uji ketersediaan setelah 1 Maret 2025. Untuk informasi selengkapnya tentang berinteraksi dengan layanan uji ketersediaan untuk operasi CRUD, lihat Dukungan TLS Azure Resource Manager. Sumber daya ini memberikan detail selengkapnya tentang dukungan TLS dan garis waktu penghentian.

Di mana saya bisa mendapatkan dukungan TLS?

Untuk pertanyaan umum sekeliling masalah TLS warisan, lihat Memecahkan masalah TLS.

Bagikan melalui

Uji ketersediaan Application Insights

Jenis pengujian ketersediaan

Membuat pengujian ketersediaan

Prasyarat

Memulai

Pemberitahuan ketersediaan

Tag populasi lokasi

Fungsikan pemberitahuan

Kriteria pemberitahuan

Mengubah kriteria pemberitahuan

Membuat aturan pemberitahuan kustom

Mengotomatiskan pemberitahuan

Melihat hasil uji ketersediaan Anda

Memeriksa ketersediaan

Memeriksa dan mengedit pengujian

Jika Anda melihat kegagalan

Kueri di Analitik Log

Memigrasikan pengujian ping URL klasik ke pengujian standar

Prasyarat

Memulai

Menguji di balik firewall

Pengaktifan uji ketersediaan publik

Mengautentikasi lalu lintas

Mengonfigurasi firewall Anda untuk mengizinkan permintaan masuk dari pengujian ketersediaan

Skenario pemutusan atau tanpa ingress

Konfigurasi TLS yang didukung

Menghentikan konfigurasi TLS

TLS 1.0 dan TLS 1.1

TLS 1.2 dan TLS 1.3

Pemecahan Masalah

Buku kerja Waktu Henti & Pemadaman

Fleksibilitas parameter

Halaman gambaran umum

Waktu henti, pemadaman, dan kegagalan

Fitur lainnya

Tanya jawab umum

Umum

Dapatkah saya menjalankan pengujian ketersediaan pada server intranet?

Apa string agen pengguna untuk pengujian ketersediaan?

Dukungan TLS

Bagaimana penghentian ini memengaruhi perilaku pengujian web saya?

Bagaimana cara memastikan pengujian web saya tidak terpengaruh?

Bagaimana cara memvalidasi konfigurasi TLS apa yang didukung titik akhir jarak jauh?

Setelah 1 Maret 2025, apa perilaku pengujian web untuk tes yang terkena dampak?

Dapatkah saya melihat konfigurasi TLS apa yang saat ini digunakan oleh pengujian web saya?

Komponen mana yang memengaruhi penghentian dalam layanan uji ketersediaan?

Di mana saya bisa mendapatkan dukungan TLS?

Langkah berikutnya

Saran dan Komentar

Sumber Daya Tambahan: