Edit

Bagikan melalui

Memantau aplikasi layanan mikro di AKS

Azure Monitor
Azure Kubernetes Service (AKS)

Artikel ini menjelaskan praktik terbaik untuk memantau aplikasi layanan mikro yang dijalankan di Azure Kubernetes Service (AKS). Topik tertentu termasuk pengumpulan telemetri, memantau status kluster, metrik, pengelogan, pengelogan terstruktur, dan pelacakan terdistribusi. Yang terakhir diilustrasikan dalam diagram ini:

Diagram that shows the architecture of a drone delivery application.

Unduh file Visio arsitektur ini.

Koleksi telemetri

Di semua aplikasi yang kompleks, pada suatu titik akan terjadi kesalahan. Dalam aplikasi layanan mikro, Anda perlu melacak hal yang terjadi dalam puluhan atau bahkan ratusan layanan. Untuk memahami apa yang terjadi, Anda perlu mengumpulkan telemetri dari aplikasi. Telemetri dapat dibagi menjadi kategori ini: log, jejak, dan metrik.

Log adalah rekaman peristiwa berbasis teks yang terjadi saat aplikasi sedang berjalan. Mereka mencakup hal-hal seperti log aplikasi (pernyataan jejak) dan log server web. Secara terutama, log berguna untuk melakukan forensik dan analisis akar penyebab.

Jejak, juga disebut operasi, menghubungkan langkah-langkah satu permintaan di beberapa panggilan di dalam dan di seluruh layanan mikro. Mereka dapat memberikan pengamatan terstruktur ke dalam interaksi komponen sistem. Jejak dapat dimulai lebih awal dalam proses permintaan, seperti dalam UI aplikasi, dan dapat menyebar melalui layanan jaringan di seluruh jaringan layanan mikro yang menangani permintaan.

  • Rentang adalah unit pekerjaan dalam pelacakan. Setiap rentang terhubung dengan satu jejak dan dapat disarangkan dengan rentang lain. Mereka sering sesuai dengan permintaan individu dalam operasi lintas layanan, tetapi mereka juga dapat menentukan pekerjaan dalam komponen individual dalam layanan. Rentang juga melacak panggilan keluar dari satu layanan ke layanan lain. (Terkadang rentang disebut rekaman dependensi.)

Metrik adalah nilai numerik yang dapat dianalisis. Anda dapat menggunakannya untuk mengamati sistem secara real time (atau mendekati real time) atau untuk menganalisis tren performa dari waktu ke waktu. Untuk memahami sistem secara holistik, Anda perlu mengumpulkan metrik di berbagai tingkat arsitektur, dari infrastruktur fisik hingga aplikasi, termasuk:

  • Metrik tingkat node, mencakup CPU, memori, jaringan, disk, dan penggunaan sistem file. Metrik sistem membantu Anda memahami alokasi sumber daya untuk setiap simpul dalam kluster, dan memecahkan masalah outlier.

  • Metrikkontainer. Untuk aplikasi kontainer, Anda perlu mengumpulkan metrik pada tingkat kontainer, tidak hanya pada tingkat VM.

  • Metrikaplikasi. Metrik ini relevan untuk memahami perilaku layanan. Contohnya termasuk jumlah permintaan HTTP masuk yang diantrekan, latensi permintaan, dan panjang antrean pesan. Aplikasi juga dapat menggunakan metrik kustom yang khusus untuk domain, seperti jumlah transaksi bisnis yang diproses per menit.

  • Metriklayanan dependen. Layanan terkadang memanggil layanan eksternal atau titik akhir, seperti layanan PaaS atau SaaS terkelola. Layanan pihak ketiga mungkin tidak menyediakan metrik. Jika tidak, Anda perlu mengandalkan metrik aplikasi Anda sendiri untuk melacak statistik latensi dan tingkat kesalahan.

Memantau status kluster

Gunakan Azure Monitor untuk memantau kesehatan kluster Anda. Cuplikan layar berikut menunjukkan kluster yang memiliki kesalahan penting dalam pod yang disebarkan pengguna:

Screenshot that shows the Monitor dashboard.

Dari sini, Anda dapat menelusuri lebih lanjut untuk menemukan masalahnya. Misalnya, jika status pod adalah ImagePullBackoff, Kubernetes tidak dapat menarik gambar kontainer dari registri. Masalah ini dapat disebabkan oleh tag kontainer yang tidak valid atau kesalahan autentikasi selama penarikan dari registri.

Jika kontainer crash, kontainer State menjadi Waiting, dengan Reason .CrashLoopBackOff Untuk skenario umum, di mana pod adalah bagian dari set replika dan kebijakan coba lagi adalah Always, masalah ini tidak ditampilkan sebagai kesalahan dalam status kluster. Namun, Anda dapat menjalankan kueri atau menyiapkan peringatan untuk kondisi ini. Untuk informasi selengkapnya, lihat Memahami performa kluster AKS dengan wawasan Kontainer Azure Monitor.

Ada beberapa buku kerja khusus kontainer yang tersedia di panel buku kerja sumber daya AKS. Anda dapat menggunakan buku kerja ini untuk gambaran umum, pemecahan masalah, manajemen, dan wawasan cepat. Cuplikan layar berikut ini memperlihatkan daftar buku kerja yang tersedia secara default untuk beban kerja AKS.

Screenshot that shows the workbooks for an AKS resource.

Metrik

Kami menyarankan agar Anda menggunakan Monitor untuk mengumpulkan dan melihat metrik untuk kluster AKS Anda dan layanan Azure dependen lainnya.

  • Untuk metrik kluster dan kontainer, aktifkan wawasan Kontainer Azure Monitor. Ketika fitur ini diaktifkan, Monitor mengumpulkan metrik memori dan prosesor dari pengontrol, simpul, dan kontainer melalui API Metrik Kubernetes. Untuk informasi selengkapnya tentang metrik yang tersedia dari wawasan Kontainer, lihat Memahami performa kluster AKS dengan wawasan Kontainer Azure Monitor.

  • Gunakan Application Insights untuk mengumpulkan metrik aplikasi. Application Insights adalah layanan manajemen performa aplikasi (APM) yang dapat diperluas. Untuk menggunakannya, Anda memasang paket instrumentasi di aplikasi Anda. Paket ini memantau aplikasi dan mengirim data telemetri ke Application Insights. Paket ini juga dapat menarik data telemetri dari lingkungan host. Data kemudian dikirim ke Monitor. Application Insights juga menyediakan korelasi bawaan dan pelacakan dependensi. (Lihat Pelacakan terdistribusi, nanti di artikel ini.)

Application Insights memiliki throughput maksimum yang diukur dalam peristiwa per detik, dan membatasi telemetri jika laju data melebihi batas. Untuk mengetahui detailnya, lihat Batas Application Insights. Buat instans Application Insights yang berbeda untuk setiap lingkungan, sehingga lingkungan dev/test tidak bersaing dengan telemetri produksi untuk kuota.

Satu operasi dapat menghasilkan banyak peristiwa telemetri, jadi jika aplikasi mengalami volume lalu lintas yang tinggi, pengambilan telemetrinya kemungkinan akan dibatasi. Untuk memitigasi masalah ini, Anda dapat melakukan pengambilan sampel untuk mengurangi lalu lintas telemetri. Tradeoff adalah bahwa metrik Anda akan kurang tepat, kecuali instrumentasi mendukung pra-agregasi. Dalam hal ini, akan ada lebih sedikit sampel jejak untuk pemecahan masalah, tetapi metrik mempertahankan akurasi. Untuk informasi selengkapnya, lihat Mengambil sampel di Application Insights. Anda juga dapat mengurangi volume data dengan melakukan pra-agregasi metrik. Artinya, Anda dapat menghitung nilai statistik, seperti rata-rata dan simpangihan standar, dan mengirim nilai-nilai tersebut alih-alih telemetri mentah. Posting blog ini menjelaskan pendekatan untuk menggunakan Application Insights dalam skala besar: Azure Monitoring dan Analytics dalam Skala Besar.

Jika tingkat data Anda cukup tinggi untuk memicu pembatasan, dan pengambilan sampel atau agregasi tidak dapat diterima, pertimbangkan untuk mengekspor metrik ke database rangkaian waktu, seperti Azure Data Explorer, Prometheus, atau InfluxDB, yang berjalan di kluster.

  • Azure Data Explorer adalah layanan eksplorasi data asli Azure yang sangat dapat diskalakan untuk data log dan telemetri. Ini fitur dukungan untuk beberapa format data, bahasa kueri yang kaya, dan koneksi untuk mengkonsumsi data dalam alat populer seperti Jupyter Notebooks dan Grafana. Azure Data Explorer memiliki konektor bawaan untuk menyerap data log dan metrik melalui Azure Event Hubs. Untuk informasi selengkapnya, lihat Data pemantauan penyerapan dan kueri di Azure Data Explorer.

  • InfluxDB adalah sistem berbasis pendorongan. Agen perlu mendorong metrik. Anda dapat menggunakan tumpukan TICK untuk menyiapkan pemantauan Kubernetes. Selanjutnya, Anda dapat mendorong metrik ke InfluxDB dengan menggunakan Telegraf, yang merupakan agen untuk mengumpulkan dan melaporkan metrik. Anda dapat menggunakan InfluxDB untuk peristiwa tidak teratur dan jenis data string.

  • Prometheus adalah sistem berbasis penarikan. Sistem ini secara berkala mengekstraksi metrik dari lokasi yang telah dikonfigurasikan. Prometheus dapat mengikis metrik yang dihasilkan oleh Azure Monitor atau kube-state-metrics. kube-state-metrics adalah layanan yang mengumpulkan metrik dari server API Kubernetes dan membuatnya tersedia untuk Prometheus (atau scraper yang kompatibel dengan titik akhir klien Prometheus). Untuk metrik sistem, gunakan pengekspor simpul, yang merupakan pengekspor Prometheus untuk metrik sistem. Prometheus mendukung data floating-point tetapi bukan data string, sehingga sesuai untuk metrik sistem tetapi bukan log. Server Metrik Kubernetes adalah agregator kluster data penggunaan sumber daya yang mencakup satu kluster.

Pencatatan

Berikut adalah beberapa tantangan yang biasa dihadapi dalam pengelogan aplikasi layanan mikro:

  • Memahami pemrosesan end-to-end dari suatu permintaan klien, di mana beberapa layanan dapat diterapkan untuk menangani satu permintaan.
  • Mengonsolidasikan log dari beberapa layanan ke dalam satu tampilan agregat.
  • Mengurai log yang berasal dari beberapa sumber yang menggunakan skema pengelogan mereka sendiri atau tidak memiliki skema tertentu. Log mungkin dihasilkan oleh komponen pihak ketiga yang tidak Anda kontrol.
  • Arsitektur layanan mikro sering menghasilkan volume log yang lebih besar daripada monolit tradisional karena ada lebih banyak layanan, panggilan jaringan, dan langkah-langkah dalam transaksi. Hal itu berarti pengelogan itu sendiri dapat menjadi penyempitan performa atau sumber daya bagi aplikasi.

Ada beberapa tantangan tambahan untuk arsitektur berbasis Kubernetes:

  • Kontainer dapat dipindahkan dan dijadwal ulang.
  • Kubernetes memiliki abstraksi jaringan yang menggunakan alamat IP virtual dan pemetaan port.

Dalam Kubernetes, pendekatan standar dalam pengelogan yaitu kontainer menulis log ke stdout dan stderr. Mesin kontainer mengalihkan aliran ini ke driver pengelogan. Untuk mempermudah kueri, dan untuk mencegah kemungkinan hilangnya data log jika simpul berhenti merespons, pendekatan yang biasa adalah mengumpulkan log dari setiap simpul dan mengirimnya ke lokasi penyimpanan pusat.

Azure Monitor terintegrasi dengan AKS untuk mendukung pendekatan ini. Monitor mengumpulkan log kontainer dan mengirimkannya ke ruang kerja Analitik Log. Dari sana, Anda dapat menggunakan Bahasa Kueri Kusto untuk menulis kueri di seluruh log agregat. Misalnya, berikut adalah kueri Kusto untuk menampilkan log kontainer untuk pod tertentu:

ContainerLogV2
| where PodName == "podName" //update with target pod
| project TimeGenerated, Computer, ContainerId, LogMessage, LogSource

Azure Monitor adalah layanan terkelola, dan mengonfigurasi kluster AKS untuk menggunakan Monitor adalah perubahan konfigurasi sederhana dalam templat CLI atau Azure Resource Manager. (Untuk informasi selengkapnya, lihat Cara mengaktifkan wawasan Kontainer Azure Monitor.) Keuntungan lain menggunakan Azure Monitor adalah mengonsolidasikan log AKS Anda dengan log platform Azure lainnya untuk memberikan pengalaman pemantauan terpadu.

Azure Monitor ditagih per gigabyte (GB) data yang diserap ke dalam layanan. (Lihat Harga Azure Monitor.) Pada volume tinggi, biaya mungkin menjadi pertimbangan. Ada banyak alternatif sumber terbuka yang tersedia untuk ekosistem Kubernetes. Misalnya, banyak organisasi yang menggunakan Fluentd dengan Elasticsearch. Fluentd adalah pengumpul data sumber terbuka, dan Elasticsearch adalah database dokumen yang digunakan untuk pencarian. Tantangan dengan opsi ini adalah bahwa mereka memerlukan konfigurasi dan manajemen kluster tambahan. Untuk beban kerja produksi, Anda mungkin perlu bereksperimen dengan pengaturan konfigurasi. Anda juga harus memantau performa dari infrastruktur pengelogan.

OpenTelemetry

OpenTelemetry adalah upaya lintas industri untuk meningkatkan pelacakan dengan menstandarkan antarmuka antara aplikasi, pustaka, telemetri, dan pengumpul data. Saat Anda menggunakan pustaka dan kerangka kerja yang diinstrumentasikan dengan OpenTelemetry, sebagian besar pekerjaan operasi pelacakan yang secara tradisional merupakan operasi sistem ditangani oleh pustaka yang mendasarinya, yang mencakup skenario umum berikut:

  • Pengelogan operasi permintaan dasar, seperti waktu mulai, waktu keluar, dan durasi
  • Pengecualian dilemparkan
  • Penyebaran konteks (seperti mengirim ID korelasi di seluruh batas panggilan HTTP)

Sebagai gantinya, pustaka dasar dan kerangka kerja yang menangani operasi ini menciptakan rentang yang saling terkait yang kaya dan melacak struktur data dan menyebarkannya di seluruh konteks. Sebelum OpenTelemetry, ini biasanya hanya disuntikkan sebagai pesan log khusus atau sebagai struktur data kepemilikan yang khusus untuk vendor yang membangun alat pemantauan. OpenTelemetry juga mendorong model data instrumentasi yang lebih kaya daripada pendekatan logging-first tradisional, dan log lebih berguna karena pesan log ditautkan ke jejak dan rentang tempat mereka dihasilkan. Ini sering membuat menemukan log yang terkait dengan operasi atau permintaan tertentu menjadi mudah.

Banyak Azure SDK telah diinstrumentasikan dengan OpenTelemetry atau sedang dalam proses penerapannya.

Pengembang aplikasi dapat menambahkan instrumentasi manual dengan menggunakan SDK OpenTelemetry untuk melakukan aktivitas berikut:

  • Tambahkan instrumentasi di mana pustaka yang mendasar tidak menyediakannya.
  • Perkaya konteks pelacakan dengan menambahkan rentang untuk mengekspos unit kerja khusus aplikasi (seperti perulangan pesanan yang membuat rentang untuk pemrosesan setiap baris pesanan).
  • Perkaya rentang yang ada dengan kunci entitas untuk mengaktifkan pelacakan yang lebih mudah. (Misalnya, tambahkan kunci/nilai OrderID ke permintaan yang memproses pesanan tersebut.) Kunci ini muncul oleh alat pemantauan sebagai nilai terstruktur untuk kueri, pemfilteran, dan agregasi (tanpa mengurai string pesan log atau mencari kombinasi urutan pesan log, seperti yang umum dengan pendekatan pencatatan pertama).
  • Sebarkan konteks pelacakan dengan mengakses atribut pelacakan dan rentang, menyuntikkan traceId ke dalam respons dan payload, dan/atau membaca traceId dari pesan masuk, untuk membuat permintaan dan rentang.

Baca selengkapnya tentang instrumentasi dan SDK OpenTelemetry dalam dokumentasi OpenTelemetry.

Application Insights

Application Insights mengumpulkan data yang kaya dari OpenTelemetry dan pustaka instrumentasinya dan menangkapnya di penyimpanan data yang efisien untuk memberikan dukungan visualisasi dan kueri yang kaya. Pustaka instrumentasi berbasis Application Insights OpenTelemetry, untuk bahasa seperti .NET, Java, Node.js, dan Python, memudahkan untuk mengirim data telemetri ke Application Insights.

Jika Anda menggunakan .NET Core, kami sarankan Anda juga mempertimbangkan Application Insights untuk pustaka Kubernetes . Pustaka ini memperkaya jejak Application Insights dengan informasi tambahan, seperti kontainer, simpul, pod, label, dan set replika.

Application Insights memetakan konteks OpenTelemetry ke model data internalnya:

  • Jejak -> Operasi
  • ID Pelacakan -> ID Operasi
  • Rentang -> Permintaan atau Dependensi

Pertimbangkan pertimbangan berikut:

  • Application Insights membatasi telemetri jika tingkat data melebihi batas maksimum. Untuk mengetahui detailnya, lihat Batas Application Insights. Satu operasi dapat menghasilkan beberapa peristiwa telemetri, jadi jika aplikasi mengalami volume lalu lintas yang tinggi, kemungkinan akan dibatasi.
  • Karena Application Insights mengumpulkan data, Anda dapat kehilangan batch jika proses gagal dengan pengecualian yang tidak tertangani.
  • Penagihan Application Insights didasarkan pada volume data. Untuk informasi selengkapnya, lihat Mengelola harga dan volume data di Application Insights.

Pengelogan terstruktur

Untuk membuat log lebih mudah diurai, gunakan pengelogan terstruktur saat Anda bisa. Saat Anda menggunakan pengelogan terstruktur, aplikasi menulis log dalam format terstruktur, seperti JSON, daripada menghasilkan string teks yang tidak terstruktur. Ada banyak pustaka pengelogan terstruktur yang tersedia. Misalnya, berikut adalah pernyataan pengelogan yang menggunakan pustaka Serilog untuk .NET Core:

public async Task<IActionResult> Put([FromBody]Delivery delivery, string id)
{
    logger.LogInformation("In Put action with delivery {Id}: {@DeliveryInfo}", id, delivery.ToLogInfo());

    ...
}

Di sini, panggilan untuk LogInformation mencakup parameter Id dan parameter DeliveryInfo. Saat Anda menggunakan pengelogan terstruktur, nilai-nilai ini tidak diinterpolasi ke dalam string pesan. Sebagai gantinya, output log terlihat seperti ini:

{"@t":"2019-06-13T00:57:09.9932697Z","@mt":"In Put action with delivery {Id}: {@DeliveryInfo}","Id":"36585f2d-c1fa-4a3d-9e06-a7f40b7d04ef","DeliveryInfo":{...

Ini adalah string JSON, di mana @t bidang adalah tanda waktu, @mt adalah string pesan, dan pasangan kunci/nilai yang tersisa adalah parameter. Output format JSON membuatnya lebih mudah untuk mengkueri data secara terstruktur. Misalnya, kueri Analitik Log berikut, yang ditulis dalam bahasa kueri Kusto, mencari instans pesan khusus ini dari semua kontainer bernama fabrikam-delivery:

traces
| where customDimensions.["Kubernetes.Container.Name"] == "fabrikam-delivery"
| where customDimensions.["{OriginalFormat}"] == "In Put action with delivery {Id}: {@DeliveryInfo}"
| project message, customDimensions["Id"], customDimensions["@DeliveryInfo"]

Jika Anda melihat hasilnya dalam portal Azure, Anda dapat melihat bahwa DeliveryInfo itu adalah rekaman terstruktur yang berisi representasi model yang diserialisasikanDeliveryInfo:

Screenshot that shows the Log Analytics workspace.

Berikut adalah JSON dari contoh ini:

{
  "Id": "36585f2d-c1fa-4a3d-9e06-a7f40b7d04ef",
  "Owner": {
    "UserId": "user id for logging",
    "AccountId": "52dadf0c-0067-43e7-af76-86e32b48bc5e"
  },
  "Pickup": {
    "Altitude": 0.29295161612934972,
    "Latitude": 0.26815900219052985,
    "Longitude": 0.79841844309047727
  },
  "Dropoff": {
    "Altitude": 0.31507750848078986,
    "Latitude": 0.753494655598651,
    "Longitude": 0.89352830773849423
  },
  "Deadline": "string",
  "Expedited": true,
  "ConfirmationRequired": 0,
  "DroneId": "AssignedDroneId01ba4d0b-c01a-4369-ba75-51bde0e76cc9"
}

Banyak pesan log menandai awal atau akhir unit kerja, atau mereka menghubungkan entitas bisnis dengan serangkaian pesan dan operasi untuk keterlacakan. Dalam banyak kasus, memperkaya rentang OpenTelemetry dan objek permintaan adalah pendekatan yang lebih baik daripada hanya mencatat awal dan akhir operasi. Melakukannya menambahkan konteks tersebut ke semua jejak yang terhubung dan operasi anak, dan menempatkan informasi tersebut dalam cakupan operasi penuh. SDK OpenTelemetry untuk berbagai bahasa mendukung pembuatan rentang atau menambahkan atribut kustom pada rentang. Misalnya, kode berikut menggunakan Java OpenTelemetry SDK, yang didukung oleh Application Insights. Rentang induk yang ada (misalnya, rentang permintaan yang terkait dengan panggilan pengontrol REST dan dibuat oleh kerangka kerja web yang digunakan) dapat diperkaya dengan ID entitas yang terkait dengannya, seperti yang ditunjukkan di sini:

import io.opentelemetry.api.trace.Span;

// ...

Span.current().setAttribute("A1234", deliveryId);

Kode ini menetapkan kunci atau nilai pada rentang saat ini, yang terhubung ke operasi dan pesan log yang terjadi di bawah rentang tersebut. Nilai muncul di objek permintaan Application Insights, seperti yang ditunjukkan di sini:

requests
| extend deliveryId = tostring(customDimensions.deliveryId)  // promote to column value (optional)
| where deliveryId == "A1234"
| project timestamp, name, url, success, resultCode, duration, operation_Id, deliveryId

Teknik ini menjadi lebih kuat ketika digunakan dengan log, pemfilteran, dan anotasi jejak log dengan konteks rentang, seperti yang ditunjukkan di sini:

requests
| extend deliveryId = tostring(customDimensions.deliveryId)  // promote to column value (optional)
| where deliveryId == "A1234"
| project deliveryId, operation_Id, requestTimestamp = timestamp, requestDuration = duration  // keep some request info
| join kind=inner traces on operation_Id   // join logs only for this deliveryId
| project requestTimestamp, requestDuration, logTimestamp = timestamp, deliveryId, message

Jika Anda menggunakan pustaka atau kerangka kerja yang sudah diinstrumentasikan dengan OpenTelemetry, itu menangani pembuatan rentang dan permintaan, tetapi kode aplikasi mungkin juga membuat unit kerja. Misalnya, metode yang mengulang melalui array entitas yang melakukan pekerjaan pada masing-masing mungkin membuat rentang untuk setiap perulangan pemrosesan. Untuk informasi tentang menambahkan instrumentasi ke aplikasi dan kode pustaka, lihat dokumentasi instrumentasi OpenTelemery.

Pelacakan terdistribusi

Salah satu tantangan saat Anda menggunakan layanan mikro adalah memahami alur peristiwa di seluruh layanan. Satu transaksi dapat melibatkan panggilan ke beberapa layanan.

Contoh pelacakan terdistribusi

Contoh ini menjelaskan jalur transaksi terdistribusi melalui sekumpulan layanan mikro. Contohnya didasarkan pada aplikasi pengiriman drone.

Diagram that shows the architecture of a drone delivery application.

Dalam skenario ini, transaksi terdistribusi mencakup langkah-langkah berikut:

  1. Layanan Penyerapan menempatkan pesan pada antrean Azure Bus Layanan.
  2. Layanan Alur Kerja menarik pesan dari antrean.
  3. Layanan Alur Kerja memanggil tiga layanan back-end untuk memproses permintaan (Penjadwal Drone, Paket, dan Pengiriman).

Cuplikan layar berikut menunjukkan peta aplikasi untuk aplikasi pengiriman drone. Peta ini menampilkan panggilan ke titik akhir API publik yang menghasilkan alur kerja yang melibatkan lima layanan mikro.

Screenshot that shows the application map for the drone delivery application.

Panah dari fabrikam-workflow dan fabrikam-ingestion ke antrean Bus Layanan menunjukkan tempat pesan dikirim dan diterima. Anda tidak dapat mengetahui dari diagram layanan mana yang mengirim pesan dan mana yang menerima. Panah hanya menunjukkan bahwa kedua layanan memanggil Bus Layanan. Tetapi informasi tentang layanan mana yang dikirim dan yang menerima tersedia dalam detail:

Screenshot that shows the application map details.

Karena setiap panggilan menyertakan ID operasi, Anda juga dapat melihat langkah-langkah menyeluruh dari satu transaksi, termasuk informasi waktu dan panggilan HTTP di setiap langkah. Berikut adalah visualisasi salah satu transaksi tersebut:

Screenshot that shows an end-to-end transaction.

Visualisasi ini memperlihatkan langkah-langkah dari layanan penyerapan ke antrean, dari antrean ke layanan Alur Kerja, dan dari layanan Alur Kerja ke layanan back-end lainnya. Langkah terakhir adalah layanan Alur Kerja yang menandai bahwa pesan Bus Layanan telah selesai.

Contoh ini menunjukkan panggilan ke layanan back-end yang gagal:

Screenshot that shows an application map with errors.

Peta ini menunjukkan bahwa sebagian besar (36%) panggilan ke layanan Penjadwal Drone gagal selama periode kueri. Tampilan transaksi end-to-end mengungkapkan bahwa pengecualian terjadi ketika permintaan HTTP PUT dikirim ke layanan:

Screenshot of the end-to-end transaction. It shows that an exception occurs when an HTTP PUT request is sent to the service.

Jika Anda menelusuri lebih lanjut, Anda dapat melihat bahwa pengecualian adalah pengecualian soket: "Tidak ada perangkat atau alamat tersebut."

Fabrikam.Workflow.Service.Services.BackendServiceCallFailedException: 
No such device or address 
---u003e System.Net.Http.HttpRequestException: No such device or address 
---u003e System.Net.Sockets.SocketException: No such device or address

Pengecualian ini menunjukkan bahwa layanan back-end tidak dapat dijangkau. Pada tahap ini, Anda dapat menggunakan kubectl untuk melihat konfigurasi penyebaran. Dalam contoh ini, nama host layanan tidak menyelesaikan karena kesalahan dalam file konfigurasi Kubernetes. Artikel Debug Services dalam dokumentasi Kubernetes memiliki tips untuk mendiagnosis jenis kesalahan ini.

Berikut adalah beberapa penyebab umum kesalahan:

  • Bug pada kode. Bug ini mungkin muncul sebagai:
    • Pengecualian. Lihat di log Application Insights untuk melihat detail pengecualian.
    • Proses gagal. Lihat status kontainer dan pod, dan lihat log kontainer atau jejak Application Insights.
    • Kesalahan HTTP 5xx .
  • Kelelahan sumber daya:
    • Carilah pembatasan (HTTP 429) atau minta waktu jeda.
    • Periksa metrik kontainer untuk CPU, memori, dan disk.
    • Lihat konfigurasi untuk batas sumber daya kontainer dan pod.
  • Penemuan layanan Periksa konfigurasi layanan Kubernetes dan pemetaan port.
  • Ketidakcocokan API. Carilah kesalahan HTTP 400. Jika API diberi versi, lihat versi yang sedang dipanggil.
  • Kesalahan dalam menarik gambar kontainer. Lihat spesifikasi dari pod. Pastikan juga bahwa kluster berwenang untuk menarik dari registri kontainer.
  • Masalah RBAC.

Langkah berikutnya

Pelajari lebih lanjut mengenai fitur di Azure Monitor yang mendukung pemantauan aplikasi di AKS: