모니터링 및 원격 분석(Azure를 사용하여 실제 Cloud Apps 빌드)

아티클
11/08/2024

Azure eBook을 사용하여 Real World Cloud Apps 빌드는 Scott Guthrie가 개발한 프레젠테이션을 기반으로 합니다. 클라우드용 웹앱을 성공적으로 개발하는 데 도움이 되는 13개의 패턴과 사례를 설명합니다. 전자책에 대한 자세한 내용은 첫 번째 장을 참조 하세요.

많은 사람들이 애플리케이션이 중단된 경우 고객에게 알리기 위해 고객에 의존합니다. 이는 실제로 어디서나 모범 사례가 아니며, 특히 클라우드에서는 그렇지 않습니다. 빠른 알림을 보장하지 않으며 알림을 받으면 발생한 일에 대한 최소한의 또는 오해의 소지가 있는 데이터를 얻는 경우가 많습니다. 좋은 원격 분석 및 로깅 시스템을 사용하면 앱에서 발생하는 작업을 파악할 수 있으며 문제가 발생하면 즉시 알게 되고 유용한 문제 해결 정보를 사용할 수 있습니다.

원격 분석 솔루션 구입 또는 임대

참고 항목

이 문서는 Application Insights가 릴리스되기 전에 작성되었습니다. Application Insights는 Azure에서 원격 분석 솔루션에 대한 기본 접근 방식입니다. 자세한 내용은 ASP.NET 웹 사이트에 대한 Application Insights 설정을 참조하세요.

클라우드 환경에 대한 좋은 점 중 하나는 승리를 위해 길을 구입하거나 임대하는 것이 정말 쉽다는 것입니다. 원격 분석이 예입니다. 많은 노력이 없으면 매우 비용 효율적으로 정말 좋은 원격 분석 시스템을 가동하고 실행할 수 있습니다. Azure와 통합되는 수많은 훌륭한 파트너가 있으며, 그 중 일부는 무료 계층을 가지고 있으므로 아무 것도 기본 원격 분석을 얻을 수 없습니다. 다음은 현재 Azure에서 사용할 수 있는 몇 가지 항목입니다.

Microsoft System Center 에는 모니터링 기능도 포함되어 있습니다.

원격 분석 시스템을 사용하는 것이 얼마나 쉬운지 보여 줄 New Relic 설정을 빠르게 살펴보겠습니다.

Azure 관리 포털에서 서비스에 등록합니다. 새로 만들기를 클릭한 다음 스토어를 클릭합니다. 추가 기능 선택 대화 상자가 나타납니다. 아래로 스크롤하여 New Relic을 클릭합니다.

추가 기능 선택

오른쪽 화살표를 클릭하고 원하는 서비스 계층을 선택합니다. 이 데모에서는 무료 계층을 사용합니다.

추가 기능 개인 설정

오른쪽 화살표를 클릭하고 "구매"를 확인하면 이제 New Relic이 포털에서 추가 기능으로 표시됩니다.

구매 검토

관리 포털의 New Relic 추가 기능

연결 정보를 클릭하고 라이선스 키를 복사합니다.

연결 정보

포털에서 웹앱에 대한 구성 탭으로 이동하여 성능 모니터 추가 기능으로 설정하고 추가 기능 선택 드롭다운 목록을 New Relic으로 설정합니다. 그런 다음 Save를 클릭합니다.

구성 탭의 New Relic

Visual Studio에서 앱에 New Relic NuGet 패키지를 설치합니다.

구성 탭의 개발자 분석

Azure에 앱을 배포하고 사용을 시작합니다. New Relic에서 모니터링할 수 있는 몇 가지 작업을 제공하는 몇 가지 Fix It 작업을 만듭니다.

그런 다음 포털의 추가 기능 탭에서 New Relic 페이지로 돌아가서 관리를 클릭합니다. 포털에서 인증을 위해 Single Sign-On을 사용하여 New Relic 관리 포털로 보내므로 자격 증명을 다시 입력할 필요가 없습니다. 개요 페이지에는 다양한 성능 통계가 표시됩니다. (개요 페이지를 전체 크기로 보려면 이미지를 클릭합니다.)

다음은 확인할 수 있는 몇 가지 통계입니다.

하루 중 다른 시간에 대한 평균 응답 시간입니다.
하루 중 다른 시간에 처리량 속도(분당 요청 수)입니다.
서버 CPU 시간은 서로 다른 HTTP 요청을 처리하는 데 소요됩니다.
애플리케이션 코드의 여러 부분에서 소요된 CPU 시간:
기록 성능 통계입니다.
Blob 서비스와 같은 외부 서비스에 대한 호출 및 서비스가 얼마나 안정적이고 응답성이 있었는지에 대한 통계입니다.
전 세계 위치 또는 미국 웹앱 트래픽의 원본 위치에 대한 정보입니다.

보고서 및 이벤트를 설정할 수도 있습니다. 예를 들어 오류가 표시되면 언제든지 지원 직원에게 문제를 알리는 전자 메일을 보낼 수 있습니다.

보고서

New Relic은 원격 분석 시스템의 한 예일 뿐입니다. 다른 서비스에서도 이 모든 것을 가져올 수 있습니다. 클라우드의 매력은 코드를 작성할 필요 없이 비용을 최소화하거나 비용 없이 애플리케이션이 사용되는 방식과 고객이 실제로 경험하는 것에 대한 더 많은 정보를 갑자기 얻을 수 있다는 것입니다.

인사이트에 대한 로그

원격 분석 패키지는 좋은 첫 번째 단계이지만 사용자 고유의 코드를 계측해야 합니다. 원격 분석 서비스는 문제가 있는 경우를 알려주고 고객이 겪고 있는 문제를 알려 주지만 코드에서 발생하는 일에 대한 많은 인사이트를 제공하지는 않을 수 있습니다.

앱이 수행하는 작업을 확인하기 위해 프로덕션 서버로 원격으로 연결하지 않아도 됩니다. 서버가 하나 있을 때는 실용적일 수 있지만 수백 대의 서버로 확장한 후 원격으로 연결해야 하는 서버를 모르는 경우는 어떨까요? 로깅은 문제를 분석하고 디버그하기 위해 프로덕션 서버로 원격으로 연결할 필요가 없는 충분한 정보를 제공해야 합니다. 로그를 통해서만 문제를 격리할 수 있도록 충분한 정보를 로깅해야 합니다.

프로덕션 로그인

많은 사람들이 문제가 있고 디버그하려는 경우에만 프로덕션에서 추적을 켭니다. 이로 인해 문제를 인식하는 시간과 문제에 대한 유용한 문제 해결 정보를 얻는 시간 사이에 상당한 지연이 발생할 수 있습니다. 그리고 사용자가 받는 정보는 일시적인 오류에 유용하지 않을 수 있습니다.

스토리지가 저렴한 클라우드 환경에서 권장되는 것은 항상 프로덕션 환경에서 로그온을 유지한다는 것입니다. 이렇게 하면 오류가 발생할 때 이미 기록되고 시간이 지남에 따라 개발되거나 다른 시간에 정기적으로 발생하는 문제를 분석하는 데 도움이 되는 기록 데이터가 있습니다. 제거 프로세스를 자동화하여 이전 로그를 삭제할 수 있지만 로그를 유지하는 것보다 이러한 프로세스를 설정하는 것이 더 비싸다는 것을 알 수 있습니다.

로깅의 추가 비용은 문제가 발생할 때 필요한 모든 정보를 이미 사용할 수 있도록 하여 절감할 수 있는 문제 해결 시간과 비용의 양에 비해 간단합니다. 그런 다음 누군가가 어젯밤 8:00 경에 임의의 오류가 있다고 말하지만 오류를 기억하지 못하면 문제가 무엇인지 쉽게 알 수 있습니다.

한 달에 4달러 미만인 경우 50GB의 로그를 보관할 수 있으며, 성능 병목 현상을 방지하기 위해 로깅 라이브러리가 비동기 상태인지 확인합니다.

작업이 필요한 로그에서 알리는 로그 구분

로그는 INFORM(무언가를 알고 싶습니다) 또는 ACT(작업을 수행하려고 함)를 의미합니다. 조치를 취하기 위해 사람 또는 자동화된 프로세스가 진정으로 필요한 문제에 대해서만 ACT 로그를 작성해야 합니다. ACT 로그가 너무 많으면 노이즈가 발생하므로 정품 문제를 찾기 위해 모든 것을 선별하는 데 너무 많은 작업이 필요합니다. 또한 ACT 로그가 지원 직원에게 전자 메일을 보내는 것과 같은 일부 작업을 자동으로 트리거하는 경우 단일 문제로 인해 수천 개의 작업이 트리거되지 않도록 합니다.

.NET System.Diagnostics 추적에서 로그에 오류, 경고, 정보 및 디버그/자세한 정보 수준이 할당될 수 있습니다. ACT 로그의 오류 수준을 예약하고 INFORM 로그에 대해 더 낮은 수준을 사용하여 INFORM 로그와 ACT를 구분할 수 있습니다.

로깅 수준

런타임에 로깅 수준 구성

프로덕션 환경에서 항상 로그온하는 것이 가치가 있지만, 또 다른 모범 사례는 애플리케이션을 다시 배포하거나 다시 시작하지 않고도 로깅하는 세부 수준을 런타임에 조정할 수 있는 로깅 프레임워크를 구현하는 것입니다. 예를 들어 추적 기능을 System.Diagnostics 사용하는 경우 오류, 경고, 정보 및 디버그/자세한 정보 로그를 만들 수 있습니다. 프로덕션 환경에서 오류, 경고 및 정보 로그를 항상 기록하는 것이 좋으며, 사례별로 문제 해결을 위해 디버그/자세한 정보 로깅을 동적으로 추가할 수 있습니다.

Azure 앱 Service의 Web Apps는 파일 시스템, Table Storage 또는 Blob Storage에 로그를 쓰기 System.Diagnostics 위한 기본 제공 지원을 제공합니다. 각 스토리지 대상에 대해 다른 로깅 수준을 선택할 수 있으며 애플리케이션을 다시 시작하지 않고도 즉시 로깅 수준을 변경할 수 있습니다. Blob Storage 지원을 사용하면 HDInsight가 Blob Storage를 직접 사용하는 방법을 알고 있으므로 애플리케이션 로그에서 HDInsight 분석 작업을 더 쉽게 실행할 수 있습니다.

예외 기록

예외만 두지 마세요. 로깅 코드의 ToString() 이는 상황별 정보를 남깁니다. SQL 오류의 경우 SQL 오류 번호가 제외됩니다. 모든 예외의 경우 컨텍스트 정보, 예외 자체 및 내부 예외를 포함하여 문제 해결에 필요한 모든 것을 제공하고 있는지 확인합니다. 예를 들어 컨텍스트 정보에는 서버 이름, 트랜잭션 식별자 및 사용자 이름(암호 또는 비밀은 포함되지 않음)이 포함될 수 있습니다.

각 개발자가 예외 로깅을 사용하여 올바른 작업을 수행하는 경우 그 중 일부는 그렇지 않습니다. 매번 올바른 방식으로 수행되도록 하려면 로거 인터페이스에 바로 예외 처리를 빌드합니다. 예외 개체 자체를 로거 클래스에 전달하고 로거 클래스에서 예외 데이터를 올바르게 기록합니다.

서비스에 대한 호출 기록

데이터베이스 또는 REST API 또는 외부 서비스에 관계없이 앱이 서비스에 호출할 때마다 로그를 작성하는 것이 좋습니다. 로그에 성공 또는 실패의 표시뿐만 아니라 각 요청이 걸린 기간을 포함합니다. 클라우드 환경에서는 가동 중단을 완료하지 않고 속도 저하와 관련된 문제가 자주 표시됩니다. 일반적으로 10밀리초가 걸리는 경우 갑자기 1초 정도 걸릴 수 있습니다. 누군가가 앱이 느리다는 것을 알릴 때 New Relic 또는 보유한 원격 분석 서비스를 살펴보고 해당 환경의 유효성을 검사할 수 있기를 원하며, 느린 이유에 대한 세부 정보를 자세히 알아보기 위해 고유한 로그를 볼 수 있기를 원합니다.

ILogger 인터페이스 사용

프로덕션 애플리케이션을 만들 때 수행하는 것이 좋습니다. 간단한 ILogger 인터페이스를 만들고 그 안에 몇 가지 메서드를 붙이는 것입니다. 이렇게 하면 나중에 로깅 구현을 쉽게 변경할 수 있으며 이를 위해 모든 코드를 거치지 않아도 됩니다. Fix It 앱 전체에서 클래스를 System.Diagnostics.Trace 사용할 수 있지만, 대신 ILogger를 구현하는 로깅 클래스의 표지 아래에 클래스를 사용하고 앱 전체에서 ILogger 메서드를 호출합니다.

이렇게 하면 로깅을 더 풍부하게 만들려는 경우 원하는 로깅 메커니즘으로 바꿀 System.Diagnostics.Trace 수 있습니다. 예를 들어 앱이 커짐에 따라 NLog 또는 엔터프라이즈 라이브러리 로깅 애플리케이션 블록과 같은 보다 포괄적인 로깅 패키지를 사용하도록 결정할 수 있습니다. (Log4Net 은 또 다른 인기 있는 로깅 프레임워크이지만 비동기 로깅은 수행하지 않습니다.)

NLog와 같은 프레임워크를 사용하는 한 가지 가능한 이유는 로깅 출력을 별도의 대용량 및 고가용성 데이터 저장소로 쉽게 나눌 수 있기 때문입니다. 이렇게 하면 ACT 데이터에 대한 빠른 액세스를 유지하면서 빠른 쿼리를 실행할 필요가 없는 대량의 INFORM 데이터를 효율적으로 저장할 수 있습니다.

의미 체계 로깅

보다 유용한 진단 정보를 생성할 수 있는 로깅을 수행하는 비교적 새로운 방법은 SLAB(Enterprise Library 의미 체계 로깅 애플리케이션 블록)을 참조하세요. SLAB은 .NET 4.5의 ETW(Windows용 이벤트 추적) 및 EventSource 지원을 사용하여 보다 구조화되고 쿼리 가능한 로그를 만들 수 있습니다. 기록하는 각 이벤트 유형에 대해 다른 메서드를 정의하여 작성하는 정보를 사용자 지정할 수 있습니다. 예를 들어 SQL Database 오류를 기록하려면 메서드를 LogSQLDatabaseError 호출할 수 있습니다. 이러한 종류의 예외의 경우 중요한 정보 조각이 오류 번호라는 것을 알고 있으므로 메서드 서명에 오류 번호 매개 변수를 포함하고 오류 번호를 작성하는 로그 레코드에 별도의 필드로 기록할 수 있습니다. 숫자는 별도의 필드에 있으므로 오류 번호를 메시지 문자열에 연결하는 경우보다 SQL 오류 번호를 기반으로 보고서를 보다 쉽고 안정적으로 가져올 수 있습니다.

수정 앱에서 로깅

ILogger 인터페이스

다음은 수정 앱의 ILogger 인터페이스입니다.

public interface ILogger
{
    void Information(string message);
    void Information(string fmt, params object[] vars);
    void Information(Exception exception, string fmt, params object[] vars);

    void Warning(string message);
    void Warning(string fmt, params object[] vars);
    void Warning(Exception exception, string fmt, params object[] vars);

    void Error(string message);
    void Error(string fmt, params object[] vars);
    void Error(Exception exception, string fmt, params object[] vars);

    void TraceApi(string componentName, string method, TimeSpan timespan);
    void TraceApi(string componentName, string method, TimeSpan timespan, string properties);
    void TraceApi(string componentName, string method, TimeSpan timespan, string fmt, params object[] vars);
}

이러한 메서드를 사용하면 System.Diagnostics에서 지원하는 동일한 4개 수준에서 로그를 작성할 수 있습니다. TraceApi 메서드는 대기 시간에 대한 정보를 사용하여 외부 서비스 호출을 로깅하기 위한 것입니다. 디버그/자세한 정보 표시 수준에 대한 메서드 집합을 추가할 수도 있습니다.

ILogger 인터페이스의 로거 구현

인터페이스의 구현은 정말 간단합니다. 기본적으로 표준 System.Diagnostics 메서드를 호출합니다 . 다음 코드 조각은 세 가지 정보 메서드와 각각 하나씩을 보여 줍니다.

public class Logger : ILogger
{
    public void Information(string message)
    {
        Trace.TraceInformation(message);
    }

    public void Information(string fmt, params object[] vars)
    {
        Trace.TraceInformation(fmt, vars);
    }

    public void Information(Exception exception, string fmt, params object[] vars)
    {
        var msg = String.Format(fmt, vars);
        Trace.TraceInformation(string.Format(fmt, vars) + ";Exception Details={0}", exception.ToString());
    }

    public void Warning(string message)
    {
        Trace.TraceWarning(message);
    }

    public void Error(string message)
    {
        Trace.TraceError(message);
    }

    public void TraceApi(string componentName, string method, TimeSpan timespan, string properties)
    {
        string message = String.Concat("component:", componentName, ";method:", method, ";timespan:", timespan.ToString(), ";properties:", properties);
        Trace.TraceInformation(message);
    }
}

ILogger 메서드 호출

Fix It 앱의 코드가 예외를 catch할 때마다 ILogger 메서드를 호출하여 예외 세부 정보를 기록합니다. 또한 데이터베이스, Blob 서비스 또는 REST API를 호출할 때마다 호출 전에 스톱워치를 시작하고, 서비스가 반환될 때 스톱워치를 중지하고, 성공 또는 실패에 대한 정보와 함께 경과된 시간을 기록합니다.

로그 메시지에는 클래스 이름과 메서드 이름이 포함됩니다. 로그 메시지가 애플리케이션 코드에서 작성한 부분을 식별하는 것이 좋습니다.

public class FixItTaskRepository : IFixItTaskRepository
{
    private MyFixItContext db = new MyFixItContext();
    private ILogger log = null;

    public FixItTaskRepository(ILogger logger)
    {
        log = logger;
    }

    public async Task<FixItTask> FindTaskByIdAsync(int id)
    {
        FixItTask fixItTask = null;
        Stopwatch timespan = Stopwatch.StartNew();

        try
        {
            fixItTask = await db.FixItTasks.FindAsync(id);
            
            timespan.Stop();
            log.TraceApi("SQL Database", "FixItTaskRepository.FindTaskByIdAsync", timespan.Elapsed, "id={0}", id);
        }
        catch(Exception e)
        {
            log.Error(e, "Error in FixItTaskRepository.FindTaskByIdAsynx(id={0})", id);
        }

        return fixItTask;
    }

이제 Fix It 앱이 SQL Database를 호출할 때마다 호출, 호출한 메서드 및 정확히 얼마나 많은 시간이 걸렸는지 확인할 수 있습니다.

로그의 SQL Database 쿼리

엔터티 속성 편집 및 성공한 업데이트에 대해 각 속성의 모양을 보여 주는 스크린샷.

로그를 탐색하는 경우 데이터베이스 호출에 걸리는 시간이 가변적임을 알 수 있습니다. 이 정보는 유용할 수 있습니다. 앱이 이 모든 것을 기록하기 때문에 시간이 지남에 따라 데이터베이스 서비스가 수행되는 방식의 기록 추세를 분석할 수 있습니다. 예를 들어 서비스는 대부분의 시간 동안 빠를 수 있지만 요청이 실패하거나 응답 속도가 하루 중 특정 시간에 느려질 수 있습니다.

Blob 서비스에 대해 동일한 작업을 수행할 수 있습니다. 앱이 새 파일을 업로드할 때마다 로그가 있으며 각 파일을 업로드하는 데 걸린 시간을 정확하게 확인할 수 있습니다.

Blob 업로드 로그

서비스를 호출할 때마다 작성할 수 있는 몇 개의 추가 코드 줄이며, 이제 누군가가 문제가 발생했다고 말하면 문제가 무엇인지, 오류인지 또는 실행 속도가 느려졌는지 정확히 알 수 있습니다. 오류가 발생한 후 서버에 원격으로 연결하거나 로깅을 켜고 다시 만들지 않고도 문제의 원인을 파악할 수 있습니다.

Fix It 앱의 종속성 주입

위에 표시된 예제의 리포지토리 생성자가 어떻게 로거 인터페이스 구현을 가져오는지 궁금할 수 있습니다.

public class FixItTaskRepository : IFixItTaskRepository
{
    private MyFixItContext db = new MyFixItContext();
    private ILogger log = null;

    public FixItTaskRepository(ILogger logger)
    {
        log = logger;
    }

인터페이스를 구현에 연결하기 위해 앱은 AutoFac과 함께 DI(종속성 주입 )를 사용합니다. DI를 사용하면 코드 전체의 여러 위치에서 인터페이스를 기반으로 개체를 사용할 수 있으며 인터페이스가 인스턴스화될 때 사용되는 구현을 한 곳에서만 지정하면 됩니다. 이렇게 하면 구현을 보다 쉽게 변경할 수 있습니다. 예를 들어 System.Diagnostics 로거를 NLog 로거로 바꿀 수 있습니다. 또는 자동화된 테스트를 위해 모의 버전의 로거를 대체할 수 있습니다.

Fix It 애플리케이션은 모든 리포지토리 및 모든 컨트롤러에서 DI를 사용합니다. 컨트롤러 클래스의 생성자는 리포지토리가 로거 인터페이스를 가져오는 것과 동일한 방식으로 ITaskRepository 인터페이스를 가져옵니다.

public class DashboardController : Controller
{
    private IFixItTaskRepository fixItRepository = null;

    public DashboardController(IFixItTaskRepository repository)
    {
        fixItRepository = repository;
    }

앱은 AutoFac DI 라이브러리를 사용하여 이러한 생성자에 대한 TaskRepository 및 Logger 인스턴스를 자동으로 제공합니다.

public class DependenciesConfig
{
    public static void RegisterDependencies()
    {
        var builder = new ContainerBuilder();

        builder.RegisterControllers(typeof(MvcApplication).Assembly);
        builder.RegisterType<Logger>().As<ILogger>().SingleInstance();

        builder.RegisterType<FixItTaskRepository>().As<IFixItTaskRepository>();
        builder.RegisterType<PhotoService>().As<IPhotoService>().SingleInstance();
        builder.RegisterType<FixItQueueManager>().As<IFixItQueueManager>();

        var container = builder.Build();
        DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
    }
}

이 코드는 기본적으로 생성자에 ILogger 인터페이스가 필요하고, Logger 클래스의 인스턴스를 전달하며, IFixItTaskRepository 인터페이스가 필요할 때마다 FixItTaskRepository 클래스의 인스턴스를 전달한다고 말합니다.

AutoFac 은 사용할 수 있는 많은 종속성 주입 프레임워크 중 하나입니다. 또 다른 인기 있는 것은 Microsoft 패턴 및 사례에서 권장되고 지원되는 Unity입니다.

Azure의 기본 제공 로깅 지원

Azure 앱 Service에서 Web Apps에 대한 다음과 같은 종류의 로깅을 Azure 지원.

System.Diagnostics 추적(사이트를 다시 시작하지 않고도 즉시 수준을 켜고 끌 수 있습니다).
Windows 이벤트.
IIS 로그(HTTP/FREB).

Azure 지원 Cloud Services에서 다음과 같은 종류의 로깅을 수행합니다.

System.Diagnostics 추적
성능 카운터.
Windows 이벤트.
IIS 로그(HTTP/FREB).
사용자 지정 디렉터리 모니터링.

Fix It 앱은 System.Diagnostics 추적을 사용합니다. 웹앱에서 System.Diagnostics 로깅을 사용하도록 설정하려면 포털에서 스위치를 대칭 이동하거나 REST API를 호출하기만 하면 됩니다. 포털에서 사이트의 구성 탭을 클릭하고 아래로 스크롤하여 애플리케이션 진단 섹션을 확인합니다. 로깅을 켜거나 끄고 원하는 로깅 수준을 선택할 수 있습니다. Azure에서 파일 시스템 또는 스토리지 계정에 로그를 쓰도록 할 수 있습니다.

구성 탭의 앱 진단 및 사이트 진단

Azure에서 로깅을 사용하도록 설정한 후에는 로그가 만들어질 때 Visual Studio 출력 창에서 로그를 볼 수 있습니다.

스트리밍 로그 메뉴

스트리밍 로그 메뉴2

또한 스토리지 계정에 로그를 작성하고 Visual Studio의 서버 탐색기 또는 Azure Storage Explorer와 같은 Azure Storage Table Service에 액세스할 수 있는 도구를 사용하여 볼 수도 있습니다.

서버 탐색기의 로그

요약

기본 제공 원격 분석 시스템을 구현하고, 사용자 고유의 코드로 로깅을 계측하고, Azure에서 로깅을 구성하는 것은 매우 간단합니다. 또한 프로덕션 문제가 있는 경우 원격 분석 시스템과 사용자 지정 로그를 조합하면 고객에게 주요 문제가 되기 전에 문제를 신속하게 해결하는 데 도움이 됩니다.

다음 챕터에서는 일시적인 오류가 조사해야 하는 프로덕션 문제가 되지 않도록 처리하는 방법을 살펴보겠습니다.

리소스

자세한 내용은 다음 리소스를 참조하세요.

주로 원격 분석에 대한 설명서:

Microsoft 패턴 및 사례 - Azure 지침. 계측 및 원격 분석 지침, 서비스 계량 지침, 상태 엔드포인트 모니터링 패턴 및 런타임 재구성 패턴을 참조하세요.
클라우드에서 페니 꼬집기: Azure Websites에서 New Relic 성능 모니터 사용
Azure Cloud Services에서 대규모 서비스 디자인에 대한 모범 사례입니다. 마크 심스와 마이클 토마시 백서. 원격 분석 및 진단 섹션을 참조하세요.
Application Insights를 사용한 차세대 개발. MSDN 잡지 기사.

주로 로깅에 대한 설명서:

SLAB(의미 체계 로깅 애플리케이션 블록). 닐 매켄지는 SLAB을 사용하여 의미 체계 로깅의 사례를 제시합니다.
의미 체계 로깅을 사용하여 구조적 및 의미 있는 로그 만들기 (비디오) 줄리안 도밍게즈는 SLAB을 사용하여 의미 체계 로깅의 경우를 제시합니다.
EF6 SQL 로깅 – 1부: 단순 로깅. Arthur Vickers는 EF 6에서 Entity Framework에서 실행한 쿼리를 기록하는 방법을 보여 줍니다.
ASP.NET MVC 애플리케이션에서 Entity Framework와의 연결 복원력 및 명령 가로채기 9부로 구성된 자습서 시리즈의 네 번째 부분에서는 EF 6 명령 가로채기 기능을 사용하여 Entity Framework에서 데이터베이스로 전송된 SQL 명령을 기록하는 방법을 보여 줍니다.
C# 5.0 호출자 정보 특성을 사용하여 로깅을 개선합니다. 리터럴로 하드 코딩하거나 리플렉션을 사용하여 수동으로 호출 메서드를 사용하지 않고 호출 메서드의 이름을 쉽게 기록하는 방법입니다.

주로 문제 해결에 대한 설명서:

Azure 문제 해결 및 디버깅 블로그.
AzureTools – Azure 개발자 지원 팀에서 사용하는 진단 유틸리티입니다. Azure VM에서 다양한 진단 및 모니터링 도구를 다운로드하고 실행하는 데 사용할 수 있는 도구에 대한 다운로드 링크를 소개하고 제공합니다. 특정 VM에서 문제를 진단해야 하는 경우에 유용합니다.
Visual Studio를 사용하여 Azure 앱 Service에서 웹앱 문제를 해결합니다. System.Diagnostics 추적 및 원격 디버깅을 시작하기 위한 단계별 자습서입니다.

동영상:

FailSafe: 확장성 있는 복원력 있는 Cloud Services를 빌드합니다. 울리히 호만, 마크 머큐리, 마크 심스의 9부작 시리즈. 실제 고객과의 CAT(Microsoft 고객 자문 팀) 경험에서 가져온 스토리와 함께 매우 접근성이 높고 흥미로운 방식으로 높은 수준의 개념과 아키텍처 원칙을 제시합니다. 에피소드 4와 9는 모니터링 및 원격 분석에 관한 것입니다. 에피소드 9에는 모니터링 서비스 MetricsHub, AppDynamics, New Relic 및 PagerDuty에 대한 개요가 포함되어 있습니다.
큰 빌드: Azure 고객으로부터 배운 교훈 - 파트 II. Mark Simms는 실패를 위한 설계 및 모든 계측에 대해 이야기합니다. Failsafe 시리즈와 비슷하지만 자세한 방법은 자세히 설명합니다.

코드 샘플:

Azure의 클라우드 서비스 기본 사항 Microsoft Azure 고객 자문 팀에서 만든 샘플 애플리케이션입니다. 다음 문서에 설명된 대로 원격 분석 및 로깅 방법을 모두 보여 줍니다. 샘플은 NLog를 사용하여 애플리케이션 로깅을 구현합니다. 관련 설명서는 원격 분석 및 로깅에 대한 4개의 TechNet Wiki 문서 시리즈를 참조하세요.

이전 다음

다음을 통해 공유