모니터링 시스템 디자인 및 만들기에 대한 권장 사항

이 Azure Well-Architected Framework 운영 우수성 검사 목록 권장 사항에 적용됩니다.

OE:07	모니터링 시스템을 설계 및 구현하여 디자인 선택 사항의 유효성을 검사하고 향후 디자인 및 비즈니스 결정을 알릴 수 있습니다. 이 시스템은 워크로드의 인프라 및 코드에서 내보내는 운영 원격 분석, 메트릭 및 로그를 캡처하고 노출합니다.

관련 가이드: 애플리케이션 계측을 위한 권장 사항

이 가이드에서는 모니터링 시스템을 디자인하고 만들기 위한 권장 사항을 설명합니다. 보안, 성능 및 안정성을 위해 워크로드를 효과적으로 모니터링하려면 모든 모니터링, 검색 및 경고 기능에 대한 기초를 제공하는 자체 스택이 있는 포괄적인 시스템이 필요합니다.

정의

용어	정의
로그	기록된 시스템 이벤트입니다. 로그는 구조화된 텍스트 형식 또는 자유 형식 텍스트 형식의 다양한 형식의 데이터를 포함할 수 있습니다. 타임스탬프가 포함됩니다.
metrics	정기적으로 수집되는 숫자 값입니다. 메트릭은 특정 시간에 시스템의 일부 측면을 설명합니다.

주요 디자인 전략

워크로드에 대한 포괄적인 모니터링 시스템 디자인을 구현하려면 다음 핵심 구성 요소에 따릅니다.

• 실용적일 때마다 플랫폼 제공 모니터링 도구를 활용합니다. 이 도구는 일반적으로 구성이 거의 필요하지 않으며 워크로드에 대한 심층적인 인사이트를 제공할 수 있으며, 그렇지 않으면 수행하기 어려울 수 있습니다.

• 전체 워크로드 스택에서 로그 및 메트릭을 수집합니다. 모든 인프라 리소스 및 애플리케이션 함수는 표준화되고 의미 있는 데이터를 생성하도록 구성되어야 하며 해당 데이터를 수집해야 합니다.

• 수집된 데이터를 표준화되고 안정적이며 안전한 스토리지 솔루션에 저장합니다.

• 저장된 데이터를 처리하여 분석 및 시각화 솔루션에서 처리할 수 있습니다.

• 처리된 데이터를 분석하여 워크로드 상태를 정확하게 확인합니다.

• 워크로드 팀 및 기타 이해 관계자에 대한 의미 있는 대시보드 또는 보고서에서 워크로드 상태를 시각화합니다.

• 문제가 발생할 때 워크로드 팀에 알리도록 지능적으로 정의된 임계값에 대한 실행 가능한 경고 및 기타 자동 응답을 구성합니다.

• 전반적인 워크로드 테스트 사례에 모니터링 및 경고 시스템을 포함합니다.

• 지속적인 개선을 위해 모니터링 및 경고 시스템이 scope 있는지 확인합니다. 프로덕션의 애플리케이션 및 인프라 동작은 지속적인 학습 기회를 제공합니다. 이러한 단원을 모니터링 및 경고 디자인에 통합합니다.

• 수집하고 분석하는 모니터링 데이터를 시스템 및 사용자 흐름에 연결하여 워크로드의 전반적인 상태 외에도 흐름의 상태를 데이터와 상호 연결합니다. 흐름 측면에서 해당 데이터를 분석하면 가시성 전략을 상태 모델에 맞추는 데 도움이 됩니다.

모니터링 시스템의 모든 기능을 가능한 한 자동화해야 하며, 모든 기능이 하루 종일 지속적으로 실행되어야 합니다.

이 워크플로 파이프라인은 모니터링 시스템을 보여 줍니다.

컬렉션

참고

로깅을 사용하도록 설정하려면 애플리케이션을 계측해야 합니다. 자세한 내용은 계측 가이드를 참조하세요.

인프라 리소스 또는 애플리케이션 함수에 관계없이 모든 워크로드 구성 요소를 구성하여 원격 분석 및/또는 로그 및 메트릭과 같은 이벤트를 캡처해야 합니다.

로그는 변칙을 검색하고 조사하는 데 주로 유용합니다. 일반적으로 로그는 워크로드 구성 요소에 의해 생성된 다음 모니터링 플랫폼으로 전송되거나 자동화를 통해 모니터링 플랫폼에서 가져옵니다.

메트릭은 주로 상태 모델을 빌드 하고 워크로드 성능 및 안정성의 추세를 식별하는 데 유용합니다. 메트릭은 고객의 사용 동작 추세를 식별하는 데에도 유용합니다. 이러한 추세는 고객 관점에서 개선 사항에 대한 의사 결정을 안내하는 데 도움이 될 수 있습니다. 일반적으로 메트릭은 모니터링 플랫폼에 정의되며 모니터링 플랫폼 및 기타 도구는 워크로드를 폴링하여 메트릭을 캡처합니다.

애플리케이션 데이터

애플리케이션의 경우 수집 서비스는 계측 데이터를 생성하는 애플리케이션에서 자율적으로 실행할 수 있는 APM(애플리케이션 성능 관리) 도구일 수 있습니다. APM을 사용하도록 설정한 후에는 실시간 및 역사적으로 중요한 메트릭을 명확하게 파악할 수 있습니다. 적절한 수준의 로깅을 사용합니다. 자세한 로깅에는 상당한 비용이 발생할 수 있습니다. 환경에 따라 로그 수준을 설정합니다. 예를 들어, 낮은 환경은 프로덕션과 동일한 수준의 세부 정보를 필요로 하지 않습니다.

애플리케이션 로그는 엔드투엔드 애플리케이션 수명 주기를 지원합니다. 로깅은 애플리케이션이 다양한 환경에서 작동하는 방식, 발생하는 이벤트 및 발생하는 조건을 이해하는 데 필수적입니다.

모든 주요 환경에서 애플리케이션 로그 및 이벤트를 수집하는 것이 좋습니다. 실제적인 경우 각 환경에 대해 서로 다른 데이터 저장소를 사용하여 가능한 한 환경 간에 데이터를 분리합니다. 필터를 사용하여 비임계 환경이 프로덕션 로그의 해석을 복잡하게 만들지 않도록 합니다. 마지막으로 애플리케이션 전체의 해당 로그 항목은 해당 트랜잭션에 대한 상관 관계 ID를 캡처해야 합니다.

구조화되지 않은 문자열 형식이 아닌 컴퓨터에서 읽을 수 있는 데이터 요소를 사용하여 구조화된 데이터 형식으로 애플리케이션 이벤트를 캡처해야 합니다. 잘 알려진 스키마를 사용하는 구조화된 형식을 사용하면 로그를 더 쉽게 구문 분석하고 분석할 수 있습니다. 또한 구조화된 데이터를 쉽게 인덱싱하고 검색할 수 있으며 보고가 크게 간소화될 수 있습니다.

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

인프라 데이터

워크로드의 인프라 리소스의 경우 로그와 메트릭을 모두 수집해야 합니다. IaaS(Infrastructure as a Service) 시스템의 경우 워크로드 상태와 관련된 메트릭 외에도 OS, 애플리케이션 계층 및 진단 로그를 캡처합니다. PaaS(Platform as a Service) 리소스의 경우 기본 인프라와 관련된 로그를 캡처하는 기능이 제한될 수 있지만 워크로드 상태와 관련된 메트릭 외에 진단 로그를 캡처할 수 있어야 합니다.

가능한 한 클라우드 플랫폼에서 로그를 수집합니다. 관리 평면에 대한 구독 및 진단 로그에 대한 활동 로그를 수집할 수 있습니다.

컬렉션 전략

모든 구성 요소에서 수동으로 원격 분석 데이터를 검색하지 마세요. 중앙 위치로 데이터를 이동하고 해당 위치로 통합합니다. 다중 지역 솔루션의 경우 먼저 지역별로 데이터를 수집, 통합 및 저장한 다음 지역 데이터를 단일 중앙 시스템으로 집계하는 것이 좋습니다.

절충: 지역 및 중앙 집중식 데이터 저장소를 보유하는 데 비용 영향이 있다는 점에 유의하세요.

대역폭 사용을 최적화하려면 데이터의 중요도에 따라 우선 순위를 지정합니다. 덜 긴급한 데이터를 일괄 전송할 수 있습니다. 그러나 특히 시간에 민감한 정보가 포함된 경우 이 데이터를 무기한으로 지연해서는 안 됩니다.

컬렉션 서비스에서 계측 데이터를 수집하는 데 사용할 수 있는 두 가지 기본 모델이 있습니다.

• 끌어오기 모델: 애플리케이션의 각 instance 대한 다양한 로그 및 기타 원본에서 데이터를 적극적으로 검색합니다.

• 푸시 모델: 애플리케이션의 각 instance 구성하는 구성 요소에서 데이터가 전송될 때까지 수동적으로 기다립니다.

모니터링 에이전트

끌어오기 모델에서 모니터링 에이전트를 사용할 수 있습니다. 에이전트는 애플리케이션의 각 instance 있는 별도의 프로세스에서 로컬로 실행되어 주기적으로 데이터를 끌어와 애플리케이션의 모든 인스턴스에서 공유하는 일반 스토리지에 직접 정보를 기록합니다.

참고

모니터링 에이전트를 사용하는 것은 자연스럽게 데이터 원본에서 끌어온 계측 데이터를 캡처하는 데 가장 적합합니다. 단일 위치에 있는 제한된 수의 노드에서 실행되는 소규모 애플리케이션에 적합합니다. 예를 들어 SQL Server 동적 관리 뷰의 정보 또는 Azure Service Bus 큐의 길이가 있습니다.

성능 고려 사항

복잡하고 확장성이 뛰어난 애플리케이션은 대량의 데이터를 생성할 수 있습니다. 데이터의 양은 단일 중앙 위치에 사용할 수 있는 I/O 대역폭을 쉽게 압도할 수 있습니다. 원격 분석 솔루션은 병목 현상이 되어서는 안 되며 시스템 확장에 따라 확장 가능해야 합니다. 이상적으로 솔루션은 시스템의 일부가 실패할 경우 중요한 모니터링 정보(예: 감사 또는 청구 데이터)를 잃을 위험을 줄이기 위해 어느 정도의 중복성을 통합해야 합니다.

계측 데이터를 버퍼링하는 한 가지 방법은 큐를 사용하는 것입니다.

이 아키텍처에서 데이터 컬렉션 서비스는 데이터를 큐에 게시합니다. 메시지 큐는 게시 후 큐에 대기 중인 데이터가 손실되지 않도록 하는 데 도움이 되는 "한 번 이상" 의미 체계를 제공하기 때문에 적합합니다. 별도의 작업자 역할을 사용하여 스토리지 쓰기 서비스를 구현할 수 있습니다. 우선 순위 큐 패턴을 사용하여 이 아키텍처를 구현할 수 있습니다.

확장성을 위해 스토리지 쓰기 서비스의 여러 인스턴스를 실행할 수 있습니다. 많은 양의 이벤트 또는 많은 수의 데이터 요소가 모니터링되는 경우 Azure Event Hubs 사용하여 처리 및 스토리지를 위해 데이터를 다른 컴퓨팅 instance 디스패치할 수 있습니다.

통합 전략

애플리케이션의 단일 instance 수집된 데이터는 해당 instance 상태 및 성능에 대한 지역화된 보기를 제공합니다. 시스템의 전반적인 상태를 평가하려면 로컬 뷰에서 데이터의 일부 측면을 통합해야 합니다. 데이터를 저장한 후에는 이 작업을 수행할 수 있지만 경우에 따라 데이터가 수집될 때 수행할 수 있습니다.

계측 데이터는 데이터를 결합하고 필터 및 정리 프로세스 역할을 하는 별도의 데이터 통합 서비스를 통과할 수 있습니다. 예를 들어 활동 ID와 같은 동일한 상관 관계 정보를 포함하는 계측 데이터를 통합할 수 있습니다. (사용자가 한 노드에서 비즈니스 작업을 시작한 다음 첫 번째 노드가 실패하거나 부하 분산이 구성된 방식 때문에 다른 노드로 전송될 수 있습니다.) 이 프로세스는 중복된 데이터를 검색하고 제거할 수도 있습니다. (원격 분석 서비스가 메시지 큐를 사용하여 계측 데이터를 스토리지로 푸시하는 경우 중복이 발생할 수 있습니다.)

스토리지

스토리지 솔루션을 선택할 때 데이터 형식, 사용 방법 및 긴급하게 필요한 방법을 고려합니다.

참고

비프로덕션 및 프로덕션 환경에 별도의 스토리지 솔루션을 사용하여 각 환경의 데이터를 쉽게 식별하고 관리할 수 있도록 합니다.

스토리지 기술

각 형식이 사용될 가능성이 가장 높은 기술에 다양한 유형의 정보가 저장되는 다각형 지속성 접근 방식을 고려합니다.

예를 들어 Azure Blob Storage 및 Azure Table Storage는 비슷한 방식으로 액세스됩니다. 그러나 수행할 수 있는 작업은 보유하는 데이터의 세분성과 마찬가지로 다릅니다. 자세한 분석 작업을 수행해야 하거나 데이터에 대한 전체 텍스트 검색 기능이 필요한 경우에는 특정 유형의 쿼리 및 데이터 액세스에 최적화된 기능을 제공하는 데이터 스토리지를 사용하는 것이 더 적합할 수 있습니다. 예를 들면 다음과 같습니다.

• 성능 카운터 데이터는 SQL 데이터베이스에 저장하여 임시 분석을 가능하도록 만들 수 있습니다.

• 추적 로그를 Azure Monitor 로그 또는 Azure Data Explorer 저장하는 것이 더 좋을 수 있습니다.

• HDFS 솔루션에 보안 정보를 저장할 수 있습니다.

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

리소스 잠금 및 일시 삭제와 같이 실수로 삭제되지 않도록 데이터를 보호하는 기능을 사용하도록 설정해야 합니다.

또한 역할 기반 액세스 제어를 사용하여 스토리지에 대한 액세스를 보호하여 데이터에 액세스해야 하는 개인만 액세스할 수 있도록 해야 합니다.

통합 서비스

공유 스토리지에서 데이터를 주기적으로 검색하고, 파티션을 만들고, 용도에 따라 필터링한 다음, 적절한 데이터 저장소 집합에 쓰는 다른 서비스를 구현할 수 있습니다.

이 접근 방식 대신, 이 기능을 통합 및 정리 프로세스에 포함하고 데이터를 중간 공유 스토리지 영역에 저장하지 않고 검색되면 바로 이 스토리지에 쓰는 방법을 택할 수도 있습니다.

각 접근 방식은 모두 장점과 단점이 있습니다. 별도의 분할 서비스를 구현하면 통합 및 정리 서비스의 부하가 줄어들고 필요한 경우(공유 스토리지에 보존되는 데이터의 양에 따라) 분할된 데이터 중 적어도 일부를 다시 생성할 수 있습니다. 그러나 이 방법은 추가 리소스를 사용합니다. 또한 계측 데이터가 각 애플리케이션 인스턴스에서 검색되는 시점과 이 데이터가 조치 가능한 정보로 변환되는 시점 사이에 지연이 발생할 수 있습니다.

쿼리 고려 사항

데이터가 얼마나 시급하게 필요한지 고려합니다. 경고를 생성하는 데이터는 신속하게 액세스해야 하므로 빠른 데이터 스토리지에 보관하고 경고 시스템이 수행하는 쿼리를 최적화하기 위해 인덱스를 생성하거나 구조화해야 합니다. 경우에 따라 경고 시스템의 로컬 인스턴스가 알림을 빠르게 보낼 수 있도록 컬렉션 서비스에서 데이터를 로컬로 포맷하고 저장해야 할 수 있습니다. 다른 목적을 위해 필요한 경우 동일한 데이터를 이전 다이어그램에 표시된 스토리지 쓰기 서비스로 디스패치하고 중앙에서 저장할 수도 있습니다.

데이터 보존 고려 사항

경우에 따라 데이터를 처리하고 전송한 후 로컬에 저장된 원래 원시 원본 데이터를 제거할 수 있습니다. 다른 경우에는 원시 정보를 저장하는 것이 필요하거나 유용할 수 있습니다. 예를 들어 디버깅을 위해 생성된 데이터를 원시 형식으로 사용할 수 있도록 유지한 다음 버그가 해결된 후 신속하게 삭제할 수 있습니다.

성능 데이터는 성능 추세를 파악하고 용량 계획에 사용할 수 있도록 더 긴 수명을 갖는 경우가 많습니다. 이 데이터에 대한 통합 보기는 일반적으로 빠른 액세스가 가능하도록 온라인에서 일정 기간 동안 유지됩니다. 그 이후에 보관되거나 삭제됩니다.

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

계량 및 고객 대금 청구용으로 수집되는 데이터는 무기한 저장해야 할 수 있습니다. 또한 규정 요구 사항에 따라 감사 및 보안을 위해 수집된 정보를 보관하고 저장해야 할 수 있습니다. 이 데이터도 중요한 데이터이므로 암호화하거나 변조할 수 없도록 보호해야 할 수 있습니다. ID 사기를 저지르는 데 사용할 수 있는 사용자 암호 또는 기타 정보를 기록해서는 안 됩니다. 저장되기 전에 데이터에서 이러한 세부 정보를 스크러빙해야 합니다.

법률 및 규정을 준수하려면 식별 가능한 정보의 저장을 최소화합니다. 식별 가능한 정보를 저장해야 하는 경우 솔루션을 디자인할 때 개인이 해당 정보 삭제를 요청할 수 있는 요구 사항을 고려해야 합니다.

분석

다양한 데이터 원본에서 데이터를 수집한 후 분석하여 시스템의 전반적인 복지를 평가합니다. 이 분석을 위해 다음을 명확하게 이해합니다.

• 정의한 KPI 및 성능 메트릭을 기반으로 데이터를 구성하는 방법입니다.

• 다른 메트릭 및 로그 파일에서 캡처된 데이터의 상관 관계를 지정하는 방법. 이 상관 관계는 일련의 이벤트를 추적할 때 중요하며 문제를 진단하는 데 도움이 될 수 있습니다.

대부분의 경우 아키텍처의 각 구성 요소에 대한 데이터는 로컬로 캡처된 다음 다른 구성 요소에서 생성된 데이터와 정확하게 결합됩니다.

예를 들어 3계층 애플리케이션에는 다음이 있을 수 있습니다.

• 사용자가 웹 사이트에 연결할 수 있는 프레젠테이션 계층입니다.

• 비즈니스 논리를 처리하는 마이크로 서비스 집합을 호스트하는 중간 계층입니다.

• 작업과 연결된 데이터를 저장하는 데이터베이스 계층입니다.

단일 비즈니스 작업에 대한 사용량 데이터는 세 계층 모두에 걸쳐 있을 수 있습니다. 작업의 리소스 및 처리 사용량에 대한 전체 보기를 제공하려면 이 정보의 상관 관계를 지정해야 합니다. 상관 관계에는 데이터베이스 계층에서 데이터를 전처리 및 필터링하는 작업이 포함될 수 있습니다. 중간 계층에서 집계 및 서식 지정은 일반적인 작업입니다.

권장 사항

• 애플리케이션 수준 및 리소스 수준 로그의 상관 관계를 지정합니다. 두 수준에서 데이터를 평가하여 문제 검색 및 해당 문제 해결을 최적화합니다. 단일 데이터 싱크에서 데이터를 집계하거나 두 수준에서 이벤트를 쿼리하는 메서드를 활용할 수 있습니다. 애플리케이션 수준 및 리소스 수준 로그를 집계하고 쿼리하려면 Azure Log Analytics와 같은 통합 솔루션을 사용하는 것이 좋습니다.

• 콜드 분석을 위해 스토리지에 대한 명확한 보존 시간을 정의합니다. 특정 기간 동안 기록 분석을 사용하도록 설정하려면 이 방법을 사용하는 것이 좋습니다. 또한 스토리지 비용을 제어하는 데 도움이 될 수 있습니다. 장기 추세 분석을 위해 데이터를 더 저렴한 스토리지에 보관하고 데이터를 집계하는 프로세스를 구현합니다.

• 장기 추세를 분석하여 운영 문제를 예측합니다. 장기 데이터를 평가하여 운영 전략을 수립하고 발생할 가능성이 있는 운영 문제 및 시기를 예측합니다. 예를 들어 평균 응답 시간은 시간이 지남에 따라 서서히 증가하고 최대 목표에 근접하고 있음을 확인할 수 있습니다.

이러한 권장 사항에 대한 자세한 지침은 클라우드 애플리케이션에 대한 모니터링 데이터 분석을 참조하세요.

시각화

대시보드

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

워크로드의 워크로드 또는 구성 요소가 정상, 성능 저하 또는 비정상 상태인 경우를 나타내도록 대시보드를 상태 모델에 맞춥니다.

dashboard 시스템이 효과적으로 작동하려면 워크로드 팀에 의미가 있어야 합니다. 워크로드 상태와 관련된 정보를 시각화하고 실행 가능할 수도 있습니다. 워크로드 또는 구성 요소가 저하되거나 비정상이면 워크로드 팀의 구성원은 워크로드에서 문제가 발생한 위치를 쉽게 식별하고 수정 작업 또는 조사를 시작할 수 있어야 합니다. 반대로, 실행 불가능하거나 워크로드 상태와 관련이 없는 정보를 포함하면 실행 가능한 데이터에서 백그라운드 노이즈를 분별하려는 팀 구성원에게 dashboard 불필요하게 복잡하고 실망스러울 수 있습니다.

관련자 또는 개발자를 위한 대시보드가 관련되는 워크로드에 대한 데이터만 표시하도록 사용자 지정되어 있을 수 있습니다. 워크로드 팀이 다른 팀이 대시보드를 보고자 하는 데이터 요소 유형을 이해하고 대시보드를 공유하여 명확성을 위해 검사 미리 볼 수 있는지 확인합니다. 관련자를 위해 워크로드에 대한 대시보드를 제공하는 것은 워크로드 상태를 계속 파악하는 좋은 방법이지만 이해 관계자가 표시되는 데이터를 명확하게 이해하지 못하면 비생산적일 위험이 있습니다.

좋은 dashboard 정보를 표시하는 것이 아닙니다. 또한 분석가가 해당 정보에 대해 즉흥적인 질문을 할 수 있습니다. 일부 시스템에서는 운영자가 이러한 작업을 완료하고 기본 데이터를 탐색하는 데 사용할 수 있는 관리 도구를 제공합니다. 대신 정보를 보관하는 데 사용되는 리포지토리에 따라 데이터를 직접 쿼리하거나 추가 분석 및 보고를 위해 Excel과 같은 도구로 가져올 수 있습니다.

참고

권한 있는 담당자에 대한 dashboard 액세스를 제한합니다. 대시보드에 대한 정보는 상업적으로 중요할 수 있습니다. 또한 사용자가 데이터를 변경하지 못하도록 기본 데이터를 보호해야 합니다.

보고

보고는 시스템 전체 보기를 생성하기 위해 사용됩니다. 기록 데이터와 현재 정보를 통합할 수 있습니다. 보고 요구 사항은 크게 운영 보고와 보안 보고의 두 가지 범주로 나뉩니다.

운영 보고에는 일반적으로 다음이 포함됩니다.

• 지정된 시간 범위 동안 전체 시스템 또는 지정된 하위 시스템의 리소스 사용률을 이해하도록 사용할 수 있는 통계 집계.

• 지정된 기간 동안 전체 시스템 또는 지정된 하위 시스템에 대한 리소스 사용 추세 파악.

• 지정된 기간 동안 시스템 전체 또는 지정된 하위 시스템에서 발생한 예외 모니터링

• 배포된 리소스에 대한 애플리케이션의 효율성을 결정하고, 불필요하게 성능에 영향을 주지 않고 리소스 볼륨 및 관련 비용을 줄일 수 있는지 여부를 이해합니다.

보안 보고는 시스템의 고객 사용을 추적합니다. 다음을 포함할 수 있습니다.

• 사용자 작업 감사 이 작업을 수행하려면 날짜 및 시간과 함께 각 사용자가 완료하는 개별 요청을 기록해야 합니다. 관리자가 지정된 기간 동안 사용자가 완료하는 작업 시퀀스를 신속하게 재구성할 수 있도록 데이터를 구조화해야 합니다.

• 사용자에 의한 리소스 사용 추적 이 작업을 수행하려면 사용자의 각 요청이 시스템을 구성하는 다양한 리소스에 액세스하는 방법과 기간 동안 기록해야 합니다. 관리자는 이 데이터를 사용하여 사용자가 청구에 대해 지정된 기간 동안 사용률 보고서를 생성할 수 있습니다.

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

경고

시스템이 정상, 응답성 및 보안을 유지하도록 하려면 운영자가 적시에 응답할 수 있도록 경고를 설정합니다. 경고에는 진단 활동을 빠르게 시작하는 데 도움이 되는 충분한 컨텍스트 정보가 포함될 수 있습니다. 경고는 자동 크기 조정 또는 기타 자가 복구 메커니즘과 같은 수정 함수를 호출하는 데 사용할 수 있습니다. 경고는 예산 및 한도에 대한 가시성을 제공하여 비용 인식을 가능하게 할 수도 있습니다.

권장 사항

• 책임 있는 소유자 및 조치를 식별하는 경고 대응 프로세스를 정의합니다.

• 잘 정의된 범위(리소스 종류 및 리소스 그룹)에 대한 경고를 구성하고 세부 정보 표시를 조정하여 노이즈를 최소화합니다.

• 사용자가 문제를 적극적으로 검색하도록 요구하는 대신 Splunk 또는 Azure Monitor와 같은 자동화된 경고 솔루션을 사용합니다.

• 경고를 사용하여 수정 프로세스를 운영합니다. 예를 들어, 문제 및 해결 방법을 추적하는 티켓을 자동으로 만듭니다.

• 지역에서 클라우드 플랫폼 서비스의 상태, 중단에 대한 통신, 계획된 유지 관리 활동 및 기타 상태 권고를 추적합니다.

임계값

경고는 모니터링 시스템에서 감지한 임계값을 초과할 때 생성됩니다. 일반적으로 설정한 임계값을 통해 워크로드에 필요한 변경 내용을 구현하여 성능 저하 또는 중단을 방지할 수 있는 충분한 시간을 제공해야 합니다. 예를 들어 실행 중인 시스템이 저하된 사용자 환경의 지점에 압도되기 전에 크기 조정을 시작하도록 자동 크기 조정 임계값을 설정합니다. 인프라 관리에서 과거 환경에 할당한 임계값을 기반으로 하고 테스트 사례의 일부로 수행하는 테스트를 통해 유효성을 검사합니다.

경고 사용 사례 및 기타 고려 사항에 대한 자세한 지침은 신뢰할 수 있는 모니터링 및 경고 전략 설계를 참조하세요.

Azure 촉진

• Azure Monitor 는 클라우드 및 온-프레미스 환경에서 모니터링 데이터를 수집, 분석 및 응답하기 위한 포괄적인 모니터링 솔루션입니다.

• Log Analytics는 Log Analytics 작업 영역의 데이터에 대한 로그 쿼리를 편집하고 실행하는 데 사용할 수 있는 Azure Portal 도구입니다.

  여러 작업 영역을 사용하는 경우 모범 사례는 Log Analytics 작업 영역 아키텍처 가이드 를 참조하세요.

• Application Insights 는 Azure Monitor의 확장입니다. APM 기능을 제공합니다.

• Azure Monitor Insights 는 특정 Azure 기술(예: VM, 앱 서비스 및 컨테이너)에 대한 고급 분석 도구입니다. 이러한 도구는 Azure Monitor 및 Log Analytics의 일부입니다.

• SAP용 Azure Monitor 솔루션 은 Azure에서 실행되는 SAP 환경을 위한 Azure 모니터링 도구입니다.

• Azure Policy를 통해 조직 표준을 적용하고 규모에 맞게 규정 준수를 평가할 수 있습니다.

관련 링크

• 계측 가이드
• 신뢰할 수 있는 모니터링 및 경고 전략을 설계하기 위한 권장 사항
• 모니터링 및 위협 탐지에 대한 권장 사항
• 성능 데이터 수집을 위한 권장 사항

커뮤니티 링크

• AMBA(Azure Monitor 기준 경고) 는 고객과 파트너가 Azure Monitor 채택을 통해 가시성 환경을 개선하는 데 사용할 수 있는 경고 정의의 중앙 리포지토리입니다.

운영 우수성 검사 목록

전체 권장 사항 집합을 참조하세요.

운영 우수성 검사 목록