다음을 통해 공유

Azure Service Fabric 모니터링

  • 아티클

이 문서에서는 다음을 설명합니다.

  • 이 서비스에 대해 수집할 수 있는 모니터링 데이터의 유형.
  • 해당 데이터를 분석하는 방법.

참고 항목

이 서비스 및/또는 Azure Monitor에 이미 익숙하고 모니터링 데이터를 분석하는 방법만 알고 싶은 경우 이 문서의 끝부분에 있는 분석 섹션을 참조하세요.

Azure 리소스를 사용하는 중요한 애플리케이션 및 비즈니스 프로세스가 있는 경우 시스템을 모니터링하고 시스템에 대한 경고를 받아야 합니다. Azure Monitor 서비스는 시스템의 모든 구성 요소에서 메트릭과 로그를 수집하고 집계합니다. Azure Monitor는 가용성, 성능, 복원력에 대한 보기를 제공하고 문제를 알려 줍니다. Azure Portal, PowerShell, Azure CLI, REST API 또는 클라이언트 라이브러리를 사용하여 모니터링 데이터를 설정하고 볼 수 있습니다.

Azure Service Fabric 모니터링

Azure Service Fabric에는 모니터링할 수 있는 다음과 같은 계층이 있습니다.

  • 애플리케이션 모니터링: 노드에서 실행되는 애플리케이션입니다. Application Insights 키 또는 SDK, EventStore 또는 ASP.NET Core 로깅을 사용하여 애플리케이션을 모니터링할 수 있습니다.
  • 플랫폼(클러스터) 모니터링: 컨테이너 메트릭을 포함한 플랫폼 또는 클러스터 노드에 ​​대한 클라이언트 메트릭, 로그 및 이벤트입니다. 메트릭과 로그는 Linux 또는 Windows 노드에 대해 다릅니다.
  • 인프라(성능) 모니터링: 서비스 인프라에 대한 서비스 상태 및 성능 카운터입니다.

애플리케이션 사용 방법, Service Fabric 플랫폼에서 수행한 작업, 성능 카운터를 사용한 리소스 사용률 및 클러스터의 전반적인 상태를 모니터링할 수 있습니다. Azure Monitor 로그 및 Application Insights Service Fabric과의 기본 제공 통합을 제공합니다.

Service Fabric Explorer

Windows, macOS 및 Linux용 데스크톱 애플리케이션인Service Fabric Explorer Azure Service Fabric 클러스터를 검사하고 관리하기 위한 오픈 소스 도구입니다. 자동화를 사용하도록 설정하기 위해 Service Fabric Explorer를 통해 수행할 수 있는 모든 작업은 PowerShell 또는 REST API를 통해 수행할 수도 있습니다.

애플리케이션 모니터링

애플리케이션 모니터링은 애플리케이션의 기능 및 구성 요소가 사용되는 방식을 추적합니다. 애플리케이션을 모니터링하여 사용자에게 영향을 주는 문제가 발견되었는지 확인하려고 합니다. 애플리케이션 모니터링은 애플리케이션의 비즈니스 논리마다 고유하므로, 그 책임은 애플리케이션 및 해당 서비스를 개발하는 사용자에게 있습니다. 애플리케이션 모니터링은 다음 시나리오에서 유용할 수 있습니다.

  • 내 애플리케이션에서 발생하는 트래픽 양은 얼마나 되나요? - 사용자 수요를 충족하거나 애플리케이션의 잠재적 병목 상태를 해결하기 위해 서비스를 확장해야 하나요?
  • 서비스 간 호출이 성공적이며 추적되나요?
  • 내 애플리케이션 사용자는 어떤 작업을 수행하나요? - 원격 분석을 수집하면 향후 기능 개발과 애플리케이션 오류에 대한 더 나은 진단이 가능해집니다.
  • 내 애플리케이션에서 처리되지 않은 예외를 throw하나요?
  • 내 컨테이너 내에서 실행되는 서비스에서 어떤 상황이 발생하나요?

애플리케이션 모니터링은 애플리케이션 컨텍스트 내에서 진행되므로 개발자가 원하는 도구 및 프레임워크를 사용할 수 있다는 장점이 있습니다. Application Insights를 사용하여 이벤트 분석에서 Azure Monitor Application Insights를 사용한 애플리케이션 모니터링을 위한 Azure 솔루션에 대해 자세히 알아볼 수 있습니다.

.NET 애플리케이션용으로 설정하는 방법을 제공하는 자습서도 있습니다. 이 자습서는 적절한 도구를 설치하는 방법, 애플리케이션의 사용자 지정 원격 분석 쓰기 예제 및 Azure Portal에서 응용 프로그램 진단 및 원격 분석 보기 방법을 설명합니다.

애플리케이션 로깅

코드를 계측하는 것은 사용자에 대한 인사이트를 얻는 방법일 뿐만 아니라 애플리케이션에 문제가 있는지 여부도 알 수 있고 수정해야 할 항목을 진단할 수 있는 방법입니다. 기술적으로 디버거를 프로덕션 서비스에 연결할 수도 있지만 일반적인 방법은 아닙니다. 따라서 자세한 계측 데이터를 갖는 것이 중요합니다.

일부 제품은 자동으로 코드를 계측합니다. 이러한 솔루션이 제대로 작동할 수 있지만, 수동 계측은 거의 항상 비즈니스 논리에 맞게 수행되어야 합니다. 결국 애플리케이션을 과학 수사 방식으로 디버그하는 데 필요한 정보가 충분히 있어야 합니다. Service Fabric 애플리케이션은 모든 로깅 프레임워크를 통해 계측할 수 있습니다. 이 섹션에서는 코드 계측에 대한 몇 가지 방식과 다른 방식보다 한 가지 방식을 선택하는 경우에 대해 설명합니다.

  • Application Insights SDK: Application Insights는 기본적으로 Service Fabric과 풍부한 통합 기능을 갖추고 있습니다. 사용자는 AI Service Fabric NuGet 패키지를 추가하고 Azure Portal에서 볼 수 있도록 만들어지고 수집된 데이터 및 로그를 받습니다. 또한 사용자는 해당 애플리케이션을 진단 및 디버그하고 애플리케이션에서 가장 많이 사용되는 서비스 및 부분을 추적하기 위해 고유한 원격 분석을 추가하는 것이 좋습니다. SDK에서 TelemetryClient 클래스는 애플리케이션에서 원격 분석을 추적하는 여러 방법을 제공합니다. 자세한 내용은 Application Insights 이벤트 분석 및 시각화를 참조하세요.

    .NET 애플리케이션 모니터링 및 진단에 대한 자습서에서 Application Insights를 계측하고 애플리케이션에 추가하는 방법의 예를 확인합니다.

  • EventSource: Visual Studio의 템플릿에서 Service Fabric 솔루션을 만들면 EventSource 파생 클래스(ServiceEventSource 또는 ActorEventSource)가 생성됩니다. 애플리케이션 또는 서비스에 대한 이벤트를 추가할 수 있는 템플릿을 만듭니다. EventSource 이름은 고유해야 하며 MyCompany-<solution>-<project> 기본 템플릿 문자열에서 이름을 변경해야 합니다. 동일한 이름을 사용하는 EventSource 정의가 여러 개 있으면 런타임에서 문제가 발생합니다. 정의된 각 이벤트에는 고유 식별자가 있어야 합니다. 식별자가 고유하지 않으면 런타임 오류가 발생합니다. 일부 조직에서는 별도의 개발 팀 간에 충돌을 피하기 위해 식별자에 대한 값의 범위가 미리 할당됩니다. 자세한 내용은 Vance의 블로그 또는 MSDN 설명서를 참조하세요.

  • ASP.NET Core 로깅: 코드를 계측하는 방법을 신중하게 계획해야 합니다. 올바른 계측 계획을 사용하면 잠재적인 코드 기반의 불안정을 피한 다음 코드를 다시 계측할 수 있습니다. 위험을 줄이기 위해 Microsoft ASP.NET Core의 일부인 Microsoft.Extensions.Logging과 같은 계측 라이브러리를 선택할 수 있습니다. ASP.NET Core에는 기존 코드에 미치는 영향을 최소화하면서 선택한 공급자와 함께 사용할 수 있는 ILogger 인터페이스가 있습니다. Windows 및 Linux의 ASP.NET Core 및 전체 .NET Framework의 코드를 사용하여 계측 코드를 표준화할 수 있습니다.

이러한 제안을 사용하는 방법에 대한 예제는 Service Fabric 애플리케이션에 로깅 추가를 참조하세요.

플랫폼(클러스터) 모니터링

사용자는 코드를 직접 작성하기 때문에 해당 애플리케이션에서 제공되는 원격 분석을 제어하지만, Service Fabric 플랫폼에서 제공되는 진단의 경우는 어떤가요? Service Fabric의 목표 중 하나는 애플리케이션을 하드웨어 오류에 대해 복원력 있게 유지하는 것입니다. 이 목표는 플랫폼의 시스템 서비스가 인프라 문제를 감지하고 워크로드를 클러스터의 다른 노드로 빠르게 장애 조치(failover)할 수 있기 때문에 실현이 가능합니다. 그러나 이러한 특정 상황에서 시스템 서비스 자체에 문제가 있다면 어떻게 될까요? 또는 작업을 배포 또는 이동할 때 서비스 배치 규칙에 위배되면 어떻게 될까요? Service Fabric은 이러한 경우와 기타 경우에 대한 진단을 제공하여 사용자가 클러스터에서 진행되는 작업에 대해 알 수 있도록 합니다. 클러스터 모니터링에 대한 몇 가지 샘플 시나리오에는 다음이 포함됩니다.

플랫폼(클러스터) 모니터링에 대한 자세한 내용은 클러스터 모니터링을 참조하세요.

서비스 패브릭 이벤트

Service Fabric은 EventStore 또는 플랫폼이 노출하는 운영 이벤트 채널을 통해 액세스할 수 있는 포괄적인 진단 이벤트 집합을 제공합니다. 이러한 Service Fabric 이벤트는 노드, 애플리케이션, 서비스 및 파티션과 같은 여러 엔터티에서 플랫폼에서 수행하는 작업을 보여 줍니다. 동일한 이벤트를 Windows 및 Linux 클러스터 둘 다에서 사용할 수 있습니다.

  • Service Fabric 이벤트 채널: Windows에서 Service Fabric 이벤트는 운영 채널과 데이터 및 메시징 채널 중에서 선택하는 데 사용되는 관련 logLevelKeywordFilters 집합을 통해 단일 ETW 공급자로부터 제공됩니다. 이는 나가는 Service Fabric 이벤트를 분리하여 필요에 따라 필터링하는 방식입니다. Linux에서는 Service Fabric 이벤트가 LTTng를 통해 수신되어 단일 Storage 테이블에 배치되며, 필요에 따라 어디서나 필터링할 수 있습니다. 이러한 채널에는 클러스터 상태 이해에 도움이 되는 구조화된 조정 이벤트가 포함되어 있습니다. 진단은 클러스터 생성 시 기본적으로 사용이 가능하며, 나중에 쿼리할 수 있도록 이러한 채널의 이벤트가 전송되는 Azure Storage 테이블이 만들어집니다.

  • EventStore Service Fabric Explorer에서 Service Fabric 플랫폼 이벤트를 표시하고 Service Fabric 클라이언트 라이브러리 REST API를 통해 프로그래밍 방식으로 표시하는 기능입니다. 각 노드, 서비스 및 애플리케이션에 대한 클러스터의 진행 내용에 대한 스냅샷 보기와 이벤트 시간을 기준으로 쿼리를 볼 수 있습니다. EventStore API는 Azure에서 실행되는 Windows 클러스터에만 사용할 수 있습니다. Windows 컴퓨터에서 이러한 이벤트는 이벤트 로그에 공급되므로 이벤트 뷰어에서 Service Fabric 이벤트를 볼 수 있습니다.

NodeDown 이벤트를 포함하여 노드 창에서 여러 이벤트의 이벤트 탭을 보여 주는 스크린샷.

제공되는 진단은 기본적으로 포괄적인 이벤트 세트 형식으로 되어 있습니다. 이러한 Service Fabric 이벤트는 노드, 애플리케이션, 서비스, 파티션 등의 다른 엔터티에 대해 플랫폼에서 수행되는 작업을 보여 줍니다. 위의 마지막 시나리오에서 노드가 작동 중단되면 플랫폼은 NodeDown 이벤트를 발생하며, 선택한 모니터링 도구를 통해 즉시 알림을 받을 수 있습니다. 다른 일반적인 예로 장애 조치(failover) 동안의 ApplicationUpgradeRollbackStarted 또는 PartitionReconfigured가 있습니다. 동일한 이벤트를 Windows 및 Linux 클러스터 둘 다에서 사용할 수 있습니다.

이벤트가 Windows 및 Linux 둘 다의 표준 채널을 통해 전송되며, 이러한 채널을 지원하는 모니터링 도구에서 읽을 수 있습니다. Azure Monitor 솔루션은 Azure Monitor 로그입니다. 클러스터에 대한 사용자 지정 작업 대시보드와 경고를 만들 수 있는 샘플 쿼리가 몇 가지 포함되어 있는 Azure Monitor 로그 통합에 대해 자세히 알아보세요. 플랫폼 수준 이벤트 및 로그 생성에서 더 많은 클러스터 모니터링 개념을 확인할 수 있습니다.

상태 모니터링

Service Fabric 플랫폼에는 클러스터의 엔터티 상태에 대한 확장 가능한 상태 보고를 제공하는 상태 모델이 포함되어 있습니다. 각 노드, 애플리케이션, 서비스, 파티션, 복제본 또는 인스턴스에는 지속적으로 업데이트 가능한 상태가 있습니다. 시스템 상태는 “정상”, “경고” 또는 “오류”일 수 있습니다. Service Fabric 이벤트를 다양한 엔터티에 대해 클러스터가 수행하는 동사로, 상태를 각 엔터티에 대한 형용사로 간주할 수 있습니다. 특정 엔터티의 상태가 전환될 때마다 이벤트도 발생합니다. 이러한 방식으로 다른 이벤트와 마찬가지로 원하는 모니터링 도구에서 상태 이벤트에 대한 쿼리 및 경고를 설정할 수 있습니다.

또한 사용자가 엔터티의 상태를 재정의하도록 할 수도 있습니다. 애플리케이션이 업그레이드를 거치게 되며, 유효성 검사 테스트가 실패하면 Health API를 통해 Service Fabric 상태에 애플리케이션이 더 이상 정상 상태가 아니라고 쓸 수 있습니다. 그러면 Service Fabric은 업그레이드를 자동으로 롤백합니다. 상태 모델에 대한 자세한 내용은 Service Fabric 상태 모니터링 소개를 참조하세요.

SFX 상태 대시보드의 스크린샷.

Watchdog

일반적으로 Watchdog는 전체 서비스의 상태와 부하를 감시하고, 엔드포인트에 Ping을 수행하고, 클러스터에 있는 예기치 않은 상태 이벤트를 보고하는 별도의 서비스입니다. 이렇게 하면 단일 서비스의 성능만을 기준으로 감지되지 않는 오류를 방지할 수 있습니다. 또한 Watchdog은 특정 시간 간격으로 스토리지에서 로그 파일을 정리하는 것처럼 사용자 상호 작용이 필요하지 않은 수정 작업을 수행하는 코드를 호스트하기 좋은 위치입니다. 사용하기 쉬운 Watchdog 확장성 모델을 포함하고 Windows 및 Linux 클러스터 모두에서 실행되는 완전히 구현된 오픈 소스 SF Watchdog 서비스를 사용하려면 FabricObserver 프로젝트를 참조하세요. FabricObserver는 프로덕션에 최적화된 소프트웨어입니다. 테스트 및 프로덕션 클러스터에 FabricObserver를 배포하고 플러그 인 모델을 통해 요구 사항에 맞게 확장하거나, 이를 분기하고 사용자 고유의 기본 제공 관찰자를 작성하면 좋습니다. 전자(플러그 인)가 권장되는 방법입니다.

인프라(성능) 모니터링

지금까지 애플리케이션 및 플랫폼의 진단에 대해 알아보았습니다. 하드웨어가 예상대로 작동하는지를 어떻게 알 수 있을까요? 기본 인프라 모니터링은 클러스터 상태 및 리소스 사용률을 이해하는 데 중요한 부분입니다. 시스템 성능 측정은 작업에 따라 주관적일 수 있는 다양한 요인에 따라 달라집니다. 이러한 요소는 일반적으로 성능 카운터를 통해 측정됩니다. 이러한 성능 카운터는 운영 체제, .NET Framework 또는 Service Fabric 플랫폼 자체를 포함하는 다양한 원본에서 가져올 수 있습니다. 성능 카운터를 유용하게 사용할 수 있는 몇 가지 시나리오는 다음과 같습니다.

  • 하드웨어를 효율적으로 활용하고 있나요? 하드웨어를 90% CPU 또는 10% CPU 중 어디에서 사용하고 싶나요? 이 시나리오는 클러스터의 크기를 조정하거나 애플리케이션 프로세스를 최적화하는 경우에 도움이 됩니다.
  • 인프라 문제를 사전에 예측할 수 있나요? - 문제에 앞서 성능이 갑자기 변경(저하)되는 경우가 많으므로 네트워크 I/O, CPU 사용률 등의 성능 카운터를 사용하여 문제를 사전에 예측하고 진단할 수 있습니다.

인프라 수준에서 수집해야 하는 성능 카운터 목록은 성능 메트릭에서 확인할 수 있습니다.

클러스터 수준 이벤트를 모니터링하는 데 Azure Monitor 로그를 사용하는 것이 좋습니다. 작업 영역에서 Log Analytics 에이전트를 구성한 후 다음을 수집할 수 있습니다.

  • CPU 사용률과 같은 성능 메트릭
  • 프로세스 수준 CPU 사용률과 같은 .NET 성능 카운터입니다.
  • 신뢰할 수 있는 서비스의 예외 수와 같은 Service Fabric 성능 카운터입니다.
  • CPU 사용률과 같은 컨테이너 메트릭

리소스 유형

Azure는 리소스 유형 및 ID의 개념을 사용하여 구독의 모든 항목을 식별합니다. 마찬가지로 Azure Monitor는 네임스페이스라고도 하는 리소스 유형에 따라 핵심 모니터링 데이터를 메트릭 및 로그로 구성합니다. 리소스 유형에 따라 다른 메트릭 및 로그를 사용할 수 있습니다. 서비스는 둘 이상의 리소스 유형과 연결될 수 있습니다.

리소스 유형은 Azure에서 실행되는 모든 리소스에 대한 리소스 ID의 일부이기도 합니다. 예를 들어 가상 머신의 리소스 유형 중 하나는 Microsoft.Compute/virtualMachines입니다. 서비스 및 관련 리소스 유형 목록은 리소스 공급자를 참조하세요.

Azure Service Fabric의 리소스 종류에 대한 자세한 내용은 Service Fabric 모니터링 데이터 참조를 참조하세요.

데이터 저장소

Azure Monitor의 경우:

  • 메트릭 데이터는 Azure Monitor 메트릭 데이터베이스에 저장됩니다.
  • 로그 데이터는 Azure Monitor 로그 저장소에 저장됩니다. 로그 분석은 이 저장소를 쿼리할 수 있는 Azure Portal의 도구입니다.
  • Azure 활동 로그는 Azure Portal에 자체 인터페이스가 있는 별도의 저장소입니다.

선택적으로 메트릭 및 활동 로그 데이터를 Azure Monitor 로그 저장소로 라우팅할 수 있습니다. 그런 다음 Log Analytics를 사용하여 데이터를 쿼리하고 다른 로그 데이터와 상호 연결할 수 있습니다.

많은 서비스에서는 진단 설정을 사용하여 메트릭 및 로그 데이터를 Azure Monitor 외부의 다른 스토리지 위치로 보낼 수 있습니다. 예를 들면 Azure Storage, 호스트된 파트너 시스템 및 Event Hubs를 사용하는 비 Azuree 파트너 시스템이 있습니다.

Azure Monitor가 데이터를 저장하는 방법에 대한 자세한 내용은 Azure Monitor 데이터 플랫폼을 참조하세요.

Azure Monitor 플랫폼 메트릭

Azure Monitor는 많은 서비스에 대한 플랫폼 메트릭을 제공합니다. Azure Monitor의 모든 리소스에 대해 수집할 수 있는 모든 메트릭 목록은 Azure Monitor에서 지원되는 메트릭을 참조하세요.

이 서비스는 플랫폼 메트릭을 수집하지 않습니다.

비 Azure Monitor 기반 메트릭

이 서비스는 Azure Monitor 메트릭 데이터베이스에 포함되지 않은 다른 메트릭을 제공합니다.

게스트 OS 메트릭

Service Fabric 클러스터 노드에서 실행되는 게스트 OS(운영 체제)에 대한 메트릭은 게스트 OS에서 실행되는 하나 이상의 에이전트를 통해 수집되어야 합니다. 게스트 OS 메트릭에는 게스트 CPU 백분율 또는 메모리 사용량을 추적하는 성능 카운터가 포함되며, 둘 다 자동 스케일링 또는 경고에 자주 사용됩니다.

사용자 지정 메트릭 API를 통해 게스트 OS 성능 메트릭을 Azure Monitor 메트릭 데이터베이스로 보내도록 Azure Monitor 에이전트를 사용하고 구성하는 것이 가장 좋습니다. 동일한 에이전트를 사용하여 Azure Monitor 로그에 게스트 OS 메트릭을 보낼 수 있습니다. 그런 다음 Log Analytics를 사용하여 해당 메트릭 및 로그를 쿼리할 수 있습니다.

참고 항목

Azure Monitor 에이전트는 게스트 OS 라우팅을 위해 Azure Diagnostics 확장 및 Log Analytics 에이전트를 대체합니다. 자세한 내용은 Azure Monitor 에이전트 개요를 참조하세요.

Azure Monitor 리소스 로그

리소스 로그는 Azure 리소스에서 수행한 작업에 대한 인사이트를 제공합니다. 로그는 자동으로 생성되지만 저장하거나 쿼리하려면 Azure Monitor 로그로 라우팅해야 합니다. 로그는 범주로 구성됩니다. 지정된 네임스페이스에는 수집할 수 있는 여러 리소스 로그 범주가 있을 수 있습니다.

이 서비스는 리소스 로그를 수집하지 않지만 Azure 리소스 모니터링 데이터에서 해당 로그에 대한 정보를 찾을 수 있습니다.

Service Fabric 로그 및 이벤트

Service Fabric은 다음 로그를 수집할 수 있습니다.

  • Windows 클러스터의 경우 Diagnostics Agent 및 Azure Monitor 로그를 사용하여 클러스터 모니터링을 설정할 수 있습니다.
  • Linux 클러스터의 경우 Azure Monitor 로그는 Azure 플랫폼 및 인프라 모니터링에 권장되는 도구이기도 합니다. Linux 플랫폼 진단에는 다른 구성이 필요합니다. 자세한 내용은 Syslog의 Service Fabric Linux 클러스터 이벤트를 참조하세요.
  • Azure Monitor 로그에 게스트 OS 로그를 보내도록 Azure Monitor 에이전트를 구성할 수 있습니다. 여기서 Log Analytics를 사용하여 쿼리할 수 있습니다.
  • Stdout 또는stderr Service Fabric 컨테이너 로그를 작성하여 Azure Monitor 로그에서 사용할 수 있습니다.
  • Azure Monitor 로그용 컨테이너 모니터링 솔루션을 설정하여 컨테이너 이벤트를 볼 수 있습니다.

다른 로깅 솔루션

권장되는 두 가지 솔루션인 Azure Monitor 로그 및 Application Insights는 Service Fabric과 통합되어 있지만, 많은 이벤트가 ETW 공급자를 통해 작성되고 다른 로깅 솔루션으로 확장될 수 있습니다. Elastic Stack(특히 오프라인 환경에서 클러스터를 실행하려는 경우), Dynatrace 또는 기타 원하는 플랫폼도 살펴봐야 합니다. 통합 파트너 목록은 Azure Service Fabric 모니터링 파트너를 참조하세요.

플랫폼을 선택할 때는 사용자 인터페이스, 쿼리 기능, 사용자 지정 시각화 및 사용 가능한 대시보드, 모니터링 환경 개선을 위해 제공하는 추가 도구의 편의성을 고려해야 합니다.

Azure 활동 로그

활동 로그에는 해당 리소스의 외부에서 볼 때 각 Azure 리소스에 대한 작업을 추적하는 구독 수준 이벤트(예: 새 리소스 만들기 또는 가상 머신 시작)가 포함되어 있습니다.

수집: 활동 로그 이벤트는 자동으로 생성되고 별도의 저장소에 수집되어 Azure Portal에서 볼 수 있습니다.

라우팅: 다른 로그 데이터와 함께 분석할 수 있도록 활동 로그 데이터를 Azure Monitor 로그로 보낼 수 있습니다. Azure Storage, Azure Event Hubs, 특정 Microsoft 모니터링 파트너와 같은 다른 위치도 사용할 수 있습니다. 활동 로그를 라우팅하는 방법에 대한 자세한 내용은 Azure 활동 로그 개요를 참조하세요.

모니터링 데이터 분석

모니터링 데이터를 분석하기 위한 많은 도구가 있습니다.

Azure Monitor 도구

Azure Monitor는 다음과 같은 기본 도구를 지원합니다.

더 복잡한 시각화를 허용하는 도구는 다음과 같습니다.

  • 대시보드: 다양한 종류의 데이터를 Azure Portal에서 하나의 창에 결합할 수 있습니다.
  • 통합 문서: Azure Portal에서 만들 수 있는 사용자 지정 가능한 보고서입니다. 통합 문서에는 텍스트, 메트릭, 로그 쿼리가 포함될 수 있습니다.
  • Grafana: 뛰어난 운영 대시보드를 제공하는 개방형 플랫폼 도구입니다. Grafana를 사용하여 Azure Monitor 외의 여러 소스에서 온 데이터를 포함하는 대시보드를 만들 수 있습니다.
  • Power BI: 다양한 데이터 소스에서 대화형 시각화를 제공하는 비즈니스 분석 서비스입니다. Azure Monitor에서 자동으로 로그 데이터를 가져오도록 Power BI를 구성하여 이러한 시각화를 활용할 수 있습니다.

일반적인 Service Fabric 모니터링 분석 시나리오에 대한 개요는 Service Fabric을 사용하여 일반적인 시나리오 진단을 참조하세요.

Azure Monitor 내보내기 도구

다음 방법을 사용하여 Azure Monitor에서 다른 도구로 데이터를 내보낼 수 있습니다.

Azure Monitor용 REST API를 시작하려면 Azure 모니터링 REST API 연습을 참조하세요.

Kusto 쿼리

KQL(Kusto 쿼리 언어)을 사용하여 Azure Monitor 로그/로그 분석 저장소에서 모니터링 데이터를 분석할 수 있습니다.

Important

포털의 서비스 메뉴에서 로그를 선택하면 쿼리 범위가 현재 서비스로 설정된 상태로 로그 분석이 열립니다. 이 범위는 로그 쿼리에 해당 유형의 리소스의 데이터만 포함된다는 의미입니다. 다른 Azure 서비스의 데이터를 포함하는 쿼리를 실행하려면 Azure Monitor 메뉴에서 로그를 선택합니다. 자세한 내용은 Azure Monitor Log Analytics의 로그 쿼리 범위 및 시간 범위를 참조하세요.

모든 서비스에 대한 일반적인 쿼리 목록은 로그 분석 쿼리 인터페이스를 참조하세요.

샘플 쿼리

다음 쿼리는 노드에 대한 작업을 포함하여 Service Fabric 이벤트를 반환합니다. 다른 유용한 쿼리는 Service Fabric 이벤트를 참조하세요.

지난 한 시간 동안 기록된 작업 이벤트를 반환합니다.

ServiceFabricOperationalEvent
| where TimeGenerated > ago(1h)
| join kind=leftouter ServiceFabricEvent on EventId
| project EventId, EventName, TaskName, Computer, ApplicationName, EventMessage, TimeGenerated
| sort by TimeGenerated

HealthState == 3(오류)을 사용하여 상태 보고서를 반환하고 EventMessage 필드에서 더 많은 속성을 추출합니다.

ServiceFabricOperationalEvent
| join kind=leftouter ServiceFabricEvent on EventId
| extend HealthStateId = extract(@"HealthState=(\S+) ", 1, EventMessage, typeof(int))
| where TaskName == 'HM' and HealthStateId == 3
| extend SourceId = extract(@"SourceId=(\S+) ", 1, EventMessage, typeof(string)),
         Property = extract(@"Property=(\S+) ", 1, EventMessage, typeof(string)),
         HealthState = case(HealthStateId == 0, 'Invalid', HealthStateId == 1, 'Ok', HealthStateId == 2, 'Warning', HealthStateId == 3, 'Error', 'Unknown'),
         TTL = extract(@"TTL=(\S+) ", 1, EventMessage, typeof(string)),
         SequenceNumber = extract(@"SequenceNumber=(\S+) ", 1, EventMessage, typeof(string)),
         Description = extract(@"Description='([\S\s, ^']+)' ", 1, EventMessage, typeof(string)),
         RemoveWhenExpired = extract(@"RemoveWhenExpired=(\S+) ", 1, EventMessage, typeof(bool)),
         SourceUTCTimestamp = extract(@"SourceUTCTimestamp=(\S+)", 1, EventMessage, typeof(datetime)),
         ApplicationName = extract(@"ApplicationName=(\S+) ", 1, EventMessage, typeof(string)),
         ServiceManifest = extract(@"ServiceManifest=(\S+) ", 1, EventMessage, typeof(string)),
         InstanceId = extract(@"InstanceId=(\S+) ", 1, EventMessage, typeof(string)),
         ServicePackageActivationId = extract(@"ServicePackageActivationId=(\S+) ", 1, EventMessage, typeof(string)),
         NodeName = extract(@"NodeName=(\S+) ", 1, EventMessage, typeof(string)),
         Partition = extract(@"Partition=(\S+) ", 1, EventMessage, typeof(string)),
         StatelessInstance = extract(@"StatelessInstance=(\S+) ", 1, EventMessage, typeof(string)),
         StatefulReplica = extract(@"StatefulReplica=(\S+) ", 1, EventMessage, typeof(string))

특정 서비스 및 노드와 함께 집계된 Service Fabric 작업 이벤트를 가져옵니다.

ServiceFabricOperationalEvent
| where ApplicationName  != "" and ServiceName != ""
| summarize AggregatedValue = count() by ApplicationName, ServiceName, Computer

경고

Azure Monitor 경고는 모니터링 데이터에서 특정한 조건이 발견될 때 사용자에게 사전에 알립니다. 경고를 통해 사용자에게 알리기 전에 시스템 문제를 식별하고 해결할 수 있습니다. 자세한 내용은 Azure Monitor 경고을 참조하세요.

Azure 리소스에 대한 일반적인 경고의 소스에는 여러 가지가 있습니다. Azure 리소스에 대한 일반적인 경고의 예는 샘플 로그 경고 쿼리를 참조하세요. AMBA(Azure Monitor 기준 경고) 사이트는 중요한 플랫폼 메트릭 경고, 대시보드 및 지침을 구현하는 반자동 방법을 제공합니다. 이 사이트는 ALZ(Azure 랜딩 존)의 일부인 전체 서비스를 포함하여 지속적으로 확장되는 Azure 서비스 하위 집합에 적용됩니다.

공통 경고 스키마는 Azure Monitor 경고 알림의 사용을 표준화합니다. 자세한 내용은 일반 경고 스키마를 참조하세요.

경고 유형

Azure Monitor 데이터 플랫폼의 모든 메트릭 또는 로그 데이터 원본에 대해 경고할 수 있습니다. 모니터링하는 서비스 및 수집하는 모니터링 데이터에 따라 다양한 유형의 경고가 있습니다. 서로 다른 형식의 경고에는 다양한 장점과 단점이 있습니다. 자세한 내용은 올바른 모니터링 경고 유형 선택을 참조하세요.

다음 목록에서는 만들 수 있는 Azure Monitor 경고의 유형에 대해 설명합니다.

  • 메트릭 경고는 정기적으로 리소스 메트릭을 평가합니다. 메트릭은 플랫폼 메트릭, 사용자 지정 메트릭, 메트릭으로 변환된 Azure Monitor의 로그 또는 Application Insights 메트릭일 수 있습니다. 메트릭 경고는 여러 조건과 동적 임계값을 적용할 수도 있습니다.
  • 로그 경고를 사용하면 사용자가 로그 분석 쿼리를 사용하여 미리 정의된 빈도로 리소스 로그를 평가할 수 있습니다.
  • 활동 로그 경고는 정의된 조건과 일치하는 새 활동 로그 이벤트가 발생할 때 트리거됩니다. Resource Health 경고 및 Service Health 경고는 서비스 및 Resource Health를 보고하는 활동 로그 경고입니다.

일부 Azure 서비스는 스마트 검색 경고, Prometheus 경고 또는 권장 경고 규칙도 지원합니다.

일부 서비스의 경우 동일한 Azure 지역에 존재하는 동일한 형식의 여러 리소스에 동일한 메트릭 경고 규칙을 적용하여 대규모로 모니터링할 수 있습니다. 모니터링되는 각 리소스에 대해 개별 알림이 전송됩니다. 지원되는 Azure 서비스 및 클라우드에 대한 내용은 하나의 경고 규칙을 사용하여 여러 리소스 모니터링을 참조하세요.

Service Fabric 경고 규칙

다음 표에서는 Service Fabric에 대한 몇 가지 경고 규칙을 나열합니다. 이러한 경고는 예제일 뿐입니다. Service Fabric 모니터링 데이터 참조 또는 Service Fabric 이벤트 목록에 나열된 메트릭, 로그 항목 또는 활동 로그 항목에 대한 경고를 설정할 수 있습니다.

경고 유형 조건 설명
노드 이벤트 노드가 중단됩니다. ServiceFabricOperationalEvent 여기서 EventID >= 25622 및 EventID <= 25626입니다. 이러한 이벤트 ID는 노드 이벤트 참조에 있습니다.
애플리케이션 이벤트 애플리케이션 업그레이드 롤백 ServiceFabricOperationalEvent 여기서 EventID == 29623 또는 EventID == 29624. 이러한 이벤트 ID는 애플리케이션 이벤트 참조에 있습니다.
리소스 상태 업그레이드 서비스에 연결할 수 없음/사용할 수 없음 클러스터가 UpgradeServiceUnreachable 상태로 이동합니다.

Advisor 권장 사항

일부 서비스의 경우 리소스 작업 중에 위험한 상태 또는 임박한 변경 사항이 발생하는 경우 해당 서비스에서 포털의 개요 페이지에 경고가 표시됩니다. 왼쪽 메뉴의 모니터링 아래 Advisor 권장 사항에서 해당 경고에 대한 자세한 정보와 권장 수정 사항을 찾을 수 있습니다. 정상적으로 작동하는 중에는 Advisor 권장 사항이 표시되지 않습니다.

Azure Advisor에 대한 자세한 내용은 Azure Advisor 개요를 참조하세요.

각 모니터링 영역 및 예제 시나리오를 완료했으므로 다음에 제공되는 Azure 모니터링 도구 및 위의 모든 영역을 모니터링하는 데 필요한 설정 요약을 확인하세요.

또한 샘플 ARM 템플릿을 사용하고 수정하여 필요한 모든 리소스와 에이전트의 배포를 자동화할 수도 있습니다.

관련 콘텐츠