Azure SignalR Service 로그 모니터링 및 문제 해결
이 문서에서는 Azure Monitor 기능을 사용하여 Azure SignalR에서 생성된 리소스 로그 모니터링 데이터를 분석하고 문제를 해결하는 방법을 설명합니다.
각 Azure SignalR Service에 대한 Azure Portal의 개요 페이지에는 동시 연결 및 메시지 수와 같은 리소스 사용량에 대한 간략한 보기가 포함되어 있습니다. 이 유용한 정보는 포털에서 사용할 수 있는 적은 양의 모니터링 데이터일 뿐입니다. 이 데이터 중 일부는 자동으로 수집되며 리소스를 만드는 즉시 분석에 사용할 수 있습니다.
일부 구성 후에 다른 형식의 데이터 수집을 사용하도록 설정할 수 있습니다. 이 문서에서는 Azure Monitor 도구를 사용하여 로그 데이터 수집을 구성하고 이 데이터를 분석하고 문제를 해결하는 방법을 안내합니다.
- Azure SignalR Service 모니터링에 대한 자세한 내용은 Azure SignalR Service 모니터링을 참조 하세요.
- Azure SignalR Service에 대해 수집된 메트릭 및 로그의 자세한 목록은 Azure SignalR Service 모니터링 데이터 참조를 참조 하세요.
필수 조건
리소스 로그를 사용하도록 설정하려면 Azure Storage 또는 Log Analytics와 같은 로그 데이터를 저장할 장소를 설정해야 합니다.
- Azure Storage 는 정책 감사, 정적 분석 또는 백업을 위해 리소스 로그를 유지합니다.
- Log Analytics 는 Azure 리소스에서 생성된 원시 로그를 분석할 수 있는 유연한 로그 검색 및 분석 도구입니다.
리소스 로그 사용
Azure SignalR Service는 연결 로그, 메시징 로그 및 Http 요청 로그를 지원합니다. 이러한 유형의 로그에 대한 자세한 내용은 리소스 로그 범주를 참조하세요.
리소스 로그는 기본적으로 사용되지 않습니다. 진단 설정을 사용하여 리소스 로그를 사용하도록 설정하려면 다음 단계를 수행합니다.
Azure Portal의 모니터링에서 진단 설정을 선택합니다.
진단 설정의 전체 보기를 볼 수 있습니다.
로그 원본 설정을 구성합니다.
- 로그 원본 설정 섹션의 표는 각 로그 유형의 수집 동작을 보여줍니다.
- 모든 연결에서 수집할 로그 유형을 선택합니다. 그렇지 않으면 진단 클라이언트에 대해서만 로그가 수집됩니다.
로그 대상 설정을 구성합니다.
- 로그 대상 설정 섹션의 진단 설정 표에는 기존 진단 설정이 표시됩니다. 이 표에서 링크를 선택하면 수집된 리소스 로그를 볼 수 있는 로그 대상에 액세스할 수 있습니다.
- 이 섹션에서 진단 설정을 추가, 업데이트 또는 삭제하는 로그 대상 설정 구성 단추를 선택합니다.
- 새 설정을 추가하려면 진단 설정 추가를 선택하고, 기존 진단 설정을 편집하려면 편집을 선택합니다.
- 원하는 보관 대상을 설정합니다. 현재 Azure SignalR Service는 스토리지 계정에 보관하고 Log Analytics로 보내기를 지원합니다.
- 보관하려는 로그를 선택합니다. 리소스 로그에는
AllLogs만 사용할 수 있습니다. SignalR 서비스는 로그 보관 여부만 제어합니다. Azure SignalR Service에서 생성해야 하는 로그 유형을 구성하려면 로그 원본 설정 섹션에서 구성합니다.
- 새 진단 설정을 저장합니다. 새 설정은 약 10분 후에 적용됩니다. 그런 다음 로그가 구성된 보관 대상으로 전송됩니다. 진단 대상 설정 구성에 대한 자세한 내용은 Azure 리소스 로그 개요를 참조하세요.
로그는 진단 로그 창에 구성된 Storage 계정에 저장됩니다 . 스토리지 형식 및 필드에 대한 자세한 내용은 데이터 스토리지를 참조하세요.
리소스 로그 쿼리
리소스 로그를 쿼리하려면 다음 단계를 수행합니다.
대상 Log Analytics에서 로그를 선택합니다.
SignalRServiceDiagnosticLogs를 입력하고 시간 범위를 선택합니다. 고급 쿼리의 경우 Azure Monitor에서 Log Analytics 시작을 참조하세요.
Azure SignalR Service에 대한 샘플 쿼리를 사용하려면 다음 단계를 수행합니다.
대상 Log Analytics에서 로그를 선택합니다.
쿼리 탭을 선택하여 쿼리 탐색기를 엽니다.
리소스 유형을 선택하여 리소스 종류 에서 샘플 쿼리를 그룹화합니다.
실행을 선택하여 스크립트를 실행합니다.
Azure SignalR Service에 대한 예제 쿼리는 SignalRServiceDiagnosticLogs 테이블에 대한 쿼리를 참조 하세요.
참고 항목
스토리지 대상에 대한 쿼리 필드 이름은 Log Analytics의 필드 이름과 약간 다릅니다. Storage 테이블과 Log Analytics 테이블 간의 필드 이름 매핑에 대한 자세한 내용은 리소스 로그 테이블 매핑을 참조하세요.
리소스 로그 문제 해결
Azure SignalR Service 문제를 해결하려면 서버/클라이언트 쪽 로그를 사용하도록 설정하여 오류를 캡처할 수 있습니다. Azure SignalR Service가 리소스 로그를 노출하는 경우 리소스 로그를 활용하여 서비스에 대한 로그 문제를 해결할 수 있습니다.
연결 관련 문제
연결이 예기치 않게 증가하거나 삭제되는 경우 연결 로그를 활용하여 문제를 해결할 수 있습니다. 일반적인 문제에는 종종 예기치 않은 연결 수량 변경, 연결 연결 제한에 도달, 권한 부여 실패가 포함됩니다. 다음 섹션에서는 문제 해결 방법을 설명합니다.
예기치 않은 연결 끊김
예기치 않은 연결이 끊어지면 먼저 서비스, 서버 및 클라이언트 쪽에서 로그를 사용하도록 설정합니다.
연결이 끊어지면 리소스 로그에서 이 연결 끊김 이벤트를 기록합니다 ConnectionAbortedConnectionEndedoperationName.
차이점은 ConnectionAbortedConnectionEndedConnectionEnded 클라이언트 또는 서버 쪽에서 트리거되는 예상되는 연결 끊김입니다. ConnectionAborted 일반적으로 예기치 않은 연결 삭제 이벤트이며 중단 이유가 제공됩니다message.
다음 표에서는 중단 이유를 나열합니다.
| 이유 | 설명 |
|---|---|
| 연결 수가 제한에 도달 | 연결 수가 현재 가격 계층의 제한에 도달했습니다. 서비스 단위를 스케일 업하는 것이 좋습니다. |
| 애플리케이션 서버가 연결을 닫음 | 앱 서버가 중단을 트리거합니다. 예상된 중단으로 간주될 수 있습니다. |
| 연결 ping 시간 제한 | 이 문제는 일반적으로 네트워크 문제로 인해 발생합니다. 인터넷에서 앱 서버 가용성을 확인하는 것이 좋습니다. |
| 서비스 다시 로드, 다시 연결 시도 | Azure SignalR Service를 다시 로드하고 있습니다. Azure SignalR은 자동 다시 연결을 지원합니다. 다시 연결될 때까지 또는 수동으로 Azure SignalR Service에 다시 연결될 때까지 대기할 수 있습니다. |
| 내부 서버의 일시적인 오류 | Azure SignalR Service에서 일시적인 오류가 발생하며, 자동으로 복구되어야 함 |
| 서버 연결 끊김 | 서버 연결이 알 수 없는 오류와 함께 끊깁니다. 먼저 서비스/서버/클라이언트 쪽 로그를 사용하여 자체 문제 해결을 하는 것이 좋습니다. 기본 문제(예: 네트워크 문제, 앱 서버 쪽 문제 등)가 아닌지 확인해보세요. 문제가 해결되지 않으면 Microsoft에 문의하여 도움을 받으세요. 자세한 내용은 도움 받기 섹션을 참조하세요. |
예기치 않은 연결 증가
예기치 않은 연결 증가 문제를 해결하려면 먼저 추가 연결을 필터링해야 합니다. 테스트 클라이언트 연결에 고유한 테스트 사용자 ID를 추가할 수 있습니다. 리소스 로그를 확인하세요. 둘 이상의 클라이언트 연결에 동일한 테스트 사용자 ID 또는 IP가 있는 경우 클라이언트 쪽이 예상보다 더 많은 연결을 만들 가능성이 높습니다. 클라이언트 쪽을 확인합니다.
권한 부여 실패
클라이언트 요청에 대해 인증되지 않은 401이 반환되는 경우 리소스 로그를 확인합니다. 이 Failed to validate audience. Expected Audiences: <valid audience>. Actual Audiences: <actual audience>경우 액세스 토큰의 모든 대상 그룹은 유효하지 않습니다. 로그에 제안된 유효한 대상 그룹을 사용하세요.
제한
Azure SignalR Service에 대한 SignalR 클라이언트 연결을 설정할 수 없는 경우 리소스 로그를 확인합니다. 리소스 로그에 Connection count reaches limit이 나올 경우 연결 수 제한에 도달할 정도로 SignalR Service에 대한 연결을 너무 많이 설정한 것입니다. SignalR Service를 스케일 업하는 것이 좋습니다. 리소스 로그에서 발생하는 Message count reaches limit 경우 무료 계층을 사용하고 메시지 할당량을 사용한다는 의미입니다. 더 많은 메시지를 보내려면 SignalR Service를 표준 계층으로 변경하는 것이 좋습니다. 자세한 내용은 Azure SignalR Service 가격 책정을 참조 하세요.
메시지 관련 문제
메시지 관련 문제가 발생하는 경우 메시징 로그를 활용하여 문제를 해결할 수 있습니다. 먼저 서버 및 클라이언트에 대한 서비스 및 로그에서 리소스 로그를 사용하도록 설정합니다.
참고 항목
ASP.NET Core의 경우 서버 및 클라이언트에서 로깅을 사용하도록 설정하려면 여기를 참조하세요.
ASP.NET의 경우 서버 및 클라이언트에서 로깅을 사용하도록 설정하려면 여기를 참조하세요.
성능 효과 가능성과 클라이언트-서버 방향 메시지를 신경 쓰지 않는 경우 Log Source Settings/Types에서 Messaging을 확인하여 모든 로그 수집 동작을 사용하도록 설정합니다. 이 동작에 대한 자세한 내용은 모두 수집을 참조하세요.
그렇지 않으면 Messaging을 선택 취소하여 부분적으로 수집 로그 수집 동작을 사용하도록 설정합니다. 이 동작을 사용하려면 클라이언트 및 서버에서 이 동작을 사용하도록 구성해야 합니다. 자세한 내용은 부분 수집을 참조 하세요.
메시지 손실
메시지 손실 문제가 발생하면 메시지가 손실된 위치를 찾는 것이 중요합니다. 기본적으로 Azure SignalR Service를 사용할 때는 SignalR 서비스, 서버 및 클라이언트의 세 가지 구성 요소가 있습니다. 서버와 클라이언트는 모두 SignalR 서비스에 연결되지만 협상이 완료되면 직접 서로 연결하지 않습니다. 따라서 메시지에 대해 두 가지 방향을 고려해야 하며 각 방향에 대해 다음 두 경로를 고려해야 합니다.
- SignalR 서비스를 통해 클라이언트에서 서버로
- 경로 1: 클라이언트에서 SignalR 서비스로
- 경로 2: SignalR 서비스에서 서버로
- SignalR 서비스를 통해 서버에서 클라이언트로
- 경로 3: 서버에서 SignalR 서비스로
- 경로 4: SignalR 서비스에서 클라이언트로
모두 수집 수집 동작의 경우:
Azure SignalR Service는 SignalR 서비스를 통해 서버에서 클라이언트로의 방향으로만 메시지를 추적합니다. 추적 ID는 서버에서 생성됩니다. 메시지는 추적 ID를 SignalR 서비스로 전달합니다.
참고 항목
메시지를 추적하고 앱 서버의 허브 외부에서 메시지를 전송하려면 모두 수집 수집 동작을 사용하도록 설정하여 진단 클라이언트에서 시작되지 않은 메시지의 메시지 로그를 수집합니다. 진단 클라이언트는 모두수집하고 부분적으로 수집 동작을 수집하지만 로그를 수집하는 데 더 높은 우선 순위를 갖습니다. 자세한 내용은 진단 클라이언트 섹션을 참조하세요.
로그인 서버 및 서비스 쪽을 확인하면 메시지가 서버에서 전송되고, SignalR 서비스에 도착하고, SignalR 서비스에서 나가는지 쉽게 확인할 수 있습니다. 기본적으로 메시지 추적 ID를 기준으로 받은 메시지와 보낸 메시지가 일치하는지 여부를 확인하면 메시지 손실 문제가 이 방향의 서버에서 발생하는지 아니면 SignalR 서비스에서 발생하는지 알 수 있습니다. 자세한 내용은 아래의 세부 정보를 참조하세요.
부분적으로 수집 수집 동작의 경우:
클라이언트를 진단 클라이언트로 표시하면 Azure SignalR Service는 양방향으로 메시지를 추적합니다.
로그인 서버 및 서비스 쪽을 확인하면 메시지가 서버 또는 SignalR 서비스를 성공적으로 전달하는지 쉽게 확인할 수 있습니다. 기본적으로 메시지 추적 ID를 기준으로 받은 메시지와 보낸 메시지가 일치하는지 여부를 확인하면 메시지 손실 문제가 서버에서 발생하는지 아니면 SignalR 서비스에서 발생하는지 알 수 있습니다. 자세한 내용은 다음 세부 정보를 참조하세요.
메시지 흐름의 세부 정보
SignalR 서비스를 통해 클라이언트에서 서버로의 방향에 대해 SignalR Service는 진단 클라이언트에서 시작된 호출, 즉 진단 클라이언트에서 직접 생성된 메시지 또는 진단 클라이언트 호출로 인해 간접적으로 생성된 서비스 메시지만 고려합니다.
추적 ID는 메시지가 경로 1의 SignalR 서비스에 도착하면 SignalR 서비스에서 생성됩니다. SignalR Service는 진단 클라이언트의 각 메시지에 대한 로그 Received a message <MessageTracingId> from client connection <ConnectionId>. 를 생성합니다. 메시지가 SignalR에서 서버로 나가면 SignalR 서비스에서 로그 메시지를 Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.생성합니다. 이러한 두 로그가 표시되면 메시지가 SignalR 서비스를 성공적으로 통과한다는 것을 확신할 수 있습니다.
참고 항목
ASP.NET Core SignalR의 제한으로 인해 클라이언트에서 가져온 메시지는 메시지 수준 ID를 포함하지 않지만 ASP.NET SignalR은 각 메시지에 대한 호출 ID를 생성합니다. 추적 ID로 매핑하는 데 사용할 수 있습니다.
그 후 메시지가 경로 2의 추적 ID 서버를 전달합니다. 메시지가 도착하면 서버에서 로그 Received message <messagetracingId> from client connection <connectionId> 를 생성합니다.
메시지가 서버에서 허브 메서드를 호출하면 새 추적 ID를 사용하여 새 서비스 메시지가 생성됩니다. 서비스 메시지가 생성되면 서버는 로그인 템플릿 Start to broadcast/send message <MessageTracingId> ...을 생성합니다. 실제 로그는 시나리오를 기반으로 합니다. 그런 다음, 메시지는 경로 3의 SignalR 서비스로 전달됩니다. 서비스 메시지가 서버에서 나가면 호출 Succeeded to send message <MessageTracingId> 된 로그가 생성됩니다.
참고 항목
클라이언트에서 메시지의 추적 ID는 SignalR 서비스로 보낼 서비스 메시지의 추적 ID에 매핑할 수 없습니다.
서비스 메시지가 SignalR Service에 도착하면 호출 Received a <MessageType> message <MessageTracingId> from server connection <ConnectionId>. 된 로그가 생성됩니다. 그 후 SignalR 서비스는 서비스 메시지를 처리하여 대상 클라이언트에 전달합니다. 경로 4에서 클라이언트로 메시지를 보내면 로그 Sent a message <MessageTracingId> to client connection <ConnectionId> successfully. 가 생성됩니다.
요약하면 메시지가 SignalR 서비스 및 서버로 들어가고 나가는 경우 메시지 로그가 생성됩니다. 이러한 로그를 사용하여 메시지가 이러한 구성 요소에서 손실되었는지 여부를 확인할 수 있습니다.
다음 예제는 일반적인 메시지 손실 문제입니다.
클라이언트가 그룹의 메시지를 받지 못함
이 문제의 일반적인 현상은 클라이언트가 그룹 메시지를 보낸 후 그룹에 조인하는 것입니다.
Class Chat : Hub
{
public void JoinAndSendGroup(string name, string groupName)
{
Groups.AddToGroupAsync(Context.ConnectionId, groupName); // join group
Clients.Group(groupName).SendAsync("ReveiceGroupMessage", name, "I'm in group"); // send group message
}
}
예를 들어 누군가가 조인 그룹을 호출하고 동일한 허브 메서드에서 그룹 메시지를 전송할 수 있습니다. 여기서 AddToGroupAsync 문제는 메서드입니다 async . 완료될 때까지 대기할 수 없 awaitAddToGroupAsync 으므로 그룹 메시지가 완료되기 전에 AddToGroupAsync 보냅니다. 네트워크 지연 및 클라이언트를 일부 그룹에 조인하는 프로세스의 지연으로 인해 그룹 조인 작업이 그룹 메시지 전송보다 늦게 완료될 수 있습니다. 이 경우 첫 번째 그룹 메시지에는 수신자로 클라이언트가 없으므로 그룹에 가입된 클라이언트가 없으므로 메시지 손실 문제가 됩니다.
리소스 로그가 없으면 클라이언트가 그룹에 조인하는 시간과 그룹 메시지가 전송되는 시간을 확인할 수 없습니다. 메시지 로그를 사용하도록 설정하면 SignalR 서비스에서 메시지 도착 시간을 비교할 수 있습니다. 다음 단계를 수행하여 문제를 해결합니다.
- 서버에서 메시지 로그를 찾아 클라이언트가 그룹에 조인한 시간과 그룹 메시지가 전송된 시간을 찾습니다.
- 메시지 로그에서 그룹 조인의 메시지 추적 ID A와 그룹 메시지의 메시지 추적 ID B를 가져옵니다.
- 로그 보관 대상의 메시징 로그 간에 이러한 메시지 추적 ID를 필터링한 다음 도착 타임스탬프를 비교합니다. SignalR 서비스에서 먼저 도착한 메시지를 찾습니다.
- 메시지 추적 ID A 도착 시간이 B 도착 시간보다 늦으면 클라이언트가 그룹에 가입하기 전에 그룹 메시지를 보내야 합니다. 그룹 메시지를 보내기 전에 클라이언트가 그룹에 있는지 확인해야 합니다.
SignalR 또는 서버에서 메시지가 손실되는 경우 메시지 추적 ID에 따라 경고 로그를 가져와 이유를 확인합니다. 추가 도움이 필요한 경우 도움말 보기 섹션을 참조하세요.
리소스 로그 수집 동작
특히 메시징 로그의 경우 리소스 로그를 사용하는 두 가지 일반적인 시나리오가 있습니다.
어떤 사람은 각 메시지의 품질에 관심이 있습니다. 예를 들어 이들은 메시지가 성공적으로 전송/수신되었는지 여부에 민감하거나, SignalR 서비스를 통해 전달되는 모든 메시지를 기록하려고 합니다.
한편 어떤 사람은 성능에 관심이 있습니다. 이들은 메시지의 대기 시간에 민감하며, 어떤 이유로 모든 연결이 아닌 몇 개 연결에서 메시지를 추적해야 할 때가 있습니다.
따라서 SignalR 서비스는 두 가지 종류의 수집 동작을 제공합니다.
- 모두 수집: 모든 연결에서 로그 수집
- 부분적으로 수집: 일부 특정 연결에서 로그 수집
참고 항목
로그 수집과 로그를 수집하지 않는 클라이언트 간의 연결을 구분하기 위해 SignalR Service는 리소스 로그가 항상 수집되는 서버 및 클라이언트의 진단 클라이언트 구성에 따라 일부 클라이언트를 진단 클라이언트로 처리하지만 다른 클라이언트는 그렇지 않습니다. 자세한 내용은 부분적으로 수집 섹션을 참조하세요.
모두 수집
모든 연결에서 리소스 로그가 수집됩니다. 메시지 로그를 예로 들 수 있습니다. 이 동작을 사용하도록 설정하면 SignalR Service는 서버에 알림을 보내 각 메시지에 대한 추적 ID 생성을 시작합니다. 추적 ID는 서비스에 메시지로 전달됩니다. 또한 서비스는 추적 ID를 사용하여 메시지를 기록합니다.
참고 항목
SignalR 서비스의 성능을 보장하기 위해 SignalR 서비스는 클라이언트에서 보낸 전체 메시지를 대기하고 구문 분석하지 않습니다. 따라서 클라이언트 메시지는 기록되지 않습니다. 클라이언트가 진단 클라이언트로 표시되면 클라이언트 메시지가 SignalR 서비스에 기록됩니다.
구성 가이드
이 동작을 사용하도록 설정하려면 로그 원본 설정의 형식 섹션에서 확인란을 선택합니다.
이 동작은 서버 쪽 구성을 업데이트할 필요가 없습니다. 이 구성 변경 내용은 항상 자동으로 서버로 전송됩니다.
부분적으로 수집
오직 진단 클라이언트만이 리소스 로그를 수집합니다. 클라이언트 메시지 및 연결 이벤트를 포함한 모든 메시지가 진단 클라이언트에 기록됩니다.
참고 항목
진단 클라이언트 개수 제한은 100입니다. 진단 클라이언트 수가 100을 초과하면 수의 진단 클라이언트가 SignalR 서비스에 의해 제한됩니다. 신규이지만 열세 클라이언트는 SignalR 서비스에 연결하지 못하고 메시지가 Response status code does not indicate success: 429 (Too Many Requests)있는 throwSystem.Net.Http.HttpRequestException합니다. 이미 연결된 클라이언트는 제한 정책의 영향을 받지 않고 작동합니다.
진단 클라이언트
진단 클라이언트는 논리적 개념입니다. 모든 클라이언트는 진단 클라이언트일 수 있습니다. 서버는 진단 클라이언트가 될 수 있는 클라이언트를 제어합니다. 클라이언트가 진단 클라이언트로 표시되면 모든 리소스 로그가 이 클라이언트에서 사용하도록 설정됩니다. 클라이언트를 진단 클라이언트로 설정하려면 구성 가이드를 참조하세요.
구성 가이드
이 동작을 사용하려면 서비스, 서버 및 클라이언트 쪽을 구성해야 합니다.
서비스 쪽
이 동작을 사용하도록 설정하려면 로그 원본 설정의 형식 섹션에서 특정 로그 유형에 대한 확인란을 선택 취소합니다.
서버 쪽
또한 클라이언트의 http 컨텍스트를 기반으로 진단 클라이언트의 필터를 정의하도록 ServiceOptions.DiagnosticClientFilter를 설정합니다. 예를 들어 허브 URL이 <HUB_URL>?diag=yes인 클라이언트를 설정한 다음, 진단 클라이언트를 필터링하도록 ServiceOptions.DiagnosticClientFilter를 설정합니다. 반환 true되는 경우 클라이언트는 진단 클라이언트로 표시됩니다. 그렇지 않으면 일반 클라이언트로 유지됩니다. ServiceOptions.DiagnosticClientFilter는 다음과 같이 시작 클래스에서 설정할 수 있습니다.
// sample: mark a client as diagnostic client when it has query string "?diag=yes" in hub URL
public IServiceProvider ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services
.AddSignalR()
.AddAzureSignalR(o =>
{
o.ConnectionString = "<YOUR_ASRS_CONNECTION_STRING>";
o.DiagnosticClientFilter = context => context.Request.Query["diag"] == "yes";
});
return services.BuildServiceProvider();
}
클라이언트 쪽
http 컨텍스트를 구성하여 클라이언트를 진단 클라이언트로 표시합니다. 예를 들어 쿼리 문자열 diag=yes를 추가하면 클라이언트가 진단 클라이언트로 표시됩니다.
var connection = new HubConnectionBuilder()
.WithUrl("<HUB_URL>?diag=yes")
.Build();
도움말 보기
먼저 자체적으로 문제를 해결하는 것이 좋습니다. 대부분의 문제는 앱 서버 또는 네트워크 문제로 인해 발생합니다. 리소스 로그 및 기본 문제 해결 가이드와 함께 문제 해결 가이드에 따라 근본 원인을 찾습니다. 그래도 문제를 해결할 수 없는 경우 GitHub에서 문제를 열거나 Azure Portal에서 티켓을 만드는 것이 좋습니다. 제공:
- 문제가 발생하는 시간 범위는 30분입니다.
- Azure SignalR Service의 리소스 ID
- 다음과 같이 문제에 대해 최대한 구체적으로 설명: 앱 서버가 메시지를 보내지 않음, 클라이언트 연결 끊김 등
- 서버/클라이언트 쪽에서 수집된 로그 및 유용하게 사용할 수 있는 기타 자료
- [선택 사항]재현 코드
참고 항목
GitHub에서 문제를 여는 경우 중요한 정보(예: 리소스 ID, 서버/클라이언트 로그)를 비공개로 유지합니다. Microsoft 조직의 구성원에게만 비공개로 보냅니다.