WxCalling에 대한 HAR 로그 이해 및 트러블슈팅

소개

이 문서에서는 HAR 로그의 이해 및 문제 해결에 대해 설명합니다.

기능 개요

HAR 로그(HTTP 아카이브 로깅의 약어)는 특정 세션 동안 브라우저와 웹 사이트 간의 모든 네트워크 활동에 대한 로그입니다.

웹 사이트를 방문하면 브라우저에서 서버에 요청을 보내고 응답을 받습니다. HAR 파일은 이러한 모든 요청, 응답 및 타이밍 정보를 캡처합니다.

웹 성능 문제를 진단하고 네트워크 오류를 해결하며 API 트랜잭션을 분석하는 데 필수적입니다.

HAR 로그는 느린 로드 리소스, 실패한 요청, 웹 애플리케이션과의 사용자 상호 작용을 추적하는 데 도움이 됩니다.

제한 사항

• HAR 파일은 크고 수동으로 구문 분석하기가 어려울 수 있습니다.
• 중요한 데이터를 기록할 수 있습니다. 공유하기 전에 데이터 무결성 보장
• 일부 보안 정책은 전체 HAR 캡처를 차단할 수 있습니다.

주의: HAR 파일은 요청 및 응답의 전체 내용을 일반 텍스트(비밀번호, 세션 ID, 쿠키 등 포함)로 포함합니다. 따라서 세션에서 가져온 HAR 파일을 공개적으로 사용 가능한 서비스에 공유해서는 안 됩니다. 비밀번호를 입력할 때 Network(네트워크) 탭이 열리면 HAR 파일의 일반 텍스트로 표시됩니다. HAR 파일을 공유하기 전에 이러한 자격 증명을 제거할 수 있습니다. 텍스트 편집기에서 저장된 HAR 파일을 열고 암호를 찾은 다음 ""과 같은 임의의 텍스트로 바꿉니다. 이 변경 사항을 적용하는 동안 파일의 JSON 형식을 수정하지 마십시오. 검토용으로 올바르게 구문 분석되지 않습니다.

HAR Sanitizer 툴

기록

2023년에 Okta는 지원 사례 관리 시스템에서 HAR 파일을 도난당하는 보안 침해를 겪었습니다. 공격자는 해당 파일의 액세스 토큰과 쿠키를 사용하여 고객 계정에 액세스했습니다. 이에 대응하여 Okta는 삭제 도구를 구현했습니다.

현재 상태

현재 추적에서 민감한 재료를 제거하려고 하고 있지만 나머지는 문제를 해결하고 분석하는 기능을 유지하기 위해 그대로 두는 지속적인 자동화가 있습니다.

HAR 파일을 업로드하면 툴이 자동으로 다음을 수행합니다.

1. HAR 파일이 업로드되었음을 탐지합니다.
2. https://har-sanitize.cisco.com을 사용하여 HAR 파일을 정리합니다
3. 정리된 파일을 케이스에 업로드합니다.
4. GPG를 사용하여 원본 HAR 파일을 암호화합니다.
5. 암호화된 HAR 파일을 케이스에 업로드합니다.
6. 케이스에서 원본 HAR 파일을 삭제합니다.
7. 수행된 작업을 설명하는 케이스 메모 및 이 도구에 대한 링크를 추가합니다.

참고: HAR 파일의 삭제 버전을 사용하여 문제를 해결할 수 없는 경우 다음 섹션에 설명된 대로 예외를 제출하고 원래 HAR 파일의 복사본을 다시 가져올 수 있습니다.

HAR 로그를 추출하는 방법

브라우저에서 HAR 파일 생성

참조: 브라우저에서 HAR 파일을 생성합니다.

문서에서 추출:

• 크롬:
  Developer Tools(F12) > Network(네트워크) 탭 > Preserve Log(로그 보존) > Start Recording(기록 시작) > Reproduce Issue(문제 재생) > Export HAR File(HAR 파일 내보내기)을 엽니다.
• Firefox:
  Developer Tools(F12) > Network(네트워크) 탭 > Engine(엔진) 아이콘을 열고 > "Persist Logs(로그 지속)"를 선택합니다. > Start Recording(기록 시작) > Save HAR(HAR 저장)을 선택합니다.

HAR 로그를 분석하기 전에 유용한 정보

HTTP 메서드

HTTP 메서드(HTTP 동사라고도 함)는 클라이언트가 지정된 리소스(예: 데이터 또는 웹 페이지)에서 수행하려는 작업의 유형을 정의합니다.

각 방법에는 특정한 목적과 의미가 있다.

가장 일반적인 HTTP 메서드는 다음과 같습니다. GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE.

* PATCH는 일반적으로 이분성이지만 구현에 따라 다릅니다.

열 설명

• 안전: HTTP 메서드가 안전한 것으로 간주되는지 여부를 나타냅니다. 즉, 리소스 또는 서버 상태를 수정하지 않습니다. 안전 메서드는 검색을 위해서만 사용되며 변경을 위해서가 아닙니다. 일반적으로 읽기 전용 작업에 사용됩니다.
• Idempotent: 동일한 HTTP 요청을 여러 번 반복해도 한 번 수행하는 것과 동일한 효과가 있는지 여부를 지정합니다. idempotent 메소드는 요청이 몇 번 반복되어도 결과가 변경되지 않은 상태로 유지됨을 의미합니다(첫 번째 성공 요청 이후)
• 일반 사용: HTTP 메소드가 사용되는 일반적인 목적 또는 시나리오를 설명합니다. 이 옵션은 웹 개발 또는 API 설계에서 각 메소드를 사용하는 시기와 이유에 대한 컨텍스트를 제공합니다.
• Request Body(요청 본문): 일반적으로 HTTP 요청에 본문(서버로 전송된 데이터)이 포함되는지 여부를 나타냅니다. 요청 본문은 리소스를 만들거나 업데이트할 때와 같이 서버에 데이터(예: JSON, XML, 양식 데이터)를 보내는 데 자주 사용됩니다. 
• 응답 본문: HTTP 응답에 일반적으로 본문(서버에서 반환한 데이터)이 포함되는지 여부를 지정합니다. 응답 본문은 요청된 리소스, 상태 메시지 또는 작업 확인과 같이 서버에서 클라이언트로 다시 전송되는 데이터입니다.

HAR 로그 분석

참고: 이 섹션의 모든 예제 이미지는 조직의 Control HUB에서 위치를 로드할 때 생성되었습니다

헤더

HTTP 요청 및 응답 중에 클라이언트(브라우저)와 서버 간에 교환되는 메타데이터를 캡처합니다.

헤더는 콘텐츠 유형, 인증 정보, 캐싱 정책 등과 같이 전송 또는 수신하는 데이터에 대한 컨텍스트를 제공합니다.

헤더는 HAR 로그의 다음 섹션에 포함됩니다.

1. 요청 헤더: 이러한 메시지는 HTTP 요청의 일부로 브라우저(클라이언트)에서 서버로 전송됩니다.
2. 응답 헤더: 이러한 정보는 요청에 대한 응답으로 서버에서 브라우저에 반환됩니다.

헤더는 키-값 쌍의 배열로 저장됩니다. 여기서

• 키: 헤더의 이름입니다.
• 가치: 헤더와 연결된 값입니다.

공통 요청 헤더

1. 호스트 서버의 도메인 이름(예: as example.com) 및 포트 번호를 지정합니다.

• 예: 호스트: www.example.com

2. 사용자-대리인 버전 및 운영 체제와 함께 요청을 하는 브라우저 또는 클라이언트를 식별합니다.

• 예: 사용자 에이전트: Mozilla/5.0 \(Windows NT 10.0; Win64; x64\)

3. 수락: 클라이언트가 처리할 수 있는 콘텐츠 형식(예: HTML, JSON, 이미지)을 나타냅니다.

• 예: Accept: text/html,application/xhtml+xml

4. 인코딩 허용: 클라이언트가 디코딩할 수 있는 인코딩 유형(예: gzip, deflate)을 지정합니다.

• 예: Accept-Encoding: gzip, deflate

5. 인가 인증용 자격 증명(예: 토큰 또는 기본 인증 자격 증명)을 포함합니다.

• 예: 권한 부여: 전달자 <토큰>

6. 쿠키 클라이언트가 서버로 보낸 쿠키를 포함합니다.

• 예: 쿠키: sessionId=12345; userPref=darkMode

7. 콘텐츠 형식 요청 본문에서 전송되는 데이터 유형을 나타냅니다(POST/PUT 요청의 경우).

• 예: Content-Type: application/json

8. 심판 클라이언트를 현재 리소스로 참조한 페이지의 URL을 식별합니다.

• 예: 참조: https://www.example.com/

공통 응답 헤더

1. 콘텐츠 형식: 리소스의 MIME 유형(예: text/html, application/json)을 지정합니다.

• 예: Content-Type: application/json

2. 내용연수 응답 본문의 크기를 바이트 단위로 나타냅니다.

• 예: Content-Length: 1234

3. 캐시 제어 리소스에 대한 캐싱 정책(예: 캐싱 가능 여부 및 기간)을 지정합니다.

• 예: 캐시 제어: no-cache, no-store, revalidate해야 함

4. 서버 서버 소프트웨어/버전을 식별합니다.

• 예: 서버: Apache/2.4.29

5. 세트쿠키 서버가 클라이언트에 저장할 쿠키를 포함합니다.

• 예: Set-Cookie sessionId=67890; 경로=/; 보안

6. 날짜 서버에서 응답을 생성한 날짜 및 시간입니다.

• 예: 날짜: 2023년 10월 10일 화요일 12:00:00 GMT

7. 위치 리디렉션에 사용되며 클라이언트가 이동해야 하는 URL을 나타냅니다.

• 예: 위치: https://www.example.com/new-page

8. 전자문서 캐싱과 버전 지정에 자주 사용되는 리소스의 고유 식별자입니다.

• 예: ETag: 12345abcd

9. 콘텐츠 인코딩 응답 본문이 인코딩되는 방식(예: gzip, deflate)을 나타냅니다.

• 예: 콘텐츠 인코딩: 지집

10. 출입통제 허용기준 리소스에 액세스할 수 있는 원본을 지정합니다(CORS에서 사용).

• 예: Access-Control-Allow-Origin *

참고: Webex Calling과 가장 관련이 있는 것은 Trackingid 헤더이며, 이는 LMA 툴에서 조회할 수 있는 ID입니다.

페이로드

HTTP 요청 또는 응답의 본문에서 보내거나 받은 데이터.

POST, PUT 또는 PATCH 요청과 가장 일반적으로 연관되어 있으며, 클라이언트는 양식 제출, 파일 업로드 또는 API를 위한 JSON 데이터와 같은 데이터를 서버에 전송합니다.

페이로드는 HTTP 응답에도 존재할 수 있으며, 여기에는 HTML, JSON 또는 이진 콘텐츠(예: 이미지, 파일)와 같이 서버에서 반환하는 데이터가 포함됩니다.

페이로드가 HAR 로그에 표시되는 위치

페이로드는 일반적으로 HAR 로그의 두 가지 기본 섹션에 있습니다.

1. 요청 페이로드: 클라이언트(브라우저)에서 HTTP 요청 본문의 서버로 전송된 데이터.
2. 응답 페이로드: 서버가 HTTP 응답 본문에서 클라이언트에 반환한 데이터.

미리보기

response.content 개체의 일부이며, 서버가 반환한 데이터를 구조적이고 사람이 읽을 수 있는 형식으로 표시합니다(사용 가능한 경우).

Preview는 일반적으로 응답 본문에서 구문 분석되거나 구조화된 데이터를 JSON, XML 또는 기타 형식과 같은 사용자 친화적인 방식으로 표시하는 데 사용됩니다.

이 섹션은 API 디버깅, 반환된 데이터 검사 또는 서버 응답의 구조 이해에 특히 유용합니다.

응답

응답은 특정 요청을 위해 서버가 클라이언트(브라우저)에 보낸 HTTP 응답에 대한 세부 정보를 제공합니다. 이 섹션에는 메타데이터, 헤더, 콘텐츠 세부 정보 및 요청-응답 주기 동안 서버의 동작을 이해하는 데 도움이 될 수 있는 기타 중요한 데이터가 포함되어 있습니다. HTTP 요청에 대한 서버 응답의 자세한 스냅샷을 제공합니다.

개시자

개시자는 웹 페이지를 로드하는 동안 특정 HTTP 요청을 트리거한 대상에 대한 정보를 제공합니다. 개시자는 네트워크 요청의 소스 또는 원인을 식별하여 개발자가 요청으로 이어진 이벤트 체인을 이해할 수 있도록 도와줍니다. 또한 개시자는 요청의 출처를 추적하고 요청을 만드는 정확한 코드나 리소스를 가리킬 수 있습니다.

타이밍

타이밍은 HTTP 요청 및 응답 처리와 관련된 여러 단계의 세부 분석을 제공합니다. 이 방법은 개발자가 연결을 시작하는 시점부터 최종 응답을 받는 시점까지 요청-응답 주기의 각 단계가 얼마나 걸리는지 이해하는 데 도움이 됩니다. 또한 브라우저가 서버에 요청을 하고 응답을 받을 때 발생하는 이벤트의 시퀀스 및 기간을 추적합니다. DNS 확인, 연결 설정, 요청 전송, 서버 응답 대기 및 응답 데이터 다운로드에 대한 자세한 메트릭이 포함됩니다.

문제 해결

HAR 로그를 보는 내부 도구

EasyLmaSearch > Import HAR/Saz file(HAR/Saz 파일 가져오기)로 이동합니다.

일반 문제 해결 단계

1. 에서 HAR 파일을 엽니다.
2. 실패한 요청(예: HTTP 4xx/5xx 오류)을 식별합니다.

3. 응답 시간 및 느린 로딩 요소를 확인합니다.

4. 인증 및 CORS 문제에 대한 요청/응답 헤더를 분석합니다.

5. 네트워크 요청에서 추적 ID를 찾고 를 클릭합니다.
6. 가능한 경우 응답에 대한 불합격 여부의 비교

티켓의 문제 해결 예

느린 로딩 요소

예:

• Control Hub에서 위치에 대한 번호를 로드하는 데 시간이 오래 걸립니다.

문제 해결:

• 문제에 대한 비디오를 요청합니다(위치에 대한 숫자 페이지를 로드하려고 시도).
• 위치에 대한 번호를 로드하는 동안 HAR 로그 요청

1. HAR 뷰어 또는 브라우저 개발자 도구에서 HAR 파일을 엽니다.
   
2. Waterfall에서 요청 식별 보기
   
3. 로드하는 데 시간이 오래 걸리는 요청을 클릭합니다.
4. 로그의 Timing 탭을 검토합니다.

5. 응답 시간 및 느린 로딩 요소를 확인합니다.

6. 해당 헤더의 Trackingid를 수집합니다.

7. EasyLMA를 열고 추적 ID로 검색합니다.

타이밍 분류 단계 설명

다음은 시간 탭에서 볼 수 있는 각 단계에 대한 자세한 정보입니다.

• 대기 중입니다. 브라우저는 연결 시작 전 및 다음과 같은 경우에 요청을 대기시킵니다.
  • 우선 순위가 더 높은 요청이 있습니다. 요청 우선 순위는 리소스 유형 및 문서 내의 위치와 같은 요소에 의해 결정됩니다. 자세한 내용은 fetchpriority guide의 resource priority 섹션을 참조하십시오.
  • 이 오리진에 대해 이미 6개의 TCP 연결이 열려 있으며, 이는 제한입니다. (HTTP/1.0 및 HTTP/1.1에만 적용됩니다.)
  • 브라우저가 디스크 캐시에 공간을 할당하는 중입니다.
• 멈춰. 요청은 큐잉에 설명된 이유 중 하나로 인해 연결 시작 후 중단될 수 있습니다.
• DNS 조회. 브라우저에서 요청 IP 주소를 확인하고 있습니다.
• 초기 연결. 브라우저에서 연결을 설정하고 있으며, 여기에는 TCP 핸드셰이크 또는 재시도, SSL 협상 등이 포함됩니다.
• 프록시 협상. 브라우저에서 프록시 서버와 요청을 협상하고 있습니다.
• 요청이 전송되었습니다. 요청을 보내는 중입니다.
• ServiceWorker 준비 브라우저에서 서비스 작업자를 시작하고 있습니다.
• ServiceWorker에 요청 서비스 작업자에게 요청을 보내고 있습니다.
• 대기 중(TTFB). 브라우저가 응답의 첫 번째 바이트를 기다리고 있습니다. TTFB는 Time To First Byte를 의미합니다. 이 타이밍에는 1회의 왕복 지연 시간과 서버가 응답을 준비하는 데 걸린 시간이 포함됩니다.
• 콘텐츠 다운로드. 브라우저가 네트워크에서 직접 또는 서비스 작업자로부터 응답을 수신합니다. 이 값은 응답 본문을 읽는 데 소요된 총 시간입니다. 값이 예상보다 크면 네트워크가 느리거나 브라우저가 다른 작업을 수행 중이어서 응답 읽기가 지연되고 있음을 나타낼 수 있습니다.

리소스를 사용할 수 없음

예: 

"관리 제어 허브의 사용자에 대해 SNR을 활성화했지만 user.webex.com 포털에 로그인할 때 SNR 번호를 설정하는 옵션이 표시되지 않습니다.
사용자 허브에서 볼 수 없는 이유를 조직 및 사용자를 확인해 주시겠습니까?"

문제 해결:

1. 작업 중인 사용자와 그렇지 않은 사용자의 스크린샷을 비교하여 사용자가 무엇을 보고 있는지 확인합니다.

2. 사용자에 대한 옵션을 로드하는 동안 HAR 로그를 요청합니다.

다음 단계:

1. HAR 뷰어 또는 브라우저 개발자 도구에서 HAR 파일을 엽니다. 
   
2. 요청 식별:

Service Makes a Request (GET) to Know the Services of the User

사용자에게 표시되는 서비스의 템플릿을 최종 사용자 기능 액세스 템플릿 요청(GET)으로 호출:

1. 요청/응답 헤더 분석
   
   "No Access(액세스 권한 없음)"는 템플릿이 사용자에 대해 이러한 옵션을 숨기고 있음을 의미합니다.
2. 조직의 템플릿을 검토하고 사용자가 사용자 허브에서 볼 수 있도록 단일 번호 도달 범위를 켜야 합니다.

예:

기능을 활성화할 수 없음

통화 녹음 예:

사용자에 대해 통화 녹음을 활성화하려고 하면 다음과 같은 오류 메시지가 표시됩니다. "통화 녹음 변경을 실패했습니다."

문제 해결 방법:

1. 전체 오류 메시지 텍스트를 요청하여 오류를 확인합니다.

2. 오류 스크린샷을 요청합니다.

3. 영향을 받은 사용자에게 "통화 녹음"을 사용하도록 설정하는 동안 HAR 로그를 요청합니다.

4. HAR 뷰어 또는 브라우저 개발자 도구에서 HAR 파일을 엽니다.

5. 실패한 요청(예: HTTP 4xx/5xx 오류)을 식별합니다.

6. EasyLMA에서 추적 ID를 찾습니다.


7. cpapi 예외로 BEMS를 열 수 있습니다.

8. 수집된 정보로 BEMS를 엽니다.

• 스크린샷
• 오류 메시지 완료
• 추적 ID
• cpapi 예외
  
  

9. Dubber 공간에서 또는 BU 팀에 요청하여 Dubber 팀과 함께 오류를 검토합니다.
"오류 응답 요약: 400: 잘못된 제품: Dubber에서 dub 지점을 만들지 못했습니다. HTTP 상태: 502"

팩스 메시징

마이크로서비스를 통해 이동하는 프로비저닝 흐름을 보여주는 다이어그램은 다음과 같습니다.

Control Hub에서 팩스 메시징 프로비저닝 문제를 해결할 때, 문제의 본질에 대한 자세한 정보를 수집하고 프로비저닝 실패의 원인을 파악하기 위해 HAR 추적을 수집하는 것이 중요합니다. 

팩스 메시징 기능을 활성화하면 HAR 추적은 CH에서 CPAPI로의 관련 요청을 캡처하여 표시합니다. 이 캡처된 요청은 특정 형식을 따릅니다.

CPAPI→ CH에서:

패치
요청 URL: https://cpapi-r.wbx2.com/api/v1/customers/[OrgID]/users/[CHUserID]/voicemail
TrackingID ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

게시물 데이터 {
"사용": 참,
"알림": {
"사용": 참,
"대상": "lazoclaudiafi+faxmessaging@gmail.com"
},
"모든 통화 보내기": {
"사용": 틀려
},
"통화 중 통화 보내기": {
"사용": 참,
"인사말": "기본값"
},
"응답하지 않은 통화 보내기": {
"사용": 참,
"인사말": "기본값",
"maxRings": 3
},
"호전환 번호": {
"사용": 틀려
},
"전자 메일 사본 메시지": {
"사용": 참,
"전자 메일 ID": "lazoclaudiafi+faxmessaging@gmail.com"
},
"팩스 메시지": {
"사용": 거짓,
"전화 번호": "+12099193323",
"확장": 공백
},
"메시지 저장소": {
"mwiEnabled": 참,
"storageType": "내부",
"외부 이메일": "lazoclaudiafi+faxmessaging@gmail.com"
}

EasyLMA에서 이 정보를 효과적으로 추적하려면 여기에 제공된 자세한 지침을 참조하십시오. 

범주: TrackingID
하위 범주: 글로벌
Webex 추적 ID: ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

에스컬레이션 정보

• HAR 로그 파일
• 오류 스크린샷
• 문제 재현 단계
• 인시던트의 타임스탬프
• LMA 로그

추가 트러블슈팅에 도움이 되므로 BEMS 에스컬레이션을 열기 전에 다음 질문에 답하십시오.

• 어떤 오류가 보입니까?
• 어떤 추적 ID가 표시됩니까?
• LMA에서 추적 ID를 검토했습니까?
• LMA에는 어떤 내용이 있습니까?
• 이 BEMS가 정말 필요합니까?