Azure SignalR Service에 대한 리소스 로그

이 자습서는 Azure SignalR Service에 대한 리소스 로그, 설정 방법 및 문제 해결 방법을 설명합니다.

사전 요구 사항

리소스 로그를 사용하도록 설정하려면 로그 데이터를 저장하는 위치에 있어야 합니다. 이 자습서에서는 Azure Storage와 Log Analytics를 사용합니다.

  • Azure storage - 정책 감사, 정적 분석 또는 백업에 대한 리소스 로그를 유지합니다.
  • Log Analytics - Azure 리소스에서 생성된 원시 로그를 분석할 수 있는 유연한 로그 검색 및 분석 도구입니다.

Azure SignalR Service에 대한 리소스 로그 설정

Azure SignalR Service에 대한 리소스 로그를 볼 수 있습니다. 이러한 로그는 Azure SignalR Service 인스턴스에 대한 연결에 대한 보다 풍부한 보기를 제공합니다. 리소스 로그는 모든 연결에 대한 자세한 정보를 제공합니다. 예를 들어 연결의 기본 정보(사용자 ID, 연결 ID 및 전송 유형 등) 및 이벤트 정보(연결, 연결 끊기 및 이벤트 중단 등)가 있습니다. 문제 식별, 연결 추적 및 분석에 리소스 로그를 사용할 수 있습니다.

리소스 로그 사용

리소스 로그는 기본적으로 사용되지 않습니다. 리소스 로그를 활성화하려면 다음 단계를 수행합니다.

  1. Azure Portal모니터링에서 진단 설정을 선택합니다.

    진단 설정 창 탐색

  2. 그런 다음 진단 설정의 전체 보기를 볼 수 있습니다.

    진단 설정의 전체 보기

  3. 로그 원본 설정을 구성합니다.

    1. 로그 원본 설정 섹션에서는 각 로그 유형에 대한 수집 동작을 보여 줍니다.
    2. 모든 연결에 대해 수집하려는 특정 로그 유형을 확인합니다. 그렇지 않으면 진단 클라이언트에 대해서만 로그가 수집됩니다.
  4. 로그 대상 설정을 구성합니다.

    1. 로그 대상 설정 섹션에서 진단 설정 테이블은 기존 진단 설정을 표시합니다. 테이블에서 링크를 선택하여 로그 대상에 액세스하여 수집된 리소스 로그를 볼 수 있습니다.
    2. 이 섹션에서는 진단 설정을 추가, 업데이트 또는 삭제하도록 로그 대상 설정 구성 단추를 선택합니다.
    3. 진단 설정 추가를 선택하여 새 진단 설정을 추가하거나 편집을 선택하여 기존 진단 설정을 수정합니다.
    4. 원하는 보관 대상을 설정합니다. 현재 SignalR 서비스는 스토리지 계정에 대한 보관Log Analytics로 보내기를 지원합니다.
    5. 보관하려는 로그를 선택합니다. 리소스 로그에만 AllLogs 사용할 수 있습니다. 로그를 보관할지 여부만 제어합니다. SignalR 서비스에서 생성해야 하는 로그 유형을 구성하려면 로그 원본 설정 섹션에서 구성합니다.

    진단 설정 창

    1. 새 진단 설정을 저장합니다. 새 설정은 약 10분 후에 적용됩니다. 그런 다음 구성된 보관 대상으로 로그가 전송됩니다. 로그 대상 설정을 구성하는 방법에 대한 자세한 내용은 Azure 리소스 로그 개요를 참조하세요.

리소스 로그 범주

Azure SignalR은 연결 로그 및 메시징 로그의 세 가지 유형의 로그를 지원합니다.

연결 로그

연결 로그는 SignalR Hub 연결에 대한 자세한 정보를 제공합니다. 예를 들어 기본 정보(사용자 ID, 연결 ID 및 전송 유형 등) 및 이벤트 정보(연결, 연결 끊기 및 이벤트 중단 등)가 있습니다. 따라서 연결 로그는 연결 관련 문제를 해결하는 데 유용합니다. 일반적인 연결 관련 문제 해결 가이드는 연결 관련 문제를 참조하세요.

메시징 로그

메시징 로그는 SignalR 서비스를 통해 수신 및 전송된 SignalR Hub 메시지에 대한 추적 정보를 제공합니다. 예를 들어 메시지의 추적 ID와 메시지 유형이 있습니다. 추적 ID 및 메시지 유형도 앱 서버에 로그인됩니다. 일반적으로 메시지는 서비스 또는 서버에 도착하거나 나가면 기록됩니다. 따라서 메시지 로그는 메시지 관련 문제를 해결하는 데 유용합니다. 일반적인 메시지 관련 문제 해결 가이드는 메시지 관련 문제를 참조하세요.

참고

이 유형의 로그는 모든 메시지에 대해 생성됩니다. 메시지가 자주 전송되는 경우 메시징 로그는 SignalR 서비스의 성능에 영향을 미칠 수 있습니다. 그러나 성능 영향을 최소화하기 위해 다른 수집 동작을 선택할 수 있습니다. 아래 동작을 수집하는 리소스 로그를 참조하세요 .

Http 요청 로그

Http 요청 로그는 Azure SignalR에서 수신한 http 요청에 대한 자세한 정보를 제공합니다. 예를 들어 요청의 상태 코드 및 URL입니다. Http 요청 로그는 요청 관련 문제를 해결하는 데 유용합니다.

스토리지 계정에 보관

로그는 진단 로그 창에 구성된 스토리지 계정에 저장됩니다. insights-logs-alllogs이라는 컨테이너는 리소스 로그를 저장하기 위해 자동으로 만들어집니다. 컨테이너 내에서 로그는 resourceId=/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/XXXX/PROVIDERS/MICROSOFT.SIGNALRSERVICE/SIGNALR/XXX/y=YYYY/m=MM/d=DD/h=HH/m=00/PT1H.json 파일에 저장됩니다. 기본적으로 경로는 resource IDDate Time으로 결합됩니다. 로그 파일은 hour로 분할됩니다. 따라서 분은 항상 m=00입니다.

모든 로그는 JSON(JavaScript Object Notation) 형식으로 저장됩니다. 각 항목에는 다음 섹션에 설명된 형식을 사용하는 문자열 필드가 있습니다.

보관 로그 JSON 문자열에는 다음 표에 나열된 요소가 포함되어 있습니다.

Format

이름 설명
time 로그 이벤트 시간
수준 로그 이벤트 수준
resourceId Azure SignalR Service의 리소스 ID
위치 Azure SignalR Service의 위치
category 로그 이벤트 범주
operationName 이벤트의 작업 이름
callerIpAddress 서버/클라이언트의 IP 주소
properties 해당 로그 이벤트와 관련된 자세한 속성입니다. 더 자세히 알아보려면 아래 속성 표를 참조하세요.

속성 표

이름 Description
type 로그 이벤트의 유형입니다. 현재 Azure SignalR Service에 대한 연결 정보를 제공합니다. ConnectivityLogs 형식만 사용할 수 있습니다.
collection 로그 이벤트의 컬렉션입니다. 허용되는 값은 Connection, AuthorizationThrottling입니다.
connectionId 연결 ID
transportType 연결의 전송 유형입니다. 허용되는 값은 다음과 같습니다. Websockets | ServerSentEvents | LongPolling
connectionType 연결 유형입니다. 허용되는 값은 다음과 Server | Client같습니다. Server: 서버 쪽에서 연결, Client: 클라이언트 쪽에서 연결
userId 사용자 ID
message 로그 이벤트의 세부 메시지

다음 코드는 보관 로그 JSON 문자열에 대한 예입니다.

{
    "properties": {
        "message": "Entered Serverless mode.",
        "type": "ConnectivityLogs",
        "collection": "Connection",
        "connectionId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "userId": "User",
        "transportType": "WebSockets",
        "connectionType": "Client"
    },
    "operationName": "ServerlessModeEntered",
    "category": "AllLogs",
    "level": "Informational",
    "callerIpAddress": "xxx.xxx.xxx.xxx",
    "time": "2019-01-01T00:00:00Z",
    "resourceId": "/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/XXXX/PROVIDERS/MICROSOFT.SIGNALRSERVICE/SIGNALR/XXX",
    "location": "xxxx"
}

Log Analytics에 대한 보관 로그 스키마

리소스 로그를 보려면 다음 단계를 수행합니다.

  1. 대상 Log Analytics에서 선택합니다 Logs .

    Log Analytics 메뉴 항목

  2. SignalRServiceDiagnosticLogs를 입력하고 리소스 로그를 쿼리하는 시간 범위를 선택합니다. 고급 쿼리의 경우 Azure Monitor에서 Log Analytics 시작을 참조하세요.

    Log Analytics 쿼리 로그

SignalR Service에 대한 샘플 쿼리를 사용하려면 다음 단계를 수행합니다.

  1. 대상 Log Analytics에서 선택합니다 Logs .

  2. 쿼리 탐색기를 열려면 선택합니다 Queries .

  3. 리소스 종류에서 샘플 쿼리를 그룹화하려면 선택합니다 Resource type .

  4. 스크립트를 실행하려면 선택합니다 Run .

    Log Analytics의 샘플 쿼리

보관 로그 열에는 다음 표에 나열된 요소가 포함되어 있습니다.

이름 Description
TimeGenerated 로그 이벤트 시간
컬렉션 로그 이벤트의 컬렉션입니다. 허용되는 값은 Connection, AuthorizationThrottling입니다.
OperationName 이벤트의 작업 이름
Location Azure SignalR Service의 위치
Level 로그 이벤트 수준
callerIpAddress 서버/클라이언트의 IP 주소
메시지 로그 이벤트의 세부 메시지
UserId 사용자 ID
ConnectionId 연결 ID
ConnectionType 연결 유형입니다. 허용되는 값은 다음과 Server | Client같습니다. Server: 서버 쪽에서 연결, Client: 클라이언트 쪽에서 연결
TransportType 연결의 전송 유형입니다. 허용되는 값은 다음과 같습니다. Websockets | ServerSentEvents | LongPolling

리소스 로그 문제 해결

Azure SignalR Service에 대한 문제를 해결하기 위해 서버/클라이언트 쪽 로그를 사용하도록 설정하여 오류를 캡처할 수 있습니다. 이제 리소스 로그를 노출하는 Azure SignalR Service 서비스 쪽에 로그를 사용하도록 설정할 수도 있습니다.

예기치 않게 연결이 늘어나거나 줄어드는 상황이 발생할 경우 리소스 로그를 활용하여 문제를 해결할 수 있습니다.

일반적인 문제는 연결의 예기치 않은 수량 변경, 연결의 연결 제한 도달 및 권한 부여 오류에 대한 경우가 많습니다. 문제를 해결하는 방법에 대한 다음 섹션을 참조하세요.

연결이 예기치 않게 증가하거나 삭제되는 상황이 발생하는 경우 연결 로그를 활용하여 문제를 해결할 수 있습니다.

일반적인 문제는 종종 연결의 예기치 않은 수량 변경, 연결 제한에 도달하여 권한 부여 실패 및 메시지 손실에 관한 것입니다. 문제를 해결하는 방법에 대한 다음 섹션을 참조하세요.

예기치 않은 연결 수 변경
예기치 않은 연결 끊김

예기치 않은 연결 끊김이 발생하는 경우 먼저 서비스, 서버 및 클라이언트 쪽에서 로그를 사용하도록 설정합니다.

연결이 끊어지면 리소스 로그가 이 연결 끊김 이벤트를 ConnectionAbortedConnectionEndedoperationName기록합니다.

ConnectionAbortedConnectionEnded의 차이점은 ConnectionEnded가 클라이언트 또는 서버 쪽에서 트리거되는 예상한 연결 끊김이라는 것입니다. 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 합니다. 이 동작을 사용하려면 클라이언트 및 서버의 구성이 필요합니다. 자세한 내용은 부분 섹션 수집을 참조하세요.

메시지 손실

메시지 손실 문제가 발생하는 경우 핵심은 메시지를 분실한 위치를 찾는 것입니다. 기본적으로 SignalR 서비스를 사용할 때는 SignalR 서비스, 서버 및 클라이언트의 세 가지 구성 요소가 있습니다. 서버와 클라이언트는 모두 SignalR 서비스에 연결되며, 협상이 완료되면 서로 직접 연결되지 않습니다. 따라서 메시지에 대해 두 방향을 고려해야 합니다. 각 방향에 대해 다음 두 가지 경로를 고려해야 합니다.

  • SignalR 서비스를 통해 클라이언트에서 서버로
    • 경로 1: 클라이언트에서 SignalR 서비스로
    • 경로 2: 서버에 대한 SignalR 서비스
  • SignalR 서비스를 통해 서버에서 클라이언트로
    • 경로 3: 서버에서 SignalR 서비스로
    • 경로 4: 클라이언트에 대한 SignalR 서비스

메시지 경로

모든 수집 동작을 수집 하려면 다음을 수행합니다.

SignalR Service는 SignalR 서비스를 통해 서버에서 클라이언트로의 방향 메시지만 추적합니다. 추적 ID는 서버에서 생성되며, 메시지는 추적 ID를 SignalR 서비스로 전달합니다.

참고

메시지를 추적하고 앱 서버 의 허브 외부에서 메시지를 보내 려면 모든 수집 동작을 수집 하여 진단 클라이언트에서 시작되지 않은 메시지에 대한 메시지 로그를 수집하도록 설정해야 합니다. 진단 클라이언트는 모두 수집하고부분적으로 수집 되는 동작을 수집합니다. 로그를 수집하는 것이 우선 순위가 높습니다. 자세한 내용은 진단 클라이언트 섹션을 참조하세요.

로그인 서버 및 서비스 쪽을 확인하면 메시지가 서버에서 전송되고 SignalR 서비스에 도착하며 SignalR 서비스에서 나가는지 쉽게 확인할 수 있습니다. 기본적으로 메시지 추적 ID에 따라 수신보낸 메시지가 일치하는지 여부를 확인하여 메시지 손실 문제가 서버 또는 SignalR 서비스에 있는지 여부를 알 수 있습니다. 자세한 내용은 아래 세부 정보를 참조하세요.

부분적으로 수집 동작을 수집하려면 다음을 수행합니다.

클라이언트를 진단 클라이언트로 표시하면 SignalR 서비스는 양방향으로 메시지를 추적합니다.

로그인 서버 및 서비스 쪽을 확인하여 메시지가 서버 또는 SignalR 서비스를 성공적으로 전달했는지 쉽게 확인할 수 있습니다. 기본적으로 메시지 추적 ID를 기반으로 수신보낸 메시지가 일치하는지 여부를 확인하여 메시지 손실 문제가 서버 또는 SignalR 서비스에 있는지 여부를 알 수 있습니다. 자세한 내용은 아래 세부 정보를 참조하세요.

메시지 흐름의 세부 정보

SignalR 서비스를 통해 클라이언트에서 서버로의 방향에 대해 SignalR 서비스는 진단 클라이언트에서 시작된 호출, 즉 진단 클라이언트에서 직접 생성된 메시지 또는 진단 클라이언트 호출로 인해 간접적으로 생성된 서비스 메시지 고려합니다.

메시지가 경로 1의 SignalR 서비스에 도착하면 추적 ID가 SignalR 서비스에서 생성됩니다. SignalR 서비스는 진단 클라이언트의 각 메시지에 대한 로그 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를 포함하지 않습니다. 그러나 SignalR이 각 메시지에 대한 호출 ID 를 생성할 ASP.NET 추적 ID로 매핑하는 데 사용할 수 있습니다.

그런 다음, 메시지는 경로 2에서 추적 ID 서버를 전달합니다. 메시지가 도착하면 서버에서 로그 Received message <messagetracingId> from client connection <connectionId> 를 생성합니다.

메시지가 서버에서 허브 메서드를 호출하면 새 추적 ID를 사용하여 새 서비스 메시지가 생성됩니다. 서비스 메시지가 생성되면 서버는 로그인 템플릿 Start to broadcast/send message <MessageTracingId> ...을 생성하고 실제 로그는 시나리오를 기반으로 합니다. 그런 다음, 서비스 메시지가 서버에서 나가면 호출된 로그 Succeeded to send message <MessageTracingId> 가 생성된 후 경로 3의 SignalR 서비스에 메시지가 전달됩니다.

참고

클라이언트에서 메시지의 추적 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
    }
}

예를 들어 누군가가 조인 그룹을 호출하고 동일한 허브 메서드에서 그룹 메시지를 보낼 수 있습니다. 여기서 AddToGroupAsyncasync 문제는 방법입니다. 완료되기 전에 AddToGroupAsync 보낸 그룹 메시지가 완료되기를 AddToGroupAsync 기다릴 필요가 없습니다await. 네트워크 지연 및 일부 그룹에 클라이언트를 조인하는 프로세스의 지연으로 인해 그룹 메시지 배달 이후 조인 그룹 작업이 완료 될 수 있습니다. 이 경우 첫 번째 그룹 메시지는 그룹에 가입된 클라이언트가 없으므로 수신자로 클라이언트가 없습니다. 따라서 메시지 손실 문제가 됩니다.

리소스 로그가 없으면 클라이언트가 그룹에 조인하는 시기와 그룹 메시지가 전송되는 시기를 확인할 수 없습니다. 메시징 로그를 사용하도록 설정하면 SignalR 서비스의 메시지 도착 시간을 비교할 수 있습니다. 아래 단계에 따라 문제를 해결합니다.

  1. 서버에서 메시지 로그를 찾아 클라이언트가 그룹에 가입한 시기와 그룹 메시지가 전송되는 시기를 찾습니다.
  2. 그룹 가입의 메시지 추적 ID A와 메시지 로그에서 그룹 메시지의 메시지 추적 ID B를 가져옵니다.
  3. 로그 보관 대상의 메시징 로그 간에 이러한 메시지 추적 ID를 필터링한 다음 도착하는 타임스탬프를 비교하면 SignalR 서비스에서 먼저 도착한 메시지를 찾을 수 있습니다.
  4. 메시지 추적 ID A가 B 도착 시간보다 늦게 도착하는 경우 클라이언트가 그룹에 가입 하기 전에 그룹 메시지를 보내야 합니다. 그런 다음, 그룹 메시지를 보내기 전에 클라이언트가 그룹에 있는지 확인해야 합니다.

SignalR 또는 서버에서 메시지가 손실된 경우 메시지 추적 ID에 따라 경고 로그를 가져와 이유를 확인합니다. 추가 도움이 필요한 경우 도움말 보기 섹션을 참조하세요.

고급

동작을 수집하는 리소스 로그

특히 메시징 로그의 경우 리소스 로그 사용에 대한 두 가지 일반적인 시나리오가 있습니다.

누군가는 각 메시지의 품질에 관심이 있을 수 있습니다. 예를 들어 메시지가 성공적으로 전송/수신되었는지 또는 SignalR 서비스를 통해 전달되는 모든 메시지를 기록하려고 하는지에 민감합니다.

그 동안, 다른 사람은 성능에 대해 걱정할 수 있습니다. 메시지 대기 시간에 민감하며 어떤 이유로든 모든 연결 대신 몇 가지 연결에서 메시지를 추적해야 하는 경우가 있습니다.

따라서 SignalR Service는 두 가지 종류의 수집 동작을 제공합니다.

  • 모두 수집: 모든 연결에서 로그 수집
  • 부분적으로 수집: 일부 특정 연결에서 로그 수집

참고

로그 수집과 로그를 수집하지 않는 클라이언트 간의 연결을 구분하기 위해 SignalR Service는 리소스 로그가 항상 수집되는 서버 및 클라이언트의 진단 클라이언트 구성에 따라 일부 클라이언트를 진단 클라이언트로 처리하지만 다른 클라이언트는 그렇지 않습니다. 자세한 내용은 부분 섹션 수집을 참조하세요.

모두 수집

리소스 로그는 모든 연결에서 수집됩니다. 예를 들어 메시징 로그를 사용합니다. 이 동작을 사용하도록 설정하면 SignalR Service는 서버에 알림을 보내 각 메시지에 대한 추적 ID 생성을 시작합니다. 추적 ID는 서비스에 메시지로 전달되고, 서비스는 추적 ID를 사용하여 메시지를 기록합니다.

참고

SignalR 서비스의 성능을 보장하기 위해 SignalR Service는 클라이언트에서 보낸 전체 메시지를 기다리고 구문 분석하지 않으므로 클라이언트 메시지가 기록되지 않습니다. 그러나 클라이언트가 진단 클라이언트로 표시되면 클라이언트 메시지가 SignalR 서비스에 기록됩니다.

구성 가이드

이 동작을 사용하려면 로그 원본 설정형식 섹션에서 확인란을 선택합니다.

이 동작은 서버 쪽 구성을 업데이트할 필요가 없습니다. 이 구성 변경 내용은 항상 자동으로 서버로 전송됩니다.

부분적으로 수집

리소스 로그는 진단 클라이언트에서 수집됩니다. 진단 클라이언트의 클라이언트 메시지 및 연결 이벤트를 포함하여 모든 메시지가 기록됩니다.

참고

진단 클라이언트 수의 제한은 100입니다. 진단 클라이언트 수가 100을 초과하면 열거된 진단 클라이언트가 SignalR 서비스에 의해 제한됩니다. 신규이지만 열세 클라이언트는 SignalR 서비스에 연결하지 못하고 메시지가 Response status code does not indicate success: 429 (Too Many Requests)있는 클라이언트를 throw System.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 티켓을 만드는 것이 좋습니다. 다음을 제공합니다.

  1. 문제가 발생하는 시간 범위는 30분입니다.
  2. Azure SignalR Service의 리소스 ID
  3. 가능한 한 구체적인 문제 세부 정보: 예를 들어 appserver는 메시지를 보내지 않고 클라이언트 연결이 끊기는 등의 작업을 수행합니다.
  4. 서버/클라이언트 쪽에서 수집된 로그 및 유용하게 사용할 수 있는 기타 자료
  5. [선택 사항]재현 코드

참고

GitHub에서 문제를 여는 경우 중요한 정보(예: 리소스 ID, 서버/클라이언트 로그)를 비공개로 유지하고 Microsoft 조직의 구성원에게만 비공개로 보냅니다.