Application Insights에서 Azure Logic Apps 표준 워크플로에 대한 향상된 원격 분석 사용 및 보기
적용 대상: Azure Logic Apps(표준)
Application Insights에서 표준 논리 앱 리소스에 대해 향상된 원격 분석 수집을 사용하도록 설정한 다음 워크플로가 실행을 완료한 후 수집된 데이터를 볼 수 있습니다. 이 기능을 사용하면 워크플로에 대한 인사이트를 검색하고 데이터 원본에서 이벤트 필터링을 보다 쉽게 제어할 수 있는 간소화된 환경을 제공하여 스토리지 비용을 절감할 수 있습니다. 이러한 개선 사항은 시스템의 상태 및 동작에 대한 인사이트를 제공하는 실시간 성능 메트릭에 초점을 맞춥니다. 이렇게 하면 이전에 문제를 사전에 감지하고 해결하는 데 도움이 될 수 있습니다.
Application Insights에 연결된 논리 앱을 사용하면 라이브 메트릭 스트림을 사용하여 Azure Portal을 통해 로그 데이터 및 기타 메트릭을 거의 실시간으로 볼 수 있습니다. 들어오는 요청, 나가는 요청, 전체 상태 및 추적 수준 진단 테이블에 대한 액세스를 그리는 데 도움이 되는 시각화도 있습니다.
다음 목록에서는 몇 가지 원격 분석 개선 예제를 설명합니다.
- 트리거 및 작업 이벤트에는 이제 트리거 또는 작업 유형과 특정 커넥터 사용을 쿼리할 수 있는 API 이름이 포함됩니다.
- 재시도 이벤트를 더 쉽게 추적할 수 있도록 합니다.
- 트리거 및 작업 실패에 대한 예외를 캡처합니다.
- 워크플로가 아닌 관련 이벤트 필터링을 더 자세히 제어합니다.
- 트리거 및 작업을 포함하여 이벤트를 내보내는 방법을 더 자세히 제어할 수 있는 고급 필터링입니다.
이 가이드에서는 표준 논리 앱에 대한 Application Insights에서 향상된 원격 분석 컬렉션을 켜는 방법을 보여 줍니다.
필수 조건
Azure 계정 및 구독 구독이 없는 경우 Azure 체험 계정에 등록합니다.
Application Insights 인스턴스. 이 리소스는 표준 논리 앱을 만들 때 또는 논리 앱 배포 후에 미리 만듭니다.
Azure Portal 또는 Visual Studio Code의 표준 논리 앱 및 워크플로
논리 앱 리소스 또는 프로젝트에서는 기본적으로 사용하도록 설정되는 Azure Functions v4 런타임을 사용해야 합니다.
논리 앱은 진단 로깅 및 추적을 위해 Application Insights를 사용하도록 설정해야 합니다. 논리 앱을 만들 때 또는 배포 후에 설정할 수 있습니다.
Application Insights에서 향상된 원격 분석 사용
Azure Portal에서 표준 논리 앱 리소스를 엽니다.
논리 앱 메뉴의 개발 도구에서 고급 도구를 선택합니다. 고급 도구 페이지에서 이동을 선택합니다. 그러면 Kudu 도구가 열립니다.
Kudu 페이지의 디버그 콘솔 메뉴에서 CMD를 선택합니다. 폴더 디렉터리 테이블에서 site/wwwroot/host.json 파일을 찾아 편집을 선택합니다.
host.json 파일에서 다음 JSON 코드를 추가합니다.
{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows", "version": "[1, 2.00]" }, "extensions": { "workflow": { "Settings": { "Runtime.ApplicationInsightTelemetryVersion": "v2" } } } }이 구성을 사용하면 기본 세부 정보 표시 수준이 설정됩니다. 다른 옵션은 원본에서 필터링 적용을 참조하세요.
Application Insights 열기
워크플로에서 실행을 완료하고 몇 분 정도 지나면 Application Insights 리소스를 엽니다.
Azure Portal에 있는 논리 앱 메뉴의 설정 아래에서 Application Insights를 선택합니다.
Application Insights 리소스 메뉴의 모니터링 아래에서 로그를 선택합니다.
Application Insights에서 향상된 로그 보기
다음 섹션에서는 워크플로 실행에서 생성된 향상된 원격 분석을 찾고 볼 수 있는 Application Insights의 테이블에 대해 설명합니다.
| 테이블 이름 | 설명 |
|---|---|
| 요청 | 워크플로 실행의 다음 이벤트에 대한 세부 정보 - 트리거 및 작업 이벤트 - 재시도 횟수 - 커넥터 사용 |
| Traces | 워크플로 실행의 다음 이벤트에 대한 세부 정보 - 워크플로 시작 및 종료 이벤트 - 보내기 일괄 처리 및 받기 일괄 처리 이벤트 |
| 예외 | 워크플로 실행의 예외 이벤트에 대한 세부 정보 |
| 종속성 | 워크플로 실행의 종속성 이벤트에 대한 세부 정보 |
요청 테이블
Requests 테이블에는 표준 워크플로 실행의 다음 이벤트에 대한 데이터를 추적하는 필드가 포함되어 있습니다.
- 트리거 및 작업 이벤트
- 다시 시도 횟수
- 커넥터 사용
데이터가 이러한 필드에 입력되는 방법을 보여주기 위해 Request 트리거, Compose 작업, Response 작업으로 차례로 시작하는 다음과 같은 표준 워크플로 예가 있다고 가정해 보겠습니다.
트리거의 설정에는 사용자 지정 추적 ID라는 매개 변수가 있습니다. 매개 변수 값은 들어오는 메시지의 본문에서 orderId 속성 값을 가져오는 식으로 설정됩니다.
다음으로 워크플로의 Compose 작업 설정에는 solutionName이라는 추적된 속성이 추가되어 있습니다. 속성 값은 논리 앱 리소스의 이름으로 설정됩니다.
Compose 작업 뒤에는 호출자에게 응답을 반환하는 Response 작업이 나옵니다.
다음 목록에는 Requests 테이블에 대해 만들고 실행할 수 있는 쿼리 예가 있습니다.
| 작업 | 단계 |
|---|---|
| 모든 트리거 및 작업 이벤트 보기 | 모든 트리거 및 작업 이벤트 쿼리 |
| 트리거 이벤트 또는 작업 이벤트만 보기 | 트리거 또는 작업 이벤트만 쿼리 |
| 특정 작업 유형이 포함된 트리거 또는 작업 이벤트 보기 | 작업 유형을 기준으로 트리거 또는 작업 이벤트 쿼리 |
| 특정 워크플로 실행 ID가 포함된 트리거 및 작업 이벤트 보기 | 워크플로 실행 ID를 기준으로 트리거 및 작업 이벤트 쿼리 |
| 특정 클라이언트 추적 ID가 포함된 트리거 및 작업 이벤트 보기 | 클라이언트 추적 ID를 기준으로 트리거 및 작업 이벤트 쿼리 |
| 특정 솔루션 이름이 포함된 트리거 및 작업 이벤트 보기 | 솔루션 이름을 기준으로 트리거 및 작업 이벤트 쿼리 |
| 재시도 횟수가 포함된 트리거 및 작업 이벤트 보기 | 재시도 횟수에 대한 트리거 및 작업 이벤트 쿼리 |
| 커넥터 사용이 포함된 트리거 및 작업 이벤트 보기 | 커넥터 사용에 대한 트리거 및 작업 이벤트 쿼리 |
모든 트리거 및 작업 이벤트 쿼리
워크플로가 실행되고 몇 분 정도 지나면 Requests 테이블에 대한 쿼리를 만들어 모든 작업 이벤트를 볼 수 있습니다.
필요한 경우 검토하려는 시간 범위를 선택합니다. 기본적으로 이 값은 지난 24시간입니다.
모든 트리거 및 작업 이벤트를 보려면 다음 쿼리를 만들고 실행합니다.
requests | sort by timestamp desc | take 10다음 예에서는 각 행에 표시된 열과 데이터가 있는 결과 탭을 보여줍니다.
열 설명 예제 이름 워크플로 작업 이름 이 예의 행에는 manual(Request 트리거), Compose 및 Response가 표시되어 있습니다. success 작업 실행 상태 이 예의 모든 행에는 성공적인 실행에 대해 True가 표시되어 있습니다. 오류가 발생한 경우 값은 False입니다. resultCode 작업 실행 상태 코드 이 예의 모든 행에는 Succeeded(200)가 표시되어 있습니다. duration 작업 실행 기간 각 작업마다 다릅니다. 특정 작업에 대한 세부 정보를 보려면 트리거 또는 작업에 대한 행을 확장합니다.
다음 예에서는 Request 트리거에 대한 확장된 세부 정보를 보여줍니다.
속성 Description 예시 범주 작업 범주(항상 작업에 따라 Workflow.Operations.Triggers 또는 Workflow.Operations.Actions) Workflow.Operations.Triggers. clientTrackingId 사용자 지정 추적 ID(지정된 경우) 123456 runId 워크플로 실행 인스턴스의 ID 08585358375819913417237801890CU00 triggerName 트리거 이름 수동 workflowId 트리거를 실행한 워크플로의 ID c7711d107e6647179c2e15fe2c2720ce workflowName 트리거를 실행한 워크플로의 이름 Request-Response-Workflow operation_Name 트리거를 실행한 작업의 이름입니다. 이 경우 이 이름은 워크플로 이름과 동일합니다. Request-Response-Workflow operation_Id 방금 실행된 구성 요소 또는 워크플로의 ID입니다. 이 ID는 워크플로 실행 인스턴스의 runId 값과 동일합니다. 예외 또는 종속성이 있는 경우 이 값은 테이블을 트랜센드하므로 이 트리거 레코드를 해당 예외 또는 종속성에 연결할 수 있습니다. 08585358375819913417237801890CU00 operation_ParentId 트리거를 호출한 워크플로의 연결 가능한 ID f95138daff8ab129 다음 예에서는 Compose 작업에 대한 확장된 세부 정보를 보여줍니다.
속성 Description 예시 범주 작업 범주(항상 작업에 따라 Workflow.Operations.Triggers 또는 Workflow.Operations.Actions) Workflow.Operations.Actions clientTrackingId 사용자 지정 추적 ID(지정된 경우) 123456 actionName 작업 이름 Compose runId 워크플로 실행 인스턴스의 ID 08585358375819913417237801890CU00 workflowId 작업을 실행한 워크플로의 ID c7711d107e6647179c2e15fe2c2720ce workflowName 작업을 실행한 워크플로의 이름 Request-Response-Workflow solutionName 추적된 속성 이름(지정된 경우) LA-AppInsights operation_Name 작업을 실행한 작업의 이름. 이 경우 이 이름은 워크플로 이름과 동일합니다. Request-Response-Workflow operation_Id 방금 실행된 구성 요소 또는 워크플로의 ID입니다. 이 ID는 워크플로 실행 인스턴스의 runId 값과 동일합니다. 예외 또는 종속성이 있는 경우 이 값은 테이블을 트랜센드하므로 이 작업 레코드를 해당 예외 또는 종속성에 연결할 수 있습니다. 08585358375819913417237801890CU00 operation_ParentId 작업을 호출한 워크플로의 연결 가능한 ID f95138daff8ab129
트리거 또는 작업 이벤트만 쿼리
Requests 테이블에 대한 쿼리를 만들어 작업 범주 및 워크플로 이름을 기반으로 하여 작업 이벤트의 하위 집합을 볼 수 있습니다.
필요한 경우 검토하려는 시간 범위를 선택합니다. 기본적으로 이 값은 지난 24시간입니다.
특정 워크플로의 모든 트리거 이벤트를 보려면 customDimensions.Category 속성 값이 Workflow.Operations.Triggers로 설정되고 operation_Name이 워크플로 이름으로 설정된 쿼리를 만들고 실행합니다. 예를 들어 다음과 같습니다.
requests | where customDimensions.Category == "Workflow.Operations.Triggers" and operation_Name == "Request-Response-Workflow"
특정 워크플로의 모든 작업 이벤트를 보려면 customDimensions.Category 속성 값이 Workflow.Operations.Actions로 설정되고 operation_Name을 워크플로 이름으로 설정된 쿼리를 만들고 실행합니다. 예를 들어 다음과 같습니다.
requests | where customDimensions.Category == "Workflow.Operations.Actions" and operation_Name == "Request-Response-Workflow"
작업 유형을 기준으로 트리거 또는 작업 이벤트 쿼리
Requests 테이블에 대한 쿼리를 만들어 특정 트리거 또는 작업 유형에 대한 이벤트를 볼 수 있습니다.
필요한 경우 검토하려는 시간 범위를 선택합니다. 기본적으로 이 값은 지난 24시간입니다.
특정 트리거 유형이 포함된 모든 작업 이벤트를 보려면 customDimensions.triggerType 값이 원하는 트리거 유형으로 설정된 쿼리를 만들고 실행합니다. 예를 들어 다음과 같습니다.
requests | where customDimensions.triggerType == "Request"
특정 작업 유형이 포함된 모든 작업 이벤트를 보려면 customDimensions.actionType 값이 원하는 작업 유형으로 설정된 쿼리를 만들고 실행합니다. 예를 들어 다음과 같습니다.
requests | where customDimensions.actionType == "Compose"
워크플로 실행 ID를 기준으로 트리거 및 작업 이벤트 쿼리
Requests 테이블에 대한 쿼리를 만들어 워크플로 실행 ID를 기반으로 하여 작업 이벤트의 하위 집합을 볼 수 있습니다. 이 워크플로 실행 ID는 워크플로 실행 기록에서 찾을 수 있는 ID와 동일합니다.
필요한 경우 검토하려는 시간 범위를 선택합니다. 기본적으로 이 값은 지난 24시간입니다.
특정 워크플로 실행 ID가 있는 모든 작업 이벤트를 보려면 operation_Id 값이 워크플로 실행 ID로 설정된 쿼리를 만들고 실행합니다. 예를 들어 다음과 같습니다.
requests | where operation_Id == "08585287554177334956853859655CU00"
클라이언트 추적 ID를 기준으로 트리거 및 작업 이벤트 쿼리
Requests 테이블에 대한 쿼리를 만들어 워크플로 이름과 클라이언트 추적 ID를 기반으로 하여 작업 이벤트의 하위 집합을 볼 수 있습니다.
필요한 경우 검토하려는 시간 범위를 선택합니다. 기본적으로 이 값은 지난 24시간입니다.
특정 워크플로의 특정 클라이언트 추적 ID가 포함된 모든 작업 이벤트를 보려면 operation_Name 값이 워크플로 이름으로 설정되고 clientTrackingId 속성 값이 원하는 값으로 설정된 쿼리를 만들고 실행합니다. 예를 들어 다음과 같습니다.
requests | where operation_Name == "Request-Response-Workflow" | extend correlation = todynamic(tostring(customDimensions.correlation)) | where correlation.clientTrackingId == "123456"
솔루션 이름을 기준으로 트리거 및 작업 이벤트 쿼리
Requests 테이블에 대한 쿼리를 만들어 워크플로 이름과 솔루션 이름을 기반으로 하여 작업 이벤트의 하위 집합을 볼 수 있습니다.
필요한 경우 검토하려는 시간 범위를 선택합니다. 기본적으로 이 값은 지난 24시간입니다.
특정 워크플로의 특정 클라이언트 추적 ID가 포함된 모든 작업 이벤트를 보려면 operation_Name 값이 워크플로 이름으로 설정되고 solutionName 속성 값이 원하는 값으로 설정된 쿼리를 만들고 실행합니다. 예를 들어 다음과 같습니다.
requests | where operation_Name == "Request-Response-Workflow" and customDimensions has "trackedProperties" | extend trackedProperties = todynamic(tostring(customDimensions.trackedProperties)) | where trackedProperties.solutionName == "LA-AppInsights"
다시 시도 횟수
이 데이터가 Requests 테이블에 입력되는 방법을 보여주기 위해 다음 표준 워크플로 예에서는 확인되지 않는 URL을 호출하는 HTTP 작업을 사용합니다. 워크플로에는 60초마다 한 번씩 세 번 다시 시도하는 고정 간격으로 설정된 재시도 정책도 있습니다.
재시도 횟수에 대한 트리거 및 작업 이벤트 쿼리
Requests 테이블에 대한 쿼리를 만들어 재시도 횟수가 포함된 작업 이벤트의 하위 집합을 볼 수 있습니다.
필요한 경우 검토하려는 시간 범위를 선택합니다. 기본적으로 이 값은 지난 24시간입니다.
다시 시도 기록이 포함된 트리거 및 작업 이벤트만 보려면 Application Insights에서 다음 쿼리를 만들고 실행합니다.
requests | extend retryHistory = tostring(tostring(customDimensions.retryHistory)) | where isnotempty(retryHistory)재시도 정책이 포함된 특정 작업에 대한 재시도 횟수를 보려면 해당 작업에 대한 행을 확장합니다.
다음 예에서는 HTTP 작업에 대한 확장된 세부 정보를 보여줍니다.
success 및 resultCode 속성 값은 HTTP 작업이 실패했음을 나타냅니다. 레코드에는 모든 트리거 및 작업 이벤트에 대한 Requests 테이블 쿼리에서 설명하는 속성과 함께 세 번의 다시 시도를 포함하는 다음 정보가 포함됩니다.
속성 Description 예시 retryHistory 한 번 이상의 재시도 횟수에 대한 기록 세부 정보 code 특정 재시도 횟수에 대한 오류 유형 error 발생한 특정 오류에 대한 세부 정보
커넥터 사용에 대한 트리거 및 작업 이벤트 쿼리
Requests 테이블에 대한 쿼리를 만들어 특정 커넥터 사용을 기반으로 하여 작업 이벤트의 하위 집합을 볼 수 있습니다.
필요한 경우 검토하려는 시간 범위를 선택합니다. 기본적으로 이 값은 지난 24시간입니다.
특정 커넥터 유형이 포함된 모든 트리거 이벤트를 보려면 다음 속성과 값을 사용하는 쿼리를 만들고 실행합니다.
requests | where customDimensions.Category == "Workflow.Operations.Triggers" and customDimensions.triggerType =="ApiConnectionWebhook" and customDimensions.apiName =="commondataservice"속성 예제 값 customDimensions.Category Workflow.Operations.Triggers customDimensions.triggerType 작업 유형(예: ApiConnectionWebhook) customDimensions.apiName JSON 형식의 커넥터 API 이름(예: Microsoft Dataverse 커넥터의 경우 commondataservice) 
특정 커넥터 사용이 포함된 모든 작업 이벤트를 보려면 customDimensions.Category 값이 Workflow.Operations.Actions로 설정되고, customDimensions.triggerType 값이 작업 유형으로 설정되고, customDimensions.apiName이 JSON 형식의 커넥터 API 이름으로 설정된 쿼리를 만들고 실행합니다. 예를 들어 다음과 같습니다.
속성 예제 값 customDimensions.Category Workflow.Operations.Actions customDimensions.triggerType 작업 유형(예: ApiConnection) customDimensions.apiName JSON 형식의 커넥터 API 이름(예: Microsoft Office 365 Outlook 커넥터의 경우 office365) requests | where customDimensions.Category == "Workflow.Operations.Actions" and customDimensions.actionType == "ApiConnection" and customDimensions.apiName == "office365"
트리거와 작업 모두에 대해 Application Insights는 존재하는 연결 유형을 구분합니다. ApiConnection, ApiConnectionWebhook, 기본 제공 유형(예: Request) 또는 기본 제공 서비스 공급자 기반 ServiceProvider 유형이 연결에 있는지 여부에 따라 actionType 및 triggerType 필드에 다른 값이 표시될 수 있습니다.
추적 테이블
Traces 테이블에는 표준 워크플로 실행의 다음 이벤트에 대한 데이터를 추적하는 필드가 포함되어 있습니다.
워크플로 시작 및 종료 이벤트
이 정보는 장기 실행 워크플로 실행 가능성으로 인해 두 개의 개별 이벤트로 표시됩니다.
보내기 및 받기 일괄 처리 이벤트
자세한 내용은 Azure Logic Apps에서 기본 제공 Batch 작업 사용(표준)을 참조하세요.
다음 목록에는 Traces 테이블에 대해 만들고 실행할 수 있는 쿼리 예가 있습니다.
| 작업 | 단계 |
|---|---|
| 모든 워크플로 실행의 시작 및 종료 이벤트 보기 | 모든 워크플로 실행의 시작 및 종료 이벤트 쿼리 |
| 특정 워크플로 실행의 시작 및 종료 이벤트 보기 | 워크플로 실행의 시작 및 종료 이벤트 쿼리 |
| 모든 워크플로 실행의 보내기 및 받기 일괄 처리 이벤트 보기 | 모든 워크플로 실행의 보내기 일괄 처리 및 받기 일괄 처리 이벤트 쿼리 |
모든 워크플로 실행의 시작 및 종료 이벤트 쿼리
Traces 테이블에 대한 쿼리를 만들어 모든 워크플로 실행에 대한 시작 및 종료 이벤트를 모두 볼 수 있습니다.
필요한 경우 검토하려는 시간 범위를 선택합니다. 기본적으로 이 값은 지난 24시간입니다.
예를 들어 customDimensions.Category 값이 Workflow.Operations.Runs로 설정된 쿼리를 만들고 실행합니다.
traces | where customDimensions.Category == "Workflow.Operations.Runs"
특정 워크플로 실행의 시작 및 종료 이벤트 쿼리
Traces 테이블에 대한 쿼리를 만들어 특정 워크플로 실행에 대한 시작 및 종료 이벤트를 볼 수 있습니다.
필요한 경우 검토하려는 시간 범위를 선택합니다. 기본적으로 이 값은 지난 24시간입니다.
customDimensions.Category 값이 Workflow.Operations.Runs로 설정되고 operation_Id 값이 워크플로 실행 ID로 설정된 쿼리를 만들고 실행합니다. 예를 들어 다음과 같습니다.
traces | where customDimensions.Category == "Workflow.Operations.Runs" | and operation_Id == "08585287571846573488078100997CU00"
모든 워크플로 실행의 보내기 일괄 처리 및 받기 일괄 처리 이벤트 쿼리
Traces 테이블에 대한 쿼리를 만들어 모든 워크플로 실행의 보내기 일괄 처리 및 받기 일괄 처리 이벤트를 볼 수 있습니다.
필요한 경우 검토하려는 시간 범위를 선택합니다. 기본적으로 이 값은 지난 24시간입니다.
customDimensions.Category 값이 Workflow.Operations.Runs로 설정되고 operation_Id 값이 워크플로 실행 ID로 설정된 쿼리를 만들고 실행합니다. 예를 들어 다음과 같습니다.
traces | where customDimensions.Category == "Workflow.Operations.Batch"
예외 테이블
Exceptions 테이블에는 표준 워크플로 실행의 예외 이벤트에 대한 데이터를 추적하는 필드가 포함되어 있습니다. 데이터가 이러한 필드에 입력되는 방법을 보여주기 위해 Request 트리거, Compose 작업, Response 작업으로 차례로 시작하는 다음과 같은 표준 워크플로 예가 있다고 가정해 보겠습니다. Compose 작업은 값을 0으로 나누는 식을 사용하여 예외를 생성합니다.
모든 워크플로 실행의 예외 이벤트 쿼리
Exceptions 테이블에 대한 쿼리를 만들어 모든 워크플로 실행의 예외 이벤트를 볼 수 있습니다.
필요한 경우 검토하려는 시간 범위를 선택합니다. 기본적으로 이 값은 지난 24시간입니다.
모든 예외 이벤트를 보려면 Application Insights에서 다음 쿼리를 만들고 실행합니다.
exceptions | sort by timestamp desc특정 예외에 대한 세부 정보를 보려면 해당 예외에 대한 행을 확장합니다.
다음 예에서는 Compose 작업에 대한 확장된 예외와 해당 예외에 대한 세부 정보를 보여줍니다.
속성 설명 problemId 예외 유형 또는 발생한 예외에 대한 간단한 설명 outerMessage 예외에 대한 자세한 설명 details 예외에 대한 세부 정보 및 가장 완전한 정보 clientTrackingId 클라이언트 추적 ID(지정된 경우) workflowId 예외가 발생한 워크플로의 ID workflowName 예외가 발생한 워크플로의 이름 runId 워크플로 실행 인스턴스의 ID actionName 예외로 인해 실패한 작업의 이름 operation_Name 예외가 발생한 워크플로의 이름 operation_Id 방금 실행된 구성 요소 또는 워크플로의 ID입니다. 이 ID는 워크플로 실행 인스턴스의 runId 값과 동일합니다. 이 값은 테이블을 트랜센드하므로 이 예외 레코드를 워크플로 실행 인스턴스에 연결할 수 있습니다. operation_ParentId 작업을 호출한 워크플로의 ID(Requests 테이블의 작업 ID에 연결할 수 있음) 특정 워크플로에 대한 예외를 보려면 다음 쿼리를 만들고 실행합니다.
exceptions | where operation_Name contains "Request-Response-Workflow-Exception"
종속성 테이블
Dependencies 테이블에는 표준 워크플로 실행의 종속성 이벤트에 대한 데이터를 추적하는 필드가 포함되어 있습니다. 이러한 이벤트는 한 리소스에서 다른 리소스를 호출하고 두 리소스에서 모두 Application Insights를 사용할 때 발생합니다. Azure Logic Apps의 예로 HTTP, 데이터베이스 또는 파일 시스템을 통해 다른 서비스를 호출하는 서비스가 있습니다. Application Insights는 종속성 이름과 같은 정보와 함께 종속성 호출 기간과 해당 호출의 성공 또는 실패 여부를 측정합니다. 특정 종속성 호출을 조사하고 요청 및 예외와의 상관 관계를 지정할 수 있습니다.
데이터가 이러한 필드에 입력되는 방법을 보여주기 위해 HTTP 작업을 사용하여 HTTP를 통해 자식 워크플로를 호출하는 다음과 같은 표준 부모 워크플로 예가 있다고 가정해 보겠습니다.
특정 워크플로의 종속성 이벤트 쿼리
Dependencies 테이블에 대한 쿼리를 만들어 특정 워크플로 실행의 종속성 이벤트를 볼 수 있습니다.
필요한 경우 검토하려는 시간 범위를 선택합니다. 기본적으로 이 값은 지난 24시간입니다.
부모 워크플로와 자식 워크플로 간의 종속성 이벤트를 보려면 다음 쿼리를 만들고 실행합니다.
union requests, dependencies | where operation_Id contains "<runId>"이 쿼리는 union 연산자를 사용하여 Requests 테이블과 Dependencies 테이블의 레코드를 반환합니다. 또한 이 쿼리는 operation_Id 속성 값에서 원하는 워크플로 runId 값을 지정하여 레코드 간 링크를 제공합니다. 예를 들어 다음과 같습니다.
union requests, dependencies | where operation_Id contains "08585355753671110236506928546CU00"다음 예에서는 부모 워크플로에 있는 Requests 테이블의 작업 이벤트에 대한 레코드와 Dependencies 테이블의 종속성 레코드를 포함하여 지정된 워크플로에 대한 종속성 이벤트를 보여줍니다.
작업 이벤트 레코드의 경우 itemType 열에는 해당 레코드 형식이 request로 표시됩니다. 종속성 레코드의 경우 itemType 열에는 해당 레코드 형식이 dependency로 표시됩니다.
속성 설명 runId 워크플로 실행 인스턴스의 ID actionName 종속성 이벤트가 발생하는 작업의 이름 operation_Id 지정된 워크플로의 ID. 이 ID는 워크플로 실행 인스턴스의 runId 값과 동일합니다. 이 값은 테이블을 트랜센드하므로 이 종속성 레코드를 워크플로 실행 인스턴스에 연결할 수 있습니다. operation_ParentId 종속성 이벤트가 발생하는 작업에 대한 ID이며, 작업 이벤트 레코드와 종속성 이벤트 레코드도 함께 연결합니다.
쿼리를 사용하면 Application Insights에서 애플리케이션 맵을 사용할 때 부모 워크플로에서 자식 워크플로로의 종속성 호출을 시각화할 수도 있습니다. 쿼리의 operation_Id 값은 이 시각화를 가능하게 하는 링크를 제공합니다.
애플리케이션 맵을 열려면 Application Insights 리소스 메뉴의 조사 아래에서 애플리케이션 맵을 선택합니다.
이벤트 필터링
Application Insights에서는 다음과 같은 방법으로 이벤트를 필터링할 수 있습니다.
이전 섹션에서 설명한 대로 쿼리를 만들고 실행합니다.
이벤트를 내보내기 전에 평가할 조건을 지정하여 원본에서 필터링합니다.
원본에서 필터를 적용하면 필요한 스토리지 양을 줄이고 이에 따라 운영 비용도 줄일 수 있습니다.
원본에서 필터링 적용
Requests 테이블 또는 Traces 테이블의 레코드에는 Category 속성이 포함된 customDimensions라는 노드가 있습니다. 예를 들어 Requests 테이블에서 Batch 트리거 이벤트에 대한 요청 레코드는 다음 샘플과 비슷합니다.
Requests 테이블에서 다음 Category 속성 값을 사용하면 다양한 세부 정보 표시 수준을 구분하고 연결할 수 있습니다.
| Category 값 | 설명 |
|---|---|
| Workflow.Operations.Triggers | 트리거 이벤트에 대한 요청 레코드를 식별합니다. |
| Workflow.Operations.Actions | 작업 이벤트에 대한 요청 레코드를 식별합니다. |
각 Category 값에 대해 논리 앱 리소스 또는 프로젝트에 대한 host.json 파일의 세부 정보 표시 수준을 독립적으로 설정할 수 있습니다. 예를 들어 오류가 있는 트리거 또는 작업 이벤트에 대한 레코드만 반환하려면 host.json 파일에서 세부 정보 표시 수준이 있는 logLevel JSON 개체가 포함된 다음 logging JSON 개체를 추가할 수 있습니다.
{
"logging": {
"logLevel": {
"Workflow.Operations.Actions": "Error",
"Workflow.Operations.Triggers": "Error"
}
}
}
Traces 테이블 레코드의 경우 다음 예제에서는 이벤트에 대한 세부 정보 표시 수준을 변경할 수 있는 방법을 보여줍니다.
{
"logging": {
"logLevel": {
"Workflow.Host": "Warning",
"Workflow.Jobs": "Warning",
"Workflow.Runtime": "Warning"
}
}
}
다음 예제에서는 로그의 기본 세부 정보 표시 수준을 Warning으로 설정하지만, 트리거, 작업 및 워크플로 실행 이벤트에 대한 세부 정보 표시 수준은 Information으로 유지합니다.
{
"logging": {
"logLevel": {
"default": "Warning",
"Workflow.Operations.Actions": "Information",
"Workflow.Operations.Runs": "Information",
"Workflow.Operations.Triggers": "Information"
}
}
}
logLevel 값이 지정되지 않으면 기본 세부 정보 표시 수준은 Information입니다. 자세한 내용은 로그 수준 구성을 참조하세요.
Azure Portal에서 표준 논리 앱 리소스를 엽니다.
논리 앱 메뉴의 개발 도구에서 고급 도구를 선택합니다. 고급 도구 페이지에서 이동을 선택합니다. 그러면 Kudu 도구가 열립니다.
Kudu 페이지의 디버그 콘솔 메뉴에서 CMD를 선택합니다. 폴더 디렉터리 테이블에서 site/wwwroot/host.json 파일을 찾아 편집을 선택합니다.
host.json 파일에서 logLevel 값이 원하는 세부 정보 표시 수준으로 설정된 logging JSON 개체를 추가합니다.
{ "logging": { "logLevel": { "Workflow.Operations.Actions": "<verbosity-level>", "Workflow.Operations.Triggers": "<verbosity-level>" } } }
Application Insights에서 워크플로 메트릭 보기
Application Insights의 향상된 원격 분석 기능을 사용하면 [메트릭] 대시보드에서도 워크플로 인사이트를 얻을 수 있습니다.
메트릭 대시보드 열고 기본 필터 설정
아직 열지 않은 경우 Azure Portal에서 Application Insights 리소스를 엽니다.
Application Insights 리소스 메뉴의 모니터링 아래에서 메트릭을 선택합니다.
범위 목록에서 Application Insights 인스턴스를 선택합니다.
메트릭 네임스페이스 목록에서 workflow.operations를 선택합니다.
메트릭 목록에서 메트릭을 선택합니다(예: 실행 완료).
집계 목록에서 유형을 선택합니다(예: 개수 또는 평균).
완료되면 [메트릭] 대시보드에 완료된 워크플로 실행이 포함된 차트가 표시됩니다.
특정 워크플로 기준 필터링
[메트릭] 대시보드에서 다차원 메트릭을 사용하도록 설정하면 Application Insights에서 캡처된 전체 이벤트의 하위 집합을 대상으로 지정하고 특정 워크플로를 기준으로 이벤트를 필터링할 수 있습니다.
Application Insights 리소스에서 다차원 메트릭을 사용하도록 설정합니다.
Application Insights에서 메트릭 대시보드를 엽니다.
차트 도구 모음에서 필터 추가를 선택합니다.
속성 목록에서 워크플로를 선택합니다.
연산자 목록에서 등호(=)를 선택합니다.
값 목록에서 원하는 워크플로를 선택합니다.
"라이브" 로그 데이터 및 메트릭 보기
Application Insights의 향상된 원격 분석을 사용하면 Azure Portal에서 Application Insights 인스턴스의 근 실시간 로그 데이터 및 기타 메트릭을 볼 수 있습니다. 이 시각화를 사용하여 인바운드 요청, 아웃바운드 요청 및 전체 상태를 표시할 수 있습니다. 추적 수준 진단에 대한 테이블도 가져옵니다.
아직 열지 않은 경우 Azure Portal에서 Application Insights 리소스를 엽니다.
Application Insights 리소스 메뉴의 조사 아래에서 라이브 메트릭을 선택합니다.
라이브 메트릭 페이지에 로그 데이터와 기타 메트릭이 표시됩니다. 예를 들어 다음과 같습니다.
자세한 내용은 라이브 메트릭: 1초 대기 시간으로 모니터링 및 진단을 참조하세요.
참고 항목
표준 논리 앱 워크플로는 Azure Functions를 기반으로 하므로 라이브 메트릭은 이러한 논리 앱 워크플로를 지원합니다.
애플리케이션 로그 파일에서 디버그 출력 스트리밍 및 보기
Application Insights의 향상된 원격 분석을 사용하면 Azure Portal에서 애플리케이션의 로그 파일에 대한 자세한 디버깅 정보를 스트림할 수 있습니다. 이 정보는 로컬 Visual Studio Code 환경에서 워크플로를 디버그하여 생성된 출력과 동일합니다.
Azure Portal에서 표준 논리 앱 리소스를 엽니다.
논리 앱 리소스 메뉴의 모니터링 아래에서 로그 스트림을 선택합니다.
로그 스트림 페이지가 Application Insights 인스턴스에 연결되고 디버깅 출력이 표시됩니다. 예를 들어 다음 출력에는 기타 정보 중에서 요청 및 응답 호출이 포함되어 있습니다.
