WxCallingのHARログの理解とトラブルシューティング

はじめに

このドキュメントでは、HARログの説明とトラブルシューティングについて説明します。

機能の概要

HAR Log（HTTP Archive Loggingの略）は、特定のセッションにおけるブラウザとWebサイトの間のすべてのネットワークアクティビティのログです。

Webサイトにアクセスすると、ブラウザがサーバに要求を送信し、応答を受信します。HARファイルは、これらの要求、応答、およびタイミング情報をすべてキャプチャします。

これらは、Webパフォーマンスの問題の診断、ネットワークエラーのトラブルシューティング、およびAPIトランザクションの分析に不可欠です。

HARログは、読み込みが遅いリソース、要求の失敗、およびWebアプリケーションとのユーザのインタラクションの追跡に役立ちます。

制限事項

• HARファイルはサイズが大きく、手動で解析することが困難な場合があります。
• 機密データはログに記録できます。共有する前にデータのサニタイズを確認してください。
• セキュリティポリシーによっては、HARの完全なキャプチャをブロックできます。

注意: HARファイルには、要求と応答の内容全体がクリアテキスト（パスワード、セッションID、Cookieなど）で含まれています。 したがって、セッションで取得したHARファイルを公的に利用可能なサービスと共有しないでください。パスワードを入力したときに[ネットワーク]タブが開いていた場合は、HARファイル内にクリアテキストで表示されます。HARファイルを共有する前に、これらの資格情報を削除する必要があります。保存したHARファイルをテキストエディタで開き、パスワードを検索して「」のようなランダムなテキストに置き換えます。 この変更を行っている間はファイルのJSON形式を変更しないでください。変更した後は、レビュー用に適切に解析されません。

HARサニタイザーツール

履歴

2023年、Oktaはセキュリティ侵害を受け、サポートケース管理システムからHARファイルが盗まれました。攻撃者は、これらのファイルから取得したアクセストークンとcookieを使用して、顧客アカウントにアクセスしました。 これに応えて奥田はサニタイズのツールを導入。

現在の状態

現在、トレースから機密資料を削除する自動化が進行中ですが、残りは問題のトラブルシューティングと分析を維持するために残されています。

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 Tab > Preserve Log > Start Recording > Reproduce Issue > Export HAR Fileの順に開きます。
• Firefox：
  Developer Tools (F12) > Network Tab > Engine Icon > Check “Persist Logs” > Start Recording > Save HARの順に開きます。

HARログを分析する前に役立つ情報

HTTPメソッド

HTTPメソッド（HTTP動詞とも呼ばれる）は、クライアントが特定のリソース（データやWebページなど）で実行する操作の種類を定義します。

各メソッドには、特定の目的とセマンティクスがあります。

最も一般的なHTTPメソッドは、GET、POST、PUT、PATCH、DELETE、HEAD、OPTIONS、およびTRACEです。

* PATCHは一般に等力性であるが、実装に依存する。

列の説明

• Safe: HTTPメソッドが安全と見なされるかどうかを示します。つまり、リソースまたはサーバーの状態を変更しません。Safeメソッドは取得専用であり、変更を行うためではありません。通常は、読み取り専用操作に使用されます。
• Idempotent：同じHTTP要求を複数回繰り返し実行した場合に、1回実行した場合と同じ結果が得られるかどうかを指定します。 べき等性メソッドは、要求が何回繰り返されても、結果が変更されないことを意味します（最初に成功した要求の後）
• 一般的な用途：HTTP方式が使用される一般的な目的またはシナリオを説明します。 これにより、Web開発またはAPI設計で各メソッドを使用するタイミングと理由についてのコンテキストが得られます。
• リクエスト本文： HTTPリクエストに通常ボディ（サーバーに送信されるデータ）が含まれているかどうかを示します。 リクエスト本文は、リソースの作成や更新時など、サーバにデータ（JSON、XML、フォームデータなど）を送信するためによく使用されます。 
• 応答の本文： HTTP応答に通常は本文（サーバーによって返されるデータ）が含まれるかどうかを指定します。 応答の本文は、要求されたリソース、ステータスメッセージ、アクションの確認など、サーバからクライアントに返送されるデータです。

HARログの分析

注意：この項に示す例のイメージはすべて、組織のControl HUBにロケーションをロードする際に取得したものです

ヘッダー

HTTP要求および応答中にクライアント（ブラウザ）とサーバの間で交換されるメタデータをキャプチャします。

ヘッダーは、コンテンツのタイプ、認証情報、キャッシュポリシーなど、送受信されるデータに関するコンテキストを提供します。

ヘッダーはHARログの次のセクションに含まれています。

1. 要求ヘッダー：これらは、HTTP要求の一部としてブラウザ（クライアント）からサーバに送信されます。
2. 応答ヘッダー：要求に応答して、サーバからブラウザに返されます。

ヘッダーはキーと値のペアの配列として格納されます。ここで、

• キー：ヘッダーの名前。
• 値：ヘッダーに関連付けられている値。

共通の要求ヘッダー

1. Host：サーバのドメイン名(as example.comなど)とポート番号を指定します。

• 例：ホスト：www.example.com

2. ユーザエージェント：要求を行うブラウザまたはクライアント、およびそのバージョンとオペレーティングシステムを識別します。

• 例： User-Agent: Mozilla/5.0 \(Windows NT 10.0; Win64; x64\)

3. Accept：クライアントが処理できるコンテンツのタイプ（HTML、JSON、イメージなど）を示します。

• 例： Accept: text/html,application/xhtml+xml

4. Accept-Encoding：クライアントがデコードできるエンコーディングのタイプ（gzip、deflateなど）を指定します。

• 例： Accept-Encoding: gzip, deflate

5. Authorization：トークンや基本認証クレデンシャルなどの認証のためのクレデンシャルが含まれます。

• 例：Authorization: Bearer <token>

6. Cookie：クライアントからサーバに送信されるCookieを含みます。

• 例： Cookie: sessionId=12345; userPref=darkMode

7. Content-Type:（POST/PUT要求の）要求本文で送信されるデータのタイプを示します。

• 例：Content-Type:application/json

8. Referer：クライアントを現在のリソースに参照したページのURLを示します。

• 例：Referer: https://www.example.com/

一般的な応答ヘッダー

1.Content-Type：リソースのMIMEタイプを指定します（text/html、application/jsonなど）。

• 例：Content-Type:application/json

2. Content-Length：応答本文のサイズをバイト単位で示します。

• 例： Content-Length: 1234

3. Cache-Control：リソースのキャッシュポリシーを指定します（キャッシュ可能かどうか、キャッシュ期間など）。

• 例： Cache-Control: no-cache, no-store, must-revalidate

4. サーバー：サーバーのソフトウェア/バージョンを示します。

• 例：サーバ：Apache/2.4.29

5. Set-Cookie：サーバーがクライアントに保存させるCookieが含まれます。

• 例： Set-Cookie: sessionId=67890; Path=/; Secure

6. 日付：サーバーが応答を生成した日時。

• 例：日付：2023年10月10日（火）12:00:00 GMT

7. ロケーション：リダイレクトで使用され、クライアントが移動する必要があるURLを示します。

• 例：場所：https://www.example.com/new-page

8. ETag：リソースの一意の識別子で、キャッシュとバージョン管理によく使用されます。

• 例： ETag: 12345abcd

9. Content-Encoding：応答本文の符号化方法（gzip、deflateなど）を示します。

• 例：Content-Encoding:gzip

10. Access-Control-Allow-Origin：リソースへのアクセスを許可するオリジン（CORSで使用）を指定します。

• 例：Access-Control-Allow-Origin: *

注:WebEx通話に最も関連性があるのはTrackingidヘッダーです。これはLMAツールで検索できるIDです。

ペイロード

HTTP要求または応答の本文で送受信されるデータ。

POST、PUT、またはPATCHリクエストに最も一般的に関連付けられます。このリクエストでは、クライアントがサーバにデータ（フォームの送信、ファイルのアップロード、APIのJSONデータなど）を送信します。

ペイロードは、HTML、JSON、またはバイナリコンテンツ（イメージ、ファイルなど）などのサーバによって返されたデータを含むHTTP応答にも存在できます。

HARログ内のペイロードの位置

ペイロードは通常、HARログの次の2つの主要なセクションに含まれています。

1. 要求ペイロード：HTTP要求の本文で、クライアント（ブラウザ）からサーバに送信されるデータ。
2. 応答ペイロード：HTTP応答の本文で、サーバからクライアントに返されるデータ。

プレビュー

response.contentオブジェクトの一部であり、可能であれば構造化された人間が読める形式で、サーバが返すデータを表現します。

プレビューは通常、JSON、XML、またはその他の形式など、応答本文の解析されたデータまたは構造化されたデータをわかりやすい方法で表示するために使用されます。

このセクションは、APIのデバッグ、返されたデータの検査、またはサーバ応答の構造の理解に特に役立ちます。

応答

応答は、特定の要求に対してサーバからクライアント（ブラウザ）に送信されたHTTP応答に関する詳細情報を提供します。 このセクションには、メタデータ、ヘッダー、コンテンツの詳細、およびその他の重要なデータが含まれており、要求と応答のサイクル中のサーバの動作を理解するのに役立ちます。HTTP要求に対するサーバの応答の詳細なスナップショットを提供します。

依頼者（Initiator）

イニシエータは、Webページのロード中に特定のHTTP要求をトリガーした要因について情報を提供します。 ネットワーク要求の送信元または原因を特定し、要求の原因となったイベントのチェーンを開発者が理解できるようにします。 また、イニシエータは要求の発生源をトレースするのに役立ち、要求を作成する責任があるコードまたはリソースの正確な行を指すことができます。

時期

Timingは、HTTP要求および応答の処理に関係するさまざまな段階の詳細な内訳を示します。 この機能は、接続の開始から最終的な応答の受信まで、要求/応答サイクルの各ステップにかかる時間を開発者が理解するのに役立ちます。タイミングは、ブラウザがサーバに要求し、応答を受信するときに発生するイベントのシーケンスと期間を追跡します。  これには、DNS解決、接続の確立、要求の送信、サーバからの応答の待機、応答データのダウンロードに関する詳細なメトリックが含まれます。

トラブルシューティング

HARログを表示する内部ツール

EasyLmaSearch > Import HAR/Saz fileの順に移動します。

一般的なトラブルシューティングの手順

1. HARファイルをで開きます。
2. 失敗した要求（HTTP 4xx/5xxエラーなど）を特定します。

3. 応答時間と遅いロード要素を確認します。

4. 認証およびCORS問題に関する要求/応答ヘッダーを分析します。

5. ネットワーク要求およびでトラッキングIDを探します。
6. 可能であれば、応答に対して失敗をクロスチェックします。

チケットからのトラブルシューティングの例

要素の読み込みが遅い

例：

• Control Hubがロケーションの番号をロードするのに時間がかかる

トラブルシューティング：

• 問題のビデオを要求します（ロケーションの番号ページをロードしようとしています）。
• ロケーションの番号をロードするときにHARログを要求する

1. HARビューアまたはブラウザの開発者ツールでHARファイルを開きます。
   
2. ウォーターフォールで要求を特定します。 view
   
3. ロードに時間がかかる要求をクリックします。
4. ログのTiming タブを確認します。

5. レスポンス時間と遅いロード要素を確認します。

6. そのヘッダーのTrackingidを収集します。

7. EasyLMAを開き、trackingidを使用して検索します。

タイミング内訳フェーズの説明

「Timingtab」に表示される各フェーズの詳細を次に示します。

• キューイング.ブラウザは、接続が開始される前と次の場合に要求をキューに入れます。
  • 優先度の高い要求があります。要求の優先順位は、リソースの種類やドキュメント内でのリソースの場所などの要因によって決まります。詳細は、 fetchpriorityガイドのresource priorityセクションを参照してください。
  • この発信元に対しては、すでに6つのTCP接続が開かれています。これが制限です。（HTTP/1.0およびHTTP/1.1のみに適用）
  • ブラウザがディスク・キャッシュ内の領域を一時的に割り当てています。
• 停滞。「キューイング」で説明されているいずれかの理由により、接続の開始後に要求が遅延する可能性があります。
• DNSルックアップ。ブラウザが要求されたIPアドレスを解決しています。
• 初期接続。ブラウザは、TCPハンドシェイクまたは再試行を含む接続を確立し、SSLをネゴシエートしています。
• プロキシネゴシエーション。ブラウザがプロキシサーバと要求をネゴシエートしています。
• 要求が送信されました。要求を送信しています。
• ServiceWorkerの準備ブラウザはサービスワーカーを起動しています。
• ServiceWorkerに要求します。サービスワーカーに要求を送信しています。
• 待機中(TTFB)。 ブラウザは応答の最初のバイトを待っています。TTFBはTime To First Byteの略です。このタイミングには、1往復の遅延と、サーバが応答の準備に要した時間が含まれます。
• コンテンツダウンロード。ブラウザは、ネットワークから直接、またはサービスワーカーから応答を受信しています。この値は、応答の本文の読み取りに費やされた合計時間です。予想より大きい値は、ネットワークの速度が遅いこと、またはブラウザが他の作業の実行にビジー状態で応答の読み取りが遅れていることを示します。

リソースが利用できません

例： 

「Admin Control HubでユーザのSNRを有効にしましたが、user.webex.comポータルにログインするときにSNR番号を設定するオプションが表示されません。
ユーザハブに表示できない理由を確認するために、組織とユーザを確認してください。」

トラブルシューティング：

1. 作業中のユーザーと作業中でないユーザーのスクリーンショットを要求して、ユーザーの表示内容を確認します。

2. ユーザーのオプションの読み込み中にHARログを要求します。

次のステップ：

1. HARビューアまたはブラウザの開発者ツールでHARファイルを開きます。 
   
2. 要求の識別：

サービスがユーザのサービスを知るための要求(GET)を行う

エンドユーザ機能アクセステンプレート要求(GET)を呼び出して、ユーザに表示されるサービスのテンプレートを取得します。

1. 要求/応答ヘッダーを分析します。
   
   「アクセス権なし」は、テンプレートがユーザのオプションを非表示にしていることを意味します。
2. User Hubでユーザが組織を表示できるようにするには、組織のテンプレートを確認し、シングルナンバーリーチをオンにする必要があります。

例：

機能を有効にできません

コール録音の例：

ユーザのコール録音を有効にしようとすると、「Call recording change failed」というエラーメッセージが表示されます。

解決するには、以下を実行します。

1. エラーメッセージの全文を入力して、エラーを確認します。

2. エラーのスクリーンショットを要求します。

3. 影響を受けるユーザで「通話録音」を有効にするときに、HARログを要求します。

4. HARファイルをHARビューアまたはブラウザの開発者ツールで開きます。

5. 失敗した要求（HTTP 4xx/5xxエラーなど）を特定します。

6. EasyLMAでトラッキングIDを探します。


7. cpapi例外を使用すると、BEMSをオープンできます。

8. 収集した情報を使用してBEMSをオープンします。

• スクリーンショット
• エラーメッセージの完了
• 追跡ID
• cpapi例外
  
  

9. ダバースペースまたはBUチームに問い合わせて、ダバーチームとエラーを確認します。
「エラー応答の概要： 400：無効な製品：ダバでダブポイントを作成できませんでした。HTTPステータス：502インチ

FAXメッセージング

次の図は、マイクロサービスを移動するときのプロビジョニングフローを示しています。

Control Hub内でファックスメッセージングのプロビジョニングの問題をトラブルシューティングする場合、問題の性質に関する詳細な洞察を収集し、プロビジョニング失敗の原因を理解するために、HARトレースを収集することが不可欠です。 

ファックスメッセージング機能を有効にすると、HARトレースがCHからCPAPIへの関連する要求をキャプチャして表示します。このキャプチャされた要求は、特定の形式に従います。

CH → CPAPIから：

パッチ
リクエストURL:https://cpapi-r.wbx2.com/api/v1/customers/[OrgID]/users/[CHUserID]/voicemail
TrackingID ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

データの投稿{
"enabled": true,
「通知」: {
"enabled": true,
"destination": "lazoclaudiafi+faxmessaging@gmail.com"
},
"sendAllCalls": {
"enabled": false
},
"sendBusyCalls": {
"enabled": true,
「greeting」:「DEFAULT」
},
"sendUnansweredCalls": {
"enabled": true,
“greeting": "DEFAULT",
「maxRings」:3
},
「transferToNumber」: {
"enabled": false
},
"emailCopyOfMessage": {
"enabled": true,
"emailId": "lazoclaudiafi+faxmessaging@gmail.com"
},
「ファックスメッセージ」: {
"enabled": false,
"電話番号": "+12099193323",
"extension": null
},
"messageStorage": {
"mwiEnabled": true,
"storageType": "INTERNAL",
「externalEmail」:「lazoclaudiafi+faxmessaging@gmail.com」
}

EasyLMAでこの情報を効率的に追跡するには、ここで提供される詳細なガイダンスを参照してください。 

カテゴリ： TrackingID
サブカテゴリ：グローバル
WebexトラッキングID: ATLAS_4fd0efd2-f0e4-4ca2-a932-16f4b0884a48_12

エスカレーション情報

• HARログファイル
• エラーのスクリーンショット
• 問題を再現する手順
• インシデントのタイムスタンプ
• LMAログ

BEMSエスカレーションを開始する前に、次の質問に回答してください。これは、さらなるトラブルシューティングに役立ちます。

• どのようなエラーが表示されますか。
• どのようなトラッキングIDが表示されますか。
• LMAのトラッキングIDを確認しましたか。
• LMAで何が見えますか？
• このBEMSは本当に必要ですか？