ja-JP
ja-JP

メトリクスの概要


この記事の内容

メトリクスの概要

エージェントからターゲットへのプロービングは、エンドツーエンドのネットワーク接続性を測定するものです。エージェントがパケットをターゲットに送信し、その応答を測定します。ホップはパケットを最終目的地まで転送します。これにより閲覧者はトレンドの変化を素早く把握し、ネットワークの影響を受けた部分を見つけることができます。

パケットを送ると、各ホップはそのパス上の他のホップにパケットを転送します。各ホップが次のホップにパケットを転送するのにかかる累積時間は、エージェントとターゲット間のレイテンシを決定します。

次の記事では、エージェントが提供するメトリクスの種類について説明します。


レイテンシ、ジッター、ロスのメトリクス

レイテンシ

  • ミリ秒で測定されるレイテンシは、ICMP、HTTP、UDP合成パケットトラフィックがネットワークを経由してエージェントからターゲットまでかかる往復時間です。
  • HTTPの場合、プロービングTCP接続のOSによってTCPのレイテンシとジッターが報告されます。
  • 150ミリ秒以上のレイテンシは、リアルタイム通信(音声およびビデオ通話)の品質低下、アプリケーションの応答遅延、そしてほとんどのエンドユーザーにとって顕著なネットワークの劣化をもたらします。
  • 低遅延の応答時間に依存するアプリケーションは、高遅延の期間中に使用不能になる可能性があります。
  • エージェントとターゲットの距離はレイテンシに直接影響します。

ジッター

  • ジッターとは、連続した2つのパケットの往復遅延の差の絶対値です。
  • ジッターはすべてのトラフィックに影響します。特に音声またはビデオ通話中のエンドユーザーに最も顕著に現れます。

ロス

  • ロスとは、選択したアラインメント期間で失われたICMPまたはUDPパケットの割合です。
  • エージェントはICMPとUDPにおけるパケットロスの違いを判別します。
パケットロスの判別方法{"cell"=>[nil, "タイムアウト", "順序の異なるパケット"]} {"cell"=>["ICMP", "
  • プロービング間隔が1〜5秒の場合、パケットロス判定のタイムアウトはプロービング間隔と同じです (1〜5秒)。
  • プロービング間隔が5秒より長い場合、パケットロス判定のタイムアウトは5秒です。
", "
  • 順序の異なるパケットは、常にパケットロスと見なされます。
"]} {"cell"=>["UDP", "
  • 5秒以内にレスポンスがなかった場合、パケットロスと見なされます。
", "
  • N/A - パケットの順序はパケットロスとして考慮対象外です
"]}

HTTPとスピードテストのターゲットはパケットロスを報告しません。これによりダッシュボード上でのメトリックの表示が少し異なります:

  • HTTPターゲットのみが選択されている場合、パケットロスプロットの代わりにHTTPメトリックのプロットが表示されます。
  • HTTPおよびICMPまたはUDPターゲットを選択した場合、パケットロスとHTTPメトリックのプロットの両方が表示されます。
  • プロット時間の整列と線の色の一貫性を保つため、すべてのターゲットラベルは各プロットの左側に表示されます。
  • パケットロスプロットのHTTPターゲットラベルにプロット線が表示されません。
  • HTTPプロットのICMPターゲットラベルにプロット線が表示されません。


HTTPメトリクス

HTTP可用性は、Hypertext Transfer Protocol(HTTP)を介してウェブリソースに一貫性と信頼性のあるアクセスを提供します。ウェブサイトやウェブサービスの文脈では、可用性はシームレスなユーザーエクスペリエンスを提供する上で非常に重要な要素です。HTTPを監視することで、クライアントとサーバー間またはサーバーとサーバー間の通信におけるパフォーマンスのボトルネックを特定できます。

Service Experience Insightsは、エージェントからホストサーバーまでのネットワーク品質をモニタリングしますが、アプリケーションのモニタリングはできません。

HTTPリクエスト応答時間

  • プロット内の任意のポイントにカーソルを当てると、エージェントとターゲット間の各ステップのHTTP合成トラフィックの応答コードとリクエスト応答時間が表示されます。
  • メトリックはミリ秒単位で表示されます。
  • メトリックの説明
    • DNSルックアップ: DNSルックアップの実行にかかった時間です。DNSルックアップは、ドメイン名をIPアドレスに変換するためのものです。新しいドメインができるたびに、DNSルックアップを行うため完全な往復が必要です。宛先が既にIPアドレスの場合、DNSルックアップは必要ありません。
    • TCP接続: 送信元と送信先ホスト間のTCP接続を確立するためにかかった時間です。接続は、複数のステップにわたるハンドシェイクプロセスで適切に確立される必要があります。TCP接続は、OSによって管理されます。基礎となるTCP接続が確立できない場合、OS全体のTCP接続タイムアウトがアプリケーションのタイムアウト設定よりも優先されます。
    • TLSハンドシェイク: TLSハンドシェイクを完了するのにかかった時間です。ハンドシェイクプロセスにおいて、エンドポイントは安全なセッションを確立または再開するために認証と鍵を交換します。非HTTPSリクエストでは、TLSハンドシェイクはありません
    • Time to First Byte (TTFB): 初回レスポンスの待ち時間。この時間は、サーバーがリクエスト処理とレスポンス配信の待ち時間に加え、サーバーへ往復の遅延も含まれます。
    • コンテンツ転送: 応答データの受信にかかった時間です。応答データのサイズとネットワーク帯域幅によって、その時間幅が決定されます。

HTTP可用性

  • HTTPのプロービングは、パケットロスのメトリックを表示せず、代わりにターゲットに到達したパケットの割合を表示します。
    • 100%のHTTP可用性は、すべてのHTTP合成トラフィックがターゲットに到達したことを意味します。
    • <100%のHTTP可用性は、HTTPトラフィックの劣化レベルを示します。


接続性

  • エージェントは、1分ごとにコントローラに接続メトリックを送る限り、オンラインと見なされます。
  • メトリックをコントローラに送信できないエージェントは、接続性の問題として表示されます。接続している間にエージェントは到達可能なトラフィックに対してプロービングトラフィックを送信し続けます。データはエージェントのメモリに1時間保存され、エージェントがコントローラに再接続したときに時系列データベースに追加されます。
  • エージェントが1時間以上コントローラに到達できない場合、プロービングは続行され、1時間より古いバッファリングされたメトリックは破棄されます。

スタティックおよびクラウドエージェントが切断されたときに赤色で表示されます。

モバイルエージェントが切断されたときにグレー色で表示されます。モバイルエージェントは、ホストPCが使用されていないときにオフラインであることが想定されるため、グレーが使用されます。


パス検出

パス検出は、プローピング割り当てのオプション設定です。

パス検出を有効にすると、エージェントは合成されたパス検出トラフィックを送信し、エージェントとターゲット間の利用可能なパスまたはホップすべてを探索します。

プロットラインをクリックして、各ホップのIP、ASN、ISP、およびレイテンシを表示できます。

パス検出の方法

  • 各パケットのIPヘッダには、無限ループパケットを防ぐためのTTL(Time to Live)というフィールドが含まれています。
  • ルータは、IPパケットのTTL値を1減らしてから次のホップに転送します。
  • TTL値が0になると、パケットは破棄され、ルータはパケットの送信元IPにICMP TTL Exceededメッセージを返します。
  • この方法を使って、送信元ホストから宛先ホストまでのルータを検出するために、ターゲットホストに到達するまでTTLを増やしたパケットを送信し、受信したICMP TTL Exceededメッセージの送信元IPアドレスを保存します。
  • ICMPエラーメッセージにはペイロードの実際のパケットが含まれているため、送り手はTTL Exceededメッセージとエラー発生した実際のパケットを照合することができます。

トレースルートの概念

ICMPトレースルート

ICMPエコー要求メッセージは、TTLを増やしながらターゲットホストに送信されます。

  • レスポンスは通常、ICMPヘッダーのフィールドIDとシーケンス番号に基づいてリクエストに照合されます。
  • ターゲットホップに到達するか(ICMPエコー返信メッセージを受信)、設定した最大TTL(通常32~64)に到達すると実行が停止します。
  • ルーターは、ICMPのルーティングにSrc、Dst IP、プロトコルのみ取得するため、ICMPを使った等価コストマルチパス(ECMP)の検出はできません。
  • ECMPは、送信元と宛先の間でトラフィックを等コストの複数経路に分散させるルーティング技術です。
  • 従来のルーティングでは、トラフィックはエンドポイント2つの間で最良な単一パスを経由して送信されます。しかし、ECMPでは、ネットワークは複数の等コストパスを同時に使用してトラフィックを分散させます。これにより、ネットワークの容量と強靭性が向上し、輻輳を回避することができます。
  • ECMPは、データセンターネットワーク、エンタープライズネットワーク、サービスプロバイダーネットワークを含む多くの種類のネットワークトポロジで使用できます。 OSPF、IS-IS、およびBGPなど多くのルーティングプロトコルでサポートされています。

UDPトレースルート

  • UDPトレースルートは、UDPパケットをターゲットホストにポート番号33434(IANA指定のトレースルート)で送信することで実装されます。
  • Windowsプラットフォームでtracertコマンドを実行し、パストレースを取得します。
  • LinuxおよびMacでは、ECMPを検出するために、後続の試行ごとにソースポート番号を変更する実装になっています。デフォルトでは、EMCPを検出するために15回の試行が行われ、試行回数はAPIで設定できます。

TCPトレースルート

  • TCPトレースルートは、既存のアプリケーションが実行されているターゲットホストのポート番号にTCP SYNパケットを送信することで実装されます(例:80、443など)。
  • ターゲットノードはSYN ACKまたはRSTで応答します。
  • ECMPパスを検出するために、実装は後続の試行ごとに送信元ポートを変更できます。
  • 宛先がTCPアプリケーションの場合、TCPトレースルートは宛先に到達する可能性が高くなります。

TCPトレースルート(特権)

  • Rawソケットを使用してTCPパケットを手動で作成します。
  • TTLを増やした後続のパケットをTCP再送のように見せかけてファイアウォールを通過しようとします。
  • 1つのパストレースで、すべてのTCPパケットに対して同じシーケンス番号とウィンドウサイズを使用します。
  • Linuxエージェントでのみサポートします。

トレースルートができるファイアウォールの設定

  • ファイアウォールは通常トレースルートによるプローブトラフィックをブロックします。送信元及び送信先のファイアウォールを開くことで回避できます。
  • 送信先ファイアウォールを次のように設定します:
    • ICMPトレースルートに対するICMPエコーリクエストの受信
    • UDPトレースルートに対するUDPポート33434(および33435〜33655)
  • 送信元のファイアウォールを次のように設定します:
    • ICMP制御メッセージの受信(TTL超過、送信先ポートに到達できないなど)
  • SaaSアプリケーションのエンドポイントの数が増えると、これらのメッセージがブロックされ、パストレースが最後のホップを検出できなくなる場合があります。
  • 最後に検出されたホップから最後のホップまでの距離を推測することは不可能です。


デバイスとWiFiメトリクス

  • モバイルエージェントは、PCホストのデバイスとWiFiのメトリクスデータを返します。
  • WiFiメトリクスとデバイスデータは、PCホストシステムのデータから取得されます。
  • SSIDにアクセスすることで、位置情報を検出しやすくなります。


スピードテスト

  • スピードテストは、プロービング割り当てで設定可能であり、ダッシュボードのエージェントページからオンデマンドでスピードテストを提供するように設定されたエージェントから行うことができます。
  • スピードテストは、エージェントからスピードテストのプローブを受信するように設定されたマネージドターゲット(エージェント)です。これらのスピードテストターゲットは、通常サービスホストに最も近いクラウド環境に設置されます(例:重要なサービスがホスティングされているクライアントのAWSリージョンに設置)。
  • スピードテストのプローブ間隔は1時間から始まります。
  • テストパッケージのサイズは100 MBです。
  • スピードテストで消費される帯域幅については、「帯域幅の推定表」を参照してください。
  • オンデマンドのスピードテストデータについては時系列に追加され、しばらくしたらプロットに表示されます(オンデマンドのスピードテストが終了してから約2分後に表示されます)。
  • エージェントからスピードテストターゲットへのアクセスを確認してください。
    • スピードテストはHTTP CONNECTリクエストを利用してHTTP接続をWebSocketをアップグレードします。HTTPプロキシサーバによっては、非SSLポートへのHTTP CONNECTリクエストがデフォルトで拒否されている場合があります。
    • OSまたはSEIエージェントにHTTPプロキシを設定していて、かつスピードテストサーバのSSLが有効になっていない場合は、HTTPプロキシサーバに非SSLポートへのHTTP CONNECTリクエストが許可されていることを確認してください。

オンデマンドスピードテストの例

  • エージェントは、複数のスピードテストターゲットにスピードテストを送信するように設定できることをご留意ください。


データストレージと解像度

  • 各プロービングイベントの後に収集されたデータは、エージェントのローカルストレージに保存され、1分ごとにコントローラにアップロードされます。
  • Mモニタリングデータは、時系列データベースに保存されてからの時間に応じて、1分~6時間のアライメント期間で保存されます。データが保存されてからの時間が長くなるにつれて、検索可能なデータのアライメント期間も長くなります。
現在の時刻からのアライメント期間
時間幅 デフォルトのアライメント期間 最短のアライメント期間
< 4時間 自動 (1分) 1分
> 4〜12時間 自動 (3分) 1分
> 12〜20時間 自動 (15分) 1分
> 20時間〜2.5日 自動 (30分) 1分
> 2.5〜9日 自動 (1時間) 1分
> 9〜28日 自動 (3時間) 3分
> 28〜42日 自動 (6時間) 5分
> 42〜62日 自動 (6時間) 15分
> 62〜92日 自動 (6時間) 30分
> 92〜184日 自動 (6時間) 1時間
> 184〜366日 自動 (6時間) 3時間
> 366日 自動 (6時間) 6時間
  • エージェントメトリクスのデータは、アライメント期間を選択して表示することができます。
  • プロットは、選択した時間幅に合わせて最適なアライメント期間をデフォルトで設定します。
  • ページの読み込み速度は、選択したターゲットの数、時間幅の長さ、アライメント期間の長さによって変わります。
  • 時系列データを1分のアライメント期間で分析する際は、より短い時間幅を使用します。
  • 大きい数のターゲットを長期間にわたって分析する場合は、1時間単位のアライメント期間を使用します。
  • エージェントが1分以上オフラインになった場合、メトリクスプロットにその隙間(切れ目)が表示されます。プロット線がその時に再度繋がったと表示する場合は、より短いアライメント期間を選択します。
Service Experience Insights - Updated: 2023-06-07 22:38-UTC