모니터링 및 진단 지침

클라우드에서 실행되는 분산 애플리케이션 및 서비스는 특성상, 많은 이동 부분으로 구성되는 복잡한 소프트웨어입니다. 프로덕션 환경에서는 사용자가 시스템을 사용하는 방식을 추적하고, 리소스 사용률을 추적하고, 일반적으로 시스템의 상태와 성능을 모니터링할 수 있는 것이 중요합니다. 이 정보를 진단 보조 기능으로 사용하여 문제를 검색하고 수정할 수 있으며 잠재적 문제를 발견하여 이 문제가 발생하지 않도록 할 수도 있습니다.

모니터링 및 진단 시나리오

모니터링을 사용하여 시스템이 잘 작동하는지 파악할 수 있습니다. 모니터링은 서비스 품질 목표를 유지하는 데 중요한 부분입니다. 모니터링 데이터를 수집하는 일반적인 시나리오는 다음과 같습니다.

• 시스템이 정상 상태로 유지되도록 합니다.
• 시스템 및 해당 구성 요소 요소의 가용성 추적
• 작업량이 증가함에 따라 시스템 처리량이 예기치 않게 저하되지 않도록 성능을 유지합니다.
• 시스템이 고객과 설정된 모든 SLA(서비스 수준 계약)를 충족하는지 보장합니다.
• 시스템, 사용자 및 해당 데이터의 개인 정보 보호 및 보안
• 감사 또는 규제 목적으로 수행되는 작업을 추적합니다.
• 시스템의 일상적인 사용량을 모니터링하고 문제가 해결되지 않으면 문제가 발생할 수 있는 추세를 파악합니다.
• 초기 보고서에서 가능한 원인, 수정, 결과 소프트웨어 업데이트 및 배포 분석까지 발생하는 문제를 추적합니다.
• 작업을 추적하고 소프트웨어 릴리스를 디버그합니다.

다음 섹션에서는 이러한 시나리오를 자세히 설명합니다. 각 시나리오에 대한 정보는 다음과 같은 형식으로 설명합니다.

1. 시나리오에 대한 간략한 개요
2. 이 시나리오의 일반적인 요구 사항
3. 시나리오를 지원하는 데 필요한 원시 계측 데이터 및 이러한 정보의 가능한 출처
4. 이 원시 데이터를 분석 및 결합하여 유의미한 진단 정보를 생성할 수 있는 방법

상태 모니터링

시스템이 실행 중이며 요청을 처리할 수 있는 경우 시스템의 상태는 정상입니다. 상태 모니터링의 목적은 시스템의 모든 구성 요소가 예상대로 작동하는지 확인할 수 있도록 시스템의 현재 상태에 대한 스냅샷을 생성하는 것입니다.

상태 모니터링에 대한 요구 사항

시스템의 일부가 비정상으로 간주되는 경우 운영자에게 신속하게 경고해야 합니다(몇 초 내에). 연산자는 시스템의 어느 부분이 정상적으로 작동하는지, 어떤 부분에 문제가 있는지 확인할 수 있어야 합니다. 신호등 시스템을 통해 시스템 상태를 강조 표시할 수 있습니다.

• 비정상 상태의 경우 빨간색(시스템이 중지됨)
• 부분적으로 정상인 경우 노란색(시스템이 기능 감소로 실행됨)
• 완전히 정상이면 녹색

포괄적인 상태 모니터링 시스템을 사용하면 운영자가 시스템을 드릴다운하여 하위 시스템 및 구성 요소의 상태를 볼 수 있습니다. 예를 들어 전체 시스템이 부분적으로 정상으로 표시되는 경우 운영자는 확대하여 현재 사용할 수 없는 기능을 확인할 수 있어야 합니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

상태 모니터링을 지원하는 데 필요한 원시 데이터는 다음과 같은 결과로 생성될 수 있습니다.

• 사용자 요청의 실행 추적 이 정보를 사용하여 성공한 요청, 실패한 요청 및 각 요청에 걸리는 시간을 확인할 수 있습니다.
• 가상 사용자 모니터링. 이 프로세스는 사용자가 수행한 단계를 시뮬레이션하고 미리 정의된 일련의 단계를 따릅니다. 각 단계의 결과를 캡처해야 합니다.
• 예외, 장애 및 경고 기록 이 정보는 애플리케이션 코드에 포함된 추적 문과 시스템에서 참조하는 서비스의 이벤트 로그에서 정보를 검색한 결과로 캡처할 수 있습니다.
• 시스템에서 사용하는 타사 서비스의 상태를 모니터링합니다. 이 모니터링을 위해 이러한 서비스가 제공하는 상태 데이터를 검색하고 구문 분석해야 할 수 있습니다. 이 정보는 다양한 형식을 취할 수 있습니다.
• 엔드포인트 모니터링. 이 메커니즘은 "가용성 모니터링" 섹션에서 자세히 설명합니다.
• 백그라운드 CPU 사용률 또는 I/O(네트워크 포함) 활동과 같은 주변 성능 정보 수집

상태 데이터 분석

상태 모니터링의 주요 초점은 시스템이 실행 중인지 여부를 신속하게 나타내는 것입니다. 중요한 구성 요소가 비정상으로 검색되면 즉시 데이터의 핫 분석이 경고를 트리거할 수 있습니다. (예를 들어 연속된 일련의 ping에 응답하지 않는 경우가 있습니다.) 그러면 운영자는 적절한 정정 작업을 할 수 있습니다.

고급 시스템에는 최근 및 현재 워크로드에 대한 콜드 분석을 수행하는 예측 요소가 포함될 수 있습니다. 콜드 분석은 추세를 발견하고 시스템의 정상 상태가 유지될지 아니면 추가 리소스가 필요할지 여부를 결정합니다. 이 예측 요소는 다음과 같은 중요 성능 메트릭을 기반으로 해야 합니다.

• 각 서비스 또는 하위 시스템을 대상으로 하는 요청의 비율입니다.
• 이러한 요청의 응답 시간입니다.
• 각 서비스에 대해 유입되거나 유출되는 데이터의 양입니다.

메트릭의 값이 정의된 임계값을 초과하는 경우 시스템에서는 운영자나 크기 자동 조정 기능(사용할 수 있는 경우)이 시스템 상태 유지에 필요한 예방 조치를 취할 수 있도록 경고를 발생시킬 수 있습니다. 이러한 작업에는 리소스 추가, 실패한 하나 이상의 서비스 다시 시작 또는 우선 순위가 낮은 요청에 제한을 적용하는 작업이 포함될 수 있습니다.

가용성 모니터링

시스템이 진정으로 정상 상태가 되려면 시스템을 구성하는 구성 요소 및 하위 시스템이 사용 가능해야 합니다. 가용성 모니터링은 상태 모니터링과 밀접한 관련이 있습니다. 그러나 상태 모니터링은 시스템의 현재 상태를 즉시 볼 수 있는 반면, 가용성 모니터링은 시스템의 작동 시간에 대한 통계를 생성하기 위해 시스템 및 해당 구성 요소의 가용성을 추적하는 데 관련이 있습니다.

많은 시스템에서 일부 구성 요소(예: 데이터베이스)는 심각한 오류 또는 연결 손실이 발생할 경우 신속한 장애 조치(failover)를 허용하도록 기본 제공 중복성으로 구성됩니다. 이상적으로 사용자는 이러한 오류가 발생했음을 인식해서는 안 됩니다. 그러나 가용성 모니터링 관점에서 이러한 오류에 대해 가능한 한 많은 정보를 수집하여 원인을 확인하고 반복되지 않도록 수정 조치를 취해야 합니다.

가용성을 추적하는 데 필요한 데이터는 여러 하위 수준 요인에 따라 달라질 수 있습니다. 이러한 많은 요소는 애플리케이션, 시스템 및 환경과 관련될 수 있습니다. 효과적인 모니터링 시스템은 이러한 하위 수준 요소에 해당하는 가용성 데이터를 캡처한 다음 집계하여 시스템의 전반적인 그림을 제공합니다. 예를 들어 전자 상거래 시스템에서 고객이 주문을 할 수 있도록 하는 비즈니스 기능은 주문 세부 정보가 저장되는 리포지토리와 이러한 주문에 대한 지불에 대한 통화 거래를 처리하는 결제 시스템에 따라 달라질 수 있습니다. 따라서 시스템의 주문 배치 부분의 가용성은 리포지토리 및 결제 하위 시스템의 가용성 기능입니다.

가용성 모니터링에 대한 요구 사항

또한 운영자는 각 시스템 및 하위 시스템의 기록 가용성을 볼 수 있어야 하며, 이 정보를 사용하여 하나 이상의 하위 시스템이 주기적으로 실패할 수 있는 추세를 파악할 수 있어야 합니다. 예를 들어 하루 중 처리량이 가장 많은 특정 시간대에 서비스 장애가 발생하는지 확인합니다.

모니터링 솔루션은 각 하위 시스템의 가용성 또는 비가용성에 대한 즉시 보기 및 기록 보기를 제공해야 합니다. 또한 하나 이상의 서비스가 실패하거나 사용자가 서비스에 연결할 수 없는 경우 운영자에게 신속하게 경고할 수 있어야 합니다. 이는 각 서비스를 모니터링할 뿐만 아니라 서비스와 통신하려고 할 때 이러한 작업이 실패할 경우 각 사용자가 수행하는 작업을 검사하는 문제입니다. 어느 정도까지는, 특정 수준의 연결 장애는 정상이며 일시적인 오류가 원인일 수 있습니다. 그러나 시스템에서 특정 기간 동안 발생하는 지정된 하위 시스템에 대한 연결 오류 수에 대한 경고를 발생시키는 것이 유용할 수 있습니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

상태 모니터링과 마찬가지로 가용성 모니터링을 지원하는 데 필요한 원시 데이터는 가상 사용자 모니터링 및 발생할 수 있는 예외, 오류 및 경고를 로깅한 결과로 생성될 수 있습니다. 또한 엔드포인트 모니터링을 수행하여 가용성 데이터를 가져올 수 있습니다. 애플리케이션은 하나 이상의 상태 엔드포인트를 노출할 수 있으며, 각 엔드포인트는 시스템 내의 기능 영역에 대한 액세스를 테스트합니다. 모니터링 시스템은 정의된 일정에 따라 각 엔드포인트를 ping하고 결과(성공 또는 실패)를 수집할 수 있습니다.

모든 시간 제한, 네트워크 연결 실패 및 연결 재시도 시도를 기록해야 합니다. 모든 데이터는 타임스탬프가 있어야 합니다.

가용성 데이터 분석

다음 유형의 분석을 지원하려면 계측 데이터를 집계하고 상관 관계를 지정해야 합니다.

• 시스템 및 하위 시스템의 즉각적인 가용성입니다.
• 시스템 및 하위 시스템의 가용성 실패율. 이상적으로 운영자는 오류를 특정 활동과 상호 연결할 수 있어야 합니다. 시스템이 실패했을 때 어떤 일이 발생합니까?
• 지정된 기간 동안 시스템 또는 하위 시스템의 실패율과 오류가 발생한 시스템 부하(예: 사용자 요청 수)에 대한 기록 보기입니다.
• 시스템 또는 하위 시스템을 사용할 수 없는 이유입니다. 예를 들어 서비스가 실행되지 않고, 연결이 끊어지고, 연결이 끊어졌지만, 타이밍이 초과되고, 연결되었지만 오류가 반환되는 이유가 있을 수 있습니다.

다음 수식을 사용하여 일정 기간 동안 서비스의 가용성 비율을 계산할 수 있습니다.

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

이는 SLA 용도로 유용합니다. (SLA 모니터링에 대해서는 이 가이드 뒷부분에서 자세히 설명합니다.) 가동 중지 시간의 정의는 서비스에 따라 달라집니다. 예를 들어 Visual Studio Team Services 빌드 서비스는 빌드 서비스를 사용할 수 없는 기간(총 누적 시간 분)으로 가동 중지 시간을 정의합니다. 1분 내내 고객이 시작한 작업을 수행하기 위한, 빌드 서비스에 대한 모든 연속 HTTP 요청이 오류 코드를 발생시키거나 응답을 반환하지 않는 경우 해당 시간(분)을 사용할 수 없는 것으로 간주합니다.

성능 모니터링

시스템이 점점 더 많은 스트레스를 받게 됨에 따라(사용자 볼륨을 증가시킴으로써) 이러한 사용자가 액세스하는 데이터 세트의 크기가 증가하고 하나 이상의 구성 요소가 실패할 가능성이 높아집니다. 대부분의 경우 구성 요소 오류가 발생하기 전에 성능이 저하됩니다. 이러한 감소를 감지할 수 있는 경우 상황을 해결하기 위한 사전 조치를 취할 수 있습니다.

시스템 성능은 여러 가지 요인에 따라 달라집니다. 각 요소는 일반적으로 초당 데이터베이스 트랜잭션 수 또는 지정된 시간 프레임 내에 성공적으로 처리된 네트워크 요청의 볼륨과 같은 KPI(핵심 성과 지표)를 통해 측정됩니다. 이러한 KPI 중 일부는 특정 성능 측정값으로 사용할 수 있는 반면 다른 KPI는 메트릭 조합에서 파생될 수 있습니다.

성능 모니터링에 대한 요구 사항

시스템 성능을 검사하기 위해 운영자는 일반적으로 다음을 포함하는 정보를 확인해야 합니다.

• 사용자 요청에 대한 응답 속도입니다.
• 동시 사용자 요청 수입니다.
• 네트워크 트래픽의 볼륨입니다.
• 비즈니스 트랜잭션이 완료되는 비율입니다.
• 요청에 대한 평균 처리 시간입니다.

운영자가 다음과 같은 상관 관계를 발견할 수 있도록 하는 도구를 제공하는 것도 유용할 수 있습니다.

• 동시 사용자 수와 요청 대기 시간(사용자가 보낸 후 요청 처리를 시작하는 데 걸리는 시간)입니다.
• 동시 사용자 수와 평균 응답 시간(처리를 시작한 후 요청을 완료하는 데 걸리는 시간)입니다.
• 요청 볼륨과 처리 오류 수입니다.

이 고급 기능 정보와 함께 운영자는 시스템의 각 구성 요소에 대한 성능에 대한 자세한 보기를 얻을 수 있어야 합니다. 이 데이터는 일반적으로 다음과 같은 정보를 추적하는 하위 수준 성능 카운터를 통해 제공됩니다.

• 메모리 사용률입니다.
• 스레드 수입니다.
• CPU 처리 시간입니다.
• 요청 큐 길이입니다.
• 디스크 또는 네트워크 I/O 속도 및 오류입니다.
• 쓰거나 읽은 바이트 수입니다.
• 큐 길이와 같은 미들웨어 표시기입니다.

모든 시각화에서 운영자는 기간을 지정할 수 있어야 합니다. 표시된 데이터는 현재 상황의 스냅샷 또는 성능의 기록 보기일 수 있습니다.

운영자는 지정된 시간 간격으로 지정된 값에 대한 성능 측정을 기반으로 경고를 발생시킬 수 있어야 합니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

사용자가 도착하여 시스템을 통과할 때 사용자의 요청 진행률을 모니터링하여 높은 수준의 성능 데이터(처리량, 동시 사용자 수, 비즈니스 트랜잭션 수, 오류 비율 등)를 수집할 수 있습니다. 여기에는 타이밍 정보와 함께 애플리케이션 코드의 핵심 지점에 추적 문을 통합하는 작업이 포함됩니다. 모든 오류, 예외 및 경고는 발생한 요청과 상관 관계를 지정하기 위한 충분한 데이터로 캡처되어야 합니다. IIS(인터넷 정보 서비스) 로그는 또 다른 유용한 소스입니다.

가능하면 애플리케이션에 사용되는 외부 시스템에 대한 성능 데이터도 캡처해야 합니다. 이러한 외부 시스템은 성능 데이터를 요청하기 위한 자체 성능 카운터 또는 기타 기능을 제공할 수 있습니다. 이렇게 할 수 없는 경우 작업의 상태(성공, 실패 또는 경고)와 함께 외부 시스템에 대해 수행된 각 요청의 시작 시간 및 종료 시간과 같은 정보를 기록합니다. 예를 들어 시간 요청에 대한 stopwatch 접근 방식을 사용할 수 있습니다. 요청이 시작될 때 타이머를 시작한 다음 요청이 완료되면 타이머를 중지합니다.

시스템의 개별 구성 요소에 대한 낮은 수준의 성능 데이터는 Windows 성능 카운터 및 Azure Diagnostics와 같은 기능 및 서비스를 통해 사용할 수 있습니다.

성능 데이터 분석

대부분의 분석 작업은 사용자 요청 유형 또는 각 요청이 전송되는 하위 시스템 또는 서비스별로 성능 데이터를 집계하는 것으로 구성됩니다. 사용자 요청의 예는 쇼핑 카트에 항목을 추가하거나 전자 상거래 시스템에서 체크 아웃 프로세스를 수행하는 것입니다.

또 다른 일반적인 요구 사항은 선택한 백분위수의 성능 데이터를 요약하는 것입니다. 예를 들어 운영자는 요청의 99%, 요청의 95%, 요청의 70%에 대한 응답 시간을 결정할 수 있습니다. 각 백분위수에 대해 설정된 SLA 목표 또는 기타 목표가 있을 수 있습니다. 즉각적인 문제를 감지하는 데 도움이 되도록 진행 중인 결과를 거의 실시간으로 보고해야 합니다. 또한 통계 용도로 장기간에 걸쳐 집계하여 지속적으로 보고해야 합니다.

성능에 영향을 주는 대기 시간 문제의 경우 운영자는 각 요청이 수행하는 각 단계의 대기 시간을 검사하여 병목 현상의 원인을 신속하게 식별할 수 있어야 합니다. 따라서, 성능 데이터는 각 단계에 대한 성능 척도와 특정 요청을 연계시킬 수 있는 상관 관계를 설정하는 수단을 제공해야 합니다.

시각화 요구에 따라 원시 데이터의 뷰를 포함하는 데이터 큐브를 생성하고 저장하는 것이 유용할 수 있습니다. 이 데이터 큐브는 성능 정보의 복잡한 임시 쿼리 및 분석을 허용할 수 있습니다.

보안 모니터링

중요한 데이터를 포함하는 모든 상용 시스템은 보안 구조를 구현해야 합니다. 보안 메커니즘의 복잡성은 일반적으로 데이터의 민감도 함수입니다. 사용자를 인증해야 하는 시스템에서 다음을 기록해야 합니다.

• 실패 또는 성공 여부에 관계없이 모든 로그인 시도.
• 인증된 사용자가 수행한 모든 작업과 액세스한 모든 리소스에 대한 세부 정보입니다.
• 사용자가 세션을 종료하고 로그아웃하는 경우

모니터링은 시스템에 대한 공격을 감지하는 데 도움이 될 수 있습니다. 예를 들어 많은 수의 실패한 로그인 시도가 무차별 암호 대입 공격을 나타낼 수 있습니다. 예기치 않은 요청 급증은 DDoS(분산 서비스 거부) 공격의 결과일 수 있습니다. 이러한 요청의 원본에 관계없이 모든 리소스에 대한 모든 요청을 모니터링할 준비가 되어 있어야 합니다. 로그인 취약성이 있는 시스템은 사용자가 실제로 로그인할 필요 없이 실수로 외부 세계에 리소스를 노출할 수 있습니다.

보안 모니터링에 대한 요구 사항

보안 모니터링의 가장 중요한 측면은 운영자가 신속하게 다음을 수행할 수 있도록 해야 합니다.

• 인증되지 않은 엔터티에 의한 시도된 침입을 검색합니다.
• 액세스 권한을 부여받지 않은 엔터티에 의한 데이터 작업 수행 시도 식별
• 시스템 또는 시스템의 일부 부분이 외부 또는 내부에서 공격을 받고 있는지 여부를 확인합니다. (예: 인증받은 악의적인 사용자가 시스템을 중단시키려고 시도할 수 있음)

이러한 요구 사항을 지원하려면 다음과 같은 경우 운영자에게 알려야 합니다.

• 한 계정이 지정된 기간 내에 로그인 시도에 반복적으로 실패합니다.
• 하나의 인증된 계정이 지정된 기간 동안 금지된 리소스에 반복적으로 액세스를 시도합니다.
• 지정된 기간 동안 많은 수의 인증되지 않았거나 승인되지 않은 요청이 발생합니다.

운영자에게 제공되는 정보에는 각 요청에 대한 원본의 호스트 주소가 포함되어야 합니다. 특정 범위의 주소에서 보안 위반이 정기적으로 발생하는 경우 이러한 호스트가 차단될 수 있습니다.

시스템 보안을 유지하는 데 핵심적인 부분은 일상적인 패턴에서 벗어난 작업을 신속하게 감지하는 능력입니다. 실패한 로그인 요청 수 또는 성공적인 로그인 요청 수와 같은 정보를 시각적으로 표시하여 비정상적인 시간에 활동이 급증했는지 여부를 감지할 수 있습니다. 예를 들어 근무일은 오전 9시에 시작되는데 사용자가 오전 3시에 로그인하여 다수의 작업을 수행한 경우 등입니다. 이 정보를 사용하여 시간 기반 자동 크기 조정을 구성할 수도 있습니다. 예를 들어 운영자가 많은 수의 사용자가 특정 시간에 정기적으로 로그인하는 것을 관찰하는 경우 운영자는 작업량을 처리하기 위해 추가 인증 서비스를 시작하도록 정렬한 다음 피크가 지나면 이러한 추가 서비스를 종료할 수 있습니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

보안은 대부분의 분산 시스템의 포괄적인 측면입니다. 관련 데이터는 시스템 전체의 여러 지점에서 생성될 가능성이 높습니다. 애플리케이션, 네트워크 장비, 서버, 방화벽, 바이러스 백신 소프트웨어 및 기타 침입 방지 요소에서 발생하는 이벤트로 인해 발생하는 보안 관련 정보를 수집하기 위해 SIEM(보안 정보 및 이벤트 관리) 접근 방식을 채택하는 것이 좋습니다.

보안 모니터링은 애플리케이션에 속하지 않은 도구의 데이터를 통합할 수 있습니다. 이러한 도구에는 외부 기관의 포트 스캔 활동을 식별하는 유틸리티 또는 애플리케이션 및 데이터에 대한 인증되지 않은 액세스 권한을 얻기 위한 시도를 감지하는 네트워크 필터가 포함될 수 있습니다.

모든 경우에 수집된 데이터는 관리자가 공격의 특성을 확인하고 적절한 대책을 취할 수 있도록 해야 합니다.

보안 데이터 분석

보안 모니터링의 기능은 데이터가 발생하는 다양한 원본입니다. 다양한 형식과 세부 수준의 세부 정보는 캡처된 데이터를 일관된 정보 스레드에 연결하기 위해 복잡한 분석이 필요한 경우가 많습니다. 가장 간단한 경우(예: 많은 수의 실패한 로그인 검색 또는 중요한 리소스에 대한 무단 액세스를 얻기 위한 반복된 시도) 외에도 보안 데이터의 복잡한 자동화된 처리를 수행할 수 없습니다. 이런 때는 대신 전문가의 수동 분석이 가능하도록 보안 리포지토리에 이 데이터를 원래 형식으로 쓰고 타임스태프를 지정하는 것이 더 습니다.

SLA 모니터링

유료 고객을 지원하는 많은 상용 시스템은 SLA 형태로 시스템의 성능을 보장합니다. 기본적으로 SLA는 시스템이 합의된 시간 프레임 내에서 중요한 정보를 잃지 않고 정의된 작업 볼륨을 처리할 수 있다고 명시하고 있습니다. SLA 모니터링은 시스템이 측정 가능한 SLA를 충족할 수 있는지 확인하는 것과 관련이 있습니다.

SLA는 다음과 같은 측면에서 정의되는 경우가 많습니다.

• 전체 시스템 가용성. 예를 들어 조직에서 시스템을 99.9%의 시간 동안 사용할 수 있도록 보장할 수 있습니다. 이 비율은 연간 가동 중지 시간 9시간 이하 또는 주당 약 10분과 같습니다.
• 작동 처리량입니다. 이러한 측면은 종종 시스템에서 최대 100,000개의 동시 사용자 요청을 지원하거나 10,000개의 동시 비즈니스 트랜잭션을 처리할 수 있도록 보장하는 등 하나 이상의 상위 워터 마크로 표현됩니다.
• 작업 응답 시간. 또한 시스템은 요청이 처리되는 속도를 보장할 수 있습니다. 예를 들어 모든 비즈니스 트랜잭션의 99%가 2초 이내에 완료되고 단일 트랜잭션은 10초보다 오래 걸리지 않습니다.

SLA 모니터링에 대한 요구 사항

가장 높은 수준에서 운영자는 시스템이 합의된 SLA를 충족하는지 여부를 한눈에 확인할 수 있어야 합니다. 그렇지 않은 경우 연산자는 기본 요인을 드릴다운하고 검사하여 표준 이하의 성능 이유를 확인할 수 있어야 합니다.

시각적으로 표시할 수 있는 일반적인 상위 수준 표시기에는 다음이 포함됩니다.

• 서비스 작동 시간 백분율
• 애플리케이션 처리량(성공한 트랜잭션 또는 초당 작업 측면에서 측정)입니다.
• 성공/실패 애플리케이션 요청 수입니다.
• 애플리케이션 및 시스템 오류, 예외 및 경고의 수입니다.

이러한 모든 지표는 지정된 기간으로 필터링할 수 있어야 합니다.

클라우드 애플리케이션은 여러 하위 시스템 및 구성 요소로 구성될 가능성이 높습니다. 연산자는 상위 수준 표시기를 선택하고 기본 요소의 상태부터 구성하는 방법을 확인할 수 있어야 합니다. 예를 들어 전체 시스템의 가동 시간이 허용 가능한 값 아래로 떨어지는 경우 연산자는 이 오류에 기여하는 요소를 확대하고 확인할 수 있어야 합니다.

경고 목적으로 상위 수준 표시기가 지정된 임계값을 초과하는 경우 시스템에서 이벤트를 발생시켜야 합니다. 상위 수준 표시기를 구성하는 다양한 요소의 하위 수준 세부 정보는 경고 시스템에 컨텍스트 데이터로 사용할 수 있어야 합니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

SLA 모니터링을 지원하는 데 필요한 원시 데이터는 상태 및 가용성 모니터링의 일부 측면과 함께 성능 모니터링에 필요한 원시 데이터와 유사합니다. (자세한 내용은 해당 섹션을 참조하세요.) 다음을 통해 이 데이터를 캡처할 수 있습니다.

• 엔드포인트 모니터링을 수행합니다.
• 예외, 장애 및 경고 기록
• 사용자 요청 실행을 추적합니다.
• 시스템에서 사용하는 타사 서비스의 가용성 모니터링
• 성능 메트릭 및 카운터 사용.

모든 데이터는 시간과 시간이 기록되어야 합니다.

SLA 데이터 분석

시스템의 전반적인 성능에 대한 보기를 생성할 수 있도록 계측 데이터를 집계해야 합니다. 집계된 데이터는 또한 기본 하위 시스템 성능을 검사할 수 있도록 드릴 다운을 지원해야 합니다. 예를 들어 다음을 수행할 수 있습니다.

• 지정된 기간 동안의 총 사용자 요청 수를 계산하고 이러한 요청의 성공률과 실패율을 결정합니다.
• 사용자 요청의 응답 시간을 결합하여 시스템 응답 시간의 전체 보기를 생성합니다.
• 사용자 요청 진행률을 분석하여 요청의 전체 응답 시간을 해당 요청 내의 개별 작업 항목의 응답 시간으로 나눕니다.
• 시스템의 전체 가용성을 특정 기간 동안 가동 시간의 백분율로 결정합니다.
• 시스템의 개별 구성 요소 및 서비스의 시간 가용성 비율을 분석합니다. 여기에는 타사 서비스에서 생성한 로그 구문 분석이 포함될 수 있습니다.

많은 상용 시스템은 일반적으로 한 달 동안 합의된 SLA에 대한 실제 성능 수치를 보고해야 합니다. 해당 기간 동안 SLA가 충족되지 않은 경우 이 정보를 사용하여 고객에 대한 크레딧 또는 다른 형태의 상환을 계산할 수 있습니다. 가용성 데이터 분석 섹션에 설명된 기술을 사용하여 서비스의 가용성을 계산할 수 있습니다.

내부 목적을 위해 조직은 서비스가 실패하게 한 인시던트 수와 특성을 추적할 수도 있습니다. 이러한 문제를 신속하게 해결하거나 완전히 제거하는 방법을 알아두면 가동 중지 시간을 줄이고 SLA를 충족하는 데 도움이 됩니다.

감사

애플리케이션의 특성에 따라 사용자의 작업을 감사하고 모든 데이터 액세스를 기록하기 위한 요구 사항을 지정하는 법정 또는 기타 법적 규정이 있을 수 있습니다. 감사는 고객과 특정 요청을 연결하는 증거를 제공할 수 있습니다. 거부 없음은 많은 e-비즈니스 시스템에서 애플리케이션 또는 서비스를 담당하는 조직과 고객 사이의 신뢰를 유지하는 데 도움을 주는 중요한 요소입니다.

감사 요구 사항

분석가는 사용자의 작업을 재구성할 수 있도록 사용자가 수행하는 비즈니스 작업의 순서를 추적할 수 있어야 합니다. 이것은 단순히 기록의 문제로, 또는 법의학 조사의 일환으로 필요할 수 있습니다.

감사 정보는 매우 중요합니다. 수행 중인 작업과 함께 시스템 사용자를 식별하는 데이터가 포함될 수 있습니다. 이러한 이유로 감사 정보는 그래픽 작업의 드릴다운을 지원하는 대화형 시스템이 아니라 신뢰할 수 있는 분석가만 사용 가능한 보고서 형태가 될 가능성이 매우 높습니다. 분석가는 다양한 보고서를 생성할 수 있어야 합니다. 예를 들어 보고서는 지정된 시간 프레임 동안 발생하는 모든 사용자의 활동을 나열하거나, 단일 사용자에 대한 활동의 연대기를 자세히 설명하거나, 하나 이상의 리소스에 대해 수행된 작업 시퀀스를 나열할 수 있습니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

감사에 대한 기본 정보 원본에는 다음이 포함될 수 있습니다.

• 사용자 인증을 관리하는 보안 시스템
• 사용자 활동을 기록하는 추적 로그
• 식별할 수 있고 식별할 수 없는 모든 네트워크 요청을 추적하는 보안 로그입니다.

감사 데이터의 형식 및 감사 데이터의 저장 방법은 규정 요구 사항에 따라 구동될 수 있습니다. 예를 들어 어떤 방식으로든 데이터를 정리하는 것은 불가능할 수 있습니다. (원래 형식으로 기록되어야 합니다.) 변조를 방지하기 위해 데이터가 보관된 리포지토리에 대한 액세스를 보호해야 합니다.

감사 데이터 분석

분석가는 원시 데이터를 원래 형식으로 전체적으로 액세스할 수 있어야 합니다. 일반적인 감사 보고서를 생성하기 위한 요구 사항과 별도로, 이 데이터의 분석에 사용되는 도구는 특수화되어 시스템 외부에 보관될 가능성이 높습니다.

사용량 모니터링

사용 모니터링은 애플리케이션의 기능 및 구성 요소가 사용되는 방법을 추적합니다. 운영자는 수집된 데이터를 사용하여 다음을 수행할 수 있습니다.

• 많이 사용되는 기능을 확인하고 시스템의 잠재적인 핫스팟을 결정합니다. 트래픽이 많은 요소는 기능 분할 또는 복제를 통해 부하를 더 균등하게 분산할 수 있습니다. 또한 운영자는 이 정보를 사용하여 자주 사용되지 않는 기능을 확인할 수 있으며 이후 버전의 시스템에서 사용 중지 또는 교체할 수 있는 후보가 될 수 있습니다.

• 정상적으로 사용 중인 시스템의 작동 이벤트에 대한 정보를 가져옵니다. 예를 들어 전자 상거래 사이트에서 트랜잭션 수 및 해당 트랜잭션을 담당하는 고객의 볼륨에 대한 통계 정보를 기록할 수 있습니다. 이 정보는 고객 수가 증가함에 따라 용량 계획에 사용할 수 있습니다.

• 시스템의 성능 또는 기능에 대한 사용자 만족도(간접적으로)를 검색합니다. 예를 들어 전자 상거래 시스템의 많은 고객이 정기적으로 쇼핑 카트를 중단하는 경우 체크 아웃 기능에 문제가 있을 수 있습니다.

• 청구 정보를 생성합니다. 상용 애플리케이션 또는 다중 테넌트 서비스는 사용하는 리소스에 대해 고객에게 요금을 부과할 수 있습니다.

• 할당량을 적용합니다. 다중 테넌트 시스템의 사용자가 지정된 기간 동안 처리 시간 또는 리소스 사용량의 유료 할당량을 초과하는 경우 액세스를 제한하거나 처리를 제한할 수 있습니다.

사용량 모니터링에 대한 요구 사항

시스템 사용량을 검사하려면 운영자는 일반적으로 다음을 포함하는 정보를 확인해야 합니다.

• 각 하위 시스템에서 처리되어 각 리소스로 전달되는 요청의 수
• 각 사용자가 수행하는 작업입니다.
• 각 사용자가 차지하는 데이터 스토리지의 볼륨입니다.
• 각 사용자가 액세스하는 리소스입니다.

연산자도 그래프를 생성할 수 있어야 합니다. 예를 들어 그래프에는 리소스가 가장 부족한 사용자, 가장 자주 액세스되는 리소스 또는 시스템 기능이 표시될 수 있습니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

사용량 추적은 비교적 높은 수준에서 수행할 수 있습니다. 각 요청의 시작 및 종료 시간과 요청의 특성(해당 리소스에 따라 읽기, 쓰기 등)을 기록할 수 있습니다. 다음을 통해 이 정보를 얻을 수 있습니다.

• 사용자 활동 추적
• 각 리소스의 사용률을 측정하는 성능 카운터 캡처
• 각 사용자의 리소스 사용량 모니터링

측정 목적을 위해 어떤 사용자가 어떤 작업을 수행할 책임이 있고 이러한 작업에서 사용하는 리소스를 식별할 수 있어야 합니다. 수집된 정보는 정확한 청구를 가능하게 하기에 충분히 자세히 설명되어야 합니다.

문제 추적

시스템에서 예기치 않은 이벤트나 동작이 발생하는 경우 고객 및 다른 사용자가 문제를 보고할 수 있습니다. 문제 추적은 이러한 문제를 관리하고, 시스템의 근본적인 문제를 해결하기 위한 노력과 연결하고, 고객에게 가능한 해결 방법을 알리는 것과 관련이 있습니다.

문제 추적에 대한 요구 사항

운영자는 사용자가 보고하는 문제의 세부 정보를 기록하고 보고할 수 있는 별도의 시스템을 사용하여 문제 추적을 수행하는 경우가 많습니다. 이러한 세부 정보에는 사용자가 수행하려고 시도한 작업, 문제의 증상, 이벤트 시퀀스, 발생한 오류 또는 경고 메시지가 포함될 수 있습니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

문제 추적 데이터의 초기 데이터 원본은 처음에 문제를 보고한 사용자입니다. 사용자는 다음과 같은 추가 데이터를 제공할 수 있습니다.

• 크래시 덤프(애플리케이션에 사용자 데스크톱에서 실행되는 구성 요소가 포함되는 경우)
• 화면 스냅샷입니다.
• 오류가 발생한 날짜 및 시간과 사용자의 위치와 같은 다른 환경 정보입니다.

이 정보는 디버깅 작업을 돕고 소프트웨어의 향후 릴리스를 위한 백로그를 구성하는 데 도움이 될 수 있습니다.

문제 추적 데이터 분석

다른 사용자가 동일한 문제를 보고할 수 있습니다. 문제 추적 시스템은 일반적인 보고서를 연결해야 합니다.

디버깅 작업의 진행률을 각 문제 보고서에 대해 기록해야 합니다. 문제가 해결되면 고객에게 솔루션을 알릴 수 있습니다.

사용자가 문제 추적 시스템에 알려진 솔루션이 있는 문제를 보고하는 경우 운영자는 사용자에게 솔루션에 대해 즉시 알릴 수 있어야 합니다.

작업 추적 및 소프트웨어 릴리스 디버그

사용자가 문제를 보고할 때 사용자는 종종 작업에 미치는 즉각적인 영향만 인식합니다. 사용자는 시스템을 유지 관리하는 운영자에게 사용자 자신의 경험에서 나온 결과만 보고할 수 있습니다. 이러한 환경은 일반적으로 하나 이상의 근본적인 문제의 눈에 띄는 증상일 뿐입니다. 대부분의 경우 분석가는 문제의 근본 원인을 설정하기 위해 기본 작업의 연대기를 파헤쳐야 합니다. 이 프로세스를 근본 원인 분석이라고 합니다.

추적 및 디버깅을 위한 요구 사항

예기치 않은 이벤트 및 기타 문제를 추적하려면 모니터링 데이터가 충분한 정보를 제공하여 분석가가 이러한 문제의 출처를 추적하고 발생한 이벤트 시퀀스를 다시 구성할 수 있도록 하는 것이 중요합니다. 이 정보는 분석가가 모든 문제의 근본 원인을 진단할 수 있도록 충분해야 합니다. 그런 다음 개발자가 필요한 수정을 수행하여 되풀이되지 않도록 할 수 있습니다.

데이터 소스, 계측 및 데이터 수집 요구 사항

문제 해결에는 고객이 특정 요청을 하는 경우 시스템 내에서 이루어지는 논리 흐름을 설명하는 트리를 작성하는 작업 도중에 호출되는 모든 메서드 및 해당 매개 변수를 추적하는 작업이 필요할 수 있습니다. 이 흐름의 결과로 시스템에서 생성하는 예외 및 경고를 캡처하고 기록해야 합니다.

디버깅을 지원하기 위해 시스템은 운영자가 시스템의 중요한 지점에서 상태 정보를 캡처할 수 있는 후크를 제공할 수 있습니다. 또는 선택한 작업 진행률에 따라 시스템에서 자세한 단계별 정보를 제공할 수 있습니다. 이 세부 수준으로 데이터를 캡처하는 작업은 시스템에 부하를 더할 수 있으며 임시 프로세스여야 합니다. 운영자는 아주 특수한 일련의 이벤트가 발생할 때나 시스템에 하나 이상의 요소를 새로 릴리스하면서 이 요소가 예상대로 작동하는지 확인하기 위해 세심하게 모니터링해야 할 때 주로 이 프로세스를 사용합니다.

모니터링 및 진단 파이프라인

대규모 분산 시스템을 모니터링하는 것은 중대한 문제를 야기합니다. 이전 섹션에서 설명한 각 시나리오를 격리된 것으로 간주해서는 안 됩니다. 각 상황에 필요한 모니터링 데이터와 진단 데이터는 처리 및 표시 방식이 서로 다를 수는 있지만 상당히 중복될 가능성이 있습니다. 이러한 이유로 모니터링 및 진단에 대한 전체적인 시각을 가져야 합니다.

전체 모니터링 및 진단 프로세스를 그림 1에 나오는 단계를 구성하는 파이프라인으로 그려 볼 수 있습니다.

그림 1 - 모니터링 및 진단 파이프라인의 단계

그림 1에서는 모니터링 및 진단을 위한 데이터를 다양한 데이터 소스에서 가져올 수 있는 방법을 보여 줍니다. 계측 및 수집 단계는 데이터를 캡처해야 하는 원본을 식별하고, 캡처할 데이터, 캡처하는 방법 및 쉽게 검사할 수 있도록 이 데이터의 형식을 지정하는 방법을 결정하는 것과 관련이 있습니다. 분석/진단 단계에서는 원시 데이터를 가져와 이 데이터를 사용하여 운영자가 시스템 상태를 확인하는 데 사용 가능한 유의미한 정보를 생성합니다. 운영자는 이 정보를 사용하여 수행할 가능한 작업에 대한 결정을 내린 다음 결과를 계측 및 수집 단계로 다시 공급할 수 있습니다. 시각화/경고 단계 단계에서는 시스템 상태의 소모성 보기를 표시합니다. 이 뷰는 일련의 대시보드를 사용해 실시간에 가깝게 정보를 표시할 수 있으며 또한 보고서, 그래프 및 차트를 생성하여 장기 추세를 식별하는 데 도움이 되는 데이터의 기록 보기를 제공할 수 있습니다. 정보가 KPI가 허용 범위를 초과할 가능성이 있음을 나타내는 경우 이 단계에서는 운영자에게 경고를 트리거할 수도 있습니다. 경우에 따라 경고를 사용하여 자동 크기 조정과 같은 수정 작업을 시도하는 자동화된 프로세스를 트리거할 수도 있습니다.

이러한 단계는 단계가 병렬로 진행되는 연속 흐름 프로세스를 구성합니다. 이상적으로 모든 단계를 동적으로 구성할 수 있어야 합니다. 특히 시스템이 새로 배포되었거나 문제가 발생하는 경우 확장 데이터를 더 자주 수집해야 할 수도 있습니다. 다른 경우에는 기본 수준의 필수 정보 캡처로 되돌아가 시스템이 제대로 작동하고 있는지 확인할 수 있어야 합니다.

또한 전체 모니터링 프로세스는 피드백의 결과로 미세 조정 및 개선이 적용되는 라이브 진행 중인 솔루션으로 간주되어야 합니다. 예를 들어 시스템 상태를 확인하기 위해 여러 요인을 측정하는 것으로 시작할 수 있습니다. 시간이 지남에 따라 분석을 거쳐 관련성 없는 측정값을 취소하면서 조정하게 되며 이에 따라 백그라운드 노이즈를 최소화하며 필요한 데이터에 더 정확히 초점을 맞출 수 있게 됩니다.

모니터링 및 진단 데이터의 소스

모니터링 프로세스에서 사용하는 정보는 그림 1에 설명된 대로 여러 원본에서 제공될 수 있습니다. 애플리케이션 수준에서 정보는 시스템 코드에 통합된 추적 로그에서 가져옵니다. 개발자는 코드를 통해 제어 흐름을 추적하기 위한 표준 접근 방식을 따라야 합니다. 예를 들어 메서드에 대한 항목은 메서드 이름, 현재 시간, 각 매개 변수의 값 및 기타 관련 정보를 지정하는 추적 메시지를 내보낼 수 있습니다. 진입 및 종료 시간을 기록하는 것도 유용할 수 있습니다.

모든 예외 및 경고를 기록하고 중첩된 예외 및 경고의 전체 추적을 유지해야 합니다. 또한 코드를 실행하는 사용자를 식별하는 정보를 작업 상관 관계 정보와 함께 캡처하는 것이 좋습니다(시스템을 통과하는 요청을 추적하기 위해). 또한 메시지 큐, 데이터베이스, 파일 및 기타 종속 서비스와 같은 모든 리소스에 액세스하려는 시도를 기록해야 합니다. 이 정보는 계량 및 감사 목적으로 사용할 수 있습니다.

많은 애플리케이션이 네트워크를 통해 데이터 저장소에 액세스하는 등의 일반적인 작업을 수행하는 데 라이브러리 및 프레임워크를 활용합니다. 이러한 프레임워크는 트랜잭션 속도, 데이터 전송 성공 및 실패와 같은 자체 추적 메시지 및 원시 진단 정보를 제공하도록 구성할 수 있습니다.

애플리케이션이 실행되는 운영 체제는 I/O 속도, 메모리 사용률 및 CPU 사용량을 나타내는 성능 카운터와 같은 낮은 수준의 시스템 전체 정보의 원본이 될 수 있습니다. 운영 체제 오류(예: 파일을 올바르게 열지 못)도 보고될 수 있습니다.

또한 시스템이 실행되는 기본 인프라 및 구성 요소를 고려해야 합니다. 가상 머신, 가상 네트워크 및 스토리지 서비스는 모두 인프라 수준의 중요 성능 카운터 및 다른 진단 데이터의 소스가 될 수 있습니다.

애플리케이션이 웹 서버 또는 데이터베이스 관리 시스템과 같은 다른 외부 서비스를 사용하는 경우 이러한 서비스는 자체 추적 정보, 로그 및 성능 카운터를 게시할 수 있습니다. 예를 들어 SQL Server 데이터베이스에 대해 수행된 추적 작업을 위한 SQL Server 동적 관리 뷰 및 웹 서버에 대한 요청을 기록하기 위한 IIS 추적 로그가 있습니다.

시스템의 구성 요소가 수정되고 새로운 버전이 배포됨에 따라 문제, 이벤트, 메트릭 등이 어느 버전에서 비롯된 것인지 식별할 수 있어야 합니다. 특정 버전의 구성 요소에 대한 문제를 신속하게 추적하고 수정할 수 있도록 이 정보를 릴리스 파이프라인에 다시 연결해야 합니다.

보안 문제는 시스템의 어느 지점에서나 발생할 수 있습니다. 예를 들어 사용자가 잘못된 사용자 ID 또는 암호로 로그인을 시도할 수 있습니다. 인증된 사용자는 리소스에 대한 무단 액세스를 얻으려고 시도할 수 있습니다. 또는 사용자가 암호화된 정보에 액세스하기 위해 유효하지 않거나 오래된 키를 제공할 수 있습니다. 성공 및 실패 요청에 대한 보안 관련 정보는 항상 기록되어야 합니다.

애플리케이션 계측 섹션에는 캡처해야 하는 정보에 대한 추가 지침이 포함되어 있습니다. 그러나 이 정보를 수집하는 데 다양한 전략을 사용할 수 있습니다.

• 애플리케이션/시스템 모니터링. 이 전략은 애플리케이션, 애플리케이션 프레임워크, 운영 체제 및 인프라 내의 내부 원본을 사용합니다. 애플리케이션 코드는 클라이언트 요청의 수명 주기 동안 주목할 만한 지점에서 자체 모니터링 데이터를 생성할 수 있습니다. 애플리케이션에는 상황에 따라 선택적으로 사용하거나 사용하지 않도록 설정할 수 있는 추적 문이 포함될 수 있습니다. 진단 프레임워크를 사용하여 진단을 동적으로 삽입하는 것도 가능합니다. 이러한 프레임워크는 일반적으로 코드의 다양한 계측 지점에 연결하고 이러한 지점에서 추적 데이터를 캡처할 수 있는 플러그 인을 제공합니다.

  또한 코드 또는 기본 인프라가 중요한 지점에서 이벤트를 발생시키는 경우도 있습니다. 이러한 이벤트를 수신 대기하도록 구성된 모니터링 에이전트가 이벤트 정보를 기록할 수 있습니다.

• 실제 사용자 모니터링. 이 방법은 사용자와 애플리케이션 간의 상호 작용을 기록하고 각 요청 및 응답의 흐름을 관찰합니다. 이 정보에는 두 가지 목적이 있을 수 있습니다. 첫째, 이 정보를 사용하여 각 사용자의 사용 현황을 계량할 수 있습니다. 둘째, 이 정보를 사용하여 사용자가 적절한 서비스 품질(예: 빠른 응답 시간, 짧은 대기 시간, 최소한의 오류)을 받고 있는지 여부를 확인할 수 있습니다. 캡처된 데이터를 사용하여 오류가 가장 자주 발생하는 문제 영역을 식별할 수 있습니다. 데이터를 사용하여 애플리케이션의 핫스팟 또는 다른 형태의 병목 현상으로 인해 시스템이 느려지는 요소를 식별할 수도 있습니다. 이 방법을 신중하게 구현하는 경우 디버깅 및 테스트 목적으로 애플리케이션을 통해 사용자의 흐름을 재구성할 수 있습니다.

  Important

  기밀 자료가 포함될 수 있으므로 실제 사용자를 모니터링하여 캡처한 데이터를 매우 민감하게 간주해야 합니다. 캡처된 데이터를 저장하는 경우 안전하게 저장합니다. 성능 모니터링 또는 디버깅을 위해 데이터를 사용하려면 먼저 모든 개인 데이터를 제거합니다.

• 가상 사용자 모니터링. 이 방법에서는 사용자를 시뮬레이션하고 구성 가능하지만 일반적인 일련의 작업을 수행하는 고유한 테스트 클라이언트를 작성합니다. 테스트 클라이언트의 성능을 추적하여 시스템 상태를 확인할 수 있습니다. 부하 테스트 작업의 일부로 테스트 클라이언트의 여러 인스턴스를 사용하여 시스템이 스트레스로 응답하는 방식과 이러한 조건에서 생성되는 모니터링 출력의 종류를 설정할 수도 있습니다.

  참고 항목

  메서드 호출 및 애플리케이션의 다른 중요한 부분의 실행을 추적하고 시간을 지정하는 코드를 포함하여 실제 및 가상 사용자 모니터링을 구현할 수 있습니다.

• 프로파일링 이 접근 방식은 주로 애플리케이션 성능을 모니터링하고 개선하는 것을 목표로 합니다. 실제 사용자 모니터링 및 가상 사용자 모니터링의 기능 수준에서 작업하는 것보다 애플리케이션이 실행될 때 하위 수준 정보를 캡처합니다. 애플리케이션의 실행 상태에 대한 주기적 샘플링을 사용하여 프로파일링을 구현할 수 있습니다(지정된 시점에 애플리케이션이 실행 중인 코드 부분을 결정). 또한 코드의 중요 지점(예: 메서드 호출 시작 및 종료)에 프로브를 삽입하고 호출된 메서드, 호출된 시간, 각 호출에 걸린 시간 등을 기록하는 계측을 사용할 수 있습니다. 그런 다음, 이 데이터를 분석하여 성능 문제를 일으킬 수 있는 애플리케이션 부분을 확인할 수 있습니다.

• 엔드포인트 모니터링. 이 기술은 특히 모니터링을 사용할 수 있도록 애플리케이션에서 노출하는 하나 이상의 진단 엔드포인트를 사용합니다. 엔드포인트는 애플리케이션 코드에 대한 경로를 제공하고 시스템의 상태에 대한 정보를 반환할 수 있습니다. 여러 엔드포인트가 이 기능의 다양한 측면에 집중할 수 있습니다. 이러한 엔드포인트에 주기적인 요청을 보내고 응답을 동화하는 고유한 진단 클라이언트를 작성할 수 있습니다. 자세한 내용은 상태 엔드포인트 모니터링 패턴을 참조하세요.

최대 적용 범위를 위해 이러한 기술의 조합을 사용해야 합니다.

애플리케이션 계측

계측은 모니터링 프로세스의 중요한 부분입니다. 이러한 결정을 내릴 수 있는 데이터를 먼저 캡처하는 경우에만 시스템의 성능 및 상태에 대해 의미 있는 결정을 내릴 수 있습니다. 계측을 사용하여 수집하는 정보는 추적(및 디버깅)을 수동으로 수행하기 위해 원격 프로덕션 서버에 로그인하지 않고도 성능을 평가하고 문제를 진단하고 결정을 내릴 수 있을 정도로 충분해야 합니다. 계측 데이터는 일반적으로 추적 로그에 기록되는 메트릭 및 정보로 구성됩니다.

추적 로그의 콘텐츠는 애플리케이션이 작성한 텍스트 데이터의 결과이거나, 추적 이벤트의 결과로 생성된 이진 데이터(애플리케이션에서 ETW(Windows용 이벤트 추적)를 사용 중인 경우)일 수 있습니다. 웹 서버와 같은 인프라의 일부에서 발생하는 이벤트를 기록하는 시스템 로그에서 생성할 수도 있습니다. 텍스트 로그 메시지는 사용자가 읽을 수 있도록 설계되는 경우가 많지만 자동화된 시스템에서 쉽게 구문 분석할 수 있는 형식으로도 작성해야 합니다.

로그도 분류해야 합니다. 모든 추적 데이터를 단일 로그에 쓰지 말고 별도의 로그를 사용하여 시스템의 다양한 운영 측면에서 추적 출력을 기록합니다. 그런 다음, 긴 파일을 하나만 처리하지 않고도 적절한 로그에서 읽어 로그 메시지를 빠르게 필터링할 수 있습니다. 예를 들어 감사 정보와 디버깅 데이터의 경우처럼 보안 요구 사항이 서로 다른 정보를 동일한 로그에 쓰면 안 됩니다.

메트릭은 일반적으로 하나 이상의 연결된 태그 또는 차원(샘플이라고도 함)을 사용하여 특정 시간에 시스템에서 일부 측면 또는 리소스의 측정값 또는 개수가 됩니다. 메트릭의 단일 인스턴스는 일반적으로 격리에 유용하지 않습니다. 대신 시간이 지남에 따라 여러 메트릭을 캡처해야 합니다. 기록해야 할 메트릭이 어느 것이며 얼마나 자주 기록해야 하는지를 중요한 문제로 고려해야 합니다. 메트릭용으로 데이터를 생성할 때 많은 경우 시스템에 상당한 부하를 더할 수 있습니다. 반면, 메트릭을 드물게 캡처하면 중요한 이벤트를 발생시키는 상황을 놓칠 수 있습니다. 고려 사항은 메트릭마다 다릅니다. 예를 들어 서버의 CPU 사용률은 초에서 초로 크게 다를 수 있지만 사용률이 높으면 몇 분 동안 수명이 긴 경우에만 문제가 됩니다.

데이터 상관 관계를 설정하기 위한 정보

개별 시스템 수준 성능 카운터를 쉽게 모니터링하고, 리소스에 대한 메트릭을 캡처하고, 다양한 로그 파일에서 애플리케이션 추적 정보를 가져올 수 있습니다. 그러나 일부 형태의 모니터링에서는 다수의 원본에서 검색한 데이터의 상관 관계를 설정할 수 있도록 모니터링 파이프라인에 분석 및 진단 단계가 필요합니다. 이 데이터는 원시 데이터에서 여러 형태를 취할 수 있으며, 분석 프로세스는 이러한 다양한 형식을 매핑할 수 있는 충분한 계측 데이터를 제공해야 합니다. 예를 들어 애플리케이션 프레임워크 수준에서 태스크는 스레드 ID로 식별될 수 있습니다. 애플리케이션 내에서 동일한 작업이 해당 작업을 수행하는 사용자의 사용자 ID와 연결될 수 있습니다.

또한 비동기 작업은 두 명 이상의 사용자를 대신하여 작업을 수행하기 위해 동일한 스레드를 다시 사용할 수 있으므로 스레드와 사용자 요청 간에 1:1 매핑이 있을 가능성이 낮습니다. 문제를 더 복잡하게 하기 위해 실행이 시스템을 통해 흐르면서 둘 이상의 스레드에서 단일 요청을 처리할 수 있습니다. 가능하면 각 요청을 요청 컨텍스트의 일부로 시스템을 통해 전파되는 고유한 활동 ID와 연결합니다. (추적 정보에 활동 ID를 생성하고 포함하는 기술은 추적 데이터를 캡처하는 데 사용되는 기술에 따라 달라집니다.)

모든 모니터링 데이터에 같은 방식으로 타임스탬프를 지정해야 합니다. 일관성을 위해 협정 세계시(협정 세계시)를 사용하여 모든 날짜와 시간을 기록합니다. 이렇게 하면 이벤트의 시퀀스를 보다 쉽게 추적할 수 있습니다.

계측 데이터에 포함할 정보

수집해야 할 계측 데이터를 결정할 때는 다음 사항을 고려하세요.

• 추적 이벤트에 의해 캡처된 정보가 컴퓨터이고 사람이 읽을 수 있는지 확인합니다. 이 정보에 대해 잘 정의된 스키마를 채택하여 시스템 간에 로그 데이터를 자동화하고 로그를 읽는 운영 및 엔지니어링 직원에게 일관성을 제공합니다. 배포 환경, 프로세스가 실행 중인 컴퓨터, 프로세스의 세부 정보 및 호출 스택과 같은 환경 정보를 포함합니다.

• 시스템에 상당한 오버헤드를 부과할 수 있으므로 필요한 경우에만 프로파일링을 사용하도록 설정합니다. 계측을 사용하여 프로파일링은 이벤트가 발생할 때마다 이벤트(예: 메서드 호출)를 기록하는 반면 샘플링은 선택한 이벤트만 기록합니다. 선택 영역은 시간 기반(n초마다 한 번) 또는 빈도 기반(n개 요청마다 한 번)일 수 있습니다. 이벤트가 매우 자주 발생하는 경우 계측에 의한 프로파일링으로 인해 너무 많은 부담이 발생하고 그 자체가 전반적인 성능에 영향을 줄 수 있습니다. 이 경우 샘플링 방법이 바람직할 수 있습니다. 그러나 이벤트의 빈도가 낮을 때는 샘플링이 이벤트를 놓칠 수 있습니다. 이 경우에는 계측이 더 나은 접근 방식일 수 있습니다.

• 개발자나 관리자가 각 요청의 원본을 확인할 수 있도록 충분한 컨텍스트를 제공합니다. 여기에는 요청의 특정 인스턴스를 식별하는 일부 형태의 활동 ID가 포함될 수 있습니다. 또한 이 작업을 수행된 계산 작업 및 사용된 리소스와 상호 연결하는 데 사용할 수 있는 정보가 포함될 수 있습니다. 이 작업은 프로세스와 컴퓨터 경계를 넘을 수 있습니다. 계량의 경우 컨텍스트에는 요청을 발생시킨 고객에 대한 참조(다른 상관 관계가 있는 정보를 통해 직접 또는 간접적으로)도 포함되어야 합니다. 이 컨텍스트는 모니터링 데이터가 캡처된 시점의 애플리케이션 상태에 대한 중요한 정보를 제공합니다.

• 모든 요청 및 이러한 요청이 발생한 위치나 지역을 기록합니다. 이 정보는 위치별 핫스팟이 있는지 여부를 결정하는 데 도움을 줄 수 있습니다. 이 정보는 애플리케이션 또는 애플리케이션에서 사용하는 데이터를 다시 분할할지 여부를 결정하는 데에도 유용한 역할을 할 수 있습니다.

• 예외의 세부 정보를 신중하게 기록하고 캡처합니다. 예외 처리가 좋지 않으면 중요한 디버그 정보가 손실되는 경우가 많습니다. 내부 예외 및 기타 컨텍스트 정보를 포함하여 애플리케이션에서 throw하는 예외의 전체 세부 정보를 캡처합니다. 가능한 경우 호출 스택을 포함합니다.

• 이벤트를 분석하고 사용자 요청과 상관 관계를 지정하는 데 도움이 될 수 있으므로 애플리케이션의 다양한 요소가 캡처하는 데이터의 일관성을 유지합니다. 개발자가 시스템의 여러 부분을 구현하는 것과 동일한 접근 방식을 채택하는 대신 포괄적이고 구성 가능한 로깅 패키지를 사용하여 정보를 수집하는 것이 좋습니다. 수행되는 I/O의 볼륨, 네트워크 이용률, 요청 수, 메모리 사용, CPU 사용률과 같은 주요 성능 카운터에서 데이터를 수집합니다. 일부 인프라 서비스는 데이터베이스에 대한 연결 수, 트랜잭션이 수행되는 속도 및 성공 또는 실패하는 트랜잭션 수와 같은 고유한 특정 성능 카운터를 제공할 수 있습니다. 애플리케이션은 고유한 특정 성능 카운터를 정의할 수도 있습니다.

• 데이터베이스 시스템, 웹 서비스 또는 인프라의 일부인 기타 시스템 수준 서비스와 같은 외부 서비스에 대한 모든 호출을 기록합니다. 각 호출을 수행하는 데 걸린 시간 및 호출의 성공 또는 실패에 대한 정보를 기록합니다. 가능하면 발생하는 일시적인 오류에 대한 모든 재시도 시도 및 실패에 대한 정보를 캡처합니다.

원격 분석 시스템과의 호환성 보장

많은 경우에 계측에서 나오는 정보는 일련의 이벤트로 생성되고 처리와 분석을 위해 별도의 원격 분석 시스템으로 전달됩니다. 원격 분석 시스템은 일반적으로 특정 애플리케이션이나 기술에 대해 독립적이지만 정보는 대개 스키마에 정의된 특정 형식을 따라야 합니다. 스키마는 원격 분석 시스템이 수집할 수 있는 데이터 필드와 유형을 정의하는 계약을 효과적으로 지정합니다. 다양한 플랫폼 및 디바이스에서 데이터가 도착할 수 있도록 스키마를 일반화해야 합니다.

일반적인 스키마에는 이벤트 이름, 이벤트 시간, 보낸 사람의 IP 주소 및 다른 이벤트(예: 사용자 ID, 디바이스 ID 및 애플리케이션 ID)와의 상관 관계에 필요한 세부 정보와 같은 모든 계측 이벤트에 공통적인 필드가 포함되어야 합니다. 많은 수의 디바이스가 이벤트를 발생시키지 않으므로 스키마가 디바이스 유형에 의존해서는 안 됩니다. 또한 동일한 애플리케이션에 대한 이벤트가 여러 개의 다양한 디바이스에서 발생할 수 있으며, 애플리케이션이 로밍 또는 다른 형태의 디바이스 간 배포를 지원할 수도 있습니다.

스키마에는 여러 애플리케이션에서 공통적인 특정 시나리오와 관련된 도메인 필드도 포함될 수 있습니다. 예외, 애플리케이션 시작 및 종료 이벤트, 웹 서비스 API 호출의 성공 또는 실패에 대한 정보일 수 있습니다. 동일한 도메인 필드 집합을 사용하는 모든 애플리케이션은 동일한 이벤트 집합을 내보내 공통 보고서 및 분석 집합을 빌드할 수 있도록 해야 합니다.

마지막으로 스키마는 애플리케이션별 이벤트의 세부 정보를 캡처하기 위한 사용자 지정 필드를 포함할 수 있습니다.

애플리케이션 계측 모범 사례

다음은 클라우드에서 실행되는 분산 애플리케이션을 계측하기 위한 모범 사례를 요약한 목록입니다.

• 로그를 쉽게 읽고 구문 분석할 수 있도록 만듭니다. 가능한 경우 구조화된 로깅을 사용합니다. 로그 메시지에서 간결하고 설명합니다.

• 모든 로그에서 원본을 식별하고 각 로그 레코드가 기록되는 컨텍스트 및 타이밍 정보를 제공합니다.

• 모든 타임스탬프에 동일한 표준 시간대와 형식을 사용합니다. 이렇게 하면 다른 지역에서 실행되는 하드웨어 및 서비스에 걸쳐 있는 작업의 이벤트 상관 관계를 지정하는 데 도움이 됩니다.

• 로그를 분류하고 적절한 로그 파일에 메시지를 씁니다.

• 시스템에 대한 중요한 정보 또는 사용자에 대한 개인 정보를 공개하지 마세요. 기록하기 전에 이 정보를 스크러빙하지만 관련 세부 정보가 유지되는지 확인합니다. 예를 들어 데이터베이스 연결 문자열에서 ID와 암호를 제거하지만, 분석가가 시스템이 올바른 데이터베이스에 액세스하는지 확인할 수 있도록 나머지 정보는 로그에 씁니다. 모든 심각한 예외를 로그에 기록하지만, 하위 수준의 예외 및 경고에 대해서는 관리자가 로깅을 설정 및 해제할 수 있도록 합니다. 또한 모든 재시도 논리 정보를 캡처하고 기록합니다. 이 데이터는 시스템의 일시적인 상태를 모니터링하는 데 유용할 수 있습니다.

• 외부 웹 서비스 또는 데이터베이스에 대한 요청과 같은 프로세스 외 호출을 추적합니다.

• 보안 요구 사항이 서로 다른 메시지를 동일한 로그 파일에 혼합하지 마세요. 예를 들어 디버그 및 감사 정보를 동일한 로그에 쓰지 마세요.

• 감사 이벤트를 제외하고, 모든 로깅 호출은 자체 유도(fire-and-forget) 작업이어야 하며 비즈니스 작업의 진행을 차단해서는 안 됩니다. 감사 이벤트는 비즈니스에 중요하며 비즈니스 운영의 기본 부분으로 분류될 수 있으므로 예외적입니다.

• 로깅이 확장 가능하고 구체적인 대상에 대한 직접적인 종속성이 없는지 확인합니다. 예를 들어 System.Diagnostics.Trace를 사용하여 정보를 작성하는 대신 로깅 메서드를 노출하고 적절한 수단을 통해 구현할 수 있는 추상 인터페이스(예: ILogger)를 정의합니다.

• 모든 로깅이 실패로부터 안전한지 확인하고 연속 오류를 트리거하지 않아야 합니다. 로깅은 예외를 throw해서는 안 됩니다.

• 계측을 진행 중인 반복 프로세스로 처리하고 문제가 있을 때뿐만 아니라 정기적으로 로그를 검토합니다.

데이터 수집 및 저장

모니터링 프로세스의 수집 단계는 계측에서 생성하는 정보를 검색하고, 분석/진단 단계에서 더 쉽게 사용할 수 있도록 이 데이터의 서식을 지정하고, 변환된 데이터를 신뢰할 수 있는 스토리지에 저장하는 것과 관련이 있습니다. 분산 시스템의 여러 부분에서 수집하는 계측 데이터는 다양한 형식을 사용해 다양한 위치에 보관할 수 있습니다. 예를 들어 애플리케이션 코드는 추적 로그 파일을 생성하고 애플리케이션 이벤트 로그 데이터를 생성할 수 있지만 애플리케이션에서 사용하는 인프라의 주요 측면을 모니터링하는 성능 카운터는 다른 기술을 통해 캡처할 수 있습니다. 애플리케이션에서 사용하는 타사 구성 요소 및 서비스는 별도의 추적 파일, Blob Storage 또는 사용자 지정 데이터 저장소를 사용하여 다양한 형식의 계측 정보를 제공할 수 있습니다.

데이터 수집은 계측 데이터를 생성하는 애플리케이션에서 자율적으로 실행할 수 있는 컬렉션 서비스를 통해 수행되는 경우가 많습니다. 그림 2에서는 계측 데이터 수집 하위 시스템을 강조 표시하는 이 아키텍처의 예를 보여 줍니다.

그림 2 - 계측 데이터 수집

이 보기는 간소화된 보기입니다. 컬렉션 서비스는 반드시 단일 프로세스가 아니며 다음 섹션에 설명된 대로 여러 컴퓨터에서 실행되는 많은 구성 요소로 구성될 수 있습니다. 또한 일부 원격 분석 데이터의 분석을 신속하게 수행해야 하는 경우(이 문서의 뒷부분에서 핫, 웜 및 콜드 분석 지원 섹션 에 설명된 대로 핫 분석 ) 수집 서비스 외부에서 작동하는 로컬 구성 요소는 분석 작업을 즉시 수행할 수 있습니다. 그림 2에서는 선택한 이벤트에 대해 이 상황을 보여 줍니다. 분석 처리 후 결과는 시각화 및 경고 하위 시스템에 직접 보낼 수 있습니다. 웜 또는 콜드 분석이 적용되는 데이터는 처리를 기다리는 동안 스토리지에 보관됩니다.

Azure 애플리케이션 및 서비스의 경우 Azure Diagnostics는 데이터를 캡처하기 위한 하나의 가능한 솔루션을 제공합니다. Azure Diagnostics는 각 컴퓨팅 노드에 대해 다음 원본에서 데이터를 수집하고 집계한 다음 Azure Storage에 업로드합니다.

• IIS 로그
• IIS 실패한 요청 로그
• Windows 이벤트 로그
• 성능 카운터
• 크래시 덤프
• Azure Diagnostics 인프라 로그
• 사용자 지정 오류 로그
• .NET EventSource
• 매니페스트 기반 ETW

자세한 내용은 Azure: 원격 분석 기본 사항 및 문제 해결문서를 참조하세요.

계측 데이터 수집 전략

클라우드의 탄력적인 특성을 고려하고 시스템의 모든 노드에서 원격 분석 데이터를 수동 검색할 필요가 없도록 하기 위해 데이터를 하나의 중앙 위치로 전송하여 통합해야 합니다. 여러 데이터 센터에 걸쳐 있는 시스템에서는 먼저 지역별로 데이터를 수집, 통합 및 저장한 다음 지역 데이터를 단일 중앙 시스템으로 집계하는 것이 유용할 수 있습니다.

대역폭 사용을 최적화하기 위해 덜 긴급한 데이터를 일괄 처리로 청크로 전송하도록 선택할 수 있습니다. 그러나 시간이 중요한 정보가 포함된 경우 데이터를 무기한으로 지연해서는 안 됩니다.

계측 데이터 풀 및 푸시

계측 데이터 수집 하위 시스템은 애플리케이션의 각 인스턴스( 끌어오기 모델)에 대한 다양한 로그 및 기타 원본에서 계측 데이터를 적극적으로 검색할 수 있습니다. 또는 애플리케이션의 각 인스턴스( 푸시 모델)를 구성하는 구성 요소에서 데이터가 전송될 때까지 기다리는 수동 수신기 역할을 할 수 있습니다.

끌어오기 모델을 구현하는 한 가지 방법은 애플리케이션의 각 인스턴스에서 로컬로 실행되는 모니터링 에이전트를 사용하는 것입니다. 모니터링 에이전트는 로컬 노드에서 수집된 원격 분석 데이터를 주기적으로 검색(끌어오기)한 후 애플리케이션의 모든 인스턴스가 공유하는 중앙 스토리지에 이 정보를 직접 쓰는 별도의 프로세스입니다. Azure Diagnostics에서 구현하는 메커니즘입니다. Azure 웹 또는 작업자 역할의 각 인스턴스는 로컬에 저장된 진단 및 기타 추적 정보를 캡처하도록 구성할 수 있습니다. 각 인스턴스와 함께 실행되는 모니터링 에이전트는 지정된 데이터를 Azure Storage에 복사합니다. Azure Cloud Services 및 Virtual Machines에서 진단을 사용하도록 설정하는 문서에서는 이 프로세스에 대한 자세한 내용을 제공합니다. IIS 로그, 크래시 덤프 및 사용자 지정 오류 로그와 같은 일부 요소는 Blob Storage에 기록됩니다. Windows 이벤트 로그, ETW 이벤트 및 성능 카운터의 데이터는 테이블 스토리지에 기록됩니다. 그림 3에서는 이 메커니즘을 보여 줍니다.

그림 3 - 모니터링 에이전트를 사용하여 정보 끌어오기 및 공유 스토리지에 쓰기

단일 위치의 제한된 수의 노드에서 실행되는 소규모 애플리케이션에 대한 원격 분석 데이터를 저장하는 데 설명된 접근 방식을 사용할 수 있습니다. 그러나 복잡하고 확장성이 뛰어난 글로벌 클라우드 애플리케이션은 수백 개의 웹 및 작업자 역할, 데이터베이스 분할된 데이터베이스 및 기타 서비스에서 대량의 데이터를 생성할 수 있습니다. 이러한 데이터 홍수는 단일 중앙 위치에서 사용할 수 있는 I/O 대역폭을 쉽게 압도할 수 있습니다. 따라서 시스템이 확장될 때 병목 현상이 발생하지 않도록 원격 분석 솔루션을 확장할 수 있어야 합니다. 이상적으로 솔루션은 시스템의 일부가 실패할 경우 중요한 모니터링 정보(예: 감사 또는 청구 데이터)를 잃을 위험을 줄이기 위해 어느 정도의 중복성을 통합해야 합니다.

이러한 문제를 해결하기 위해 그림 4와 같이 큐를 구현할 수 있습니다. 이 아키텍처에서 로컬 모니터링 에이전트(적절하게 구성할 수 있는 경우) 또는 사용자 지정 데이터 수집 서비스(그렇지 않은 경우)는 데이터를 큐에 게시합니다. 비동기적으로 실행되는 별도의 프로세스(그림 4의 스토리지 쓰기 서비스)는 이 큐의 데이터를 가져와서 공유 스토리지에 씁니다. 메시지 큐는 게시된 후 큐에 대기 중인 데이터가 손실되지 않도록 하는 데 도움이 되는 "한 번 이상" 의미 체계를 제공하기 때문에 이 시나리오에 적합합니다. 스토리지 쓰기 서비스는 별도의 작업자 역할을 사용하여 구현할 수 있습니다.

그림 4 - 큐를 사용하여 계측 데이터 버퍼링

로컬 데이터 수집 서비스는 수신 직후 큐에 데이터를 추가할 수 있습니다. 큐가 버퍼 역할을 하며 스토리지 쓰기 서비스가 고유한 속도로 데이터를 검색하고 쓸 수 있습니다. 기본적으로 큐는 선입선출 방식으로 작동합니다. 그러나 메시지의 우선 순위를 지정하여 더 빨리 처리해야 하는 데이터가 포함된 경우 큐를 통해 메시지를 가속화할 수 있습니다. 자세한 내용은 우선 순위 큐 패턴을 참조 하세요. 또는 다양한 채널(예: Service Bus 토픽)을 사용하여 필요한 분석 처리 형식에 따라 데이터를 다른 대상으로 보낼 수 있습니다.

확장성을 위해 스토리지 쓰기 서비스 인스턴스를 여러 개 실행할 수 있습니다. 고용량의 이벤트가 있는 경우 이벤트 허브를 사용하여 처리 및 스토리지을 위해 데이터를 다양한 컴퓨팅 리소스로 디스패치할 수 있습니다.

계측 데이터 통합

데이터 수집 서비스가 애플리케이션의 단일 인스턴스에서 검색하는 계측 데이터는 해당 인스턴스의 상태 및 성능에 대한 지역화된 보기를 제공합니다. 시스템의 전반적인 상태를 평가하려면 로컬 뷰에서 데이터의 일부 측면을 통합해야 합니다. 데이터가 저장된 후에는 이 작업을 수행할 수 있지만 경우에 따라 데이터가 수집될 때 이를 달성할 수도 있습니다. 계측 데이터는 공유 스토리지에 직접 기록되는 대신 데이터를 결합하고 필터 및 정리 프로세스 역할을 하는 별도의 데이터 통합 서비스를 통과할 수 있습니다. 예를 들어 활동 ID와 같은 상관 관계 정보를 포함하는 계측 데이터를 통합할 수 있습니다. (사용자가 하나의 노드에서 비즈니스 작업 수행을 시작한 후에 노드 장애 발생 시 또는 부하 분산 구성 방식에 따라 다른 노드로 전송하는 것이 가능합니다.) 이 프로세스는 중복된 데이터를 감지하고 제거할 수도 있습니다(원격 분석 서비스가 스토리지에서 계측 데이터를 밀어내는 데 메시지 큐를 사용하는 경우 항상 가능함). 그림 5에서는 이 구조체의 예를 보여 줍니다.

그림 5 - 별도 서비스를 사용하여 계측 데이터 통합 및 정리

계측 데이터 저장

이전 토론에서는 계측 데이터가 저장되는 방식에 대한 다소 단순한 보기를 설명했습니다. 실제로 각 형식을 사용할 수 있는 방식에 가장 적합한 기술을 사용하여 다양한 유형의 정보를 저장하는 것이 합리적일 수 있습니다.

예를 들어 Azure Blob 및 Table Storage에는 액세스하는 방식에서 몇 가지 유사점이 있습니다. 그러나 이를 사용하여 수행할 수 있는 작업에는 제한이 있으며 보유하는 데이터의 세분성은 매우 다릅니다. 더 많은 분석 작업을 수행하거나 데이터에 대한 전체 텍스트 검색 기능이 필요한 경우 특정 유형의 쿼리 및 데이터 액세스에 최적화된 기능을 제공하는 데이터 스토리지를 사용하는 것이 더 적합할 수 있습니다. 예시:

• 성능 카운터 데이터를 SQL 데이터베이스에 저장하여 임시 분석을 사용하도록 설정할 수 있습니다.
• 추적 로그는 Azure Cosmos DB에 더 잘 저장될 수 있습니다.
• 보안 정보는 HDFS에 기록할 수 있습니다.
• 전체 텍스트 검색이 필요한 정보는 Elasticsearch를 통해 저장할 수 있습니다(풍부한 인덱싱을 사용하여 검색 속도를 높일 수도 있습니다).

주기적으로 공유 스토리지, 파티션에서 데이터를 검색하고 목적에 따라 데이터를 필터링한 다음 그림 6에 나온 것처럼 적절한 데이터 스토리지 집합에 이 데이터를 쓰는 추가 서비스를 구현할 수 있습니다. 다른 방법은 이 기능을 통합 및 정리 프로세스에 포함하고 중간 공유 스토리지 영역에 저장하는 대신 검색될 때 이러한 저장소에 직접 데이터를 쓰는 것입니다. 각 접근 방식에는 장점과 단점이 있습니다. 별도의 분할 서비스를 구현하면 통합 및 정리 서비스의 부하가 줄어들고 필요한 경우(공유 스토리지에 보존되는 데이터의 양에 따라) 분할된 데이터 중 적어도 일부를 다시 생성할 수 있습니다. 그러나 추가 리소스를 사용합니다. 또한 각 애플리케이션 인스턴스에서 계측 데이터를 수신하고 이 데이터를 실행 가능한 정보로 변환하는 사이에 지연이 있을 수 있습니다.

그림 6 - 분석 및 스토리지 요구 사항에 따라 데이터 분할

둘 이상의 용도에 동일한 계측 데이터가 필요할 수 있습니다. 예를 들어 성능 카운터를 사용하여 시간 경과에 따른 시스템 성능의 기록 보기를 제공할 수 있습니다. 이 정보는 고객 청구 정보를 생성하기 위해 다른 사용량 현황 데이터와 결합될 수 있습니다. 이러한 상황에서는 청구 정보를 보유하기 위한 장기 저장소 역할을 할 수 있는 문서 데이터베이스와 복잡한 성능 분석을 처리하기 위한 다차원 저장소와 같은 동일한 데이터를 둘 이상의 대상으로 보낼 수 있습니다.

또한 데이터가 얼마나 긴급하게 필요한지 고려해야 합니다. 경고용 정보를 제공하는 데이터는 신속하게 액세스할 수 있어야 하므로 빠른 데이터 스토리지에 보관하고 경고 시스템이 수행하는 쿼리를 최적화할 수 있게 인덱싱하거나 구조화해야 합니다. 경우에 따라 각 노드의 데이터를 수집하는 원격 분석 서비스가 경고 시스템의 로컬 인스턴스가 문제를 신속하게 알릴 수 있도록 데이터의 형식을 지정하고 로컬로 저장해야 할 수 있습니다. 이전 다이어그램에 표시된 스토리지 쓰기 서비스로 동일한 데이터를 디스패치하고 다른 용도로도 필요한 경우 중앙에 저장할 수 있습니다.

보다 고려된 분석, 보고 및 기록 추세를 파악하는 데 사용되는 정보는 덜 시급하며 데이터 마이닝 및 임시 쿼리를 지원하는 방식으로 저장할 수 있습니다. 자세한 내용은 이 문서의 뒷부분에 있는 핫, 웜 및 콜드 분석 지원 섹션 을 참조하세요.

로그 회전 및 데이터 보존

계측은 상당한 양의 데이터를 생성할 수 있습니다. 이 데이터는 원시 로그 파일, 추적 파일 및 각 노드에서 캡처된 기타 정보부터 공유 스토리지에 보관된 이 데이터의 통합, 정리 및 분할된 뷰로 시작하는 여러 위치에 보관할 수 있습니다. 경우에 따라 데이터가 처리 및 전송된 후 각 노드에서 원래 원시 원본 데이터를 제거할 수 있습니다. 다른 경우에는 원시 정보를 저장해야 하거나 저장해 두면 유용할 수 있습니다. 예를 들어 디버깅을 위해 생성된 데이터는 원시 형식으로 제공되는 것이 가장 좋을 수 있지만 버그가 수정된 후 신속하게 삭제할 수 있습니다.

성능 데이터는 비교적 수명이 길게 유지되므로 성능 추세를 발견하고 용량을 계획하는 데 사용될 수 있습니다. 이 데이터의 통합 보기는 일반적으로 빠른 액세스를 가능하게 하기 위해 한정된 기간 동안 온라인으로 유지됩니다. 그 후에는 보관하거나 삭제할 수 있습니다. 계량 및 청구 고객을 위해 수집된 데이터는 무기한 저장해야 할 수 있습니다. 또한 규정 요구 사항에 따라 감사 및 보안 목적으로 수집된 정보도 보관하고 저장해야 합니다. 또한 이 데이터는 중요하며 변조를 방지하기 위해 암호화하거나 보호해야 할 수도 있습니다. 사용자 암호 또는 ID 사기에 사용될 수 있는 기타 정보는 절대로 기록해서는 안 됩니다. 이러한 세부 정보는 저장되기 전에 데이터에서 삭제해야 합니다.

다운 샘플링

장기 추세를 발견할 수 있도록 기록 데이터를 저장하는 것이 유용합니다. 이전 데이터를 전체적으로 저장하는 대신 데이터를 다운 샘플링하여 해상도를 줄이고 스토리지 비용을 절감할 수 있습니다. 예를 들어 분별 성능 지표를 저장하는 대신 한 달이 지난 데이터를 통합하여 시간별 보기를 구성할 수 있습니다.

로깅 정보 수집 및 저장 모범 사례

다음은 로깅 정보를 캡처하고 저장하기 위한 모범 사례를 요약한 목록입니다.

• 모니터링 에이전트 또는 데이터 수집 서비스는 Out-of-process 서비스로 실행되어야 하며 배포가 간단해야 합니다.

• 모니터링 에이전트 또는 데이터 수집 서비스의 모든 출력은 컴퓨터, 운영 체제 또는 네트워크 프로토콜과 독립적인 독립적인 형식이어야 합니다. 예를 들어 ETL/ETW가 아닌 JSON, MessagePack 또는 Protobuf와 같은 자체 설명 형식으로 정보를 내보냅니다. 표준 형식을 사용하면 시스템에서 처리 파이프라인을 생성할 수 있으며 합의된 형식으로 데이터를 읽고 변환하고 전송하는 구성 요소를 쉽게 통합할 수 있습니다.

• 모니터링 및 데이터 수집 프로세스는 장애 조치(fail-safe)여야 하며 연속 오류 조건을 트리거해서는 안 됩니다.

• 데이터 싱크에 정보를 전송하는 동안 일시적인 오류가 발생하는 경우 모니터링 에이전트 또는 데이터 수집 서비스는 최신 정보가 먼저 전송되도록 원격 분석 데이터의 순서를 다시 정렬하도록 준비해야 합니다. (모니터링 에이전트/데이터 수집 서비스는 이전 데이터를 삭제하거나 로컬로 저장하고 나중에 자신의 재량에 따라 따라잡기 위해 전송하도록 선택할 수 있습니다.)

데이터 분석 및 문제 진단

모니터링 및 진단 프로세스의 중요한 부분은 수집된 데이터를 분석하여 시스템의 전반적인 복지를 파악하는 것입니다. 사용자 고유의 KPI 및 성능 메트릭을 정의해야 하며, 분석 요구 사항을 충족하기 위해 수집된 데이터를 구성하는 방법을 이해하는 것이 중요합니다. 다양한 메트릭과 로그 파일에서 캡처한 데이터는 이벤트 시퀀스를 추적하는 데 있어서 키가 될 수 있고 발생하는 문제를 진단하는 데에도 유용하므로 이 데이터의 상관 관계를 설정하는 방법을 이해하는 것도 중요합니다.

계측 데이터 통합 섹션에 설명된 대로 시스템의 각 부분에 대한 데이터는 일반적으로 로컬로 캡처되지만 일반적으로 시스템에 참여하는 다른 사이트에서 생성된 데이터와 결합되어야 합니다. 이 정보를 사용하려면 데이터가 정확하게 결합되도록 신중한 상관 관계가 필요합니다. 예를 들어 작업에 대한 사용량 현황 데이터는 사용자가 연결하는 웹 사이트를 호스트하는 노드, 이 작업의 일부로 액세스된 별도의 서비스를 실행하는 노드 및 다른 노드에 보관된 데이터 스토리지에 걸쳐 있을 수 있습니다. 작업에 대한 리소스 및 처리 사용량에 대한 전체 보기를 제공하려면 이 정보를 함께 연결해야 합니다. 데이터가 캡처된 노드에서 일부 데이터 사전 처리 및 필터링이 발생할 수 있으며, 중앙 노드에서는 집계 및 형식 지정이 발생할 가능성이 높습니다.

핫, 웜, 콜드 분석 지원

시각화, 보고 및 경고 목적으로 데이터를 분석하고 다시 포맷하는 것은 자체 리소스 집합을 사용하는 복잡한 프로세스일 수 있습니다. 일부 형태의 모니터링은 시간이 중요하며 데이터를 즉시 분석해야 효과적입니다. 이를 핫 분석이라고 합니다. 예를 들어 경고에 필요한 분석과 보안 모니터링의 일부 측면(예: 시스템에 대한 공격 검색)이 있습니다. 이러한 용도에 필요한 데이터는 효율적인 처리를 위해 신속하게 사용할 수 있고 구조화되어야 합니다. 경우에 따라 분석 처리를 데이터가 보관된 개별 노드로 이동해야 할 수 있습니다.

다른 형태의 분석은 시간이 덜 중요하며 원시 데이터를 받은 후 일부 계산 및 집계가 필요할 수 있습니다. 이를 웜 분석이라고 합니다. 성능 분석은 종종 이 범주에 속합니다. 이 경우 격리된 단일 성능 이벤트는 통계적으로 유의하지 않을 수 있습니다. (급격한 변동이나 결함으로 인해 발생할 수 있습니다.) 일련의 이벤트에서 나온 데이터는 시스템 성능에 대해 신뢰성 높은 보기를 제공해야 합니다.

웜 분석은 또한 건강 문제를 진단하는 데 도움이 될 수 있습니다. 상태 이벤트는 일반적으로 핫 분석을 통해 처리되며 즉시 경고를 발생할 수 있습니다. 연산자는 웜 경로에서 데이터를 검사하여 상태 이벤트의 원인을 자세히 살펴볼 수 있어야 합니다. 이 데이터에는 상태 이벤트를 발생시킨 문제로 이어지는 이벤트에 대한 정보가 포함되어야 합니다.

일부 유형의 모니터링은 더 많은 장기 데이터를 생성합니다. 나중에 미리 정의된 일정에 따라 이 분석을 수행할 수 있습니다. 일부 경우에는 분석에서 일정 기간 동안 캡처된 대용량 데이터에 대해 복잡한 필터링을 수행해야 할 수도 있습니다. 이를 콜드 분석이라고 합니다. 주요 요구 사항은 데이터가 캡처된 후 안전하게 저장된다는 것입니다. 예를 들어 사용 모니터링 및 감사에는 정기적인 시점의 시스템 상태를 정확히 파악할 수 있는 보기가 필요합니다. 그러나 이러한 상태 정보는 수집된 후에 즉시 제공되어야 할 필요는 없습니다.

연산자는 콜드 분석을 사용하여 예측 상태 분석을 위한 데이터를 제공할 수도 있습니다. 운영자는 지정된 기간에 걸쳐 기록 정보를 수집하고 사용하여 현재 상태 데이터(핫 경로에서 검색)와 함께 사용하여 곧 상태 문제를 일으킬 수 있는 추세를 발견할 수 있습니다. 이러한 경우 수정 작업을 수행할 수 있도록 경고를 발생시키는 것이 필요할 수 있습니다.

데이터 상관 관계 설정

계측 캡처하는 데이터는 시스템 상태의 스냅샷을 제공할 수 있지만 분석의 목적은 이 데이터를 실행 가능하게 만드는 것입니다. 예시:

• 특정 시간에 시스템 수준에서 강렬한 I/O 로드가 발생한 원인은 무엇인가요?
• 많은 수의 데이터베이스 작업의 결과인가요?
• 이 결과가 데이터베이스 응답 시간, 초당 트랜잭션 수, 동일한 지점의 애플리케이션 응답 시간 등에 반영되나요?

그렇다면 부하를 줄일 수 있는 한 가지 수정 작업은 더 많은 서버에 데이터를 분할하는 것일 수 있습니다. 또한 시스템 어느 수준에서나 장애로 인해 예외가 발생할 수 있습니다. 한 수준의 예외는 종종 위의 수준에서 다른 오류를 트리거합니다.

이러한 이유로 인해 각 수준에서 다양한 유형의 모니터링 데이터의 상관 관계를 설정하여 시스템 및 시스템에서 실행되는 애플리케이션의 상태에 대한 전체 보기를 제공할 수 있어야 합니다. 그런 다음 이 정보를 사용하여 시스템이 수락할 수 있는지 여부를 결정하고 시스템의 품질을 개선하기 위해 수행할 수 있는 작업을 결정할 수 있습니다.

데이터 상관 관계를 지정하기 위한 정보 섹션에 설명된 대로 원시 계측 데이터에 이벤트 상관 관계에 필요한 집계를 지원하기에 충분한 컨텍스트 및 활동 ID 정보가 포함되어 있는지 확인해야 합니다. 또한 이 데이터는 다양한 형식으로 보관할 수 있으며 분석을 위해 표준화된 형식으로 변환하려면 이 정보를 구문 분석해야 할 수도 있습니다.

문제 해결 및 문제 진단

진단에는 근본 원인 분석 수행을 포함하여 오류 또는 예기치 않은 동작의 원인을 확인하는 기능이 필요합니다. 필요한 정보에는 일반적으로 다음이 포함됩니다.

• 지정된 기간 동안 전체 시스템 또는 지정된 하위 시스템에 대한 이벤트 로그 및 추적의 자세한 정보입니다.
• 지정된 기간 동안 시스템 또는 지정된 하위 시스템 내부에서 발생하는 특정 수준의 예외 및 장애에서 발생한 전체 스택 추적
• 시스템 내 어느 곳에서나 또는 지정된 기간 동안 지정된 하위 시스템에 대해 실패한 프로세스에 대한 크래시 덤프입니다.
• 지정된 기간 동안 모든 사용자가 수행하거나 일부 선택된 사용자를 위해 수행되는 작업을 기록하는 활동 로그

문제 해결을 위해 데이터를 분석하려면 시스템 아키텍처 및 솔루션을 구성하는 다양한 구성 요소에 대한 심층적인 기술적 이해가 필요한 경우가 많습니다. 따라서 데이터를 해석하고, 문제의 원인을 설정하고, 문제를 해결하기 위한 적절한 전략을 권장하기 위해 많은 수동 개입이 필요한 경우가 많습니다. 이 정보의 복사본을 원래 형식으로 저장하고 전문가의 콜드 분석에 사용할 수 있도록 하는 것이 적절할 수 있습니다.

데이터 시각화 및 경고 발생

모니터링 시스템의 중요한 측면은 운영자가 추세 또는 문제를 신속하게 발견할 수 있는 방식으로 데이터를 표시하는 기능입니다. 또한 주의가 필요할 수 있는 중요한 이벤트가 발생한 경우 운영자에게 신속하게 알릴 수 있는 기능도 중요합니다.

데이터 프레젠테이션은 대시보드, 경고 및 보고를 사용하여 시각화를 포함하여 여러 가지 형태를 취할 수 있습니다.

대시보드를 사용하여 시각화

데이터를 시각화하는 가장 일반적인 방법은 정보를 일련의 차트, 그래프 또는 기타 그림으로 표시할 수 있는 대시보드를 사용하는 것입니다. 이러한 항목은 매개 변수화할 수 있으며 분석가는 특정 상황에서 중요한 매개 변수(예: 기간)를 선택할 수 있어야 합니다.

대시보드는 계층적으로 구성할 수 있습니다. 최상위 대시보드가 시스템의 각 측면에 대한 전체 보기를 제공할 수 있지만 운영자의 세부 정보 드릴 다운을 지원하는 기능을 포함합니다. 예를 들어 시스템의 전체 디스크 I/O를 보여 주는 대시보드를 사용하면 분석가가 각 개별 디스크에 대한 I/O 속도를 확인하여 하나 이상의 특정 디바이스가 불균형한 트래픽 볼륨을 차지하는지 여부를 확인할 수 있습니다. 이 I/O를 생성하는 각 요청의 원본(사용자 또는 활동)과 같은 관련 정보도 대시보드에 표시하는 것이 좋습니다. 그러면 이 정보를 사용하여 여러 디바이스에서 부하를 더 균등하게 분산할지 여부(및 방법)와 디바이스가 추가되면 시스템 성능이 향상될지 여부를 결정할 수 있습니다.

대시보드는 색 코딩 또는 기타 시각적 신호를 사용하여 비정상으로 표시되거나 예상 범위를 벗어난 값을 나타낼 수도 있습니다. 이전 예제에서는 다음과 같이 사용되었습니다.

• 연장된 기간(핫 디스크)에 대한 최대 용량에 근접하는 I/O 속도가 있는 디스크를 빨간색으로 강조 표시할 수 있습니다.
• I/O 속도가 짧은 기간(웜 디스크)에 대한 최대 한도에서 주기적으로 실행되는 디스크는 노란색으로 강조 표시될 수 있습니다.
• 일반적인 사용량을 나타내는 디스크는 녹색으로 표시될 수 있습니다.

대시보드 시스템이 효과적으로 작동하려면 작업할 원시 데이터가 있어야 합니다. 고유한 대시보드 시스템을 빌드하거나 다른 조직에서 개발한 대시보드를 사용하는 경우 수집해야 하는 계측 데이터, 세분성 수준 및 대시보드에서 사용할 형식을 지정하는 방법을 이해해야 합니다.

좋은 대시보드는 정보를 표시하는 것에만 그치지 않고 분석가가 해당 정보에 대한 임시 질문도 할 수 있습니다. 일부 시스템에서는 운영자가 이러한 작업을 수행하고 기본 데이터를 탐색하는 데 사용할 수 있는 관리 도구를 제공합니다. 또는 이 정보를 보관하는 데 사용되는 리포지토리에 따라 이 데이터를 직접 쿼리할 수도 있고 아니면 추가 분석 및 보고를 위해 이 데이터를 Microsoft Excel과 같은 도구로 가져올 수도 있습니다.

경고 발생

경고는 계측 데이터를 분석 및 모니터링하고 중대한 이벤트가 감지되는 경우 알림을 생성하는 프로세스입니다.

경고는 시스템이 정상, 응답성 및 보안을 유지할 수 있도록 합니다. 경고는 모든 시스템에서 성능, 가용성, 개인 정보 보호를 보장하는 중요한 부분이며 해당 데이터에 대해 즉시 조치를 취해야 할 수 있습니다. 운영자는 경고를 트리거한 이벤트에 대한 알림을 받아야 할 수 있습니다. 경고는 자동 크기 조정과 같은 시스템 함수를 호출하는 데 사용할 수도 있습니다.

경고는 일반적으로 다음 계측 데이터에 따라 달라집니다.

• 보안 이벤트입니다. 이벤트 로그에 반복되는 인증 또는 권한 부여 실패가 발생하는 것으로 표시되면 시스템이 공격을 받고 있을 수 있으며 운영자에게 알려야 합니다.
• 성능 메트릭 특정 성능 메트릭이 지정된 임계값을 초과하는 경우 시스템은 신속하게 응답해야 합니다.
• 가용성 정보. 오류가 감지되면 하나 이상의 하위 시스템을 신속하게 다시 시작하거나 백업 리소스로 장애 조치(failover)해야 할 수 있습니다. 하위 시스템에서 발생하는 반복적인 장애는 보다 심각한 문제를 나타낼 수 있습니다.

운영자는 전자 메일, 호출기 디바이스 또는 SMS 문자 메시지와 같은 많은 배달 채널을 사용하여 경고 정보를 받을 수 있습니다. 경고에는 상황이 얼마나 중요한지를 나타내는 표시가 포함될 수도 있습니다. 많은 경고 시스템은 구독자 그룹을 지원하며, 동일한 그룹의 멤버인 모든 운영자는 동일한 경고 집합을 받을 수 있습니다.

경고 시스템은 사용자 지정할 수 있어야 하며 기본 계측 데이터의 적절한 값을 매개 변수로 제공할 수 있습니다. 이렇게 하면 운영자가 데이터를 필터링하여 관심 있는 임계값이나 값 조합에 초점을 맞출 수 있습니다. 경우에 따라 원시 계측 데이터를 경고 시스템에 제공할 수 있습니다. 다른 상황에서는 집계된 데이터를 제공하는 것이 더 적절할 수 있습니다. 예를 들어 노드의 CPU 사용률이 지난 10분 동안 90%를 초과하면 경고를 트리거할 수 있습니다. 경고 시스템에 제공된 세부 정보에는 적절한 요약 및 컨텍스트 정보도 포함되어야 합니다. 이 데이터는 가양성 이벤트가 경고를 발생시킬 가능성을 줄이는 데 도움이 될 수 있습니다.

보고

보고는 시스템의 전체 보기를 생성하는 데 사용됩니다. 현재 정보 외에도 기록 데이터를 통합할 수 있습니다. 보고 요구 사항 자체는 운영 보고 및 보안 보고라는 두 가지 광범위한 범주에 속합니다.

운영 보고에는 일반적으로 다음과 같은 측면이 포함됩니다.

• 지정된 기간 동안 전체 시스템 또는 지정된 하위 시스템의 리소스 사용률을 이해하는 데 사용할 수 있는 집계 통계입니다.
• 지정된 기간 동안 전체 시스템 또는 지정된 하위 시스템의 리소스 사용 추세를 식별합니다.
• 지정된 기간 동안 시스템 전체 또는 지정된 하위 시스템에서 발생한 예외를 모니터링합니다.
• 배포된 리소스 측면에서 애플리케이션의 효율성을 결정하고, 불필요하게 성능에 영향을 주지 않고 리소스 볼륨(및 관련 비용)을 줄일 수 있는지 여부를 이해합니다.

보안 보고는 고객의 시스템 사용 추적과 관련이 있습니다. 여기에는 다음이 포함될 수 있습니다.

• 사용자 작업 감사 이렇게 하려면 각 사용자가 수행하는 개별 요청을 날짜 및 시간과 함께 기록해야 합니다. 지정된 기간 동안 사용자가 수행하는 작업 시퀀스를 관리자가 신속하게 재구성할 수 있도록 데이터를 구조화해야 합니다.
• 사용자별 리소스 사용 추적 이렇게 하려면 사용자에 대한 각 요청이 시스템을 구성하는 다양한 리소스에 액세스하는 방법과 기간 동안 기록해야 합니다. 관리자는 이 데이터를 사용하여 (예: 청구 목적으로) 지정된 기간 동안 사용자에 대한 사용률 보고서를 생성할 수 있어야 합니다.

대부분의 경우 정의된 일정에 따라 일괄 처리 프로세스에서 보고서를 생성할 수 있습니다. (대기 시간은 일반적으로 문제가 아닙니다.) 하지만 필요한 경우 임시로 생성할 수도 있어야 합니다. 예를 들어 Azure SQL Database와 같은 관계형 데이터베이스에 데이터를 저장하는 경우 SQL Server Reporting Services와 같은 도구를 통해 데이터를 추출하여 형식을 지정하고 이를 일련의 보고서로 제공할 수 있습니다.

다음 단계

• Azure Monitor 개요
• Microsoft Azure Storage 모니터링, 진단 및 문제 해결
• Microsoft Azure의 경고 개요
• Azure Portal을 사용하여 서비스 상태 알림 보기
• Application Insights란?
• Azure 가상 머신의 성능 진단
• Visual Studio용 SSDT(SQL Server Data Tools) 다운로드 및 설치

관련 참고 자료

• 자동 크기 조정 지침 은 운영자가 시스템의 성능을 지속적으로 모니터링하고 리소스 추가 또는 제거에 대한 결정을 내릴 필요성을 줄여 관리 오버헤드를 줄이는 방법을 설명합니다.
• 상태 엔드포인트 모니터링 패턴에서는 외부 도구가 노출된 엔드포인트를 통해 정기적인 간격으로 액세스할 수 있는 기능 검사를 애플리케이션 내부에 구현하는 방법을 설명합니다.
• 우선 순위 큐 패턴 은 긴급 요청을 수신하고 덜 긴급한 메시지 전에 처리할 수 있도록 큐에 대기 중인 메시지의 우선 순위를 지정하는 방법을 보여 줍니다.