Performance Hub 로고Performance Hub
사이트 섹션: 문서

조사 예시

이 페이지의 내용

이 예시는 감사 로그로 일반적인 질문에 답하는 방법을 보여 줍니다. 각 예시에는 질문, 사용할 필터와 클릭 동작, 확인할 내용이 나와 있습니다. 같은 단계는 모든 종류의 사이트에서 사용할 수 있으므로, 필터를 자신의 질문에 맞게 조정하십시오.

빠른 참조

찾는 위치: 설정(왼쪽 하단의 톱니바퀴 아이콘) → 감사 로그

대상: 조직에서 감사 로그와 Identity & Access Management가 포함된 역할(예: Organisation Administrator)이 필요합니다. 감사 로그를 사용할 수 있는 사용자를 참조하십시오.

목적: 질문에서 출발하여 그 답이 되는 요청을 찾습니다

누가 정문을 잠금 해제했습니까?

체육관 또는 레저 센터: 정문이 원격으로 잠금 해제되었고, 당직 관리자는 누가 왜 그렇게 했는지 알고 싶어 합니다.

  1. Logs 탭에서 Endpoint를 클릭하고 /api/door-gate-access/*를 입력한 다음 Apply를 클릭합니다. 목록에 Door & Gate Access 요청만 표시됩니다.
  2. 잠금 해제 시간이 포함되도록 Range를 설정합니다.
  3. 엔드포인트가 /front-entrance/unlock으로 끝나는 요청을 클릭합니다.

/api/door-gate-access/*로 필터링되고 정문 잠금 해제 요청이 열려 있는 Logs 탭/api/door-gate-access/*로 필터링되고 정문 잠금 해제 요청이 열려 있는 Logs 탭

그림 1: 모든 출입문 요청과 열려 있는 정문 잠금 해제 요청

확인할 내용: User에는 출입문을 잠금 해제한 사람이 표시됩니다(여기서는 oscar.tran@example.com). Request POST Body에는 그 사람이 입력한 사유인 "Member forgot access card"가 표시되고, Response Body에는 출입문이 잠금 해제되었음이 표시됩니다.

다음 단계: Door & Gate Access 접근 로그에서 해당 출입문의 자체 기록을 확인하십시오. 이 기록에는 모바일 앱을 포함하여 출입문의 모든 잠금 해제 시도가 기록됩니다.

직원이 다른 사람의 역할을 변경하지 못한 이유는 무엇입니까?

물리치료 클리닉: 코디네이터가 동료에게 새 역할을 부여하려 했지만 되지 않았습니다.

  1. Logs 탭에서 Status를 클릭하고 403 Forbidden을 선택합니다.
  2. 역할 변경 시점의 403 Forbidden 요청을 클릭합니다.
  3. AI Error Summary에서 Generate summary를 클릭합니다.

변경을 시도한 사람에게 해당 역할을 할당할 권한이 없었다고 설명하는 AI Error Summary변경을 시도한 사람에게 해당 역할을 할당할 권한이 없었다고 설명하는 AI Error Summary

그림 2: 요약에서 역할 변경이 거부된 이유를 설명합니다

확인할 내용: 요약에는 그 사람이 "does not have permission to assign that role"(해당 역할을 할당할 권한이 없음)이라고 표시됩니다. 이를 "You don't have permission to assign this role."이라고 표시된 Response Body와 대조하십시오. Request POST Body에는 부여하려 한 역할이 표시됩니다.

다음 단계: Organisation Administrator에게 변경을 요청하거나 그 사람의 역할을 검토하십시오. 사용자 역할 변경 및 역할 템플릿을 참조하십시오.

예약 통합이 밤사이 동기화를 멈췄습니다

수영 센터 또는 지자체 시설: 예약 시스템의 체크인이 밤사이 더 이상 표시되지 않았습니다.

  1. Logs 탭에서 Endpoint를 클릭하고 /partner/v1/*를 입력한 다음 Apply를 클릭합니다.
  2. Range를 Last 24 hours로 설정합니다.
  3. 각 행 시작 부분의 상태를 확인한 다음, 실패한 요청을 클릭하여 Response Body를 읽습니다.

확인할 내용: integrations@example.org에서 보낸 api-key 배지가 있는 요청입니다. 여기서는 목록에 통합이 짧은 시간에 너무 많은 요청을 보낸 경우인 429 Too Many Requests와 503 Service Unavailable이 표시됩니다. 실패가 언제 시작되었는지, 이후에 성공한 요청이 있는지 기록해 두십시오.

다음 단계: CSV 내보내기를 클릭하고 파일을 통합 파트너에게 보내 파트너 측을 확인하도록 하십시오. 로그 내보내기 및 Partner API 오류 페이지를 참조하십시오.

웹후크가 저장되지 않았습니다

카페, 매장 또는 접객 시설: 관리자가 방문자 세부 정보를 다른 시스템으로 보내는 웹후크를 설정했지만 저장되지 않았습니다.

  1. Logs 탭에서 Email을 클릭하고 관리자의 전체 이메일 주소를 입력합니다(여기서는 leo.hargreaves@example.com).
  2. 관리자가 웹후크를 저장한 시점의 POST 요청 두 개를 찾습니다. 같은 엔드포인트에 대한 400 Bad Request와 201 Created입니다.
  3. 400 Bad Request를 클릭한 다음 몇 분 후의 201 Created를 클릭하여 두 요청을 비교합니다.

확인할 내용: 400의 Response Body에는 "url must start with https://"라고 표시됩니다. 해당 Request POST Body에서는 주소 앞에 https://가 없습니다. 201에서는 관리자가 https://를 추가했고 웹후크가 저장되었습니다.

다음 단계: 실패한 요청의 경우 Generate summary를 클릭하면 이해하기 쉬운 설명을 볼 수 있습니다. AI Error Summary를 참조하십시오.

퇴사하는 직원이 지난주에 무엇을 했습니까?

사무실 또는 코워킹 사이트: 직원이 퇴사하기 전에 관리자가 최근 활동 기록을 원합니다.

  1. Logs 탭에서 Email을 클릭하고 그 사람의 전체 이메일 주소를 입력합니다.
  2. Range를 Last 7 days로 설정합니다.
  3. 모든 요청이 로드되도록 목록 맨 아래까지 스크롤합니다. 내보내기에는 로드된 행만 포함됩니다.
  4. CSV 내보내기를 클릭한 다음 Export를 클릭합니다.

확인할 내용: 조회가 아닌 변경 사항입니다. Method를 POST, PUT, PATCH, DELETE로 차례로 설정하여 항목을 생성, 변경 또는 제거한 요청을 확인하십시오. 예상치 못한 항목이 있으면 요청을 열고 Request POST Body를 읽으십시오.

다음 단계: 직원이 퇴사하면 접근 권한을 제거하십시오. 사용자 제거를 참조하십시오. CSV 파일은 조직의 정책에 따라 보관하십시오.

실패한 요청이 가장 많았던 사이트는 어디입니까?

다중 사이트 운영자: 어제 여러 사이트에서 문제가 보고되었고, 본사는 어디서부터 시작해야 할지 알고 싶어 합니다.

  1. Dashboard 탭에서 해당 날짜가 포함되도록 Window를 설정합니다.
  2. Errors Over Time에서 오류가 가장 많았던 구간을 클릭합니다. Logs 탭이 열리고 해당 시간의 실패한 요청이 표시됩니다.
  3. 시설를 클릭하고 각 사이트를 차례로 선택하여 사이트별 실패한 요청 수를 비교합니다.

확인할 내용: 다른 사이트보다 실패가 훨씬 많은 사이트 또는 하나의 엔드포인트에 집중된 실패입니다. 해당 사이트의 요청 몇 개를 열고 Response Body를 읽거나 Generate summary를 클릭하십시오.

다음 단계: 다른 차트는 대시보드를, 조직의 사이트는 시설을 참조하십시오.