Home application insights azure logging troubleshooting

Troubleshooting Azure: Identifying and Fixing Missing/Incorrect Application Insights Logs

Updated: • 0 • min read
Table of Contents

Monitoring Azure Function Apps effectively is crucial for maintaining healthy and performant serverless applications. A cornerstone of this monitoring capability is the seamless integration between Azure Functions and Application Insights. Application Insights provides robust telemetry collection, enabling developers and operators to gain deep insights into the behavior, performance, and errors of their function apps. This integration often works out-of-the-box, providing valuable data without requiring extensive custom configuration.

However, situations can arise where the Application Insights logs appear to be missing entirely, or the collected data seems partial, inaccurate, or delayed. These inconsistencies can obscure critical issues, making troubleshooting a challenge. This article provides a comprehensive guide to diagnosing and resolving common problems related to missing or incorrect Application Insights logs for your Azure Function Apps.

Azure Application Insights monitoring

Understanding Application Insights for Azure Functions

Azure Application Insights, a feature of Azure Monitor, is an extensible Application Performance Management (APM) service for web developers. It allows you to monitor live web applications, automatically detecting performance anomalies and providing powerful analytics tools to help you diagnose issues. When integrated with Azure Functions, it becomes an invaluable resource for tracking function executions, performance metrics, and application logs.

By default, Azure Functions are configured to send their telemetry directly to Application Insights. This includes details about function executions, dependency calls, exceptions, and any custom logs emitted by your function code. This automated collection simplifies the monitoring setup, allowing you to focus on developing your business logic while Application Insights handles the telemetry.

Diagnosing Configuration Issues

The first step in troubleshooting missing or inaccurate logs is to thoroughly examine the configuration of your Azure Function App. Incorrect or outdated settings can prevent telemetry from being sent to Application Insights, or cause it to be filtered improperly. Azure provides a built-in diagnostics tool to help identify these common configuration pitfalls quickly and efficiently.

Checking Function App Configuration via Azure Portal

To initiate a configuration check, navigate to your specific function app within the Azure portal. Once there, locate and select the “Diagnose and solve problems” option, which will open the comprehensive Azure Functions diagnostics interface. This powerful tool offers a suite of diagnostic checks designed to pinpoint common issues affecting function app operations, including those related to monitoring and logging.

Within the diagnostics interface, use the search bar to find “Function Configuration Checks” and proceed to open it. This will generate a detailed diagnostic report, summarizing the status of various configuration settings critical for optimal function app performance and monitoring. Pay close attention to the sections specifically related to Application Insights, as these will highlight any discrepancies in your logging setup.

Azure Function App diagnostics

Key Application Insights Configuration Checks

The “Function Configuration Checks” diagnostic report performs several specific validations concerning Application Insights. Understanding these checks is vital for ensuring your logs are being captured correctly. If any of these checks fail or indicate a suboptimal configuration, it’s a strong indicator of where your logging issues might originate.

Connection Settings: Instrumentation Key vs. Connection String

One of the most critical configuration aspects is how your Function App connects to Application Insights. The diagnostic tool specifically checks for the presence of only one of two connection settings: APPINSIGHTS_INSTRUMENTATIONKEY or APPLICATIONINSIGHTS_CONNECTION_STRING. While APPINSIGHTS_INSTRUMENTATIONKEY has been traditionally used, the APPLICATIONINSIGHTS_CONNECTION_STRING is now the recommended approach for more stable and feature-rich behavior.

The connection string provides a more comprehensive set of details, including endpoint overrides and authentication options, which offers greater flexibility and resilience. Microsoft intends to deprecate the use of APPINSIGHTS_INSTRUMENTATIONKEY by 2025, making the transition to the connection string a proactive measure. Ensure your function app uses the APPLICATIONINSIGHTS_CONNECTION_STRING for optimal and future-proof monitoring.

Disabling AzureWebJobsDashboard

Another important check verifies that the AzureWebJobsDashboard built-in logging is disabled. Historically, AzureWebJobsDashboard was used for monitoring and logging activities within Azure Functions, particularly for older runtime versions. However, with the advent of Application Insights, it became redundant and can sometimes interfere with modern monitoring practices.

It is strongly recommended to disable AzureWebJobsDashboard to avoid duplicate telemetry collection and potential conflicts with Application Insights. Disabling it ensures that all your monitoring efforts are consolidated through Application Insights, providing a single, consistent source of truth for your function app’s telemetry. This streamlines troubleshooting and improves the overall efficiency of your monitoring strategy.

Enabling Sampling for Telemetry

The diagnostic report also confirms that sampling is enabled for your Azure Functions telemetry, which is the default setting. Sampling is a crucial feature in Application Insights designed to reduce the volume of telemetry data transmitted and stored, thereby minimizing costs and improving performance. It intelligently selects a representative subset of telemetry items for detailed analysis while still providing accurate statistical data.

While sampling helps manage data volume, it can sometimes lead to the perception of “missing” logs if you’re expecting every single event to be present. Understanding that sampling is enabled by default and how it operates is important. We will delve deeper into troubleshooting scenarios related to sampling in a later section, but for now, ensure it’s enabled as recommended for balanced monitoring.

Runtime Version Recommendation

For robust and comprehensive log tracking, it is highly recommended that your function app operates on version 4 of the Azure Functions runtime, with a minimum version of 4.15.2xx. This specific runtime version and onwards introduce enhanced capabilities for tracking log flows from Azure Functions directly to the Application Insights service. These improvements enable more granular visibility into how logs are processed and transmitted.

By leveraging these newer runtime versions, you gain the ability to meticulously monitor the journey of your logs, identifying exactly where any potential loss or discrepancy might occur. This enhanced tracking is instrumental in pinpointing the root cause of missing logs, offering diagnostic clarity that older runtime versions may lack. Upgrading to the recommended version is a foundational step in ensuring reliable and complete telemetry capture.

Managing Custom Application Logs

By default, any custom application logs that you write within your function code are initially sent to the Functions host. The Functions host then acts as an intermediary, forwarding these logs to Application Insights under the “Worker” category. This default logging pipeline simplifies the process, as the host handles the integration with Application Insights for you.

However, certain language stacks provide the flexibility to send logs directly to Application Insights, bypassing the Functions host. This alternative pipeline changes the flow from worker > Functions host > Application Insights to a more direct worker > Application Insights. Opting for direct logging offers developers greater control over how their custom logs are emitted, including fine-tuning formatting, properties, and specific destination configurations.

Logging Pipeline Configuration by Language Stack

The ability to configure custom logs directly varies by language stack, offering different mechanisms for implementing this control. Understanding these options is key to tailoring your logging strategy.

| Language Stack | Where to Configure Custom Logs Sistem adalah seperifikasi semua yang ingin Anda lakukan.

```mermaid
sequenceDiagram
participant Client
participant Load Balancer
participant Backend Service
participant Database

Client->>Load Balancer: Request
Load Balancer->>Backend Service: Forward Request
Backend Service->>Database: Query Data
Database-->>Backend Service: Return Data
Backend Service-->>Load Balancer: Response
Load Balancer-->>Client: Return Response

```

Memeriksa Konfigurasi Aplikasi Fungsi

Integrasi erat antara Azure Functions dan Application Insights memungkinkan pemantauan mendalam terhadap aplikasi fungsi Anda. Application Insights dapat digunakan tanpa konfigurasi kustom yang rumit. Namun, jika Anda menemukan log Application Insights hilang, atau data yang muncul sebagian atau tidak akurat, langkah-langkah berikut dapat membantu Anda mengatasi masalah ini.

Langkah-langkah Diagnostik Awal

Langkah pertama dalam proses pemecahan masalah adalah memanfaatkan alat diagnostik bawaan Azure. Alat ini dirancang untuk secara otomatis memeriksa konfigurasi umum yang dapat memengaruhi pengiriman log ke Application Insights. Menggunakan alat ini dapat dengan cepat mengidentifikasi sumber masalah tanpa perlu penyelidikan manual yang mendalam.

  1. Navigasi ke aplikasi fungsi Anda di portal Azure: Masuk ke portal Azure dan cari aplikasi fungsi spesifik yang mengalami masalah logging. Ini adalah titik awal untuk semua pemeriksaan konfigurasi.
  2. Pilih Diagnosa dan pecahkan masalah: Setelah berada di halaman aplikasi fungsi Anda, pilih opsi ini dari menu sebelah kiri. Ini akan membuka dasbor diagnostik yang komprehensif untuk Azure Functions.
  3. Cari Pemeriksaan Konfigurasi Fungsi: Di bilah Pencarian dalam dasbor diagnostik, ketik “Pemeriksaan Konfigurasi Fungsi” dan buka hasilnya. Alat ini akan memulai serangkaian validasi konfigurasi otomatis.
  4. Tinjau laporan diagnostik: Anda akan melihat laporan diagnostik yang merinci semua pemeriksaan konfigurasi aplikasi fungsi. Untuk Application Insights, pemeriksaan berikut akan dilakukan secara khusus:
    • Pengaturan Koneksi Tunggal: Dipastikan hanya salah satu pengaturan koneksi berikut yang ada:
      • APPINSIGHTS_INSTRUMENTATIONKEY (Kunci Instrumentasi Application Insights)
      • APPLICATIONINSIGHTS_CONNECTION_STRING (String koneksi)
        Kami sangat menyarankan Anda menggunakan APPLICATIONINSIGHTS_CONNECTION_STRING untuk perilaku yang lebih stabil dan fitur yang lebih lengkap. Kemampuan untuk menggunakan APPINSIGHTS_INSTRUMENTATIONKEY akan dihentikan pada tahun 2025. Beralih ke string koneksi adalah langkah penting untuk masa depan.
    • AzureWebJobsDashboard Dinonaktifkan: Pastikan logging bawaan AzureWebJobsDashboard dinonaktifkan, sebagaimana direkomendasikan. Ini membantu menghindari duplikasi data dan potensi konflik dengan Application Insights.
    • Pengambilan Sampel Diaktifkan: Verifikasi bahwa pengambilan sampel (Sampling) diaktifkan untuk telemetri Azure Functions. Ini adalah pengaturan default yang membantu mengelola volume data, dan penting untuk memahami dampaknya terhadap visibilitas log Anda.

Rekomendasi Penting: Aplikasi fungsi Anda sebaiknya berada di versi 4, dan versi runtime setidaknya 4.15.2xx. Hal ini karena, mulai dari versi ini, Anda dapat melacak aliran log dari Azure Functions ke layanan Application Insights dengan lebih detail. Memantau aliran log ini memungkinkan Anda untuk memeriksa log yang hilang dengan lebih efektif dan mendalam.

Log Aplikasi Kustom

Secara default, log aplikasi kustom yang Anda tulis akan dikirim ke host Functions. Host inilah yang kemudian meneruskan log-log tersebut ke Application Insights di bawah kategori Worker. Proses ini menyederhanakan konfigurasi awal, karena host mengelola sebagian besar integrasi log. Namun, beberapa tumpukan bahasa memungkinkan Anda untuk mengirim log langsung ke Application Insights, yang memberikan Anda kendali penuh atas bagaimana log yang Anda tulis dipancarkan. Dalam skenario ini, pipeline pencatatan berubah dari worker > Functions host > Application Insights menjadi worker > Application Insights.

Pendekatan langsung ini sangat bermanfaat ketika Anda memerlukan penyesuaian yang lebih granular pada log Anda, seperti menambahkan properti kustom, mengontrol tingkat keparahan, atau memformat output log dengan cara yang spesifik. Ini memungkinkan Anda untuk menyesuaikan data telemetri agar lebih sesuai dengan kebutuhan analisis Anda, memberikan fleksibilitas yang lebih besar dalam pemantauan.

Berikut adalah ringkasan opsi konfigurasi yang tersedia untuk setiap tumpukan bahasa:

Language Stack Tempat Mengonfigurasi Log Kustom
.NET (in-process model) host.json
.NET (isolated model) Default (kirim log kustom ke host Functions): host.json. Untuk mengirim log langsung ke Application Insights, lihat [Konfigurasi Application Insights di HostBuilder].
Node.JS host.json
Python host.json
Java Default (kirim log kustom ke host Functions): host.json. Untuk mengirim log langsung ke Application Insights, lihat [Konfigurasi agen Java Application Insights].
PowerShell host.json

Memahami Perubahan Pipeline Logging

Ketika Anda mengonfigurasi log aplikasi kustom untuk dikirim secara langsung, host Functions tidak lagi memancarkannya. Ini berarti file host.json tidak lagi mengontrol perilaku log-log tersebut. Demikian pula, opsi yang diekspos oleh setiap tumpukan bahasa hanya berlaku untuk log kustom yang Anda kirim langsung. Mereka tidak mengubah perilaku log runtime lainnya yang dijelaskan dalam artikel ini.

Dalam kasus ini, untuk mengontrol perilaku semua log — baik log kustom maupun log runtime — Anda mungkin perlu membuat perubahan pada kedua konfigurasi. Ini bisa berarti menyesuaikan host.json untuk log runtime dan menggunakan API spesifik tumpukan bahasa Anda untuk log kustom. Memahami perbedaan ini sangat penting untuk mencegah log hilang atau muncul secara tidak konsisten.

Alur Pencatatan Log: Perbandingan

Memahami bagaimana log Anda bergerak dari aplikasi ke Application Insights adalah kunci untuk pemecahan masalah. Berikut adalah representasi visual dari dua alur utama:

```mermaid
graph TD
subgraph Default Logging Pipeline
A[Worker Code (Custom Logs)] → B[Functions Host]
B → C[Application Insights]
end

subgraph Direct Logging Pipeline
    D[Worker Code (Custom Logs)] --> E[Application Insights]
end

F[Functions Runtime Logs] --> C
style A fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#f9f,stroke:#333,stroke-width:2px
style F fill:#9cf,stroke:#333,stroke-width:2px

```

Diagram ini menunjukkan bahwa log runtime Azure Functions selalu melewati Host Functions sebelum mencapai Application Insights. Namun, log kustom dari kode worker Anda dapat memilih rute default melalui Host Functions atau rute langsung ke Application Insights, tergantung pada konfigurasi bahasa Anda.

Log Hilang atau Sebagian

Application Insights secara komprehensif mengumpulkan data log, kinerja, dan kesalahan untuk aplikasi Anda. Namun, jika Anda melihat log yang hilang sebagian, ini kemungkinan besar disebabkan oleh fitur pengambilan sampel (sampling). Pengambilan sampel adalah mekanisme yang digunakan untuk mengurangi volume telemetri yang dikirim dan disimpan, yang pada gilirannya dapat mengurangi biaya dan meningkatkan efisiensi pemrosesan data.

Fitur pengambilan sampel diaktifkan secara default dengan pengaturan yang biasanya ditemukan dalam file host.json aplikasi fungsi Anda. Pengaturan ini dirancang untuk menyeimbangkan kebutuhan akan data lengkap dengan efisiensi pengumpulan telemetri. Penting untuk dicatat bahwa tipe yang dikecualikan dalam konfigurasi pengambilan sampel tidak akan diambil sampelnya, yang berarti semua log dari tipe tersebut akan dikirim.

Konfigurasi Pengambilan Sampel Default

Berikut adalah contoh konfigurasi host.json yang menunjukkan pengaturan pengambilan sampel:

{
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond" : 20,
        "excludedTypes": "Request;Exception"
      }
    }
  }
}

Dalam konfigurasi ini, isEnabled: true menunjukkan bahwa pengambilan sampel aktif. maxTelemetryItemsPerSecond: 20 berarti Application Insights akan mencoba membatasi jumlah item telemetri yang dikumpulkan hingga rata-rata 20 item per detik. excludedTypes: "Request;Exception" adalah pengaturan penting yang secara eksplisit mengecualikan permintaan (Request) dan pengecualian (Exception) dari pengambilan sampel. Ini memastikan bahwa semua permintaan dan pengecualian dicatat, memberikan gambaran yang lengkap tentang interaksi dan masalah aplikasi Anda.

Menentukan Tingkat Pengambilan Sampel Sebenarnya

Jika Anda mencurigai bahwa log Anda hilang sebagian karena pengambilan sampel, Anda dapat menggunakan kueri Analytics untuk menentukan tingkat pengambilan sampel yang sebenarnya. Kueri ini akan memberikan wawasan tentang persentase telemetri yang disimpan dan yang dihilangkan oleh pengambilan sampel.

union requests,dependencies,pageViews,browserTimings,exceptions,traces
| where timestamp > todatetime("mm/dd/yyyy hh:mm:ss") and timestamp < todatetime("mm/dd/yyyy hh:mm:ss")
| summarize TelemetrySavedPercentage = 100/avg(itemCount), TelemetryDroppedPercentage = 100-100/avg(itemCount) by bin(timestamp, 1d), itemType
| sort by timestamp asc

Kueri Kusto ini menganalisis berbagai jenis telemetri (permintaan, dependensi, tampilan halaman, waktu browser, pengecualian, jejak) dalam interval waktu yang Anda tentukan. itemCount adalah properti internal yang digunakan Application Insights untuk melacak jumlah item asli sebelum pengambilan sampel. Jika Anda mengamati bahwa TelemetrySavedPercentage untuk jenis pengambilan sampel apa pun kurang dari 100%, itu menunjukkan bahwa jenis telemetri tersebut sedang diambil sampelnya. Nilai yang lebih rendah menunjukkan lebih banyak data yang dihilangkan.

Dengan memahami data ini, Anda dapat memutuskan apakah perlu menyesuaikan pengaturan pengambilan sampel Anda dalam host.json untuk mendapatkan visibilitas yang lebih besar. Namun, perlu diingat bahwa menonaktifkan pengambilan sampel sepenuhnya dapat menyebabkan peningkatan volume data yang signifikan dan berpotensi meningkatkan biaya Application Insights Anda. Oleh karena itu, penyesuaian harus dilakukan dengan hati-hati.

Application Insights Kusto query

Kebijakan Retensi dan Penyimpanan Data

Selain pengambilan sampel, penting juga untuk memahami kebijakan retensi data di Application Insights. Data telemetri hanya disimpan untuk jangka waktu tertentu, yang dapat dikonfigurasi. Jika Anda mencari log yang sangat lama, log tersebut mungkin sudah dihapus sesuai dengan kebijakan retensi. Informasi lebih lanjut tentang pengumpulan, retensi, dan penyimpanan data di Application Insights dapat ditemukan dalam dokumentasi Azure Monitor.

Mengontrol Volume dan Tingkat Detail Log

Mengelola volume dan tingkat detail log sangat penting untuk efektivitas pemantauan. Terlalu banyak log dapat membanjiri sistem dan membuatnya sulit menemukan informasi penting, sementara terlalu sedikit log dapat menyebabkan kurangnya visibilitas. Azure Functions memungkinkan Anda untuk meningkatkan atau menekan log yang ditulis dengan menggunakan kombinasi tingkat log (log level) dan kategori (category), yang keduanya dikonfigurasi dalam file host.json Anda.

Setiap log yang dihasilkan oleh logger Azure Functions memiliki kategori dan tingkat log yang terkait dengannya. Kategori menunjukkan bagian mana dari kode runtime atau kode fungsi Anda yang menghasilkan log tersebut. Misalnya, Host.Results mengacu pada log yang berkaitan dengan hasil eksekusi host, sedangkan Function.<YOUR_FUNCTION_NAME> adalah untuk log yang berasal dari fungsi spesifik Anda.

Kategori Log

Beberapa kategori log umum meliputi:

  • Host.Results: Log yang terkait dengan hasil eksekusi fungsi secara keseluruhan.
  • Function.<YOUR_FUNCTION_NAME>: Log yang berasal dari kode fungsi spesifik Anda.
  • Host.Aggregator: Log yang digunakan untuk mengagregasi metrik kinerja.
  • Function.<YOUR_FUNCTION_NAME>.User: Log kustom yang dipancarkan oleh kode pengguna dalam fungsi Anda.
  • Host.General: Log umum yang dikeluarkan oleh host Functions.

Tingkat Log

Tingkat log menunjukkan kepentingan relatif dari sebuah pesan log. Azure Functions mendukung tingkat log standar:

  • Trace: Log yang paling detail, seringkali untuk tujuan diagnostik yang mendalam.
  • Debug: Log yang berguna untuk debugging selama pengembangan.
  • Information: Log yang memberikan informasi operasional umum.
  • Warning: Log yang menunjukkan situasi yang berpotensi bermasalah tetapi tidak menghalangi fungsi.
  • Error: Log yang menunjukkan kesalahan yang tidak terduga dalam operasi.
  • Critical: Log yang menunjukkan kegagalan yang parah yang memerlukan perhatian segera.
  • None: Menonaktifkan logging sepenuhnya untuk kategori tertentu.

Mengonfigurasi Tingkat Log dalam host.json

Anda dapat mengonfigurasi bagaimana aplikasi Anda harus menulis log dengan menyesuaikan bagian logging dalam host.json. Contoh berikut menunjukkan konfigurasi yang mendetail:

{
  "version": "2.0",
  "logging": {
    "logLevel": {
      "default": "Information", // catch all default, dengan modifikasi di bawah untuk kategori individu.
      "Function": "Warning", // Tingkat Peringatan dari semua Fungsi (kecuali yang dikonfigurasi di bawah).
      "Host.Aggregator": "Trace", // Log semua jejak di tabel 'customMetrics' (dan ditampilkan di blade Metrik/Peringatan di AI) - gunakan ini atau Host.Results
      "Host.Results": "Error", // Permintaan Error dan Critical hanya dicatat di tabel 'requests' AI (dan ditampilkan di blade Monitor Functions di Aplikasi Fungsi) - gunakan ini atau Host.Aggregator
      "Function.Function1": "Information", // Log tingkat Informasi dari Fungsi 1, dicatat di tabel 'traces', 'dependencies', dan 'customMetrics' AI
      "Function.Function2.User": "Information" // Log kode pengguna dari Fungsi2, dicatat di tabel 'traces' AI
    },
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond": 1,
        "excludedTypes": "Exception"
      }
    }
  }
}

Dalam contoh ini:
* "default": "Information": Menetapkan tingkat log default menjadi Informasi untuk semua kategori yang tidak ditentukan secara eksplisit.
* "Function": "Warning": Menetapkan semua fungsi (kecuali yang dinamai secara spesifik) untuk hanya mencatat dari tingkat Peringatan ke atas. Ini membantu mengurangi kebisingan dari fungsi secara umum.
* "Host.Aggregator": "Trace": Mengaktifkan pencatatan yang sangat detail untuk agregator host, yang berguna untuk metrik kustom.
* "Host.Results": "Error": Hanya mencatat hasil host yang berada pada tingkat Kesalahan atau Kritis ke tabel permintaan di Application Insights, membatasi data kinerja yang dikumpulkan.
* "Function.Function1": "Information": Mengatur tingkat log spesifik untuk Function1 menjadi Informasi, memungkinkan detail yang lebih baik untuk fungsi tersebut.
* "Function.Function2.User": "Information": Mengatur tingkat log untuk log kode pengguna dari Function2 menjadi Informasi, memberikan visibilitas yang baik ke dalam logika bisnis.

Mengesampingkan Nilai host.json dengan Pengaturan Aplikasi

Untuk menghindari deployment ulang setiap kali Anda perlu mengubah konfigurasi host.json (terutama di lingkungan produksi), Anda dapat mengesampingkan nilai host.json spesifik dengan membuat nilai yang setara sebagai pengaturan aplikasi (application setting). Misalnya, untuk mengesampingkan "logging:logLevel:default", Anda dapat membuat pengaturan aplikasi bernama AzureFunctionsJobHost__logging__logLevel__default.

Mekanisme pengesampingan ini memberikan fleksibilitas yang luar biasa, memungkinkan Anda untuk menyesuaikan perilaku logging secara dinamis tanpa mengubah kode atau file konfigurasi yang di-deploy. Ini sangat berguna untuk skenario di mana Anda perlu meningkatkan tingkat detail log sementara untuk pemecahan masalah.

Panduan Video: Menguasai Pencatatan Azure Functions

Untuk panduan visual yang komprehensif tentang mengonfigurasi pencatatan dan memahami tingkat log di Azure Functions, pertimbangkan panduan ahli ini:

Azure Functions Logging Deep Dive
Catatan: Placeholder ini mewakili contoh sumber daya video yang relevan yang dapat memberikan detail dan demonstrasi praktis.

Aplikasi Fungsi yang Terintegrasi dengan Jaringan Virtual Tidak Menghasilkan Log

Ketika aplikasi fungsi diintegrasikan dengan jaringan virtual (Virtual Network atau VNet), konfigurasi jaringan yang ketat seringkali dapat menjadi penghalang bagi aliran data telemetri. Salah satu masalah umum yang dihadapi adalah aplikasi fungsi yang terintegrasi dengan VNet gagal menghasilkan log di Application Insights. Hal ini biasanya terjadi karena pembatasan firewall yang mencegah lalu lintas keluar ke titik akhir Application Insights.

Untuk memungkinkan Application Insights SDK atau Application Insights Agent mengirim data ke portal, Anda harus secara eksplisit membuka Port 443 untuk lalu lintas keluar di firewall server Anda. Port ini digunakan untuk komunikasi HTTPS, yang merupakan protokol standar untuk pengiriman data telemetri yang aman. Jika port ini tidak dibuka, data log tidak dapat mencapai layanan Application Insights di cloud Azure.

URL yang Diperlukan untuk Lalu Lintas Keluar

Berikut adalah URL spesifik yang harus diizinkan oleh firewall Anda untuk lalu lintas keluar melalui Port 443:

  • dc.applicationinsights.azure.com
  • dc.applicationinsights.microsoft.com
  • dc.services.visualstudio.com
  • *.in.applicationinsights.azure.com

Memastikan konektivitas ke semua URL ini sangat penting. dc.applicationinsights.azure.com dan dc.applicationinsights.microsoft.com adalah titik akhir utama untuk pengumpulan data, sementara dc.services.visualstudio.com dan *.in.applicationinsights.azure.com adalah titik akhir tambahan yang mungkin digunakan oleh Application Insights untuk berbagai fungsi, termasuk pengiriman data. Jika salah satu dari ini diblokir, Anda mungkin melihat log yang hilang sebagian atau tidak ada sama sekali.

Azure Virtual Network firewall

Pentingnya Konektivitas yang Tepat

Tanpa aturan firewall yang benar, meskipun aplikasi fungsi Anda tampaknya berjalan normal, data telemetri vital tidak akan pernah mencapai Application Insights. Ini dapat menyebabkan butanya pemantauan dan membuat pemecahan masalah menjadi sangat sulit, karena Anda tidak memiliki visibilitas ke dalam apa yang sebenarnya terjadi di aplikasi Anda. Oleh karena itu, jika Anda menggunakan integrasi VNet, pastikan tim jaringan atau administrator Anda mengonfigurasi aturan firewall ini dengan benar. Untuk informasi lebih lanjut mengenai alamat IP yang digunakan oleh Azure Monitor, termasuk Application Insights, selalu merujuk pada dokumentasi resmi Azure.

Kesimpulan

Pemantauan yang akurat dan komprehensif adalah tulang punggung setiap aplikasi yang sukses, dan Application Insights adalah alat yang sangat diperlukan untuk Azure Functions. Mengalami log yang hilang atau tidak akurat dapat menghambat kemampuan Anda untuk mendiagnosis masalah kinerja, melacak kesalahan, atau memahami perilaku aplikasi Anda. Dengan mengikuti langkah-langkah pemecahan masalah yang diuraikan dalam artikel ini — mulai dari memeriksa konfigurasi aplikasi fungsi, mengelola log kustom, memahami dampak pengambilan sampel, hingga memastikan konektivitas jaringan yang tepat — Anda dapat memulihkan visibilitas penuh ke dalam aplikasi Anda.

Menerapkan praktik terbaik ini dan secara proaktif memantau kesehatan log Anda akan memberdayakan Anda untuk menjaga aplikasi fungsi Anda berjalan dengan lancar dan efisien. Ingatlah bahwa pemahaman yang mendalam tentang bagaimana log dikumpulkan, diproses, dan dikirim adalah kunci untuk pemecahan masalah yang efektif.

Apakah Anda pernah menghadapi masalah serupa dengan log Application Insights di Azure Functions? Pengalaman atau tips apa yang Anda miliki untuk dibagikan dengan komunitas? Berikan komentar di bawah ini!

Post a Comment