작업 로그를 사용하여 뷰 로드 시간 모니터링

적용 대상: Tableau Advanced Management

사용자에게 최적의 뷰가 표시되도록 하는 것은 관리자의 중요한 역할입니다. 작업 로그를 사용하면 실시간으로 성능 문제를 식별하고 발생하는 문제를 해결하여 사이트를 원활하게 운영할 수 있습니다.

이 항목에서는 관리자가 vizql_http_request 이벤트 유형을 사용하여 뷰 로드 시간을 파악하고 성능 병목 현상을 해결하는 방법을 설명합니다.

필수 요건

뷰 로드 시간을 모니터링하려면 작업 로그 데이터가 쿼리 가능한 구조화된 형식이어야 합니다. 계속하기 전에 다음 필수 요건이 충족되는지 확인하십시오.

  • 작업 로그 구성: AWS S3 버킷에 로그 파일을 기록할 수 있도록 작업 로그를 설정합니다.

  • 데이터 가져오기: 작업 로그로 생성된 로그 파일을 Splunk 또는 Amazon EventBridge와 같은 모니터링 도구로 가져옵니다. 또는 Snowflake 또는 Google BigQuery와 같은 클라우드 데이터 웨어하우스로 가져올 수 있습니다. 그러면 데이터를 쉽게 쿼리하고 분석할 수 있는 형식으로 만들 수 있습니다.

참고: 작업 로그 데이터를 데이터 저장소로 가져오는 프로세스는 이 항목에서 다루지 않습니다. 자세한 지침은 작업 로그 설정 및 선택한 데이터 플랫폼의 설명서를 참조하십시오.

시작하기

그럼 어디서부터 시작해야 할까요? 대시보드 또는 뷰의 초기 로드 시점인 '부트스트랩 세션' 이벤트를 중점으로 하여 뷰 성능을 모니터링할 수 있습니다. 이 이벤트는 일반적으로 뷰 렌더링에 필요한 대부분의 시간을 포착하여 로드에 걸린 시간을 명확하게 보여 줍니다.

부트스트랩 이벤트를 모니터링하려면 다음을 수행합니다.

  1. Splunk, Amazon EventBridge 등 설정한 모니터링 도구를 엽니다.

  2. 다음 값을 기준으로 필터링합니다.

    1. eventType = vizql_http_request.

    2. endpointName = bootstrapSession.

    3. eventOutcome = success.

  3. 결과에서 duration 필드를 찾습니다.

vizql_http_request 이벤트의 기간 필드는 작업 완료에 걸린 시간(밀리초)을 나타냅니다. 이를 통해 Tableau 뷰의 초기 로드 시간을 추적하고 분석할 수 있습니다.

팁: 어디서부터 시작해야 할지 모르시겠나요? 관리자 인사이트 스타터 통합 문서에 포함된 '대시보드 로드 시간' 대시보드를 사용하십시오. 이 대시보드에는 콘텐츠의 로드 시간과 성능 등급이 표시되므로 문제가 있는 뷰를 쉽게 식별할 수 있습니다. 그런 다음 작업 로그를 사용하여 실시간으로 문제를 겪고 있는 사용자와 통합 문서 수정 버전이 성능에 미치는 영향을 확인할 수 있습니다. 자세한 내용은 관리자 인사이트를 사용하여 사용자 지정 뷰 만들기를 참조하십시오.

오류 모니터링

성능 외에도 부트스트랩 세션 데이터를 사용하여 사용자가 콘텐츠를 보는 동안 오류가 발생하는지 여부를 확인할 수 있습니다. 이러한 오류를 확인하려면 eventOutcome 및 eventOutcomeReason 필드를 검색합니다. 이러한 필드는 모니터링 알림을 설정하고 조사의 시작점을 제공하는 데 유용합니다. 예를 들어 사용자가 대시보드를 보는 동안 오류를 보고하는 경우 부트스트랩 세션을 확인하여 기간별 사용자 상호 작용을 볼 수 있습니다. 이렇게 하면 오류의 원인을 정확히 파악하고 문제가 시작된 시점을 확인하는 데 도움이 됩니다. 이 정보를 아는 것은 문제의 근본 원인을 해결하는 데 중요합니다.

  • eventOutcome: 이 필드에는 각 작업에 대한 상위 수준의 성공 또는 실패 범주(success, failure, client_error 또는 internal_error)가 기록됩니다.

  • eventOutcomeReason: 이 필드는 오류가 발생한 원인에 대한 보다 자세한 정보를 제공하며, 오류를 설명하는 HTTP 상태 코드를 기록하는 경우가 많습니다.

오류를 모니터링하려면 다음을 수행합니다.

  1. Splunk, Amazon EventBridge 등 설정한 모니터링 도구를 엽니다.

  2. 다음 값으로 필터링합니다.

    1. eventType = vizql_http_request.

    2. endpointName = bootstrapSession.

    3. eventOutcome != success.

  3. 결과에서 eventOutcomeReason 오류에 대한 세부 정보를 검토합니다.

성능 문제 해결

성능 문제는 여러 요인이 영향을 미치므로 조사하기 어렵습니다. 그러나 몇 가지 방법을 통해 프로세스를 간소화할 수 있습니다. 이 섹션에서는 부트스트랩 세션을 사용하여 통합 문서 성능 문제를 해결하는 일반적인 방법을 간략하게 설명합니다. 먼저, 문제가 하나의 통합 문서로 한정되는지 아니면 여러 통합 문서에 영향을 미치는지 확인합니다. 그런 다음 관련 섹션의 지침을 따르십시오.

단일 통합 문서 문제 해결

단일 통합 문서에서 성능 문제가 발생하는 경우 다음 단계를 사용하십시오.

  1. 통합 문서 수정 버전 식별:

    새 통합 문서 수정 버전에서 성능 문제가 발생했는지 확인합니다. 부트스트랩 세션에서 workbookRevision 특성을 검토하면 됩니다. 이 과정에서 사용자 방문 기록을 이전 버전의 통합 문서와 비교해야 할 수 있습니다.

    새 수정 버전으로 인해 성능 문제가 발생하는 경우 통합 문서 소유자에게 연락하여 함께 설계를 개선하십시오.

  2. 사용자별 문제 확인:

    성능 문제가 통합 문서 수정 버전과 관련이 없는 경우 특정 사용자에게만 영향을 미치는지 확인합니다. 부트스트랩 세션에서 requestUri 및 actorUserLuid 특성을 확인하면 됩니다. requestUri 특성은 액세스 중인 통합 문서 또는 뷰의 URL을 제공하고 actorUserLuid 특성은 뷰에 액세스하는 사용자를 제공합니다. 두 특성을 모두 사용하면 개별 사용자 세션을 구별하는 데 도움이 될 수 있습니다.

    사용자와 관련된 문제인 경우 사용자 간에 유사점이 있는지 확인합니다. 예를 들어 이러한 사용자가 액세스하는 사용자 지정 뷰나, 뷰와 상호 작용하는 특정 방식 때문일 수 있습니다. 특정 뷰를 식별하려면 requestURI 특성을 구문 분석해야 합니다.

  3. 행 수준 보안 검토:

    일부 사용자에게 성능 문제가 발생하고 사용자 지정 뷰가 원인이 아닌 경우, 문제는 통합 문서에 구현된 RLS(행 수준 보안)와 관련이 있을 수 있습니다. RLS는 특히 보안 규칙이 복잡하거나 데이터 집합이 큰 경우 성능에 상당한 영향을 줄 수 있습니다. 자세한 내용은 Tableau의 행 수준 보안 옵션에 대한 개요를 참조하십시오.

통합 문서 하위 집합 문제 해결

통합 문서의 하위 집합과 관련된 성능 문제가 발생한 경우 다음 단계를 사용하십시오.

  1. 공통 데이터 원본 식별:

    영향을 받는 통합 문서에 사용된 데이터 원본에서 공통점을 찾습니다.

    영향을 받는 통합 문서가 데이터베이스 서버 또는 클라우드 데이터 웨어하우스에 대한 라이브 연결을 사용하는 경우 성능 문제가 라이브 연결에 있을 수 있습니다.

    영향을 받는 통합 문서가 데이터 추출을 사용하는 경우 최근 업데이트가 있는지 확인합니다. 작업 로그의 hist_publish_datasource 이벤트 유형이나 관리자 인사이트의 TS 이벤트 데이터 원본을 사용하여 최근 변경 내용을 확인할 수 있습니다.

  2. 데이터 원본 성능 검토:

    라이브 연결의 경우 데이터베이스 서버 또는 클라우드 데이터 웨어하우스의 성능을 모니터링합니다. 서버 측에서 최근 변경 사항이나 문제가 있는지 확인합니다. 이 단계는 Tableau 외부에서 수행됩니다.

    추출된 데이터 원본의 경우 추출 프로세스와 최근 업데이트를 검토합니다. 추출이 최적화되었는지, 데이터가 지나치게 크거나 복잡하지 않은지 확인합니다. 자세한 내용은 웹에서 추출 만들기를 참조하십시오.

중요 고려 사항

작업 로그를 사용하여 뷰 로드 시간을 모니터링하면 대시보드 성능과 사용자 참여를 파악하는 데 매우 유용합니다. 그러나 모든 대시보드 또는 뷰 렌더링 작업이 부트스트랩 세션 이벤트를 생성하는 것은 아닙니다. 부트스트랩 세션 이벤트가 필요하지 않은 몇 가지 시나리오는 다음과 같습니다.

  • 캐시된 대시보드: 대시보드 또는 뷰가 이전 캐시에서 검색된 경우.

  • 탭 전환: 사용자가 동일한 통합 문서 내에서 탭을 전환하는 경우, 새 탭의 콘텐츠가 로드되거나 캐시됩니다.

vizql_http_request 이벤트 유형을 사용하고 bootstrapSession 이벤트에 초점을 맞추면 뷰 성능에 대한 유용한 인사이트를 얻고 사전에 문제를 해결할 수 있습니다.

맨 위로 이동
피드백을 제공해 주셔서 감사합니다!귀하의 피드백이 제출되었습니다. 감사합니다!