Partager via

Windows Azure 1.4 진단 기능 상세 개요

  • Article

최초 문서 게시일: 2011년 8월 24일 수요일

인터넷을 검색해 보면 Windows Azure에서 진단 기능을 사용하는 방법에 대해 다루는 많은 문서와 게시물을 확인할 수 있습니다. 그러나 실제로 사용 가능한 기능에 대한 자세한 정보를 확인하려고 하면, 관련 내용을 다루는 문서의 수는 많지만 각각 다른 Azure 버전에 대해 설명하기 때문에 많은 시간을 들여 최신 Azure SDK(1.4)에서 작동하는 기능을 일일이 찾아야 하는 경우가 많습니다. 이 게시물에서는 1.4 버전 SDK에서 Azure 진단 기능을 사용하는 방법의 요점을 설명합니다.

 

먼저, 대부분의 사용자 여러분들도 아시다시피 Azure에는 Trace.Write, Trace.WriteLine, Trace.TraceInformation 등의 Trace.* 명령을 가져와 메모리에 저장하는 기본 제공 추적 수신기가 포함되어 있습니다. 그러나 이러한 명령을 메모리에서 영구 저장소로 이동하려면 특정 작업을 수행해야 합니다. 즉, 데이터를 수동으로 전송하거나 전송 실행 일정을 구성해야 합니다. 그뿐만 아니라 이벤트 로그에서 정보를 이동하고, 성능 카운터를 캡처하고, IIS 로그와 사용자 지정 로그도 이동할 수 있습니다.

 

위에서 언급한 모든 일반적인 로깅 및 디버깅 도구를 사용하는 것 외에도, 응용 프로그램을 호스팅하는 Azure 서버에 대해 RDP를 수행하도록 배포를 구성할 수 있으며 IntelliTrace가 배포된 응용 프로그램에서 제한적인 디버깅 및 문제 해결을 수행하도록 설정할 수도 있습니다. 아래에서 이러한 각 옵션에 대해 설명하겠습니다.

 

데이터를 저장소에 영구적으로 저장하는 빈도, 할당할 저장소의 양, 캡처할 성능 카운터 등 서로 다른 진단 구성 요소를 구성하려면 표준 웹 역할 Azure 응용 프로그램에서 제공되는 WebRole.cs 파일에서 코드를 작성하는 것이 가장 쉽습니다. 작업자 역할 프로젝트의 WorkerRole.cs 파일과 같이, VM 역할을 제외한 대부분의 Azure 기능은 WebRole 클래스와 비슷합니다. 코드를 살펴보기 전에 먼저 Azure 역할 프로젝트로 이동하여 구성 탭에서 "진단 결과에 대한 저장소 계정 자격 증명을 지정하십시오."라는 확인란을 선택해야 합니다. 해당 섹션의 선택 단추를 사용하여 Azure의 저장소 계정을 선택합니다. 로컬 개발은 사용하지 마십시오. 이렇게 하면 'Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString'이라는 새 연결 문자열이 프로젝트에 저장됩니다 .

 

그러면 웹 역할 클래스의 전체 코드 청크를 살펴본 다음 각 코드 부분에 대해 자세히 살펴보겠습니다.

 

public override bool OnStart()

{

   // For information on handling configuration changes

   // see the MSDN topic at https://go.microsoft.com/fwlink/?linkid=166357&clcid=0x412(영문일 수 있음)

 

   try

   {

       //initialize the settings framework

                Microsoft.WindowsAzure.CloudStorageAccount.SetConfigurationSettingPublisher((configName, configSetter) =>

       {

          configSetter(RoleEnvironment.GetConfigurationSettingValue(configName));

       });

 

       //get the storage account using the default Diag connection string

       CloudStorageAccount cs =

          CloudStorageAccount.FromConfigurationSetting(

          "Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString");

 

       //get the diag manager

       RoleInstanceDiagnosticManager dm = cs.CreateRoleInstanceDiagnosticManager(

          RoleEnvironment.DeploymentId,

          RoleEnvironment.CurrentRoleInstance.Role.Name,

          RoleEnvironment.CurrentRoleInstance.Id);

 

       //get the current configuration

       DiagnosticMonitorConfiguration dc = dm.GetCurrentConfiguration();

 

       //if that failed, get the values from config file

       if (dc == null)

          dc = DiagnosticMonitor.GetDefaultInitialConfiguration();

 

       //Windows Azure Logs

       dc.Logs.BufferQuotaInMB = 10;

       dc.Logs.ScheduledTransferLogLevelFilter = LogLevel.Verbose;

       dc.Logs.ScheduledTransferPeriod = TimeSpan.FromMinutes(5);

 

       //Windows Event Logs

       dc.WindowsEventLog.BufferQuotaInMB = 10;

       dc.WindowsEventLog.DataSources.Add("System!*");

       dc.WindowsEventLog.DataSources.Add("Application!*");

       dc.WindowsEventLog.ScheduledTransferPeriod = TimeSpan.FromMinutes(15);

 

       //Performance Counters

       dc.PerformanceCounters.BufferQuotaInMB = 10;

       PerformanceCounterConfiguration perfConfig =

          new PerformanceCounterConfiguration();

       perfConfig.CounterSpecifier = @"\Processor(_Total)\% Processor Time";

       perfConfig.SampleRate = System.TimeSpan.FromSeconds(60);

      dc.PerformanceCounters.DataSources.Add(perfConfig);

       dc.PerformanceCounters.ScheduledTransferPeriod = TimeSpan.FromMinutes(10);

 

       //Failed Request Logs

       dc.Directories.BufferQuotaInMB = 10;

       dc.Directories.ScheduledTransferPeriod = TimeSpan.FromMinutes(30);

 

       //Infrastructure Logs

       dc.DiagnosticInfrastructureLogs.BufferQuotaInMB = 10;

       dc.DiagnosticInfrastructureLogs.ScheduledTransferLogLevelFilter =

          LogLevel.Verbose;

       dc.DiagnosticInfrastructureLogs.ScheduledTransferPeriod =

          TimeSpan.FromMinutes(60);

 

       //Crash Dumps

       CrashDumps.EnableCollection(true);

 

       //overall quota; must be larger than the sum of all items

       dc.OverallQuotaInMB = 5000;

 

       //save the configuration

       dm.SetCurrentConfiguration(dc);

   }

   catch (Exception ex)

   {

       System.Diagnostics.Trace.Write(ex.Message);

   }

 

   return base.OnStart();

}

 

이제 이 코드를 좀 더 자세히 살펴보겠습니다. 먼저, 사용 중인 저장소 계정에 연결할 수 있도록 진단에 사용되는 연결 문자열의 값을 가져옵니다. 이 저장소 계정을 사용하여 진단 모니터 구성 클래스에 액세스합니다. 그런 후에 다양한 로깅 구성 요소의 구성을 시작할 수 있습니다.

 

모든 Trace.* 호출은 Windows Azure 로그에 저장됩니다. 로그에서 사용하는 테이블에 최대 10MB의 데이터가 저장되고, 수준이 Verbose 이상인 모든 쓰기에 대해 5분마다 쓰기를 테이블에 영구 저장하도록 로그를 구성합니다. Windows Azure에서 이 로깅 데이터를 저장하는 데 사용하는 각 테이블과 큐의 목록은 https://msdn.microsoft.com/ko-kr/library/hh180875.aspx  및 https://msdn.microsoft.com/ko-kr/library/microsoft.windowsazure.diagnostics.diagnosticmonitorconfiguration.aspx(영문일 수 있음)에서 확인할 수 있습니다. 인프라 로그와 진단 로그는 사실상 동일합니다.

 

이벤트 뷰어 항목의 경우 캡처하려는 각 로그를 WindowsEventLog 클래스의 DataSources 목록에 추가해야 합니다 . 입력할 수 있는 값은 'Application!*', 'System!*' 또는 'UserData!*'입니다 . 다른 속성은 Windows Azure 로그에 대해 설명한 것과 동일합니다 .

 

성능 카운터의 경우에는 캡처할 카운터와 카운터에서 데이터를 샘플링할 빈도를 지정해야 합니다. 위의 예제에서는 CPU용 카운터를 추가하고 60초마다 데이터를 샘플링하도록 구성했습니다.

 

마지막으로 크래시 덤프를 캡처할 수 있도록 설정하고, 모든 로깅 데이터의 전체 할당량을 약 5GB로 변경한 다음 변경 내용을 저장합니다. 전체 할당량은 반드시 늘려야 하며, 그렇지 않으면 저장소 공간이 부족하여 위에서 설명한 변경을 수행할 수 없다는 예외가 throw됩니다. 현재까지는 5GB 정도면 안전하지만 이 수치는 각 환경에 따라 달라질 수 있습니다.

 

이제 구성이 완료되었으므로 응용 프로그램을 게시할 수 있습니다. Visual Studio에서 응용 프로그램을 게시할 때는 두 가지 사항에 주의해야 합니다.

 

 

먼저, Windows Azure 게시 설정(Windows Azure Publish Settings) 대화 상자에서 .NET 4 역할에 대해 IntelliTrace 사용(Enable IntelliTrace for .NET 4 roles) 확인란을 선택해야 합니다. 여기에 대해서는 뒷부분에서 자세히 설명합니다. 또한 원격 데스크톱 연결 구성...(Configure Remote Desktop connections...) 링크를 클릭하는 것이 좋습니다. 이 링크를 클릭해야만 문제를 해결할 수 있는 경우가 있습니다. 원격 데스크톱 설명서에는 다소 오래된 내용이 있으므로, 구성 파일을 수동으로 편집하지 말고 이 대화 상자의 링크를 사용하는 것이 좋습니다. 링크를 클릭하면 다음과 같은 대화 상자가 표시됩니다.

 

 

이 대화 상자에서 주목할 사항은 다음과 같습니다.

  1. PFX 파일을 가지고 있다면 어떤 인증서든 사용할 수 있습니다. 응용 프로그램을 게시하기 전에 호스티드 서비스에 이 인증서를 업로드해야 합니다.
  2. 사용자 이름(User name) 필드에는 원하는 이름을 입력하면 됩니다. 그러면 해당 사용자 이름과 암호를 사용하는 로컬 계정이 만들어집니다.

 

이와 같이 두 대화 상자에서 모두 원하는 설정을 지정하고 응용 프로그램을 게시합니다. 게시한 후에는 응용 프로그램을 한 번 방문하여 웹 역할 코드가 실행되는지 확인합니다. 그러면 아래 그림과 같이 응용 프로그램의 진단 설정을 검사하여 사용자 지정 내용이 구현되었는지를 확인할 수 있습니다. 참고로 저는 무료 CodePlex 도구를 사용하여 Azure를 관리합니다. 이 도구는 https://wapmmc.codeplex.com/(영문일 수 있음)에서 다운로드할 수 있습니다.

 

 

코드를 실행한 후 Windows Azure 로그의 다음 예약 전송 기간이 되면 다음과 같이 WADLogsTable에 Trace.* 호출이 표시됩니다.

 

 

또한 응용 프로그램에서 RDP 지원을 구성했으므로, 웹 역할을 클릭하면 Azure 개발자 포털의 도구 모음에서 해당 역할에 대한 RDB 연결을 설정하는 옵션을 사용할 수 있게 됩니다.

 

 

이제 응용 프로그램의 모든 로그와 추적을 사용할 수 있으며, 자세한 조사가 필요한 경우 서버에 대해 RDP를 수행할 수 있습니다. 또 다른 유용한 기능인 IntelliSense도 사용할 수 있습니다. 이 게시물에서는 IntelliSense에 대해서는 설명하지 않습니다. https://blogs.msdn.com/b/jnak/archive/2010/06/07/using-intellitrace-to-debug-windows-azure-cloud-services.aspx(영문일 수 있음) 및 https://blogs.msdn.com/b/ianhu/archive/2010/03/16/intellitrace-what-we-collect.aspx(영문일 수 있음)를 방문하면 IntelliSense에 대한 유용한 정보를 확인할 수 있습니다. IntelliTrace를 사용하도록 설정하면 Visual Studio 서버 탐색기에서 호스티드 서비스를 볼 때 해당 메시지가 표시됩니다.

 

 

그러면 응용 프로그램의 인스턴스를 마우스 오른쪽 단추로 클릭하고 IntelliTrace 로그 보기 메뉴 항목을 선택할 수 있습니다. 이렇게 하면 Azure에서 IntelliTrace 로그가 다운로드되어 Visual Studio에서 다음과 같이 열립니다.

 

 

위의 그림에 나와 있는 것처럼 사용된 스레드, 발생한 예외, 시스템 정보, 로드된 모듈 등을 확인할 수 있습니다. 진단 정보에 대해 전체 저장소 할당을 5MB로 설정하는 방법으로 예외를 시뮬레이트하여 로그의 작동을 테스트했습니다. 앞서 언급한 것처럼 전체 저장소는 약 5GB로 설정해야 합니다. 이와 같이 변경하고 응용 프로그램을 게시한 다음 몇 분 후에 IntelliTrace 로그를 다운로드해 보았습니다. 당연히 오류가 발생했으며, 로그 두 번째 페이지에 이 오류가 강조 표시되어 있습니다.

 

 

지금까지 Windows Azure 1.4의 진단 기능에 대해 간략하게 살펴보았습니다. 진단 기능을 통해 추적 이벤트, 이벤트 로그, 성능 카운터, IIS 로그, 크래시 덤프 및 사용자 지정 진단 로그 파일을 캡처할 수 있습니다. 필요한 경우에는 추가적인 문제 해결을 위해 서버로 RDP를 진행할 수 있습니다. 또한 응용 프로그램에서 IntelliTrace 로그를 다운로드하여 로컬 Visual Studio 2010 인스턴스에서 제한적인 디버깅 환경을 사용할 수 있습니다.

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 Windows Azure 1.4 Diagnostics All Up Overview를 참조하십시오.