AIS Services 랜딩 존 가속기 운영 관리 고려 사항
이 문서에서는 AIS 제품을 사용할 때 운영 관리 및 모니터링에 대한 고려 사항 및 권장 사항을 제공합니다.
이 섹션의 권장 사항 대부분은 Azure App Service 제품의 일부이며 동일한 관리 기능을 많이 공유하는 Logic Apps의 표준(단일 테넌트) 버전에 적용됩니다.
AIS를 구성하는 많은 리소스는 Log Analytics/Application Insights 또는 사용자 지정 스토리지 위치에 로그, 원격 분석 및 메트릭 데이터를 저장하도록 구성할 수 있습니다(이러한 리소스에는 스토리지 계정, Event Hubs 등이 포함됨).
이 정보를 활용하여 리소스의 전반적인 상태를 시각화하고 적절한 관리 작업을 수행할 수 있습니다.
정의
Azure Monitor 로그는 모니터링되는 리소스에서 로그 및 성능 데이터를 수집하고 구성합니다. Log Analytics와 같은 도구는 이 로그 정보를 쿼리하거나 시각화하거나 특정 조건이 충족되면 경고할 수 있습니다.
Azure 메트릭 로그는 모니터링되는 리소스에서 시계열 데이터베이스로 숫자 데이터를 수집합니다. Application Insights와 같은 도구는 이 데이터를 시각화하고 성능 및 런타임 문제를 식별하는 데 도움이 될 수 있습니다.
Log Analytics 는 로그 및 성능 데이터를 저장할 수 있는 위치를 제공하는 Azure Monitoring 제품으로, 해당 로그를 쿼리하기 위한 메커니즘과 언어를 제공합니다(Kusto). 및 는 이러한 로그(다른 기능 중)를 기반으로 경고 및 대시보드를 만드는 기능을 제공합니다.
Application Insights 는 모니터링되는 리소스에서 내보낸 성능 데이터를 시각화하고 경고하는 기능을 제공하는 Azure 모니터링 제품입니다.
KQL(Kusto 쿼리 언어)은 데이터 쿼리 및 서식 지정에 최적화된 강력한 쿼리 언어입니다. 예를 들어 Log Analytics의 기본 쿼리 언어입니다.
디자인 고려 사항
모니터링 솔루션을 전체적으로 고려합니다.
모니터링해야 하는 리소스는 무엇인가요?
리소스 간에 흐르는 메시지를 어떻게 추적합니까?
어떤 외부 시스템에 연결하시겠습니까?
어떤 유형의 경고가 필요한가요?
실행해야 하는 쿼리를 생각해 보세요. 예를 들어 지정된 요청이 예상보다 오래 걸리는지 알아야 합니까? 또는 단일 오류와 오류 클러스터가 표시되는 경우
어떤 수준의 추적이 필요한가요? 예를 들어 타사에서 메시지가 도착하는 경우 연결된 모든 리소스를 통해 해당 메시지를 추적해야 합니까?
수행해야 하는 관리 작업은 무엇인가요? 메시지 또는 파일을 다시 제출해야 합니까?
논리 앱 실행 기록은 기본적으로 Azure Storage에 저장되지만 메트릭 및 로그 파일을 다른 원본(예: Log Analytics 또는 외부 스토리지 계정)으로 내보내도록 선택할 수도 있습니다. 로깅 정보를 사용하는 방법과 중앙 집중식 로그 저장소를 사용하는 경우를 고려합니다.
Application Insights는 애플리케이션 성능 모니터링을 제공하는 데 사용됩니다. 이렇게 하려면 솔루션을 구성하는 리소스에서 메트릭을 수집합니다.
Log Analytics는 로그를 쿼리하고 경고를 설정하는 데 사용되므로 리소스의 상태를 확인하고 발생할 수 있는 문제를 이해할 수 있습니다. 로그 데이터에는 사용자 지정 속성이 포함될 수 있습니다(아래 추적 속성 참조).
App Services와 관련된 추가 고려 사항 및 권장 사항은 App Service 랜딩 존 가속기 관리 문서를 참조하세요.
디자인 권장 구성
데이터 원본(작업 영역 기반 리소스라고 함)으로 Log Analytics 작업 영역을 사용하도록 Application Insights를 설정합니다. 이렇게 하면 로깅 및 성능 데이터를 통합 위치에 유지할 수 있습니다.
개별 리소스 또는 워크로드와 관련된 이벤트를 적절한 팀에 알리도록 모든 리소스에 대한 경고를 설정합니다.
지원되는 경우 솔루션의 리소스를 Application Insights에 연결합니다. 예를 들어 런타임 데이터 및 메트릭을 쿼리에 사용할 수 있도록 Logic App을 Application Insights에 연결할 수 있습니다. 예제는 여기를 참조하세요.
Logic Apps의 clientTrackingId 기능을 사용하여 사용자 지정 추적 ID를 제공하여 논리 앱 실행 간에 이벤트를 상호 연결할 수 있습니다. x-ms-client-tracking-id 헤더를 사용하여 요청, HTTP 또는 HTTP+WebHook 트리거를 사용하여 이 결과를 얻을 수 있습니다.
Logic Apps의 추적된 속성 기능을 사용하여 작업의 다른 데이터(입력 또는 출력)를 로그 파일에 기록합니다. 그런 다음 Log Analytics 또는 다른 솔루션에서 KQL을 사용하여 로그를 쿼리할 때 이러한 속성을 사용할 수 있습니다.
리소스 태그 사용을 고려합니다. 리소스 태그는 Azure에서 리소스를 관리하고 구성하는 데 도움이 될 수 있습니다. 리소스 태그를 사용하여 메타데이터를 리소스에 할당할 수 있습니다. 애플리케이션 또는 비즈니스 단위별 리소스 분류, 리소스 비용 추적, 규정 준수를 위한 리소스 식별 등 다양한 용도로 이 메타데이터를 사용할 수 있습니다.
샘플 Kusto 쿼리
아래 쿼리는 AIS 로그 데이터에 사용되는 세 기본 테이블을 쿼리하는 방법을 보여 줍니다. 이러한 각 테이블은 논리 앱의 모니터링 섹션에 있는 로그 옵션에서 액세스할 수 있습니다.
기본 쿼리 테이블은 다음과 같습니다.
exceptions
이 테이블에는 논리 앱 런타임에서 throw된 예외와 같이 리소스에 의해 기록된 모든 예외가 포함되어 있습니다. 포털에서 또는 코드를 실행하는 동안 표시되는 문제의 근본 원인을 찾는 데 사용할 수 있습니다.requests
이 표에서는 Logic App 런타임에서 수행한 모든 요청을 다른 리소스 또는 워크플로 내의 특정 작업에 기록합니다.traces
이 표에는 많은 Logic Apps 런타임 로그, 트리거 실행에 대한 로깅 세부 정보, 워크플로 시작 및 중지, 작업 실행이 포함되어 있습니다. 작업에서 추적된 속성을 기록한 경우 customDimensions 섹션에서 이 데이터를 찾을 수 있습니다. 그런 다음 쿼리에서 extend 절을 사용하여 쿼리 응답에서 데이터를 열로 추가할 수 있습니다.
오류가 있는 워크플로:
> traces
>
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
>
> \| where customDimensions.LogLevel == "Error"
모든 워크플로에서 지난 24시간 동안의 워크플로 실행 수:
> traces
>
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
>
> \| where customDimensions\["EventName"\] == "WorkflowActionStart"
>
> \| where timestamp \> ago(1d)
>
> \| count
시간에 따라 그래프로 표시된 트리거 성공률
> traces
> \| where customDimensions\["Category"\] == "Host.Triggers.Workflows"
> \| where customDimensions\["EventName"\] == "WorkflowTriggerEnd"
> \|summarize
>
> success = countif(customDimensions\["prop\_\_status"\] ==
> "Succeeded"),
>
> failures = countif(customDimensions\["prop\_\_status"\] == "Failed")
>
> by bin(timestamp, 1m)
> \| render timechart
다음 단계
아키텍처에 대한 전체 고려 사항 및 권장 사항을 확인하려면 중요한 디자인 영역을 검토합니다.