Memantau pemrosesan peristiwa tanpa server

Artikel ini memberikan panduan pemantauan arsitektur yang didorong oleh peristiwa tanpa server.

Pemantauan memberikan wawasan tentang perilaku dan kesehatan sistem Anda. Ini membantu Anda membangun pandangan holistik tentang lingkungan, mengambil tren bersejarah, menghubungkan beragam faktor, dan mengukur perubahan performa, penggunaan, atau tingkat kesalahan. Anda dapat menggunakan pemantauan untuk menentukan pemberitahuan saat kondisi terjadi yang dapat memengaruhi kualitas layanan Anda, atau saat kondisi yang menarik bagi lingkungan spesifik Anda muncul.

Artikel ini menunjukkan penggunaan Azure Monitor untuk memantau aplikasi tanpa server yang dibuat menggunakan Pusat Aktivitas dan Azure Functions. Artikel ini akan membahas metrik yang berguna untuk memantau, menjelaskan cara berintegrasi dengan Application Insights lalu mengambil metrik khusus, dan menyediakan sampel kode.

Asumsi

Artikel ini mengasumsikan Anda memiliki arsitektur seperti yang dijelaskan dalam Arsitektur referensi pemrosesan peristiwa tanpa server. Pada dasarnya:

• Peristiwa tiba di Azure Event Hubs.
• Aplikasi Fungsi dipicu untuk menangani peristiwa tersebut.
• Azure Monitor tersedia untuk digunakan dengan arsitektur Anda.

Metrik dari Azure Monitor

Pertama kita perlu memutuskan metrik mana yang akan dibutuhkan sebelum kita dapat mulai merumuskan wawasan yang berguna tentang arsitektur. Setiap sumber daya melakukan tugas yang berbeda, dan secara bergiliran menghasilkan metrik yang berbeda.

Metrik dari Pusat Aktivitas ini akan menarik untuk mengambil wawasan yang bermanfaat:

• Permintaan masuk
• Permintaan keluar
• Permintaan dibatasi
• Permintaan berhasil
• Pesan masuk
• Pesan keluar
• Pesan yang diambil
• Byte masuk
• Byte keluar
• Byte yang diambil
• Kesalahan pengguna

Demikian pula, metrik dari Azure Functions ini akan menarik untuk mengambil wawasan yang berguna:

• Jumlah eksekusi fungsi
• Koneksi
• Data masuk
• Data keluar
• Kesalahan server HTTP
• Permintaan
• Permintaan dalam antrean aplikasi
• Waktu respons

Menggunakan pembuatan log diagnostik untuk mengambil wawasan

Saat dianalisis bersama, metrik di atas dapat digunakan untuk merumuskan dan mengambil wawasan berikut:

• Tingkat permintaan yang diproses oleh Pusat Aktivitas
• Tingkat permintaan yang diproses oleh Azure Functions
• Throughput Pusat Aktivitas Total
• Kesalahan pengguna
• Durasi Azure Functions
• Latensi menyeluruh
• Latensi pada setiap tahap
• Jumlah pesan yang hilang
• Jumlah pesan yang diproses lebih dari sekali

Untuk memastikan bahwa Pusat Aktivitas mengambil metrik yang diperlukan, pertama-tama kita harus mengaktifkan log diagnostik (yang dinonaktifkan secara default). Lalu kita harus memilih log mana yang diinginkan dan mengonfigurasi ruang kerja Analitik Log yang benar sebagai tujuan untuk mereka.

Kategori log dan metrik yang diminati adalah:

• OperationalLogs
• AutoScaleLogs
• KafkaCoordinatorLogs (untuk beban kerja Apache Kafka)
• KafkaUserErrorLogs (untuk beban kerja Apache Kafka)
• EventHubVNetConnectionEvent
• SemuaMetrics

Dokumentasi Azure memberikan petunjuk tentang cara Menyiapkan log diagnostik untuk pusat aktivitas Azure. Cuplikan layar berikut menunjukkan contoh panel konfigurasi Pengaturan diagnostik dengan kategori log dan metrik yang benar dipilih, dan ruang kerja Analitik Log ditetapkan sebagai tujuan. (Jika sistem eksternal digunakan untuk menganalisis log, opsi untuk Aliran ke pusat aktivitas dapat digunakan sebagai gantinya.)

Catatan

Untuk menggunakan diagnostik log untuk mengambil wawasan, Anda harus membuat pusat aktivitas di namespace yang berbeda. Ini karena kendala di Azure.

Pusat Aktivitas yang ditetapkan dalam namespace Pusat Aktivitas tertentu diwakili dalam metrik Azure Monitor di bawah dimensi bernama EntityName. Di portal Azure, data untuk pusat aktivitas tertentu biasanya dapat dilihat di instans Azure Monitor tersebut. Tetapi saat data metrik dialihkan ke diagnostik log, saat ini tidak ada cara untuk melihat data per pusat aktivitas dengan memfilter dimensi EntityName.

Sebagai solusi, membuat pusat aktivitas di namespace yang berbeda akan membantu memungkinkan untuk menemukan metrik untuk hub tertentu.

Menggunakan Application Insights

Anda dapat mengaktifkan Application Insights untuk mengambil metrik dan telemetri kustom dari Azure Functions. Hal ini memungkinkan Anda untuk menentukan analitik yang sesuai dengan tujuan Anda sendiri, memberikan cara lain untuk mendapatkan wawasan penting untuk skenario pemrosesan peristiwa tanpa server.

Cuplikan layar ini menunjukkan contoh daftar metrik dan telemetri kustom dalam Application Insights:

Metrik kustom default

Di Application Insights, metrik kustom untuk Azure Functions disimpan dalam tabel customMetrics. Ini mencakup nilai-nilai berikut, membentang di atas garis waktu untuk instans fungsi yang berbeda:

• AvgDurationMs
• MaxDurationMs
• MinDurationMs
• Successes
• Failures
• SuccessRate
• Count

Metrik ini dapat digunakan untuk menghitung rata-rata agregat secara efisien di beberapa instans fungsi yang dipanggil dalam jangka panjang.

Cuplikan layar ini memperlihatkan seperti apa metrik kustom default ini saat dilihat di Aplication Insights:

Pesan kustom

Pesan kustom yang dicatat di kode Azure Function (menggunakan ILogger) diperoleh dari tabel Application Insightstraces.

Tabel traces memiliki properti penting berikut (antara lain):

• timestamp
• cloud_RoleInstance
• operation_Id
• operation_Name
• message

Berikut adalah contoh seperti apa pesan khusus di antarmuka Application Insights:

Jika pesan Pusat Aktivitas yang masuk atau EventData[] dicatat sebagai bagian dari pesan kustom ILogger ini, maka itu juga tersedia di Application Insights. Ini bisa sangat berguna.

Untuk skenario pemrosesan peristiwa tanpa server kita, kita akan mencatat isi pesan serial JSON yang diterima dari pusat aktivitas. Hal ini memungkinkan kita untuk mengambil array byte mentah, bersama dengan SystemProperties seperti x-opt-sequence-number, x-opt-offset, dan x-opt-enqueued-time. Untuk menentukan kapan setiap pesan diterima oleh Pusat Aktivitas, properti x-opt-enqueued-time akan digunakan.

Kueri sampel:

traces
| where timestamp between(min_t .. max_t)
| where message contains "Body"
| extend m = parse_json(message))
| project timestamp = todatetime(m.SystemProperties.["x-opt-enqueued-time"])

Kueri sampel akan menampilkan pesan yang mirip dengan hasil contoh berikut, yang akan dicatat secara default di Application Insights. Properti Trigger Details dapat digunakan untuk menemukan dan mengambil wawasan tambahan seputar pesan yang diterima per PartitionId, Offsetdan SequenceNumber.

Contoh hasil kueri sampel:

"message": Trigger Details: PartitionId: 26, Offset: 17194119200, EnqueueTimeUtc: 2020-11-03T02:14:01.7740000Z, SequenceNumber: 843572, Count: 10,

Peringatan

Pustaka untuk Azure Java Functions saat ini memiliki masalah yang mencegah akses ke PartitionID dan PartitionContext saat menggunakan EventHubTrigger. Pelajari selengkapnya dalam laporan masalah GitHub ini.

Melacak alur pesan menggunakan ID transaksi dengan Application Insights

Dalam Application Insights, kita dapat melihat semua telemetri yang terkait dengan transaksi tertentu dengan melakukan permintaan pencarian Transaksi pada nilai Operation Id transaksi. Ini dapat sangat berguna untuk mengambil nilai persentil waktu rata-rata untuk pesan saat transaksi bergerak melalui alur aliran peristiwa.

Cuplikan layar berikut memperlihatkan contoh pencarian Transaksi di antarmuka Application Insights. Operation ID yang diinginkan dimasukkan dalam bidang kueri, diidentifikasi dengan ikon kaca pembesar (dan ditampilkan di sini diuraikan dalam kotak merah). Di bagian bawah panel utama, tab Results menampilkan peristiwa yang cocok dalam urutan berurutan. Di setiap entri peristiwa, nilai Operation ID disorot dengan warna biru tua untuk memudahkan verifikasi.

Kueri yang dibuat untuk ID operasi tertentu akan terlihat seperti berikut ini. Harap diingat bahwa GUID Operation ID ditentukan dalam klausul where * has baris ketiga. Contoh ini semakin mempersempit kueri antara dua datetimes yang berbeda.

union isfuzzy=true availabilityResults, requests, exceptions, pageViews, traces, customEvents, dependencies
| where timestamp > datetime("2020-10-09T06:58:40.024Z") and timestamp < datetime("2020-11-11T06:58:40.024Z")
| where * has "1c8c9d7073a00e4bbdcc8f2e6570e46"
| order by timestamp desc
| take 100

Berikut adalah cuplikan layar tentang seperti apa kueri dan hasil pencocokannya di antarmuka Application Insights:

Mengambil metrik kustom dari Azure Functions

Fungsi .NET

Pencatatan log terstruktur digunakan dalam fungsi .NET Azure untuk mengambil dimensi kustom dalam tabel pelacakan Application Insights. Dimensi kustom ini lalu dapat digunakan untuk mengkueri data.

Sebagai contoh, berikut adalah pernyataan log di TransformingFunction .NET:

log.LogInformation("TransformingFunction: Processed sensorDataJson={sensorDataJson}, " +
    "partitionId={partitionId}, offset={offset} at {enqueuedTimeUtc}, " +
    "inputEH_enqueuedTime={inputEH_enqueuedTime}, processedTime={processedTime}, " +
    "transformingLatencyInMs={transformingLatencyInMs}, processingLatencyInMs={processingLatencyInMs}",
    sensorDataJson,
    partitionId,
    offset,
    enqueuedTimeUtc,
    inputEH_enqueuedTime,
    processedTime,
    transformingLatency,
    processingLatency);

Log yang dihasilkan yang dibuat di Application Insights berisi parameter di atas sebagai dimensi kustom, seperti yang diperlihatkan dalam cuplikan layar ini:

Log ini dapat dikueri sebagai berikut:

traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name == "{Function_Name}"
| where message has "{Function_Name}: Processed"
| project timestamp = todatetime(customDimensions.prop__enqueuedTimeUtc)

Catatan

Untuk memastikan kami tidak memengaruhi performa dalam pengujian ini, kami telah mengaktifkan pengaturan pengambilan sampel log Azure Function untuk Application Insights menggunakan file host.json seperti yang ditunjukkan di bawah ini. Ini artinya semua statistik yang diambil dari pembuatan log dianggap sebagai nilai rata-rata dan bukan jumlah aktual.

contoh host.json:

"logging": {
    "applicationInsights": {
        "samplingExcludedTypes": "Request",
        "samplingSettings": {
            "isEnabled": true
        }
    }
}

Fungsi Java

Saat ini, pembuatan log terstruktur tidak didukung di fungsi Java Azure untuk mengambil dimensi kustom dalam tabel pelacakan Application Insights.

Sebagai contoh, berikut adalah pernyataan log di TransformingFunction Java:

LoggingUtilities.logSuccessInfo(
    context.getLogger(), 
    "TransformingFunction", 
    "SuccessInfo", 
    offset, 
    processedTimeString, 
    dateformatter.format(enqueuedTime), 
    transformingLatency
);

Log yang dihasilkan yang dibuat di Application Insights berisi parameter di atas dalam pesan seperti yang ditunjukkan di bawah ini:

Log ini dapat dikueri sebagai berikut:

traces
| where timestamp between(min_t .. max_t)
// Function name should be of the function consuming from the Event Hub of interest
| where operation_Name in ("{Function name}") and message contains "SuccessInfo"
| project timestamp = todatetime(tostring(parse_json(message).enqueuedTime))

Catatan

Untuk memastikan kami tidak memengaruhi performa dalam pengujian ini, kami telah mengaktifkan pengaturan pengambilan sampel log Azure Function untuk Application Insights menggunakan file host.json seperti yang ditunjukkan di bawah ini. Ini artinya semua statistik yang diambil dari pembuatan log dianggap sebagai nilai rata-rata dan bukan jumlah aktual.

contoh host.json:

"logging": {
    "applicationInsights": {
        "samplingExcludedTypes": "Request",
        "samplingSettings": {
            "isEnabled": true
        }
    }
}

Kontributor

Artikel ini dikelola oleh Microsoft. Awalnya ditulis oleh kontributor berikut.

Penulis utama:

• Rajasa Savant | Insinyur Perangkat Lunak Senior

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Sumber daya terkait

• Pemrosesan peristiwa tanpa server adalah arsitektur referensi yang merinci arsitektur umum jenis ini, dengan sampel kode dan diskusi tentang pertimbangan pentingnya.
• De-batching dan pemfilteran dalam pemrosesan peristiwa tanpa server dengan Pusat Aktivitas menjelaskan lebih rinci bagaimana bagian arsitektur referensi ini berfungsi.
• Skenario tautan privat dalam pemrosesan aliran peristiwa adalah ide solusi untuk menerapkan arsitektur serupa dalam jaringan virtual (VNet) dengan titik akhir privat, untuk meningkatkan keamanan.
• Azure Kubernetes dalam pemrosesan aliran peristiwa menjelaskan variasi arsitektur berbasis peristiwa tanpa server yang berjalan di Azure Kubernetes dengan penskala KEDA.