Application Insights FAQ – 질문과 대답

애플리케이션을 계측하여 Application Insights를 사용하도록 설정하는 방법에 대한 자세한 내용은 데이터 수집 기본 사항을 참조하세요.

애플리케이션을 계측하여 Application Insights를 사용하도록 설정한 후 먼저 라이브 메트릭 및 애플리케이션 맵을 확인하는 것이 좋습니다.

서버 웹앱들로부터:

• HTTP 요청
• 종속성. SQL 데이터베이스 호출, 외부 서비스, Azure Cosmos DB, Azure Table Storage, Azure Blob Storage 및 Azure Queue Storage에 대한 HTTP 호출
• 예외 및 스택 추적.
• 성능 카운터: 다음을 사용할 때 성능 카운터를 사용할 수 있습니다.
  • Azure Monitor Application Insights 에이전트
  • VM 또는 가상 머신 확장 집합에 대한 Azure 모니터링
  • Application Insights collectd 작성자.
• 직접 코드로 작성하는 사용자 지정 이벤트 및 메트릭.
• 적절한 수집기를 구성한 경우 추적 로그.

클라이언트 웹 페이지에서:

• 다음에 대한 정보를 포함하여 앱의 catch되지 않은 예외

  • 스택 추적
  • 오류 세부 정보 및 동반 메시지
  • 오류가 발생한 줄 및 열 번호
  • 오류가 발생한 URL
  • 귀하의 앱에 의해 이루어진 네트워크 종속 요청, 즉 XML Http Request(XHR) 및 Fetch(기본적으로 Fetch 수집은 사용 안 함) 요청에는 다음에 대한 정보가 포함됩니다.
    • 종속성 원본의 URL
    • 종속성을 요청하는 데 사용된 명령 및 메서드
    • 요청 지속 시간
    • 요청의 결과 코드 및 성공 상태
    • 요청을 수행하는 사용자의 ID(있는 경우)
    • 요청이 수행된 상관 관계 컨텍스트(있는 경우)

• 사용자 정보(예: 위치, 네트워크, IP)

• 디바이스 정보(예: 브라우저, OS, 버전, 언어, 모델)

• 세션 정보

  비고

  SPA(단일 페이지 애플리케이션)와 같은 일부 애플리케이션의 경우 기간이 항상 기록되지는 않으며, 이 경우 기본값은 0입니다.

  자세한 내용은 Application Insights의 데이터 수집, 보존 및 스토리지를 참조하세요.

다른 원본(구성한 경우):

• Azure 진단
• Log Analytics로 가져오기
• Log Analytics
• Logstash

환경 전체에서 애플리케이션 또는 구성 요소를 다루는 데 필요한 Application Insights 리소스 수를 이해하려면 Application Insights 배포 계획 가이드를 참조하세요.

Azure Resource Monitor를 사용하여 PowerShell 스크립트를 작성함으로써 다음을 수행할 수 있습니다.

• Application Insights 리소스를 만들고 업데이트합니다.
• 가격 책정 계획을 설정합니다.
• 계측 키를 가져옵니다.
• 메트릭 경고를 추가합니다.
• 가용성 테스트를 추가합니다.

메트릭 탐색기 보고서를 설정하거나 연속 내보내기를 설정할 수는 없습니다.

REST API를 사용하여 Log Analytics 쿼리를 실행합니다.

Azure Monitor OpenTelemetry Distro를 사용하는 것이 좋습니다.

수집 스키마 및 엔드포인트 프로토콜은 공개적으로 사용 가능합니다.

대부분의 Application Insights 데이터에는 5분 이하의 대기 시간이 포함됩니다. 일부 데이터는 더 오래 걸릴 수 있으며, 더 큰 로그 파일에서 이러한 현상이 나타납니다. Application Insights 서비스 수준 계약을 참조하세요.

컬렉션

Application Insights는 웹 서버 원격 분석, 웹 페이지 원격 분석 및 성능 카운터를 포함하여 앱에 대한 원격 분석을 수집합니다. 이 데이터를 사용하여 앱의 성능, 상태 및 사용량을 모니터링할 수 있습니다. 새 Application Insights 리소스를 만들 때 위치를 선택할 수 있습니다.

보존 및 스토리지

데이터는 Application Insights Log Analytics 작업 영역으로 전송됩니다. 원시 데이터의 보존 기간을 30일~730일 중에서 선택할 수 있습니다. 집계된 데이터는 90일 동안 보존되고 디버그 스냅샷은 15일 동안 보존됩니다.

개인 정보 보호

Application Insights는 기본적으로 중요한 데이터를 처리하지 않습니다. 중요한 데이터를 URL에 일반 텍스트로 넣지 말고, 사용자 지정 코드가 개인 또는 기타 중요한 세부 정보를 수집하지 않는지 확인하는 것이 좋습니다. 개발 및 테스트하는 동안 IDE 및 브라우저의 디버깅 출력 창에서 보낸 데이터를 확인합니다.

보관된 정보를 보려면 Application Insights의 데이터 수집, 보존 및 스토리지를 참조하세요.

Application Insights는 해당 로그 데이터가 수집된 Log Analytics 작업 영역을 통해 요금이 청구됩니다. 기본 종량제 Log Analytics 가격 책정 계층에는 청구 계정당 월 5GB의 무료 데이터 허용량이 포함됩니다. Azure Monitor 로그 가격 책정 옵션에 대해 자세히 알아봅니다.

• Azure 웹앱이 Application Insights 컬렉션 엔드포인트가 있는 데이터 센터에서 호스트되는 경우 무료입니다.
• 호스트 데이터 센터에 컬렉션 엔드포인트가 없으면 앱의 원격 분석에 Azure 발신 요금이 부과됩니다.

이 대답은 Application Insights 리소스의 호스팅 위치가 아닌, 우리의 엔드포인트 분포에 따라 달라집니다.

예, 더 많은 네트워크 비용이 발생할 수 있으며, 이는 원격 분석이 시작되는 지역과 이동하는 지역에 따라 다릅니다. 자세한 내용은 Azure 대역폭 가격 책정을 참조하세요.

Application Insights에서 예기치 않은 요금 또는 높은 비용이 표시되는 경우 이 가이드가 도움이 될 수 있습니다. 높은 원격 분석 볼륨, 데이터 수집 급증 및 잘못 구성된 샘플링과 같은 일반적인 원인을 다룹니다. 비용 급증, 원격 분석 볼륨, 샘플링이 작동하지 않음, 데이터 한도, 높은 수집 또는 예기치 않은 청구와 관련된 문제를 해결하는 경우에 특히 유용합니다. 시작하려면 Application Insights에서 높은 데이터 수집 문제 해결을 참조하세요.

Application Insights는 TLS(전송 계층 보안) 1.2 및 1.3을 사용합니다.

레거시 TLS 문제에 대한 일반적인 질문은 TLS 문제 해결 및 Azure Resource Manager TLS 지원을 참조하세요.

자세한 내용은 Application Insights 소개를 참조하세요.

TelemetryChannels는 모두 애플리케이션이 종료되기 전에 플러시되지 않으면 버퍼링된 원격 분석이 손실됩니다.

데이터 손실을 방지하려면 애플리케이션이 종료될 때 TelemetryClient를 플러시합니다.

자세한 내용은 데이터 플러시를 참조하세요.

없음. try-catch 절에 래핑할 필요가 없습니다. SDK에 문제가 발생하면 메시지를 디버그 콘솔 출력에 로그하고, 메시지가 통과하면 진단 검색에 표시됩니다.

예, 데이터 액세스 API가 있습니다. 데이터를 추출하는 다른 방법에는 작업 영역 기반 리소스의 Power BI가 포함됩니다.

Application Insights SDK는 자동 계측과 호환되지 않습니다. 자동 계측이 사용하도록 설정되면 Track() 및 기타 사용자 지정 이벤트 및 메트릭 API에 대한 호출이 무시됩니다.

App Service 페이지의 Application Insights 탭에 있는 Azure Portal에서 자동 계측을 끄거나 ApplicationInsightsAgent_EXTENSION_VERSION을 disabled로 설정합니다.

샘플링을 하면 앱에서 포털로 전송되는 원격 분석 항목(요청, 사용자 지정 이벤트 등)의 수가 줄어듭니다. 검색에는 받은 항목 수가 표시됩니다. 이벤트 수를 표시하는 메트릭 차트에는 발생된 원래 이벤트 수가 표시됩니다.

전송되는 각 항목은 해당 항목이 나타내는 원래 이벤트의 수를 보여 주는 itemCount 속성을 전달합니다. 작업 중인 샘플링을 관찰하려면 Log Analytics에서 다음 쿼리를 실행할 수 있습니다.

requests | summarize original_events = sum(itemCount), transmitted_events = count()

Azure 경고는 메트릭에 대해서만 설정됩니다. 이벤트가 발생할 때마다 값 임계값을 초과하는 사용자 지정 메트릭을 만듭니다. 그런 다음 메트릭에 대해 경고를 설정합니다. 메트릭이 어느 방향으로든 임계값을 초과할 때마다 알림을 받습니다. 초기 값이 높거나 낮은지에 관계없이 처음 초과할 때까지는 알림을 받지 않습니다. 항상 몇 분의 대기 시간이 있습니다.

자세한 내용은 사용자 지정 이벤트 및 메트릭에 대한 Application Insights API를 참조 하세요.

예. Application Insights 에이전트를 다운로드하는 여러 방법은 다음과 같습니다.

• 컴퓨터에서 인터넷에 액세스할 수 있는 경우 -Proxy 매개 변수를 사용하여 PowerShell 갤러리에 온보딩할 수 있습니다.
• 모듈을 수동으로 다운로드하여 컴퓨터에 설치하거나 직접 사용할 수도 있습니다.

이러한 각 옵션은 자세한 지침에 설명되어 있습니다.

예. Application Insights Agent 2.0.0 이상에서 IIS에 호스트되는 ASP.NET Core 애플리케이션이 지원됩니다.

• Get-ApplicationInsightsMonitoringStatus cmdlet을 사용하여 사용이 성공했는지 확인할 수 있습니다.

• 앱에서 원격 분석을 전송하고 있는지 빠르게 확인하려면 라이브 메트릭을 사용합니다.

• Log Analytics를 사용하여 현재 원격 분석을 보내고 있는 모든 클라우드 역할을 나열할 수도 있습니다.

  union * | summarize count() by cloud_RoleName, cloud_RoleInstance
  

프록시 통과를 달성하려면 컴퓨터 수준 프록시 또는 애플리케이션 수준 프록시를 구성합니다. DefaultProxy를 참조하세요.

Web.config 예제:

<system.net>
    <defaultProxy>
    <proxy proxyaddress="http://xx.xx.xx.xx:yyyy" bypassonlocal="true"/>
    </defaultProxy>
</system.net>

자세한 내용은 온-프레미스 서버에 대한 Application Insights 에이전트 배포를 참조하세요.

Application Insights 및 Azure Monitor는 HTTPS 연결에 사용되는 TLS 버전을 제어하지 않습니다. TLS 버전은 애플리케이션이 실행되는 운영 체제 및 런타임 환경에 따라 달라집니다.

사용 중인 TLS 버전을 확인하려면 다음을 수행합니다.

• 운영 체제 및 런타임 또는 프레임워크에 대한 설명서를 검토합니다.
• 추가 도움이 필요한 경우 적절한 지원 팀에 문의하세요. Application Insights를 사용하여 지원 요청을 열지 마세요.

TLS 1.2 이상에 대한 언어 및 런타임 지원 예제

다음 버전에는 TLS 1.2 이상에 대한 통합 지원이 포함됩니다.

• .NET/ .NET Core: .NET Framework 4.6.2 이상 및 모든 버전의 .NET Core
• Java: Java 8 업데이트 161(8u161) 이상
• Python: OpenSSL 1.0.1 이상으로 빌드된 Python 배포
• Node.js: Node.js 버전 10 이상

TLS 1.2 이상에 대한 운영 체제 지원 예제

다음 운영 체제에는 TLS 1.2 이상에 대한 통합 지원이 포함됩니다.

• Windows: Windows 8, Windows Server 2012 이상
• Linux: OpenSSL 1.0.1 이상을 사용하는 최신 Linux 배포

서비스 중단을 방지하기 위해 리소스가 상호 작용하는 각 원격 엔드포인트(종속 요청 포함)는 앞에서 언급한 동일한 프로토콜 버전, 암호 그룹 및 타원형 곡선의 조합을 하나 이상 지원해야 합니다. 원격 엔드포인트가 필요한 TLS 구성을 지원하지 않는 경우 사용 중단 후 TLS 구성의 일부 조합에 대한 지원으로 업데이트해야 합니다.

영향을 받는 Application Insights 리소스는 데이터 수집을 중지하고 필요한 애플리케이션 구성 요소에 액세스할 수 없습니다. 따라서 일부 기능이 작동하지 않습니다.

이 문서에 자세히 설명된 TLS(전송 계층 보안) 사용 중단은 2025년 5월 1일 이후의 동작에만 영향을 주어야 합니다. CRUD 작업에 대한 자세한 내용은 Azure Resource Manager TLS 지원을 참조하세요. 이 리소스는 TLS 지원 및 사용 중단 일정에 대한 자세한 내용을 제공합니다.

레거시 TLS 문제에 대한 일반적인 질문은 TLS 문제 해결을 참조하세요.

자세한 내용은 TLS 지원을 참조하세요.

Application Insights를 제거하려면 애플리케이션의 API에서 NuGet 패키지 및 참조를 제거해야 합니다. Visual Studio에서 NuGet 패키지 관리자를 사용하여 NuGet 패키지를 제거할 수 있습니다.

1. 추적 컬렉션을 사용하는 경우 먼저 NuGet 패키지 관리자를 사용하여 Microsoft.ApplicationInsights.TraceListener 패키지를 제거하지만 종속성은 제거하지 않습니다.
2. NuGet 패키지 관리자를 사용하고 NuGet 패키지 관리자 옵션 컨트롤 내에서 제거 옵션을 사용하여 Microsoft.ApplicationInsights.Web 패키지를 제거하고 해당 종속성을 제거합니다.
3. Application Insights를 완전히 제거하려면 프로젝트에 추가한 모든 API 호출과 함께 추가된 코드나 파일을 확인하고 수동으로 삭제합니다. 자세한 내용은 Application Insights SDK를 추가하면 자동으로 만들어지는 항목은 무엇인가요?를 참조하세요.

프로젝트에 Application Insights를 추가하면 자동으로 파일이 만들어지고 일부 파일에 코드가 추가됩니다. NuGet 패키지를 제거해도 파일과 코드가 취소되는 것은 아닙니다. Application Insights를 완전히 제거하려면 프로젝트에 추가한 모든 API 호출과 함께 추가된 코드나 파일을 확인하고 수동으로 삭제해야 합니다.

Visual Studio ASP.NET 프로젝트에 Application Insights 원격 분석을 추가하면 다음 파일이 추가됩니다.

• ApplicationInsights.config
• AiHandleErrorAttribute.cs

다음 코드는 자동으로 추가되었습니다.

• [프로젝트 이름].csproj

    <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4</ApplicationInsightsResourceId>
  

• Packages.config

  <packages>
  ...
  
     <package id="Microsoft.ApplicationInsights" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Agent.Intercept" version="2.4.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.DependencyCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.PerfCounterCollector" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.Web" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer" version="2.12.0" targetFramework="net472" />
     <package id="Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel" version="2.12.0" targetFramework="net472" />
  
     <package id="Microsoft.AspNet.TelemetryCorrelation" version="1.0.7" targetFramework="net472" />
  
     <package id="System.Buffers" version="4.4.0" targetFramework="net472" />
     <package id="System.Diagnostics.DiagnosticSource" version="4.6.0" targetFramework="net472" />
     <package id="System.Memory" version="4.5.3" targetFramework="net472" />
     <package id="System.Numerics.Vectors" version="4.4.0" targetFramework="net472" />
     <package id="System.Runtime.CompilerServices.Unsafe" version="4.5.2" targetFramework="net472" />
  ...
  </packages>
  

• Layout.cshtml

  프로젝트에 Layout.cshtml 파일이 있는 경우 다음 코드가 추가됩니다.

  <head>
  ...
       <script type = 'text/javascript' >
           var appInsights=window.appInsights||function(config)
           {
               function r(config){ t[config] = function(){ var i = arguments; t.queue.push(function(){ t[config].apply(t, i)})} }
               var t = { config:config},u=document,e=window,o='script',s=u.createElement(o),i,f;for(s.src=config.url||'//az416426.vo.msecnd.net/scripts/a/ai.0.js',u.getElementsByTagName(o)[0].parentNode.appendChild(s),t.cookie=u.cookie,t.queue=[],i=['Event','Exception','Metric','PageView','Trace','Ajax'];i.length;)r('track'+i.pop());return r('setAuthenticatedUserContext'),r('clearAuthenticatedUserContext'),config.disableExceptionTracking||(i='onerror',r('_'+i),f=e[i],e[i]=function(config, r, u, e, o) { var s = f && f(config, r, u, e, o); return s !== !0 && t['_' + i](config, r, u, e, o),s}),t
           }({
               instrumentationKey:'00000000-0000-0000-0000-000000000000'
           });
  
           window.appInsights=appInsights;
           appInsights.trackPageView();
       </script>
  ...
  </head>
  

• ConnectedService.json

  {
     "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
     "Version": "16.0.0.0",
     "GettingStartedDocument": {
       "Uri": "https://go.microsoft.com/fwlink/?LinkID=613413"
    }
  }
  

• FilterConfig.cs

           public static void RegisterGlobalFilters(GlobalFilterCollection filters)
           {
               filters.Add(new ErrorHandler.AiHandleErrorAttribute());// This line was added
           }
  

구성에서 원격 분석 상관관계를 사용하지 않도록 설정하려면 <ExcludeComponentCorrelationHttpHeadersOnDomains>에서 를 참조하세요.

자세한 내용은 ASP.NET 웹 사이트에 대한 Application Insights 구성을 참조하세요.

ASP.NET Core 3.1은 Microsoft에서 더 이상 지원되지 않습니다.

ASP.NET Core용 Application Insights SDK 버전 2.8.0 및 Visual Studio 2019 이상은 ASP.NET Core 3.1 애플리케이션과 함께 사용할 수 있습니다.

생성자 삽입을 사용하여 TelemetryClient의 인스턴스를 가져오고, 이 인스턴스에 필요한 TrackXXX() 메서드를 호출합니다. ASP.NET Core 애플리케이션에서 새 TelemetryClient 또는 TelemetryConfiguration 인스턴스를 만들지 않는 것이 좋습니다. TelemetryClient의 싱글톤 인스턴스는 나머지 원격 분석과 DependencyInjection을 공유하는 TelemetryConfiguration 컨테이너에 이미 등록되어 있습니다. 나머지 원격 분석과 별도의 구성이 필요한 경우에만 새 TelemetryClient 인스턴스를 만듭니다.

다음 예에서는 컨트롤러에서 더 많은 원격 분석을 추적하는 방법을 보여줍니다.

using Microsoft.ApplicationInsights;

public class HomeController : Controller
{
    private TelemetryClient telemetry;

    // Use constructor injection to get a TelemetryClient instance.
    public HomeController(TelemetryClient telemetry)
    {
       this.telemetry = telemetry;
    }

    public IActionResult Index()
    {
        // Call the required TrackXXX method.
        this.telemetry.TrackEvent("HomePageRequested");
        return View();
    }
}

Application Insights의 사용자 지정 데이터 보고에 대한 자세한 내용은 Application Insights 사용자 지정 메트릭 API 참조를 참조하세요. GetMetric API를 사용하여 사용자 지정 메트릭을 Application Insights에 보내는 데 비슷한 방법을 사용할 수 있습니다.

ASP.NET Core는 을(를) 통해 HTTP 요청/응답 정보(본문 포함)를 로깅하는 ILogger을 제공합니다. 이를 활용하는 것이 좋습니다. 이로 인해 잠재적으로 원격 분석에서 PII(개인 식별 정보)가 노출될 수 있으며 비용(성능 비용 및 Application Insights 청구)이 크게 증가할 수 있으므로 이를 사용하기 전에 위험을 신중하게 평가합니다.

Application Insights의 기본 설정은 경고 및 더 심각한 로그만 캡처하는 것입니다.

다음과 같이 Application Insights 공급자의 로깅 구성을 변경하여 정보 및 덜 심각한 로그를 캡처합니다.

{
    "Logging": {
        "LogLevel": {
            "Default": "Information"
        },
        "ApplicationInsights": {
            "LogLevel": {
                "Default": "Information"
            }
        }
    },
    "ApplicationInsights": {
        "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
    }
}

다음 예로 인해 Application Insights 공급자가 Information 로그를 캡처하지는 않는다는 점에 주의해야 합니다. 캡처하지 않는 이유는 SDK가 ApplicationInsights에 Warning 로그 및 더 심각한 로그만 캡처하도록 지시하는 기본 로깅 필터를 추가하기 때문입니다. Application Insights에는 명시적 재정의가 필요합니다.

{
    "Logging": {
       "LogLevel": {
           "Default": "Information"
       }
    }
}

자세한 내용은 ILogger 구성을 참조하세요.

UseApplicationInsights() 확장 메서드는 계속 지원되지만 Application Insights SDK 버전 2.8.0 이상에서는 더 이상 사용되지 않는 것으로 표시됩니다. SDK의 다음 주요 버전에서 제거될 것입니다. Application Insights 원격 분석을 사용하도록 설정하려면 일부 구성을 제어하는 오버로드를 제공하는 AddApplicationInsightsTelemetry()를 사용합니다. 또한 ASP.NET Core 3.X 앱에서 services.AddApplicationInsightsTelemetry()는 Application Insights를 사용하도록 설정하는 유일한 방법입니다.

이 문서에서 보여 주듯이 SDK가 빌드 시간에 설치되는 경우 App Service 포털에서 Application Insights 확장을 사용하도록 설정할 필요가 없습니다. 확장이 설치된 경우 SDK가 이미 추가되었음을 검색하면 백오프됩니다. 확장에서 Application Insights를 사용하도록 설정하는 경우 SDK를 설치하고 업데이트할 필요가 없습니다. 그러나 이 문서의 지침에 따라 Application Insights를 사용하도록 설정하면 다음과 같은 이유로 유연성이 향상됩니다.

• Application Insights 원격 분석은 다음 위치에서 계속 동작합니다.
  • Windows, Linux 및 Mac을 포함한 모든 운영 체제
  • 자체 포함 또는 프레임워크 종속성을 포함한 모든 게시 모드
  • 전체 .NET Framework를 포함한 모든 대상 프레임워크
  • Web Apps, VM, Linux, 컨테이너, AKS 및 비 Azure 호스팅을 포함한 모든 호스팅 옵션.
  • 미리 보기 버전을 포함한 모든 .NET Core 버전.
• Visual Studio에서 디버그할 때 원격 분석이 로컬로 표시됩니다.
• TrackXXX() API를 사용하여 더 많은 사용자 지정 원격 분석을 추적할 수 있습니다.
• 구성을 완전히 제어할 수 있습니다.

예. Application Insights Agent 2.0.0-beta1 이상에서 IIS에 호스트되는 ASP.NET Core 애플리케이션이 지원됩니다.

예. SDK에 대한 기능 지원은 다음과 같은 경우를 제외하고 모든 플랫폼에서 동일합니다.

• 성능 카운터가 Windows에서만 지원되므로 SDK는 Linux에서 이벤트 카운터를 수집합니다. 대부분의 메트릭은 동일합니다.

아니요. 대신 작업자 서비스에 대한 Application Insights for Worker Service 애플리케이션(비 HTTP 애플리케이션)을 사용합니다.

Application Insights를 제거하려면 애플리케이션의 API에서 NuGet 패키지 및 참조를 제거해야 합니다. Visual Studio에서 NuGet 패키지 관리자를 사용하여 NuGet 패키지를 제거할 수 있습니다.

1. NuGet 패키지 관리자를 사용하여 Microsoft.ApplicationInsights.AspNetCore 패키지를 제거합니다.
2. Application Insights를 완전히 제거하려면 프로젝트에 추가한 모든 API 호출과 함께 추가된 코드나 파일을 확인하고 수동으로 삭제합니다. 자세한 내용은 Application Insights SDK를 추가할 때 생성되는 항목을 참조하세요.

프로젝트에 Application Insights를 추가하면 파일이 만들어지며 일부 파일에는 코드가 추가됩니다. NuGet 패키지를 제거한다고 해서 파일 및 코드가 항상 삭제되는 것은 아닙니다. Application Insights를 완전히 제거하려면 프로젝트에 추가한 모든 API 호출과 함께 추가된 코드나 파일을 확인하고 수동으로 삭제해야 합니다.

Visual Studio ASP.NET Core 템플릿 프로젝트에 Application Insights 원격 분석을 추가하면 다음 코드가 추가됩니다.

• [프로젝트 이름].csproj

  <PropertyGroup>
       <TargetFramework>netcoreapp3.1</TargetFramework>
       <ApplicationInsightsResourceId>/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/Default-ApplicationInsights-EastUS/providers/microsoft.insights/components/WebApplication4core</ApplicationInsightsResourceId>
  </PropertyGroup>
  
  <ItemGroup>
       <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.12.0" />
  </ItemGroup>
  
  <ItemGroup>
       <WCFMetadata Include="Connected Services" />
  </ItemGroup>
  

• Appsettings.json

  "ApplicationInsights": {
       "ConnectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000"
  }
  

• ConnectedService.json

  {    
       "ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
       "Version": "16.0.0.0",
       "GettingStartedDocument": {
           "Uri": "https://go.microsoft.com/fwlink/?LinkID=798432"
       }
  }
  

• Startup.cs

  public void ConfigureServices(IServiceCollection services)
       {
          services.AddRazorPages();
          services.AddApplicationInsightsTelemetry(); // This is added
       }
  

코드에서 원격 분석 상관관계를 사용하지 않도록 설정하려면 <ExcludeComponentCorrelationHttpHeadersOnDomains>에서 를 참조하세요.

자세한 내용은 ASP.NET Core용 Application Insights를 참조하세요.

• Exception rate: 예외 속도는 시스템 성능 카운터입니다. CLR은 발생하는 처리된 예외 및 처리되지 않은 예외를 모두 계산하고 샘플링 간격의 합계를 간격 길이로 나눕니다. Application Insights SDK는 이 결과를 수집하여 포털에 보냅니다.
• Exceptions: 예외 메트릭은 포털에서 TrackException 받은 보고서를 차트의 샘플링 간격으로 계산합니다. 여기에는 코드에서 호출을 작성하는 TrackException 처리된 예외만 포함됩니다. 처리되지 않은 모든 예외는 포함되지 않습니다.

자세한 내용은 Application Insights에서 .NET용 카운터를 참조하세요.

라이브 메트릭은 EventCounters를 표시하지 않습니다. 원격 분석을 보려면 메트릭 탐색기 또는 Analytics를 사용합니다.

ASP.NET Core용 Application Insights 확장은 아직 이 기능을 지원하지 않습니다.

자세한 내용은 Application Insights에서 .NET용 카운터를 참조하세요.

클라이언트 쪽 모니터링은 기본적으로 ASP.NET Core 앱에 사용하도록 설정됩니다. 사용하지 않도록 설정하려면 다음 정보를 사용하여 서버에서 환경 변수를 정의합니다.

• 이름: APPINSIGHTS_JAVASCRIPT_ENABLED
• 값: false

자세한 내용은 Azure VM 및 가상 머신 확장 집합에 대한 Application Insights를 참조하세요.

실패한 종속성 호출에 필드가 success False로 설정되어 있습니다. 모듈 DependencyTrackingTelemetryModule은 ExceptionTelemetry를 보고하지 않습니다. 종속성에 대한 전체 데이터 모델은 Application Insights 원격 데이터 모델에 설명되어 있습니다.

아래와 같은 코드를 사용합니다.

dependencies
| extend E2EIngestionLatency = ingestion_time() - timestamp 
| extend TimeIngested = ingestion_time()

Log Analytics 쿼리 뷰 timestamp에서는 종속성 호출 응답이 수신된 직후에 발생하는 TrackDependency() 호출이 시작된 순간을 나타냅니다. 종속성 호출이 시작된 시간을 계산하려면 먼저 timestamp을 확인하고, 그런 다음 종속성 호출의 기록된 duration을 빼십시오.

Application Insights의 종속성 추적에는 응답 본문 로깅이 포함되지 않습니다. 대부분의 애플리케이션에서 원격 분석 데이터를 너무 많이 생성하게 되기 때문입니다.

자세한 내용은 종속성 추적을 참조하세요.

가용성 테스트는 전 세계에 분산된 위치 지점에서 실행됩니다. 두 가지 해결 방법이 있습니다.

• 방화벽 문: 길고 변경 가능한 웹 테스트 에이전트 목록에서 서버에 대한 요청을 허용합니다.
• 사용자 지정 코드: 인트라넷 내부에서 서버에 주기적으로 요청을 보내는 코드를 직접 작성합니다. 이러한 목적으로 Visual Studio 웹 테스트를 실행할 수 있습니다. 테스터는 TrackAvailability() API를 사용하여 결과를 Application Insights에 보낼 수 있습니다.

사용자 에이전트 문자열은 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)입니다.

자세한 내용은 가용성 테스트를 참조하세요.

가용성 테스트는 지원되는 각 웹 테스트 위치에서 분산 클라이언트 역할을 합니다. 웹 테스트가 실행될 때마다 가용성 테스트 서비스는 웹 테스트 구성에 정의된 원격 엔드포인트에 연결을 시도합니다. 현재 지원되는 모든 TLS 구성이 포함된 TLS 클라이언트 Hello 메시지가 전송됩니다. 원격 엔드포인트가 가용성 테스트 클라이언트와 공통 TLS 구성을 공유하는 경우 TLS 핸드셰이크가 성공합니다. 그렇지 않으면 TLS 핸드셰이크 실패로 인해 웹 테스트가 실패합니다.

엔드포인트가 지원하는 TLS 구성을 테스트하는 데 사용할 수 있는 여러 도구가 있습니다. 한 가지 방법은 이 페이지에 자세히 설명된 예를 따르는 것입니다. 공용 인터넷을 통해 원격 엔드포인트를 사용할 수 없는 경우 엔드포인트 호출에 액세스할 수 있는 컴퓨터에서 원격 엔드포인트에서 지원되는 TLS 구성의 유효성을 검사해야 합니다.

이 사용 중단의 영향을 받는 모든 TLS 핸드셰이크 실패에 나타나는 예외 형식은 없습니다. 그러나 웹 테스트가 실패하기 시작하는 가장 일반적인 예외는 The request was aborted: Couldn't create SSL/TLS secure channel입니다. 또한 잠재적으로 영향을 받은 웹 테스트 결과에 대한 TLS 전송 문제 해결 단계에서 TLS 관련 오류를 확인할 수 있습니다.

웹 테스트 실행 중에 협상된 TLS 구성은 볼 수 없습니다. 원격 엔드포인트가 가용성 테스트를 통해 공통 TLS 구성을 지원하는 한, 사용 중단 후에도 아무런 영향이 나타나지 않습니다.

이 문서에 자세히 설명된 TLS 사용 중단은 2025년 5월 1일 이후에 가용성 테스트 웹 테스트 실행 동작에만 영향을 줍니다. CRUD 작업을 위한 가용성 테스트 서비스와의 상호 작용에 대한 자세한 내용은 Azure Resource Manager TLS 지원을 참조하세요. 이 리소스는 TLS 지원 및 사용 중단 일정에 대한 자세한 내용을 제공합니다.

레거시 TLS 문제에 대한 일반적인 질문은 TLS 문제 해결을 참조하세요.

자세한 내용은 지원되는 TLS 구성을 참조하세요.

세부 정보는 프로젝트의 유형에 따라 달라집니다. 다음 목록은 웹 애플리케이션의 예입니다.

• 프로젝트에 파일을 추가합니다.

  • ApplicationInsights.config
  • ai.js

• NuGet 패키지를 설치합니다.

  • Application Insights API: 핵심 API
  • 웹 애플리케이션용 Application Insights API: 서버에서 원격 분석을 보내는 데 사용
  • JavaScript 애플리케이션용 Application Insights API: 클라이언트에서 원격 분석을 보내는 데 사용

• 패키지에 어셈블리를 포함합니다.

  • Microsoft.ApplicationInsights
  • Microsoft.ApplicationInsights.Platform

• 항목 삽입 위치:

  • Web.config
  • packages.config

• 클라이언트 및 서버 코드에 코드 조각을 삽입하여 Application Insights 리소스 ID로 해당 코드를 초기화합니다. 예를 들어 MVC 앱에서 코드는 기본 페이지 Views/Shared/_Layout.cshtml에 삽입됩니다. 새 프로젝트의 경우에만 기존 프로젝트에 Application Insights를 수동으로 추가합니다.

Application Insights는 애플리케이션에 대한 요청에 대한 원격 분석을 수집합니다. WebApps/WebServer에서 오류가 발생했고 요청이 사용자 애플리케이션에 도달하지 못한 경우 Application Insights는 이에 대한 원격 분석을 하지 않습니다.

Application Insights에서 계산한 serverresponsetime의 기간은 Web Apps에서 관찰한 서버 응답 시간과 반드시 일치하지는 않습니다. 이 동작은 Application Insights가 요청이 실제로 사용자 애플리케이션에 도달하는 기간만 계산하기 때문입니다. 요청이 WebServer에서 멈추거나 대기 중인 경우 대기 시간은 Web Apps 메트릭에 포함되지만 Application Insights 메트릭에는 포함되지 않습니다.

자세한 내용은 Azure App Service에서 애플리케이션 모니터링 사용을 참조하세요.

Microsoft Learn 플랫폼에 게시된 제품 설명서는 Microsoft 스타일 가이드를 따릅니다.

일반적으로 "auto" 접두사 뒤의 하이픈은 포함하지 않습니다.

자세한 내용은 Azure Monitor Application Insights에 대한 자동 침입이란?을 참조하세요.

Node.js사용자 지정 메트릭을 원하는 경우 Azure Monitor OpenTelemetry Distro를 사용하여 애플리케이션을 수동으로 계측합니다.

Java는 자동 계측을 사용하여 사용자 지정 메트릭을 허용합니다. 코드를 업데이트하고 이 기능을 사용하도록 설정하여 사용자 지정 메트릭을 수집 할 수 있습니다. 코드에 사용자 지정 메트릭이 이미 있는 경우 자동 계측을 사용하도록 설정하면 해당 메트릭이 자동으로 전달됩니다.

AKS 자동 계측은 OSS OpenTelemetry SDK에 의해 원격 분석이 타사로 전송되지 않도록 할 수 있습니다.

AKS 자동 계측은 Application Insights 클래식 API SDK와 OpenTelemetry Distro의 수동 계측 옵션과 공존하도록 설계되었습니다.

항상 중복 데이터를 방지하고 사용자 지정 메트릭이 작동하도록 합니다.

자동 계측과 수동 계측 중 어느 것이 우선하는지를 확인하려면 이 차트를 참조하세요.

Azure Monitor OpenTelemetry 배포판에서 검색된 취약성은 우선 순위가 지정되고 수정되었으며 다음 버전에서 릴리스됩니다.

AKS 자동 계측은 배포가 변경되거나 다시 시작될 때마다 애플리케이션 Pod에 최신 버전의 Azure Monitor OpenTelemetry Distro를 삽입합니다.

OpenTelemetry 배포판은 오랜 시간 동안 변경되거나 다시 시작되지 않는 배포에 취약해질 수 있습니다. 이러한 이유로 배포의 최신 버전이 사용되고 있는지 확인하기 위해 매주 배포를 업데이트하거나 다시 시작하는 것이 좋습니다.

이 기능은 Azure Monitor OpenTelemetry Distro를 애플리케이션 포드에 주입하여 자동 계측을 구현합니다.

Java의 경우 이 기능은 Java용 독립 실행형 Azure Monitor OpenTelemetry Distro를 통합합니다. 자세한 Java 계측 바이너리 정보를 확인하려면 Java 배포판 설명서를 참조하세요.

Node.js의 경우, Node.js용 Azure Monitor OpenTelemetry Distro를 기준으로 자동 계측 바이너리를 삽입합니다. 자세한 내용은 Node.js 배포판 설명서를 참조하세요. Node.js에 대해 독립형 자동 계측이 없다는 것을 유념하세요. 그래서 배포판 문서는 수동 계측을 위한 것입니다. 수동 계측과 관련된 코드 기반 구성 단계를 무시할 수 있습니다. 그러나 기본 설정, 환경 변수 구성 등과 같은 배포판 설명서의 다른 모든 항목은 이 기능에 적용할 수 있습니다.

자세한 내용은 AKS에 대한 자동화 계측을 참조하세요.

새 Azure 지역에서는 계측 키 대신 연결 문자열을 사용해야 합니다. 연결 문자열은 원격 분석 데이터와 연결할 리소스를 식별합니다. 또한 리소스가 원격 분석의 대상으로 사용할 엔드포인트를 수정할 수 있습니다. 연결 문자열을 복사하여 애플리케이션 코드나 환경 변수에 추가합니다.

계측 키 대신 연결 문자열을 사용하는 것이 좋습니다.

APPLICATIONINSIGHTS_CONNECTION_STRING 시스템에서 자동으로 제공하지 않는 모든 시나리오에서 수동으로 설정합니다. 이러한 시나리오는 ASP.NET Core 통합을 사용하는 로컬 개발 및 .NET 격리 함수를 포함하지만 이에 국한되지 않습니다. 이러한 경우 환경 변수는 OpenTelemetry 파이프라인이 Application Insights에 원격 분석을 보낼 수 있도록 합니다. 환경 변수를 사용하여 연결 문자열을 구성하는 방법에 대한 자세한 내용은 Application Insights에서 OpenTelemetry 구성을 참조하세요.

지역 데이터 준수 요구 사항을 충족하려면 글로벌 엔드포인트 대신 지역 Application Insights 엔드포인트를 사용합니다. 글로벌 엔드포인트는 데이터가 특정 지역 내에 유지되도록 보장하지 않습니다. 지역 엔드포인트는 규제 지역 사용자의 원격 분석이 해당 지역의 데이터 센터로만 전송되도록 하는 데 도움이 됩니다.

지역 규정 준수를 위해 글로벌 웹 애플리케이션을 구성하려면 다음을 수행합니다.

• 유럽 연합 또는 미국과 같은 엄격한 규정 준수 요구 사항을 사용하여 지역당 하나의 Application Insights 리소스를 만듭니다.
• 다른 모든 지역의 사용자를 위한 다른 Application Insights 리소스를 만듭니다.
• 각 사용자의 지역에 따라 적절한 Application Insights 리소스에 원격 분석을 보내도록 애플리케이션을 구성합니다. IP 주소, 계정 메타데이터 또는 위치 설정과 같은 신호를 사용하여 지역을 결정합니다.
• 지역 간에 통합 쿼리 환경이 필요한 경우 모든 Application Insights 리소스를 Log Analytics 작업 영역에 연결합니다.

다음은 그 예입니다.

• 지역 A 연결 문자열을 사용하여 지역 A 사용자의 데이터를 지역 A Application Insights 리소스로 보냅니다.
• 지역 B 연결 문자열을 사용하여 지역 B 사용자로부터 지역 B Application Insights 리소스로 데이터를 보냅니다.
• 다른 연결 문자열을 사용하여 다른 모든 사용자 데이터를 범용 Application Insights 리소스로 보냅니다.

다음 다이어그램은 글로벌 웹 애플리케이션에 대한 설정 예제를 보여줍니다.

자세한 내용은 연결 문자열을 참조하세요.

지역 간 기존 Application Insights 리소스 전송은 지원되지 않으며 기록 데이터를 새 지역으로 마이그레이션할 수 없습니다. 해결 방법은 다음과 같습니다.

• 원하는 지역에 새 Application Insights 리소스를 만듭니다.
• 원본 리소스의 고유한 사용자 지정을 새 리소스에 다시 생성합니다.
• 새 지역 리소스의 연결 문자열로 애플리케이션을 업데이트합니다.
• 새로운 Application Insights 리소스를 사용하여 모든 것이 예상대로 작동하는지 테스트합니다.
• 원래 Application Insights 리소스를 유지하거나 삭제하도록 결정합니다. 클래식 리소스를 삭제하면 모든 기록 데이터가 손실됩니다. 리소스가 작업 영역 기반인 경우 데이터는 Log Analytics에 보존되므로 보존 기간이 만료될 때까지 기록 데이터에 액세스할 수 있습니다.

일반적으로 새 지역의 리소스에 대해 수동으로 다시 만들거나 업데이트해야 하는 고유한 사용자 지정 항목은 다음과 같습니다(단, 이에 한정되지 않음).

• 사용자 지정 대시보드 및 통합 문서를 다시 만듭니다.
• 사용자 지정 로그/메트릭 경고의 범위를 다시 만들거나 업데이트합니다.
• 가용성 경고를 다시 만듭니다.
• 사용자가 새 리소스에 액세스하는 데 필요한 모든 사용자 지정 Azure 역할 기반 액세스 제어 설정을 다시 만듭니다.
• 수집 샘플링, 데이터 보존, 일일 제한 및 사용자 지정 메트릭 활성화와 관련된 설정을 복제합니다. 이러한 설정은 사용량 및 예상 비용 창을 통해 제어됩니다.
• 릴리스 주석, 라이브 메트릭 보안 제어 채널 등과 같은 API 키에 의존하는 모든 통합. 새 API 키를 생성하고 연결된 통합을 업데이트해야 합니다.
• 클래식 리소스에서 연속 내보내기를 다시 구성해야 합니다.
• 작업 영역 기반 리소스의 진단 설정을 다시 구성해야 합니다.

API 버전을 채우는 이 방법을 사용하지 않는 것이 좋습니다. 최신 버전은 호환성을 깨뜨릴 수 있는 변경 사항이 포함될 수 있는 미리 보기 릴리스를 나타낼 수 있습니다. 최신 비 미리 보기 릴리스가 있더라도 API 버전이 항상 기존 템플릿과 호환되는 것은 아닙니다. 경우에 따라 API 버전을 일부 구독에서 사용할 수 없는 경우도 있습니다.

자세한 내용은 Application Insights 리소스 만들기 및 구성을 참조하세요.

데이터 모델 또는 스키마 문제와 제안 사항을 보고하려면 GitHub 리포지토리를 사용합니다.

PageView 원격 분석에는 URL이 포함되며 Kusto의 정규식 함수를 사용하여 UTM 매개 변수를 구문 분석할 수 있습니다.

사용자 또는 엔터프라이즈가 브라우저 설정에서 사용자 에이전트 보내기를 사용하지 않도록 설정하는 경우, 이 데이터가 없거나 정확하지 않을 수 있습니다. UA 파서 정규식에는 모든 디바이스 정보가 포함되지 않을 수도 있습니다. 또는 Application Insights에서 최신 업데이트를 채택하지 않았을 수 있습니다.

이는 문자열 값을 사용하는 경우 발생할 수 있습니다. 사용자 지정 측정에서는 숫자 값만 작동합니다.

자세한 내용은 Application Insights 원격 분석 데이터 모델을 참조하세요.

ApplicationInsightsLoggerProvider는 ILogger 로그를 캡처하여 TraceTelemetry를 만듭니다. Exception 개체가 Log의 ILogger 메서드에 전달되는 경우 ExceptionTelemetry 대신 TraceTelemetry가 생성됩니다.

ILogger 원격 분석 보기

Azure portal에서:

1. Azure Portal로 이동하여 Application Insights 리소스에 액세스합니다.
2. Application Insights 내에서 로그 섹션을 선택합니다.
3. KQL(Kusto 쿼리 언어)을 사용하여 테이블에 저장된 traces ILogger 메시지를 쿼리합니다. 쿼리 예: traces | where message contains "YourSearchTerm".
4. 심각도, 시간 범위 또는 특정 메시지 콘텐츠를 사용하여 ILogger 데이터를 필터링하도록 쿼리를 구체화합니다.

Visual Studio(로컬 디버거)에서 다음을 수행합니다.

1. Visual Studio의 디버그 모드에서 애플리케이션을 시작합니다.
2. 애플리케이션이 실행되는 동안 진단 도구 창을 엽니다.
3. 이벤트 탭에서 ILogger 로그는 다른 원격 분석 데이터와 함께 표시됩니다.
4. 특정 ILogger 메시지를 찾으려면 진단 도구 창에서 검색 및 필터 기능을 사용합니다.

항상 TraceTelemetry를 보내려면 다음 코드 조각을 사용합니다.

builder.AddApplicationInsights(
    options => options.TrackExceptionsAsExceptionTelemetry = false);

Application Insights는 다른 모든 원격 분석에 사용되는 것과 동일한 ILogger 정보를 사용하여 TelemetryConfiguration 로그를 캡처하고 전송합니다. 그러나 예외가 있습니다. 기본적으로, TelemetryConfiguration 또는 Startup.cs에서 로그하는 경우에는 이 완전하게 설정되지 않습니다. 이러한 위치의 로그에는 기본 구성이 없으므로 모든 TelemetryInitializer인스턴스와 TelemetryProcessor 인스턴스를 실행하지는 않습니다.

독립 실행형 패키지를 사용하는 경우TelemetryClient는 DI(종속성 주입) 컨테이너에 삽입되지 않습니다. 다음 코드에 나와 있는 것처럼 TelemetryClient의 새 인스턴스를 만들고 로거 공급자에서 사용하는 것과 동일한 구성을 사용해야 합니다. 이러한 요구 사항은 모든 사용자 지정 원격 분석 및 ILogger의 원격 분석에 동일한 구성이 사용되도록 합니다.

public class MyController : ApiController
{
   // This TelemetryClient instance can be used to track additional telemetry through the TrackXXX() API.
   private readonly TelemetryClient _telemetryClient;
   private readonly ILogger _logger;

   public MyController(IOptions<TelemetryConfiguration> options, ILogger<MyController> logger)
   {
        _telemetryClient = new TelemetryClient(options.Value);
        _logger = logger;
   }  
}

Azure Web Apps의 Application Insights 확장은 새 공급자를 사용합니다. 사용 중인 애플리케이션에 대한 appsettings.json 파일의 필터링 규칙을 수정할 수 있습니다.

자세한 내용은 .NET을 사용한 Application Insights 로깅을 참조하세요.

Java Profiler는 JFR(Java Flight Recorder)을 사용하여 사용자 지정된 구성을 사용하여 애플리케이션을 프로파일러합니다.

JFR(Java Flight Recorder)는 실행 중인 Java 애플리케이션의 프로파일링 데이터를 수집하기 위한 도구입니다. JFR은 JVM(Java Virtual Machine)에 통합되며 성능 문제를 해결하는 데 사용됩니다. Java SE JFR 런타임에 대해 자세히 알아봅니다.

Java 프로파일링은 Application Insights의 무료 기능입니다. Azure Monitor Application Insights 가격 책정은 수집 비용을 기반으로 합니다.

JFR에서 수집한 프로파일링 데이터에는 메서드와 실행 프로파일링 데이터, 가비지 수집 데이터, 잠금 프로필이 포함됩니다.

JFR 레코딩은 원하는 도구(예: JMC(Java Mission Control))를 사용하여 보고 분석할 수 있습니다.

'성능 진단 및 권장 사항'은 Application Insights Java Diagnostics로 곧 제공될 새로운 기능입니다. 이 기능을 미리 보려면 등록합니다. JMC(Java Mission Control)를 사용하여 JFR 기록을 볼 수 있습니다.

주문형은 실시간 사용자 트리거 프로파일링인 반면 자동 프로파일링은 미리 구성된 트리거를 사용합니다.

주문형 프로파일링 옵션으로 지금 프로파일링을 사용합니다. 지금 프로파일링은 Application Insights 인스턴스에 연결된 모든 에이전트를 즉시 프로파일링합니다.

자동화된 프로파일링은 리소스 임계값에 도달하여 트리거됩니다.

Application Insights Java 에이전트는 현재 CPU 및 메모리 사용량 모니터링을 지원합니다. CPU 임계값은 컴퓨터에서 사용 가능한 모든 코어의 백분율로 구성됩니다. 메모리는 영역의 최대 가능 크기에 대한 현재 종신 메모리 영역(OldGen) 점유율입니다.

필수 구성 요소를 검토합니다.

예, JFR을 사용하여 마이크로 서비스를 실행하는 JVM을 프로파일링할 수 있습니다.

자세한 내용은 Java용 Azure Monitor Application Insights Profiler를 참조하세요.

아니요, 샘플링 재정의는 이제 GA(일반 공급)이며 자동 침입 및 수동 계측 모두에 사용할 수 있습니다.

자동 계측을 사용하는 경우 Azure 포털에서 applicationinsights.json 파일을 업데이트합니다.

자동 계측의 경우 수동 에이전트 업로드가 필요하지 않습니다. 그러나 수동 계측의 경우 배포 패키지에 Application Insights 에이전트 JAR 파일 및 구성 파일을 포함해야 합니다.

로컬 개발은 개발자의 컴퓨터 또는 Azure Cloud Shell 인스턴스와 같이 앱을 빌드하거나 테스트하는 환경을 나타냅니다. 애플리케이션 서버는 Azure App Service 환경에서 Tomcat 11과 같이 애플리케이션을 실행하는 웹 서버를 나타냅니다. 수동 계측을 사용하는 경우 에이전트 JAR 파일이 애플리케이션 서버에 올바르게 배치되었는지 확인해야 합니다.

자동 침입의 경우 Azure Portal을 통해 샘플링 재정의를 구성할 수 있습니다. 수동 계측을 사용하는 경우 Application Insights 에이전트 JAR을 적절한 디렉터리에 배치하고 원하는 샘플링 설정에 applicationinsights.json 파일을 포함해야 합니다.

자세한 내용은 샘플링 재정의 - Java용 Azure Monitor Application Insights를 참조하세요.

TelemetryClient.trackTrace()는 Application Insights 클래식 SDK 브리지의 일부이며 로그 프로세서는 새 OpenTelemetry 기반 계측에서만 작동합니다.

자세한 내용은 원격 분석 프로세서(미리 보기) - Java용 Azure Monitor Application Insights를 참조하세요.

• JavaScript SDK는 웹 클라이언트에서 사용자 쿠키를 설정하여 다시 방문하는 사용자와 그룹 작업에 대한 세션 쿠키를 식별합니다.
• 클라이언트 쪽 스크립트가 없으면 서버에서 쿠키를 설정할 수 있습니다.
• 한 명의 실제 사용자가 특정 사이트를 다른 브라우저에서 사용하거나, in-private/incognito 검색을 통해 사용하거나, 다른 컴퓨터에서 사용하는 경우 두 번 이상 계산됩니다.
• 여러 컴퓨터 및 브라우저에서 로그인한 사용자를 식별하려면 setAuthenticatedUserContext()에 대한 호출을 추가합니다.

Application Insights JavaScript SDK는 웹 사이트에 대한 오버헤드를 최소화합니다. Gzip 압축 크기가 36KB에 불과해 초기화하는 데 15밀리초밖에 걸리지 않으므로 SDK가 웹 사이트에 추가하는 로드 시간은 무시할 수 있습니다. SDK를 사용할 때 라이브러리의 최소 구성 요소가 빠르게 로드되고 전체 스크립트가 백그라운드에서 다운로드됩니다.

또한 스크립트가 CDN에서 다운로드되는 동안 페이지의 모든 추적이 큐에 대기되므로 페이지의 전체 수명 주기 동안 원격 분석이 손실되지 않습니다. 이 설정 프로세스는 사용자에게 보이지 않는 원활한 분석 시스템을 페이지에 제공합니다.

실행 가능한 예제는 Application Insights JavaScript SDK 샘플을 참조하세요.

이 SDK가 계속해서 "작동"하고 이전 브라우저에서 로드될 때 JavaScript 실행이 중단되지 않도록 필요한 조치를 취해야 합니다. 구형 브라우저를 지원하지 않는 것이 이상적이지만 수많은 대규모 고객은 사용자의 브라우저 선택에 관여할 수 없습니다.

이 설명은 가장 낮은 수준의 일반 기능 집합만 지원한다는 의미가 아닙니다. ES3 코드 호환성을 유지해야 합니다. 새로운 기능을 ES3 JavaScript 구문 분석을 중단하지 않는 방식으로, 그리고 선택적 기능으로 추가해야 합니다.

Internet Explorer 8 지원에 대한 자세한 내용은 GitHub를 참조하세요.

예. Application Insights JavaScript SDK는 오픈 소스입니다. 소스 코드를 보거나 프로젝트에 기여하려면 공식 GitHub 리포지토리를 참조하세요.

자세한 내용은 Azure Monitor Application Insights 실제 사용자 모니터링 사용을 참조하세요.

서버 쪽에서 해당 헤더와의 연결을 수락할 수 있어야 합니다. 서버 쪽 Access-Control-Allow-Headers 구성에 따라 Request-Id, Request-Context 및 traceparent(W3C 분산 헤더)를 수동으로 추가하여 서버 쪽 목록을 확장해야 하는 경우가 많습니다.

Access-Control-Allow-Headers: Request-Id, traceparent, Request-Context<your header>

구성에서 분산 추적을 사용하지 않도록 설정할 수 있습니다.

아니요. "502 잘못된 게이트웨이" 및 "503 서비스를 사용할 수 없음" 오류는 Application Insights에서 항상 캡처되지는 않습니다. 클라이언트 측 JavaScript만 모니터링에 사용되는 경우 모니터링 JavaScript 코드 조각이 렌더링되는 HTML 헤더를 포함하는 페이지보다 먼저 오류 응답이 반환되기 때문에 이 동작이 예상됩니다.

서버 측 모니터링을 사용하는 서버에서 502 또는 503 응답을 보낸 경우 Application Insights SDK에서 오류를 수집합니다.

그러나 애플리케이션의 웹 서버에서 서버 쪽 모니터링을 사용하도록 설정한 경우에도 Application Insights에서 502 또는 503 오류가 캡처되지 않는 경우도 있습니다. 대부분의 최신 웹 서버는 클라이언트가 직접 통신하는 것을 허용하지 않습니다. 대신 역방향 프록시와 같은 솔루션을 사용하여 클라이언트와 프런트 엔드 웹 서버 간에 정보를 전달합니다.

이 시나리오에서는 역방향 프록시 계층에서 문제가 발생하여 502 또는 503 응답이 클라이언트에 반환될 수 있으며 Application Insights에서 기본으로 캡처하지 않습니다. 이 계층에서 문제를 탐지하려면 역방향 프록시에서 Log Analytics로 로그를 전달하고 502 또는 503 응답을 확인하는 사용자 지정 규칙을 만들어야 할 수 있습니다. 502 및 503 오류의 일반적인 원인에 대한 자세한 내용은 Azure App Service의 HTTP 오류 "502 잘못된 게이트웨이" 및 "503 서비스를 사용할 수 없음" 문제 해결을 참조하세요.

자세한 내용은 Application Insights JavaScript SDK 구성을 참조하세요.

브라우저는 요청의 HTTP 헤더에 있는 사용자 에이전트 문자열을 전달합니다. Application Insights 수집 서비스는 UA 파서를 사용하여 데이터 테이블 및 환경에서 표시되는 필드를 생성합니다. 따라서 Application Insights 사용자는 이러한 필드를 변경할 수 없습니다.

사용자 또는 엔터프라이즈가 브라우저 설정에서 사용자 에이전트 보내기를 사용하지 않도록 설정하는 경우, 이 데이터가 없거나 정확하지 않을 수 있습니다. UA 파서 정규식에는 모든 디바이스 정보가 포함되지 않을 수도 있습니다. 또는 Application Insights에서 최신 업데이트를 채택하지 않았을 수 있습니다.

자세한 내용은 Application Insights JavaScript SDK에 대한 프레임워크 확장 사용을 참조하세요.

아니요. 기존 ARM 템플릿 및 API 호출은 계속 작동합니다. 클래식 리소스를 만들려고 하면 관리되는 작업 영역이 있는 작업 영역 기반 리소스가 대신 만들어집니다.

아니요. 개별 리소스 마이그레이션에 대한 알림을 사용할 수 없습니다. 리소스를 마이그레이션하는 시기와 방법을 제어하려면 수동 마이그레이션을 사용합니다.

개별 마이그레이션은 일반적으로 2분 이내에 완료됩니다. 전체 롤아웃은 모든 지역에서 몇 주 동안 진행됩니다.

마이그레이션 후 리소스는 개요 페이지의 Log Analytics 작업 영역에 연결됩니다. 클래식 사용 중지 알림이 제거되고 사용 중지 통합 문서에 더 이상 리소스가 나열되지 않습니다.

비용은 일반적으로 비슷하게 유지됩니다. 작업 영역 기반 Application Insights를 사용하면 비용 절감 기능을 사용할 수 있으며 가격 책정 계획을 검토하는 것이 좋습니다.

레거시 청구 모델을 사용하는 경우 가격 책정 설명서 에서 자세한 내용을 검토하세요.

아니요. 모든 경고, 대시보드 및 가용성 테스트는 그대로 유지되며 마이그레이션 후에도 계속 작동합니다.

자세한 내용은 Application Insights의 관리되는 작업 영역을 참조하세요.

원격 분석 상관관계를 사용하지 않도록 설정하려면 구성에서 correlationHeaderExcludedDomains 속성을 사용합니다. 자세한 내용은 ApplicationInsights-node.js를 참조하세요.

Application Insights에서 사용할 원하는 로그 수준을 구성하려면 환경 변수를 APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL 사용합니다. 지원되는 값은 NONE, ERROR, WARN, INFO, DEBUG, VERBOSE 및 ALL입니다. 자세한 내용은 ApplicationInsights-node.js를 참조하세요.

자세한 내용은 Application Insights를 사용하여 Node.js 서비스 및 앱 모니터링을 참조하세요.

SDK 버전 및 이름 목록은 GitHub에서 호스팅됩니다. 자세한 내용은 SDK 버전을 참조하세요.

자세한 내용은 Application Insights에서 OpenTelemetry를 사용하여 원격 분석 수집을 참조하세요.

OpenTelemetry는 공급업체 중립적인 가시성 프레임워크입니다. OpenTelemetry SDK 또는 라이브러리에는 Application Insights API가 없습니다. 마이그레이션하기 전에 OpenTelemetry의 몇 가지 개념을 이해하는 것이 중요합니다.

• Application Insights에서 모든 원격 분석은 단일 TelemetryClient 및 TelemetryConfiguration을 통해 관리되었습니다. OpenTelemetry에서 세 가지 원격 분석 신호(추적, 메트릭, 로그)는 각각 고유한 구성을 가집니다. 외부 라이브러리 없이 .NET 런타임을 통해 원격 분석을 수동으로 만들 수 있습니다. 자세한 내용은 분산 추적, 메트릭, 로깅에 대한 .NET 가이드를 참조하세요.

• Application Insights는 TelemetryModules를 사용하여 애플리케이션에 대한 원격 분석을 자동으로 수집합니다. 대신 OpenTelemetry는 계측 라이브러리를 사용하여 특정 구성 요소(예: 요청에 대한 AspNetCore 및 종속성용 HttpClient)에서 원격 분석을 수집합니다.

• Application Insights는 TelemetryInitializers를 사용하여 추가 정보로 원격 분석을 보강하거나 속성을 재정의합니다. OpenTelemetry를 사용하면 프로세서를 작성하여 특정 신호를 사용자 지정할 수 있습니다. 또한 많은 OpenTelemetry 계측 라이브러리는 특정 구성 요소에서 생성된 원격 분석을 사용자 지정하는 Enrich 메서드를 제공합니다.

• Application Insights는 TelemetryProcessors를 사용하여 원격 분석을 필터링합니다. OpenTelemetry 프로세서를 사용하여 특정 신호에 필터링 규칙을 적용할 수도 있습니다.

이 표에서는 Application Insights 데이터 형식을 OpenTelemetry 개념 및 해당 .NET 구현에 매핑합니다.

다음 문서에서는 자세한 정보를 제공합니다.

• Azure Monitor Application Insights의 데이터 수집 기본 사항
• Application Insights 원격 분석 데이터 모델
• OpenTelemetry 개념

Application Insights는 샘플링을 구성하는 여러 옵션을 제공하지만 Azure Monitor Exporter 또는 Azure Monitor Distro는 고정 속도 샘플링만 제공합니다. 요청 및 종속성(OpenTelemetry Traces)만 샘플링할 수 있습니다.

샘플링을 구성하는 방법을 자세히 설명하는 코드 샘플은 샘플링 사용 가이드를 참조하세요.

Application Insights .NET SDK에서 원격 분석 프로세서를 사용하여 원격 분석을 필터링 및 수정하거나 삭제합니다. 원격 분석 이니셜라이저를 사용하여 사용자 지정 속성을 추가하거나 수정합니다. 자세한 내용은 Azure Monitor 설명서를 참조하세요. OpenTelemetry는 이러한 개념을 원격 분석을 보강하고 필터링하는 활동 또는 로그 프로세서로 대체합니다.

추적 필터링

OpenTelemetry에서 원격 분석 데이터를 필터링하려면 활동 프로세서를 구현할 수 있습니다. 이 예제는 Azure Monitor 설명서에 설명된 대로 원격 분석 데이터를 필터링하는 Application Insights 예제와 동일합니다. 이 예제에서는 실패한 종속성 호출이 필터링되는 위치를 보여 줍니다.

using System.Diagnostics;
using OpenTelemetry;

internal sealed class SuccessfulDependencyFilterProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (!OKtoSend(activity))
        {
            activity.ActivityTraceFlags &= ~ActivityTraceFlags.Recorded;
        }
    }

    private bool OKtoSend(Activity activity)
    {
       return activity.Kind == ActivityKind.Client && activity.Status == ActivityStatusCode.Ok;
    }
}

이 프로세서를 사용하려면 TracerProvider를 만들고 AddAzureMonitorTraceExporter 앞에 프로세서를 추가해야 합니다.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddProcessor(new SuccessfulDependencyFilterProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

로그 필터링

ILogger 구현에는 로그 필터링을 적용하는 기본 제공 메커니즘이 있습니다. 이 필터링을 통해 OpenTelemetryLoggerProvider를 포함하여 등록된 각 공급자로 전송되는 로그를 제어할 수 있습니다. “OpenTelemetry”는 필터링 규칙을 구성하는 데 사용되는 에 대한 OpenTelemetryLoggerProvider입니다.

다음 예제에서는 “오류”를 기본값 LogLevel로 정의하고 사용자 정의 범주에 대한 최소 LogLevel로 “경고”를 정의합니다. 정의된 이러한 규칙은 OpenTelemetryLoggerProvider에만 적용됩니다.

builder.AddFilter<OpenTelemetryLoggerProvider>("*", LogLevel.Error);
builder.AddFilter<OpenTelemetryLoggerProvider>("MyProduct.MyLibrary.MyClass", LogLevel.Warning);

자세한 내용은 로그에 대한 OpenTelemetry .NET 설명서를 참조하세요.

추적에 사용자 지정 속성 추가

OpenTelemetry에서 활동 프로세서를 사용하여 더 많은 속성으로 원격 분석 데이터를 보강할 수 있습니다. 원격 분석 속성을 수정할 수 있는 Application Insights에서 원격 분석 이니셜라이저를 사용하는 것과 비슷합니다.

기본적으로 Azure Monitor Exporter는 실패한 경우 응답 코드가 400 이상인 HTTP 요청에 플래그를 지정합니다. 그러나 400을 성공으로 처리하려는 경우 활동의 성공을 설정하고 더 많은 원격 분석 속성을 포함하도록 태그를 추가하는 보강 활동 프로세서를 추가할 수 있습니다. Azure Monitor 설명서에 설명된 대로 Application Insights에서 이니셜라이저를 사용하여 속성을 추가하거나 수정하는 것과 비슷합니다.

다음은 사용자 지정 속성을 추가하고 특정 응답 코드에 대한 기본 동작을 재정의하는 방법의 예입니다.

using System.Diagnostics;
using OpenTelemetry;

/// <summary>
/// Custom Processor that overrides the default behavior of treating response codes >= 400 as failed requests.
/// </summary>
internal class MyEnrichingProcessor : BaseProcessor<Activity>
{
    public override void OnEnd(Activity activity)
    {
        if (activity.Kind == ActivityKind.Server)
        {
            int responseCode = GetResponseCode(activity);

            if (responseCode >= 400 && responseCode < 500)
            {
               // If we set the Success property, the SDK won't change it
               activity.SetStatus(ActivityStatusCode.Ok);

               // Allow to filter these requests in the portal
              activity.SetTag("Overridden400s", "true");
            }

            // else leave the SDK to set the Success property
        }
    }

    private int GetResponseCode(Activity activity)
    {
       foreach (ref readonly var tag in activity.EnumerateTagObjects())
       {    
          if (tag.Key == "http.response.status_code" && tag.Value is int value)
          {
           return value;
          }
       }

       return 0;
    }
}

이 프로세서를 사용하려면 TracerProvider를 만들고 AddAzureMonitorTraceExporter 앞에 프로세서를 추가해야 합니다.

using OpenTelemetry.Trace;

public static void Main()
{
   var tracerProvider = Sdk.CreateTracerProviderBuilder()
       .AddSource("Company.Product.Name")
       .AddProcessor(new MyEnrichingProcessor())
       .AddAzureMonitorTraceExporter()
       .Build();
}

추적 보내기 - 수동

Application Insights의 추적은 RequestTelemetry 및 DependencyTelemetry로 저장됩니다. OpenTelemetry에서 추적은 Span 클래스를 사용하는 Activity으로 모델링됩니다.

OpenTelemetry .NET은 .NET 런타임의 일부인 추적에 대한 ActivitySource 클래스와 Activity 클래스를 사용합니다. 이 방법은 .NET 구현이 추적 API를 런타임 자체에 직접 통합하기 때문에 고유합니다. 이 System.Diagnostics.DiagnosticSource 패키지를 사용하면 개발자가 ActivitySource 인스턴스를 만들고 관리하는 데 Activity를 사용할 수 있습니다. 이 메서드는 .NET 에코시스템의 기본 제공 기능을 적용하여 외부 라이브러리에 의존하지 않고 .NET 애플리케이션에 추적을 추가하는 원활한 방법을 제공합니다. 자세한 내용은 분산 추적 계측 연습을 참조하세요.

수동 추적을 마이그레이션하는 방법은 다음과 같습니다.

종속성 텔레메트리

Application Insights DependencyTelemetry는 나가는 요청을 모델링하는 데 사용됩니다. 이를 OpenTelemetry로 변환하는 방법은 다음과 같습니다.

Application Insights 예제:

DependencyTelemetry dep = new DependencyTelemetry
{
   Name = "DependencyName",
   Data = "https://www.example.com/",
   Type = "Http",
   Target = "www.example.com",
   Duration = TimeSpan.FromSeconds(10),
   ResultCode = "500",
   Success = false
};

dep.Context.Cloud.RoleName = "MyRole";
dep.Context.Cloud.RoleInstance = "MyRoleInstance";
dep.Properties["customprop1"] = "custom value1";
client.TrackDependency(dep);

OpenTelemetry 예제:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("DependencyName", ActivityKind.Client))
{
  activity?.SetTag("url.full", "https://www.example.com/");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("http.request.method", "GET");
  activity?.SetTag("http.response.status_code", "500");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Error);
  activity?.SetEndTime(activity.StartTimeUtc.AddSeconds(10));
}

요청 원격 측정 (RequestTelemetry)

Application Insights RequestTelemetry는 들어오는 요청을 모델링합니다. 이를 OpenTelemetry로 마이그레이션하는 방법은 다음과 같습니다.

Application Insights 예제:

RequestTelemetry req = new RequestTelemetry
{
   Name = "RequestName",
   Url = new Uri("http://example.com"),
   Duration = TimeSpan.FromSeconds(10),
   ResponseCode = "200",
   Success = true,
   Properties = { ["customprop1"] = "custom value1" }
};

req.Context.Cloud.RoleName = "MyRole";
req.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackRequest(req);

OpenTelemetry 예제:

var activitySource = new ActivitySource("Company.Product.Name");
var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
  .SetResourceBuilder(resourceBuilder)
  .AddSource(activitySource.Name)
  .AddAzureMonitorTraceExporter()
  .Build();

// Emit traces
using (var activity = activitySource.StartActivity("RequestName", ActivityKind.Server))
{
  activity?.SetTag("url.scheme", "https");
  activity?.SetTag("server.address", "www.example.com");
  activity?.SetTag("url.path", "/");
  activity?.SetTag("http.response.status_code", "200");
  activity?.SetTag("customprop1", "custom value1");
  activity?.SetStatus(ActivityStatusCode.Ok);
}

사용자 지정 작업 추적

Application Insights에서 StartOperation 및 StopOperation 메서드를 사용하여 사용자 지정 작업을 추적합니다. OpenTelemetry .NET에서 ActivitySource 및 Activity를 사용하여 구현합니다. ActivityKind.Server 및 ActivityKind.Consumer를 사용하는 작업의 경우 Azure Monitor Exporter는 RequestTelemetry를 생성합니다. ActivityKind.Client, ActivityKind.Producer, ActivityKind.Internal의 경우 DependencyTelemetry를 생성합니다. 사용자 지정 작업 추적에 대한 자세한 내용은 Azure Monitor 설명서를 참조하세요. .NET에서 ActivitySource 및 Activity를 사용하는 방법에 대한 자세한 내용은 .NET 분산 추적 계측 연습을 참조하세요.

다음은 사용자 지정 작업에 대한 활동을 시작하고 중지하는 방법의 예입니다.

using System.Diagnostics;
using OpenTelemetry;

var activitySource = new ActivitySource("Company.Product.Name");

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
    .AddSource(activitySource.Name)
    .AddAzureMonitorTraceExporter()
    .Build();

// Start a new activity
using (var activity = activitySource.StartActivity("CustomOperation", ActivityKind.Server))
{
    activity?.SetTag("customTag", "customValue");

    // Perform your custom operation logic here

    // No need to explicitly call Activity.Stop() because the using block automatically disposes the Activity object, which stops it.
}

로그 보내기

Application Insights의 로그는 TraceTelemetry 및 ExceptionTelemetry로 저장됩니다.

TraceTelemetry

OpenTelemetry에서 로깅은 ILogger 인터페이스를 통해 통합됩니다. TraceTelemetry의 마이그레이션 방법은 다음과 같습니다.

Application Insights 예제:

TraceTelemetry traceTelemetry = new TraceTelemetry 
{
   Message = "hello from tomato 2.99",
   SeverityLevel = SeverityLevel.Warning,
};

traceTelemetry.Context.Cloud.RoleName = "MyRole";
traceTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
client.TrackTrace(traceTelemetry);

OpenTelemetry 예제:

var resourceAttributes = new Dictionary<string, object>
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory
var logger = loggerFactory.CreateLogger<Program>();

// Emit log: This uses the logger instance to write a new log
logger.FoodPrice("tomato", 2.99);

internal static partial class LoggerExtensions
{
   [LoggerMessage(LogLevel.Warning, "Hello from `{name}` `{price}`.")]
   public static partial void FoodPrice(this ILogger logger, string name, double price);
}

ExceptionTelemetry

Application Insights는 ExceptionTelemetry를 사용하여 예외를 기록합니다. OpenTelemetry로 마이그레이션하는 방법은 다음과 같습니다.

Application Insights 예제:

ExceptionTelemetry exceptionTelemetry = new ExceptionTelemetry(new Exception("Test exception"))
{
    SeverityLevel = SeverityLevel.Error
};

exceptionTelemetry.Context.Cloud.RoleName = "MyRole";
exceptionTelemetry.Context.Cloud.RoleInstance = "MyRoleInstance";
exceptionTelemetry.Properties["customprop1"] = "custom value1";
client.TrackException(exceptionTelemetry);

OpenTelemetry 예제:

var resourceAttributes = new Dictionary<string, object> 
{
   { "service.name", "MyRole" },
   { "service.instance.id", "MyRoleInstance" }
};

var resourceBuilder = ResourceBuilder.CreateDefault().AddAttributes(resourceAttributes);

using var loggerFactory = LoggerFactory.Create(builder => builder
   .AddOpenTelemetry(logging =>
   {
       logging.SetResourceBuilder(resourceBuilder);
       logging.AddAzureMonitorLogExporter();
   }));

// Create a new instance `ILogger` from the above LoggerFactory.
var logger = loggerFactory.CreateLogger<Program>();

try
{
    // Simulate exception
    throw new Exception("Test exception");
}
catch (Exception ex)
{
   // Emit exception: This uses the logger instance to write a new exception
   logger?.LogError(ex, "An error occurred");
}

메트릭 보내기

Application Insights의 메트릭은 MetricTelemetry로 저장됩니다. OpenTelemetry에서 메트릭은 Meter 패키지에서 System.Diagnostics.DiagnosticSource로 모델링됩니다.

Application Insights에는 비사전 집계(TrackMetric()) 및 사전 집계(GetMetric().TrackValue()) 메트릭 API가 모두 있습니다. OpenTelemetry와 달리 Application Insights에는 계측에 대한 개념이 없습니다. Application Insights에는 모든 메트릭 시나리오에 대해 동일한 API가 있습니다.

반면 OpenTelemetry는 사용자가 먼저 메트릭의 실제 의미 체계에 따라 올바른 메트릭 계측을 선택해야 합니다. 예를 들어 수신된 총 서버 요청 수 등과 같은 항목을 계산하려는 경우 OpenTelemetry 카운터를 사용해야 합니다. 다양한 백분위수(예: 서버 대기 시간의 P99 값)를 계산하려는 경우 OpenTelemetry 히스토그램 계측을 사용해야 합니다. Application Insights와 OpenTelemetry 간의 이러한 근본적인 차이로 인해 직접적인 비교는 수행되지 않습니다.

Application Insights와 달리 OpenTelemetry는 메트릭을 보강하거나 필터링하는 기본 제공 메커니즘을 제공하지 않습니다. Application Insights에서 원격 분석 프로세서 및 이니셜라이저를 사용하여 메트릭을 수정하거나 삭제할 수 있지만 OpenTelemetry에서는 이 기능을 사용할 수 없습니다.

또한 OpenTelemetry는 Application Insights에 있는 TrackMetric() 기능과 동일하지 않으므로 원시 메트릭 전송을 직접 지원하지 않습니다.

Application Insights에서 OpenTelemetry로 마이그레이션하려면 모든 Application Insights 메트릭 API 사용을 OpenTelemetry API로 바꿔야 합니다. 다양한 OpenTelemetry 계측과 해당 의미 체계를 이해해야 합니다.

기타 원격 분석 유형

사용자 정의 이벤트

OpenTelemetry에서 지원되지 않습니다.

Application Insights 예제:

TelemetryClient.TrackEvent()

AvailabilityTelemetry

OpenTelemetry에서 지원되지 않습니다.

Application Insights 예제:

TelemetryClient.TrackAvailability()

페이지뷰텔레메트리

OpenTelemetry에서 지원되지 않습니다.

Application Insights 예제:

TelemetryClient.TrackPageView()

라이브 메트릭을 포함하지 않는 콘솔 및 작업자 서비스 애플리케이션에는 Azure Monitor OpenTelemetry Exporter를 사용하는 것이 좋습니다.

자세한 내용은 .NET Application Insights SDK에서 Azure Monitor OpenTelemetry로 마이그레이션을 참조하세요.

Application Insights 사용자 지정 샘플러가 이전이 아닌 범위 생성 후 샘플링 결정을 내리므로 기존의 헤드 기반 접근 방식을 따르지 않습니다. 대신 범위 생성이 완료된 후, 내보내기 전에 샘플링 결정을 적용합니다.

이 동작은 어떤 면에서는 테일 기반 샘플링과 유사하지만, 샘플러는 결정하기 전에 동일한 추적에서 여러 범위를 수집할 때까지 기다리지 않습니다. 대신 추적 ID의 해시를 사용하여 추적 완성도를 보장합니다.

이 방법은 추적 완전성과 효율성의 균형을 맞추고 전체 꼬리 기반 샘플링과 관련된 더 높은 비용을 방지합니다.

전체 추적의 결과에 기반하여 샘플링 결정을 내리려면 (예: 추적 내 어떤 범위가 실패했는지를 결정하는 경우) 다운스트림 에이전트 또는 수집기에서 전체 후미 기반 샘플링이 필요합니다. 이 기능은 현재 지원되지 않지만 피드백 허브를 통해 새 기능으로 요청할 수 있습니다.

아니요, 샘플러가 추적의 모든 원격 분석 유형에 고정 속도를 적용합니다. 요청, 종속성 및 기타 범위는 동일한 샘플링 비율을 따릅니다. 원격 분석 유형별로 다양한 속도를 적용하기 위해 OpenTelemetry 스팬 프로세서 또는 (인제션 타임 변환)[opentelemetry-overview.md#telemetry-routing]을 사용하는 것이 좋습니다.

Application Insights 사용자 지정 샘플러에서는 기본적으로 W3C 추적 컨텍스트 표준을 사용하여 샘플링 결정을 전파합니다. 이 표준을 사용하면 샘플링 의사 결정이 서비스 간에 흐르도록 할 수 있습니다. 그러나 샘플러가 다운스트림 서비스를 호출한 후 범위 생성이 끝날 때 샘플링 결정을 내리기 때문에 전파는 불완전한 샘플링 정보를 전달합니다. 이 제한은 W3C 추적 컨텍스트 사양을 준수하지만 다운스트림 서비스는 이 전파된 샘플링 결정을 안정적으로 사용할 수 없습니다.

아니요, Application Insights 사용자 지정 샘플러가 업스트림 서비스에서 동일한 샘플링 알고리즘을 사용하는 경우에도 항상 독립적인 샘플링 결정을 내립니다. W3C 추적 컨텍스트 헤더를 사용하는 것을 포함하여 업스트림 서비스의 샘플링 결정은 다운스트림 서비스의 결정에 영향을 주지 않습니다. 그러나 추적 ID의 해시를 기반으로 샘플을 수행하여 추적 완성도를 보장합니다. 일관성을 개선하고 추적이 손상될 가능성을 줄이려면 시스템의 모든 구성 요소가 동일한 샘플러 및 샘플링 속도를 사용하도록 구성합니다.

추적이 불완전하게 나타날 수 있는 몇 가지 이유가 있습니다.

• 분산 시스템의 여러 노드는 의사 결정을 조정하지 않는 다양한 샘플링 방법을 사용합니다. 예를 들어 한 노드는 OpenTelemetry 헤드 기반 샘플링을 적용하고 다른 노드는 Azure Monitor 사용자 지정 샘플러를 통해 샘플링을 적용합니다.
• 서로 다른 노드는 모두 동일한 샘플링 방법을 사용하더라도 서로 다른 샘플링 속도로 설정됩니다.
• 서비스 쪽 파이프라인에서 필터링, 샘플링 또는 속도 한도를 설정하고, 이 구성은 추적 완전성을 고려하지 않고 범위를 임의로 샘플링합니다.

한 구성 요소가 샘플링 결정을 전파하지 않고(W3C 추적 컨텍스트 헤더를 통해) 헤드 기반 샘플링을 적용하는 경우 다운스트림 서비스는 독립적으로 추적을 샘플링하므로 범위가 삭제될 수 있습니다. 따라서 Application Insights에서 볼 때 추적의 일부 부분을 항상 사용할 수 있는 것은 아닙니다.

자세한 내용은 OpenTelemetry를 사용한 Azure Monitor Application Insights의 샘플링을 참조하세요.

이는 가시성을 위한 오픈 소스 표준입니다. OpenTelemetry에서 자세히 알아보세요.

Microsoft는 다음과 같은 이유로 OpenTelemetry에 투자하고 있습니다.

• 공급업체에 구애받지 않으며 모든 언어에서 일관된 API/SDK를 제공합니다.
• 시간이 지나면서 OpenTelemetry를 통해 Azure Monitor 고객은 지원되는 언어 이외의 언어로 작성된 애플리케이션을 관찰할 수 있게 될 것입니다.
• OpenTelemetry는 다양한 계측 라이브러리 집합을 통해 수집할 수 있는 데이터 형식을 확장합니다.
• OpenTelemetry SDK(소프트웨어 개발자 키트)는 이전 모델인 Application Insights SDK보다 대체로 대규모 성능이 더 우수합니다.
• OpenTelemetry는 오픈 소스를 수용하는 Microsoft의 전략에 부합합니다.

OpenTelemetry 상태를 확인하세요.

이는 Azure에서 최고 수준의 환경을 제공하기 위해 모든 OpenTelemetry 구성 요소를 함께 묶는 가는 끈이라고 생각할 수 있습니다. 이 래퍼를 OpenTelemetry의 배포라고도합니다.

커뮤니티의 네이티브 OpenTelemetry에 비해 Azure Monitor OpenTelemetry Distro를 사용하면 다음과 같은 몇 가지 이점이 있습니다.

• 활성화 노력 감소
• Microsoft에서 지원
• 다음과 같은 Azure 관련 기능을 제공합니다.
  • 클래식 Application Insights SDK와 호환되는 샘플링
  • Microsoft Entra 인증
  • 오프라인 스토리지 및 자동 다시 시도
  • 통계 비트
  • Azure Application Insights 표준 메트릭
  • 리소스 메타데이터를 검색하여 다양한 Azure 환경에서 클라우드 역할 이름과 클라우드 역할 인스턴스를 자동으로 채웁니다.
  • 실시간 지표

OpenTelemetry의 설계 방향에 따라 개방적이고 확장 가능하도록 Distro를 설계했습니다. 예를 들어, 다음을 추가할 수 있습니다.

• OTLP(OpenTelemetry Protocol) 내보내기 도구 및 두 번째 대상으로 동시에 보내기
• Distro에 포함되지 않은 기타 계측 라이브러리

Distro는 OpenTelemetry 배포를 제공하므로 Distro는 OpenTelemetry에서 지원하는 모든 항목을 지원합니다. 예를 들어 OpenTelemetry가 지원하는 경우 원격 분석 프로세서, 내보내기 도구 또는 계측 라이브러리를 더 추가할 수 있습니다.

지원되는 독립 실행형 OpenTelemetry 내보내기 도구가 없는 언어의 경우 Azure Monitor OpenTelemetry Distro는 현재 Azure Monitor에서 OpenTelemetry를 사용할 수 있는 유일한 방법입니다. 지원되는 독립 실행형 OpenTelemetry 내보내기 도구가 있는 언어의 경우 원격 분석 시나리오에 따라 Azure Monitor OpenTelemetry Distro 또는 적절한 독립 실행형 OpenTelemetry 내보내기 도구를 사용할 수 있습니다. 자세한 내용은 언제 Azure Monitor OpenTelemetry 내보내기 도구를 사용해야 하나요?를 참조하세요.

.NET, Java, JavaScript(Node.js) 및 Python에 대한 사용 설정 문서를 확인하세요.

기능이 모니터링 요구 사항에 부합하는 경우 새 프로젝트에 Azure Monitor OpenTelemetry Distro를 사용하는 것이 좋습니다. OpenTelemetry는 플랫폼 간 관찰 가능성을 향상시키고 원격 분석 수집에 대한 표준화된 접근 방식을 제공하는 업계 표준 프레임워크입니다.

그러나 Application Insights SDK는 다음을 포함하여 OpenTelemetry에서 아직 완전히 자동화되지 않은 특정 기능을 여전히 제공합니다.

• 자동 종속성 추적 – OpenTelemetry는 종속성 추적을 지원하지만 일부 종속성에는 Application Insights SDK에서 사용할 수 있는 자동 추적에 비해 추가 구성이 필요합니다.
• 사용자 지정 원격 분석 유형(예: AvailabilityTelemetry, PageViewTelemetry)은 OpenTelemetry에 직접 해당하는 항목이 없습니다. 수동 계측을 통해 유사한 기능을 구현할 수 있습니다.
• 원격 분석 프로세서 및 이니셜라이저 – OpenTelemetry에는 프로세서와 범위 프로세서가 있지만 모든 시나리오에서 Application Insights 원격 분석 프로세서 및 이니셜라이저를 완전히 대체하지는 않습니다.
• 확장 메트릭 수집 – OpenTelemetry에는 강력한 메트릭 시스템이 있지만 Application Insights SDK의 일부 기본 제공 메트릭에는 OpenTelemetry에서 수동 설정이 필요합니다.

OpenTelemetry는 다음을 포함하여 Application Insights SDK에 비해 이점을 제공합니다.

• 플랫폼 간 표준화 개선
• 계측 라이브러리의 광범위한 에코시스템
• 데이터 수집 및 처리의 유연성 향상
• Azure Monitor OpenTelemetry Distro는 여전히 Azure에 최적화되어 있지만 공급업체 중립성이 향상되었습니다.

Azure Monitor의 OpenTelemetry 통합은 지속적으로 발전하고 있으며 Microsoft는 계속해서 기능을 향상하고 있습니다. 전환을 고려 중인 경우 OpenTelemetry가 현재 관찰성 요구 사항을 충족하는지 또는 Application Insights SDK가 요구 사항에 더 잘 맞는지 신중하게 평가합니다.

ASP.NET Core, Java, Node.js 및 Python의 경우 Azure Monitor OpenTelemetry Distro를 사용하는 것이 좋습니다. 시작하는 한 줄의 코드입니다.

클래식 ASP.NET, 콘솔 앱, Windows Forms(WinForms) 등을 비롯한 다른 모든 .NET 시나리오의 경우 .NET Azure Monitor OpenTelemetry 내보내기 Azure.Monitor.OpenTelemetry.Exporter을(를) 사용하는 것이 좋습니다.

고급 구성이 필요한 더 복잡한 Python 원격 분석 시나리오의 경우 Python Azure Monitor OpenTelemetry Exporter를 사용하는 것이 좋습니다.

다음 차트는 각 언어에 대한 OpenTelemetry 기능 지원을 분석한 것입니다.

키

• ✅ 이 기능은 공식적인 지원을 통해 모든 고객이 사용할 수 있습니다.
• ⚠ 이 기능은 퍼블릭 미리 보기 상태로 지원됩니다. Microsoft Azure 미리 보기에 대한 보충 사용 약관을 참조하세요.
• ❌ 이 기능은 사용할 수 없거나 적용할 수 없습니다.

예, 하지만 권장하지 않으며 Azure에서 지원하지 않습니다. OpenTelemetry JavaScript는 Node.js에 맞게 과도하게 최적화되어 있습니다. 대신 Application Insights JavaScript SDK를 사용하는 것이 좋습니다.

OpenTelemetry 웹 SDK에는 결정된 가용성 타임라인이 없습니다. Application Insights JavaScript SDK에 대한 실행 가능한 대안인 브라우저 SDK가 제공되려면 몇 년이 걸릴 수 있습니다.

OpenTelemetry 웹 샌드박스는 OpenTelemetry가 브라우저에서 작동하도록 디자인된 포크입니다. 아직 Application Insights에 원격 분석을 보낼 수 없습니다. SDK는 일반 클라이언트 이벤트를 정의하지 않습니다.

Distro를 사용하면 Azure Monitor와 동시에 OTLP 엔드포인트로 내보낼 수 있지만 이 방식은 테스트하거나 지원할 계획이 없습니다.

이는 권장되지 않습니다. Microsoft Azure 미리 보기에 대한 보충 사용 약관을 참조하세요.

OpenTelemetry 개요를 참조하세요.

Microsoft에서 아직 애플리케이션 모니터링에 대한 에이전트 기반 접근 방법을 공식적으로 지원하지 않지만, 일부 고객은 OpenTelemetry 수집기를 에이전트 대안으로 사용합니다. 그동안 오픈 소스 커뮤니티에서는 일부 고객이 Azure Monitor Application Insights에 데이터를 보내는 데 사용하는 OpenTelemetry 수집기 Azure Monitor 내보내기 도구에 기여했습니다. Microsoft에서는 지원되지 않습니다.

OpenCensus는 OpenTelemetry의 이전 버전입니다. Microsoft에서는 OpenTracing과 OpenCensus를 통합하여 전 세계 단일 가시성 표준으로 OpenTelemetry를 만듭니다. Azure Monitor의 현재 프로덕션 권장 Python SDK는 OpenCensus를 기준으로 합니다. Microsoft는 OpenTelemetry를 기반으로 Azure Monitor를 만들기 위해 최선을 다하고 있습니다.

OpenTelemetry 추적이 아닌 원시 텍스트 로그를 시각화하려고 할 수 있습니다.

Application Insights에서 'Traces' 테이블은 진단 목적으로 원시 텍스트 로그를 저장합니다. 이는 사용자 요청, 기타 이벤트 및 예외 보고서와 관련된 추적을 식별하고 상호 연결하는 데 도움이 됩니다. 그러나 'Traces' 테이블은 Grafana와 같은 시각화 도구의 엔드투엔드 트랜잭션 보기(폭포형 차트)에 직접적으로 기여하지 않습니다.

클라우드 네이티브 방식의 채택이 증가함에 따라 원격 분석 컬렉션 및 용어도 발전하고 있습니다. OpenTelemetry는 원격 분석 데이터를 수집하고 계측하기 위한 표준이 되었습니다. 이러한 컨텍스트에서 'Traces'라는 용어는 새로운 의미를 갖게 되었습니다. OpenTelemetry의 'Traces'는 원시 로그 대신 개별 작업 단위를 나타내는 범위를 포함하는 더욱 풍부하고 구조화된 형태의 원격 분석을 나타냅니다. 이러한 범위는 자세한 트랜잭션 보기를 구성하여 클라우드 네이티브 애플리케이션을 더 효과적으로 모니터링하고 진단하는 데 중요합니다.

Blazor 앱을 계측하려면 먼저 호스팅 모델을 식별합니다. Blazor Server는 전체 OpenTelemetry 기반 계측을 지원합니다. Blazor WebAssembly는 브라우저에서 실행되며 JavaScript를 통한 제한된 계측을 지원합니다.

자세한 내용은 Application Insights에 대한 OpenTelemetry 지원 및 피드백을 참조하세요.

아니요. 대시보드에 표시되는 데이터에 대한 기간 제한은 30일입니다.

Application Insights 인스턴스를 이동하거나 이름을 바꾸면 "리소스를 찾을 수 없음" 오류가 발생할 수 있습니다.

이 동작을 해결하려면 기본 대시보드를 삭제하고 애플리케이션 대시보드를 다시 선택하여 새 대시보드를 다시 만듭니다.

자세한 내용은 Application Insights 개요 대시보드를 참조하세요.

간단한 대답은 어떠한 기본 제공 채널도 백 엔드로 원격 분석 제공에 대해 트랜잭션 유형의 보증을 제공하지 않는다는 것입니다. ServerTelemetryChannel는 신뢰할 수 있는 제공 측면에서 InMemoryChannel와 비교하여 더 고급이지만, 원격 분석을 전송하는 데에는 최선의 시도만 수행합니다. 다음과 같은 일반적인 시나리오를 비롯한 몇 가지 상황에서는 원격 분석이 여전히 손실될 수 있습니다.

• 애플리케이션의 작동이 중단되면 메모리의 항목이 손실됩니다.
• 네트워크 문제가 장기간 계속되면 원격 분석이 손실됩니다. 네트워크 중단 중에 또는 Application Insights 백 엔드에서 문제가 발생하는 경우, 원격 분석은 로컬 디스크에 저장됩니다. 그러나 48시간이 지난 항목은 삭제됩니다.
• Windows에서 원격 분석을 저장하는 기본 디스크 위치는 %LOCALAPPDATA% or %TEMP%입니다. 이러한 위치는 일반적으로 컴퓨터에 로컬로 있습니다. 애플리케이션이 물리적으로 한 위치에서 다른 위치로 마이그레이션되면, 원래 위치에 저장된 원격 분석은 모두 손실됩니다.
• Windows의 Azure Web Apps에서, 기본 디스크 스토리지 위치는 D:\local\LocalAppData입니다. 이 위치는 계속 유지되지 않습니다. 앱을 다시 시작하거나, 스케일 아웃하거나, 기타 작업 중에 그 위치가 사라져 그곳에 저장된 모든 원격 분석이 손실될 수 있습니다. 기본값을 재정의해서 D:\home과 같은 지속형 위치로 스토리지를 지정할 수 있습니다. 그러나 이러한 지속형 위치는 원격 스토리지에서 제공되므로 속도가 느려질 수 있습니다.

가능성이 낮지만 채널이 중복된 원격 분석 항목을 발생시킬 수도 있습니다. 이 동작은 ServerTelemetryChannel이(가) 네트워크 오류 또는 시간 제한으로 인해 다시 시도할 때 발생합니다. 원격 분석이 백 엔드에 전달되었지만 네트워크 문제로 인해 응답이 손실되었거나 시간 제한이 있을 경우에 해당합니다.

패키지와 네임스페이스의 이름에 "WindowsServer"가 포함되지만, 이 채널은 Windows 이외의 시스템에서 지원됩니다. 단, 다음은 예외입니다. Windows 이외의 시스템에서 이 채널은 기본값으로 로컬 스토리지 폴더를 만들지 않습니다. 로컬 스토리지 폴더를 만들고 채널이 이를 사용하도록 구성해야 합니다. 로컬 스토리지가 구성된 후에는 채널이 모든 시스템에서 동일한 방식으로 작동합니다.

네트워크 문제나 대역폭 제한이 있는 동안에 SDK는 로컬 스토리지에 원격 분석 항목을 저장합니다. 이 데이터는 로컬로 암호화되지 않습니다.

Windows 시스템의 경우, SDK는 자동으로 %TEMP% 또는 %LOCALAPPDATA% 디렉터리에 임시 로컬 폴더를 만들고 관리자와 현재 사용자만으로 액세스를 제한합니다.

Windows 이외의 시스템의 경우 SDK에서 로컬 스토리지를 자동으로 만들지 않으므로 기본값으로 로컬에 저장되는 데이터가 없습니다.

스토리지 디렉터리를 직접 만들고 채널이 이를 사용하도록 구성할 수 있습니다. 이 경우 디렉터리에 보안이 설정 되었는지 확인해야 합니다. 자세한 내용은 데이터 보호 및 프라이버시를 참조하세요.

자세한 내용은 Application Insights의 원격 분석 채널을 참조하세요.

제한 요약을 참조하세요.

POST 데이터를 자동으로 기록하지는 않지만 TrackTrace 또는 로그 호출을 사용할 수 있습니다. 메시지 매개 변수에 게시 데이터를 넣습니다. 속성을 필터링할 수 있는 동일한 방법으로 메시지에서 필터링할 수는 없지만 크기 제안은 더 깁니다.

Azure Functions는 URL 쿼리 문자열을 기록하지 않습니다.

자세한 내용은 트랜잭션 검색 및 진단을 참조하세요.

잠재적 원인은 다음과 같습니다.

• 다른 구성 요소가 Application Insights를 통해 계측됩니까?
• 최신의 안정적인 Application Insights SDK를 사용하고 있습니까?
• 이러한 구성 요소가 별도의 Application Insights 리소스인 경우 액세스 권한이 있는지 확인합니다. 액세스 권한이 있고 구성 요소가 최신 Application Insights SDK를 통해 계측되는 경우 오른쪽 위에 있는 피드백 채널을 통해 알려 주세요.

현재 아웃바운드 종속성 호출은 인바운드 요청과는 별도로 표시됩니다. 일반적으로 두 호출은 네트워크 왕복으로 인해 기간 값만 다를 뿐 동일하게 보입니다. 기간 막대의 선행 아이콘과 고유한 스타일은 구분하는 데 도움이 됩니다. 이러한 데이터 표시가 혼란스러운가요? 의견을 보내주세요!

타임라인은 트랜잭션 차트의 클록 스큐에 맞게 조정됩니다. 세부 정보 창이나 Log Analytics를 사용하여 정확한 타임스탬프를 볼 수 있습니다.

이 동작은 의도된 것입니다. 모든 구성 요소에서 관련된 모든 항목은 이미 위쪽 및 아래쪽 섹션의 왼쪽에서 사용할 수 있습니다. 새 환경에는 왼쪽에서 다루지 않는 두 개의 관련 항목, 즉 이 이벤트 전후 5분의 모든 원격 분석 및 사용자 타임라인이 있습니다.

트랜잭션 진단 환경은 작업 ID를 공유하는 단일 작업의 모든 원격 분석을 보여 줍니다. 기본적으로 JavaScript용 Application Insights SDK는 고유한 각 페이지 보기당 새 작업을 만듭니다. SPA(단일 페이지 애플리케이션)에서는 단일 페이지 보기 이벤트만 생성되며, 모든 원격 분석에 동일한 작업 ID가 사용됩니다. 따라서 많은 이벤트가 동일한 작업과 상호 연관될 수 있습니다.

이 시나리오에서는 자동 경로 추적을 사용하여 SPA에서 탐색을 위한 새 작업을 자동으로 만들 수 있습니다. URL 경로가 업데이트될 때마다(논리적 페이지 보기 발생) 페이지 보기가 생성되도록 enableAutoRouteTracking을 켜야 합니다. 작업 ID를 수동으로 새로 고치려면 appInsights.properties.context.telemetryTrace.traceID = Microsoft.ApplicationInsights.Telemetry.Util.generateW3CId()를 호출합니다. PageView 이벤트를 수동으로 트리거하면 작업 ID도 다시 설정됩니다.

Gantt 차트에 설명되지 않은 시간은 추적된 종속성이 적용되지 않는 시간입니다. 이 문제는 외부 호출이 자동으로 또는 수동으로 계측되지 않았기 때문에 발생할 수 있습니다. 또한 소요된 시간이 외부 호출이 아닌 처리 중이었기 때문에 발생할 수 있습니다.

모든 호출이 계측된 경우 처리 중이 소요 시간의 근본 원인일 수 있습니다. 프로세스를 진단하는 데 유용한 도구는 .NET Profiler입니다.

이 오류는 브라우저가 필요한 API를 호출할 수 없거나 API가 실패 응답을 반환했음을 나타냅니다. 동작 문제를 해결하려면 브라우저 InPrivate 창을 열고 실행 중인 브라우저 확장을 사용하지 않도록 설정한 다음, 포털 동작을 재현할 수 있는지 확인합니다. 포털 오류가 계속 발생하면 다른 브라우저나 다른 머신으로 테스트를 시도하고 API 호출이 실패한 클라이언트 머신에서 DNS 또는 기타 네트워크 관련 문제를 조사합니다. 포털 오류가 지속되고 추가 조사가 필요한 경우 예기치 않은 포털 동작을 재현하는 동안 브라우저 네트워크 추적을 수집하고 Azure Portal에서 지원 사례를 엽니다.

자세한 내용은 트랜잭션 검색 및 진단을 참조하세요.

시각화의 초기 이벤트는 처음으로 사용자가 세션 중 해당 페이지 보기 또는 사용자 지정 이벤트를 전송한 경우만을 나타냅니다. 사용자가 세션에서 초기 이벤트를 여러 번 보낼 수 있는 경우 1단계 열에는 모든 인스턴스가 아닌 초기 이벤트의 첫 번째 인스턴스 이후에 사용자가 동작하는 방식만 표시됩니다.

편집 메뉴의 Split by 옵션을 사용하세요.

1. 이벤트 메뉴에서 세분화할 이벤트를 선택합니다.

2. 차원 메뉴에서 차원을 선택합니다. 예를 들어 단추 클릭이라는 이벤트가 있는 경우 단추 이름이라는 사용자 지정 속성을 사용해 봅니다.

코호트와 필터는 다릅니다. 영국의 사용자로 이루어진 코호트가 있고(이전 예제와 같이 정의됨) 해당 결과를 필터 Country or region = United Kingdom을 설정할 때의 결과와 비교한다고 가정해보겠습니다.

• 코호트 버전은 현재 시간 범위에서 영국으로부터 하나 이상의 이벤트를 전송한 사용자의 모든 이벤트를 표시합니다. 국가 또는 지역별로 분할하면 많은 국가와 지역이 표시될 수 있습니다.

• 필터 버전은 영국의 이벤트만 표시합니다. 국가 또는 지역별로 분할해도 영국만 표시됩니다.

데이터 그레인 필터를 선택하여 그레인을 변경할 수 있습니다. 필터는 모든 차원 탭에서 사용할 수 있습니다.

시각적 자료가 사용자의 모든 질문에 답하지 않는 경우 HEART 워크북에 제공되는 데이터를 자세히 살펴볼 수 있습니다. 이 작업을 수행하려면 Application Insights의 모니터링 섹션에서 로그를 선택하고 테이블을 쿼리합니다 customEvents . 클릭 분석 특성 중 일부는 customDimensions 필드에 포함됩니다.

예제 쿼리는 다음과 같습니다.

customEvents
| where isnotnull(customDimensions.actionType)
| extend parentid=tostring(customDimensions.parenId),
pagename=tostring(customDimensions.pageName),
actiontype=tostring(customDimensions.actionType)
| project actiontype,parentid,pagename,
user_AuthenticatedId,user_Id,session_Id,itemType,timestamp

Azure Monitor의 로그에 대한 자세한 내용은 Azure Monitor 로그 개요를 참조하세요.

예. 통합 문서 템플릿을 편집하는 방법을 알아보려면 Azure 통합 문서 템플릿을 참조하세요.

자세한 내용은 Application Insights를 사용한 사용 현황 분석을 참조하세요.

예, 구성은 웹 애플리케이션의 나머지 부분과 공유됩니다.

생성자 삽입을 사용하여 TelemetryClient의 인스턴스를 가져오고, 이 인스턴스에 필요한 TrackXXX() 메서드를 호출합니다. 새로 TelemetryClient 인스턴스를 만드는 것은 권장하지 않습니다. TelemetryClient의 싱글톤 인스턴스는 나머지 원격 분석과 DependencyInjection을 공유하는 TelemetryConfiguration 컨테이너에 이미 등록되어 있습니다. 새 TelemetryClient 인스턴스를 만드는 것은 나머지 원격 분석과 분리된 구성이 필요한 경우에만 권장됩니다.

Visual Studio IDE의 온보딩은 현재 ASP.NET/ASP.NET Core 애플리케이션에 대해서만 지원하고 있습니다. 이 문서는 Visual Studio에서 작업자 서비스 애플리케이션 온보딩을 지원하는 경우 업데이트됩니다.

아니요. Azure Monitor Application Insights Agent는 현재 .NET만 지원합니다.

예. 해당 SDK에 대한 기능 지원은 모든 플랫폼에서 동일하지만 다음과 같은 경우는 예외입니다.

• 성능 카운터는 라이브 메트릭에 표시된 프로세스 CPU/메모리를 제외하고 Windows에서만 지원됩니다.

• ServerTelemetryChannel을 기본적으로 사용하도록 설정하는 경우에도 애플리케이션이 Linux 또는 macOS에서 실행될 때 네트워크 문제가 있으면 채널에서 원격 분석을 일시적으로 유지하기 위해 로컬 스토리지 폴더를 자동으로 만들지 않습니다. 이 제한으로 인해 일시적인 네트워크 또는 서버 문제가 있으면 원격 분석이 손실됩니다. 이 문제를 해결하려면 다음과 같이 채널에 대한 로컬 폴더를 구성합니다.

  using Microsoft.ApplicationInsights.Channel;
  using Microsoft.ApplicationInsights.WindowsServer.TelemetryChannel;
  
       public void ConfigureServices(IServiceCollection services)
       {
           // The following will configure the channel to use the given folder to temporarily
           // store telemetry items during network or Application Insights server issues.
           // User should ensure that the given folder already exists
           // and that the application has read/write permissions.
           services.AddSingleton(typeof(ITelemetryChannel),
                                   new ServerTelemetryChannel () {StorageFolder = "/tmp/myfolder"});
           services.AddApplicationInsightsTelemetryWorkerService();
       }
  

자세한 내용은 작업자 서비스 애플리케이션용 Application Insights(비 HTTP 애플리케이션)를 참조하세요.