Azure Communication Services 호출 로그 개요
Azure Communication Services는 Communication Services 솔루션을 모니터링하고 디버깅하는 데 사용할 수 있는 로깅 기능을 제공합니다. Azure Portal을 통해 이러한 기능을 구성합니다.
이 문서의 내용은 Azure Monitor를 통해 사용하도록 설정된 로그를 참조합니다(FAQ 참조). 이러한 로그를 Communication Services에 사용하도록 설정하려면 진단 설정에서 로깅 사용을 참조하세요.
Important
로그를 분석하려면 로그를 수집해야 합니다. 자세한 내용은 다음을 참조하세요. 어떻게 할까요? 로그를 저장하시겠습니까?
이러한 특정 진단 설정을 사용하도록 설정하지 않는 한 Azure는 통화 로그 데이터를 저장하지 않습니다. 통화 데이터는 소급하여 사용할 수 없습니다. 진단 설정을 만든 후 데이터를 누적합니다.
통화 로그를 사용하는 방법
통화 사용량을 모니터링하고 통화 품질을 개선하고 릴리스할 때 Azure Communication Services에서 새 로그를 받을 수 있도록 로그 분석 리소스에서 사용 가능한 모든 통화 로그를 수집하는 것이 좋습니다.
통화를 모니터링하고 통화 품질을 개선하는 데 사용할 수 있는 두 가지 주요 도구가 있습니다.
음성 및 비디오 인사이트 대시보드 대시보드를 사용하여 품질 조사를 시작하고 필요에 따라 통화 진단을 사용하여 세부적인 세부 정보가 필요할 때 개별 통화를 탐색하는 것이 좋습니다.
사용 가능한 로그
Azure Communication Services는 8개의 호출 로그를 만듭니다.
호출 요약 업데이트 로그:
이러한 로그 데이터는 호출 요약 로그보다 더 빠르게 Azure Monitor에 도착하며 호출 요약 로그 스키마 대신 이러한 로그를 사용하는 것이 좋습니다. 이 로그에는 모든 관련 ID, 타임스탬프를 포함한 호출에 대한 기본 정보, 엔드포인트 및 SDK 정보가 포함됩니다.
자세한 내용은 다음을 참조하세요 . 통화 요약 업데이트 로그 스키마
통화 요약 로그:
이 로그는 호출 요약 업데이트 로그 스키마의 하위 집합입니다. 여기에는 모든 관련 ID, 타임스탬프를 포함한 호출에 대한 기본 정보, 엔드포인트 및 SDK 정보가 포함됩니다. 더 빠른 로그 대기 시간을 위해 대신 호출 요약 업데이트 로그를 사용합니다.
자세한 내용은 다음을 참조하세요 . 통화 요약 로그 스키마
진단 업데이트 로그 호출:
이러한 로그 데이터는 호출 진단 로그보다 더 빠르게 Azure Monitor에 도착하며 호출 진단 로그 스키마 대신 이러한 로그를 사용하는 것이 좋습니다. 이 로그에는 참가자의 통화 미디어 스트림에 대한 정보와 경험 측정 품질을 나타내는 메트릭 집합이 포함되어 있습니다.
자세한 내용은 다음을 참조하세요 . 진단 업데이트 로그 스키마 호출
진단 로그 호출:
이 로그는 호출 진단 업데이트 로그 스키마의 하위 집합입니다. 여기에는 환경 측정 품질을 나타내는 메트릭 집합과 함께 스트림에 대한 정보가 포함됩니다. 더 빠른 로그 대기 시간을 위해 대신 호출 요약 업데이트 로그를 사용합니다.
자세한 내용은 다음을 참조하세요 . 진단 로그 스키마 호출
클라이언트 작업 로그 호출:
자세한 호출 클라이언트 이벤트를 포함합니다. 이러한 로그 이벤트는 통화의 각 EndpointId에 대해 생성되며, 생성되는 이벤트 로그 수는 통화 중에 참가자가 수행한 작업에 따라 달라집니다.
자세한 내용은 다음을 참조 하세요. 클라이언트 작업 로그 스키마 호출
클라이언트 미디어 통계 로그 호출:
자세한 미디어 스트림 값을 포함합니다. 이러한 로그는 통화의 각 미디어 스트림에 대해 생성됩니다. 통화(서버 포함) 내의 각 EndpointId에 대해 Azure Communication Services에서 엔드포인트 간의 각 미디어 스트림(예: 오디오 또는 비디오)에 대해 고유한 로그를 만듭니다. 각 로그에서 생성된 데이터의 볼륨은 통화 기간 및 통화 중 미디어 스트림 수에 따라 달라집니다.
P2P 통화에서 각 로그에는 각 엔드포인트와 연결된 각 아웃바운드 스트림과 관련된 데이터가 포함됩니다. 그룹 통화에서 endpointType = "Server"에 연결된 각 스트림은 인바운드 스트림에 대한 데이터가 포함된 로그를 만듭니다. 다른 모든 스트림은 서버가 아닌 모든 엔드포인트에 대한 아웃바운드 스트림에 대한 데이터를 포함하는 로그를 만듭니다. 그룹 통화에서 participantId 값을 키로 사용하여 관련된 인바운드 및 아웃바운드 로그를 고유한 참가자 연결에 조인합니다.
자세한 내용은 다음을 참조하세요. 클라이언트 미디어 통계 시계열 로그 스키마 호출
통화 종료 설문 조사 로그:
이러한 로그는 웹 호출 클라이언트가 호출이 끝날 때 설문 조사를 제출할 때 채워집니다. 이러한 로그를 사용하여 사용자의 통화 품질에 대한 주관적인 인식을 학습할 수 있습니다.
자세한 내용은 다음을 참조하세요. 통화 종료 설문 조사 개요
메트릭 로그 호출:
이러한 로그에는 SDK 버전, OS 이름 및 오류 하위 코드와 같은 특성에 따라 일일 bin에 집계된 호출 메트릭이 포함됩니다. 이러한 로그는 음성 및 비디오 인사이트 대시보드에서 다양한 작업의 성공 및 실패한 통화 SDK API 호출 수에 따라 안정성, 품질 및 성능의 장기 그래프를 시각화하는 데 사용됩니다.
자세한 내용은 다음을 참조 하세요. 메트릭 로그 스키마 호출
데이터 개념
다음과 같은 데이터 개념에 대한 개략적인 설명은 음성 및 영상 통화와 관련이 있습니다. 로그에 캡처된 데이터의 의미를 이해할 수 있도록 이러한 개념을 검토해야 합니다.
엔터티 및 ID
다음 용어를 숙지하세요.
통화: 데이터에 표시된 대로 통화는
correlationId로 표시되는 추상적 개념입니다.correlationId값은 각 통화마다 고유하며callStartTime및callDuration을 기반으로 시간 제한됩니다.참가자: 엔드포인트와 서버 간의 연결을 나타냅니다. 참가자(
participantId)는 통화가 그룹 통화인 경우에만 있습니다.엔드포인트:
endpointId로 표시되는 가장 고유한 엔터티입니다. 모든 통화는 둘 이상의 엔드포인트의 데이터를 포함하는 이벤트입니다. 엔드포인트는 통화의 참가자를 나타냅니다.EndpointType은 엔드포인트가 인간 사용자(PSTN 또는 VoIP)인지, 봇인지 또는 통화 내에서 여러 참가자를 관리하는 서버인지를 알려줍니다.endpointType값이"Server"이면 고유 ID가 엔드포인트에 할당되지 않습니다.endpointType및endpointId값의 수를 분석하여 통화에 참여하는 사용자 및 인간이 아닌 기타 참가자(봇 및 서버)의 수를 확인할 수 있습니다.Android 및 iOS용 네이티브 SDK는 여러 통화에서 사용자에 대해 동일한
endpointId값을 다시 사용하므로 세션 간 환경을 이해할 수 있습니다. 이 프로세스는 각각의 새 통화에 대해 항상 새endpointId값을 생성하는 웹 기반 엔드포인트와 다릅니다.스트림: 가장 세분화된 엔터티입니다. 각 방향(인바운드 또는 아웃바운드) 및
mediaType값(예:Audio또는Video)에 대해 하나의 스트림이 있습니다.
P2P 통화 및 그룹 통화
참고 항목
이 문서에서 P2P 및 그룹 호출은 기본적으로 동일한 테넌트 내에 있습니다. 교차 테넌트인 모든 호출 시나리오는 문서 전체에서 적절하게 지정됩니다.
callType으로 표시되는 통화에는 두 가지 유형이 있습니다.
P2P(피어 투 피어) 통화: 서버 엔드포인트 없는 두 엔드포인트 간의 연결입니다. P2P 통화는 이러한 엔드포인트 간의 통화로 시작되며, 연결 전에 그룹 통화 이벤트로 만들어지지 않습니다.
그룹 통화: 3개 이상의 엔드포인트가 연결된 통화입니다. 그룹 통화에는 서버 엔드포인트 및 각 엔드포인트와 서버 간의 연결이 포함됩니다. 통화 중에 다른 엔드포인트를 추가하는 P2P 통화는 더 이상 P2P가 아니며 그룹 통화가 됩니다.
participantStartTime및participantDuration메트릭을 사용하여 각 엔드포인트가 통화에 참여한 시점의 타임라인을 확인할 수 있습니다.
다양한 호출 유형의 예
참고 항목
이 문서에서 P2P 및 그룹 호출은 기본적으로 동일한 테넌트 내에 있습니다. 교차 테넌트인 모든 호출 시나리오는 문서 전체에서 적절하게 지정됩니다.
예: P2P 통화
다음 다이어그램에서는 P2P 통화에 직접 연결된 두 개의 엔드포인트를 나타냅니다. 이 예제에서 Communication Services는 두 개의 호출 요약 로그(각 participantID 값에 대해 하나씩)와 4개의 호출 진단 로그(각 미디어 스트림에 대해 하나씩)를 만듭니다.
Azure Communication Services 통화 클라이언트 참가자의 경우 일련의 통화 클라이언트 작업 로그 및 통화 클라이언트 미디어 통계 시계열 로그도 있습니다. 이러한 로그의 정확한 수는 호출되는 SDK 작업의 종류와 통화 시간에 따라 달라집니다.
예: 그룹 통화
다음 다이어그램에서는 3개의 participantId 값(3명 참가자)과 하나의 서버 엔드포인트가 있는 그룹 통화 예를 나타냅니다.
endpointId에 대한 여러 값은 잠재적으로 여러 참가자에게 나타날 수 있습니다(예: 동일한 디바이스에서 통화에 다시 참여하는 경우). Communication Services는 각 participantId 값에 대해 하나의 통화 요약 로그를 만듭니다. 4개의 호출 진단 로그(각 미디어 스트림당 participantId하나씩)를 만듭니다.
Azure Communication Services 통화 클라이언트 참가자의 경우 통화 클라이언트 작업 로그는 P2P 통화와 동일합니다. 통화 SDK를 사용하는 각 참가자에 대해 일련의 통화 클라이언트 작업 로그가 있습니다.
Azure Communication Services 통화 클라이언트 작업 로그 및 통화 클라이언트 미디어 통계 시계열 로그는 P2P 통화와 동일합니다. 통화 SDK를 사용하는 각 참가자의 경우 일련의 통화 클라이언트 작업 로그 및 통화 클라이언트 미디어 통계 시계열 로그가 있습니다.
예: 테넌트 간 P2P 통화
다음 다이어그램에서는 P2P 통화에서 직접 연결된 여러 테넌트에 걸친 2명의 참가자를 나타냅니다. 이 예에서 Communication Services는 수정된 OS 및 SDK 버전을 사용하여 하나의 통화 요약 로그(각 참가자에 대해 하나씩)를 만듭니다. 또한 Communication Services는 4개의 호출 진단 로그(각 미디어 스트림에 대해 하나씩)를 만듭니다. 각 로그에는 participantID의 아웃바운드 스트림과 관련된 데이터가 포함됩니다.
예: 테넌트 간 그룹 통화
다음 다이어그램에서는 여러 테넌트에 걸쳐 3개의 participantId 값이 있는 그룹 통화 예를 나타냅니다. Communication Services는 수정된 OS 및 SDK 버전을 사용하여 각 참가자에 대해 하나의 통화 요약 로그를 만듭니다. 또한 Communication Services는 각 값과 관련된 4개의 호출 진단 로그를 만듭니다(각 participantId 미디어 스트림에 대해 하나씩).
참고 항목
이 릴리스는 아웃바운드 진단 로그만 지원합니다. Communication Services는 참가자와 봇의 ID를 동일한 방식으로 처리하므로 봇 및 참가자와 연결된 OS 및 SDK 버전을 수정할 수 있습니다.
자주 묻는 질문
로그를 저장할 어떻게 할까요? 있나요?
다음 섹션에서는 이 요구 사항을 설명합니다.
Azure Communication Services 로그는 기본적으로 Azure 계정에 저장되지 않으므로 음성 및 비디오 인사이트 대시보드와 같은 도구와 통화 진단이 작동하려면 저장을 시작해야 합니다. 이러한 호출 로그를 수집하려면 호출 데이터를 Log Analytics 작업 영역으로 안내하는 진단 설정을 사용하도록 설정해야 합니다.
데이터는 소급하여 저장되지 않으므로 진단 설정을 구성한 후에만 통화 로그 캡처를 시작합니다.
Azure Monitor에서 진단 설정을 통해 로그 사용의 지침에 따라 리소스에 대한 진단 설정을 추가합니다. 처음에는 모든 로그를 수집하는 것이 좋습니다. Azure Monitor의 기능을 이해한 후에는 보존할 로그와 보존 기간을 결정합니다. 진단 설정을 추가하면 로그를 선택하라는 메시지가 표시됩니다. 모든 로그를 수집하려면 allLogs를 선택합니다.
Azure Monitor 내 Log Analytics의 데이터 볼륨, 보존 및 사용량은 기존 Azure 데이터 미터를 통해 청구됩니다. 필요에 따라 비용 고려 사항에 대한 데이터 사용량 및 보존 정책을 모니터링하는 것이 좋습니다. 자세한 내용은 비용 관리를 참조하세요.
Azure Communications Services 리소스 ID가 여러 개 있는 경우 각 리소스 ID에 대해 이러한 설정을 사용하도록 설정해야 합니다.
다음 단계
통화 품질과 안정성을 관리하기 위한 모범 사례를 알아보려면 통화 품질 개선 및 관리를 참조하세요.
음성 통화 및 화상 통화 로그를 모니터링하는 인사이트 대시보드에 대해 알아봅니다.
통화 로그를 사용하여 통화 진단에서 통화 품질 및 안정성 문제를 진단하는 방법을 알아보려면 통화 진단을 참조하세요.