メトリクス

メトリクス

エージェントからターゲットへのプロービングにより、エンドツーエンドのネットワーク接続性を測定します。エージェントはパケットをターゲットに送信し、その応答を測定します。経路上のホップはパケットを宛先まで転送します。これによりユーザーはトレンドの変化を素早く把握し、ネットワークの影響のあった箇所を見つけることができます。

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

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

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

レイテンシー

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

ジッター

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

ロス

• ロスとは、選択したアラインメント期間で失われたICMPまたはUDPパケットの割合です。
• エージェントはICMPとUDPにおけるパケットロスの違いを判別します。

パケットロスの判別方法

	タイムアウト	順序の異なるパケット
ICMP	プロービング間隔が1秒から5秒の場合、パケットロス判定のタイムアウトはプロービング間隔と同じです (1秒から5秒)。 プロービング間隔が5秒より長い場合、パケットロス判定のタイムアウトは5秒です。	順序の異なるパケットは、常にパケットロスと見なされます。
UDP	5秒以内にレスポンスがなかった場合、パケットロスと見なされます。	対象外 - パケットの順序はパケットロスとみなしません。

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

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

HTTPメトリクス

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

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

HTTPリクエスト応答時間

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

HTTP可用性

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

接続性

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

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

モバイルエージェントはホストPCが使用されていない場合にオフラインとなり、この期間はグレーで表示されます。

パスディスカバリー

パスディスカバリーが有効なプロービング割り当てにエージェントが追加されると、エージェントはパスディスカバリーを行うようになります。

エージェントはトレースルートを実行し、エージェントからターゲット間のホップ可視化します。パスディスカバリーのグラフでは、各ホップのIPおよびレイテンシー、実行時に取得できたキャリアやASNの情報が表示されます。

設定したインターバルごと、ターゲットへのレイテンシーが変化した場合、または異なるIPアドレスを検知した場合に、トレースルートは自動的に実行されます。オンデマンドのトラブルシュート機能として手動のトレースルートの実行も可能です。エージェントがどのようにパスディスカバリーを行うかについては、エージェント概要

パスディスカバリーが設定されたエージェントのビューにおいて、グラフ中のターゲットのプロットラインをクリックすると、設定されている期間において実行されたトレースルートの結果が可視化されたグラフが開きます。

パスディスカバリーの方法

• 各パケットの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アプリケーションのエンドポイントの数が増えると、これらのメッセージがブロックされ、パストレースが最後のホップを検出できなくなる場合があります。
• 最後に検出されたホップから最後のホップまでの距離を推測することは不可能です。

スピードテスト

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

スピードテストで使用する帯域の消費量についてはデータ使用量の推測値をご覧ください。

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

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

デバイスメトリクス

• ホストOS上で動くエージェントは、デバイスのメトリクスをレポートします。
  • SPEKTRAエッジおよびEdgeLQ OS用スタティックエージェント
  • Windowsおよび macOS用モバイルエージェント
• Dockerコンテナーおよび VMで実行されているエージェントは、CPUやメモリの情報をキャプチャできません。インターフェースのメトリクスは当該のインターフェースが利用されている場合に有効になります。
  • Docker 用スタティックエージェント
  • クラウドエージェント
• 利用可能なメトリクス
  • CPUとメモリ使用量
  • 送信インターフェースロス (TX)
  • 受信インターフェースロス (RX)
  • 送信インターフェースエラー (TX)
  • 受信インターフェースエラー(RX)

インターフェースのロスとエラー

メトリック	説明
送信インターフェースロス	送信を妨げるようなエラーが検出されなかったにもかかわらず、破棄された送信パケットの数。理由のひとつとして、バッファスペースの解放が考えられます。
受信インターフェースロス	エラーが検出されなかったにもかかわらず、上位層プロトコルへの配信を妨げるために破棄された受信パケットの数。理由のひとつとしては、バッファスペースの解放が考えられます。
送信インターフェースエラー	エラーのために破棄された送信パケットの数。この原因となるシナリオとしては、デュプレックスの不一致、CRCの不一致などが考えられます。
受信インターフェースエラー	エラーのために破棄された受信パケットの数。これを引き起こす考えられるシナリオとして、デュプレックスの不一致が考えられます。

WiFi信号強度

• WiFi信号強度は、WiFiアクセスポイントを介してコントローラに接続されているエージェントに対してのみレポートされます。
• WiFiのSSIDは、位置情報の検出を向上させるために取得されます。

データストレージと保存期間

データの収集と集計

• エージェントはプロービングイベントに伴いデータを収集します。ターゲットへICMPパケットを送信するのはプロービングイベントの一例です。
• プロービングイベントはメトリクスの種類ごとにデータポイントを作ります。
  • エージェントからサーバへのICMPプロービングでは、2つのデータポイントが作成されます。ひとつはロスに関するもの、もうひとつはレイテンシーとジッターを決定するために使用されるRound Trip Time(RTT)です。
  • HTTPリクエスト応答時間のプロービングでは、DNSルックアップタイム、SSLネゴシエーション、レスポンスコードなど多数のデータポイントが作成されます。
• プロービング間隔でプロービングイベントの頻度を設定します。短いプロービング間隔ではより多くのデータポイントが作成されます。

• これらのデータポイントは一旦エージェントのローカルメモリに保存されます。
• 60秒ごとにデータポイントはコントローラにアップロードされ、5つの メトリクス値 として集計されます:
  • 平均：この1分間で観測したデータポイントの平均値
  • 最大：この1分間で観測したデータポイント最大の値
  • 中央値：この1分間で観測したデータポイントの中央値
  • 95パーセンタイル：この1分間で観測したデータポイントの上位95%と下位5%を分ける値
  • 99パーセンタイル：この1分間で観測したデータポイントの上位99%と下位1%を分ける値

• 60秒間のプロービングデータが5つのメトリクス値に集計されるため、高頻度でプロービングを行ってもメトリクス値の数は増えません。
• ただし、プロービングを高頻度で行うとより、集計に利用されるプロービングデータが増えるため、より高い精度の集計が期待できます。例えば：
  • プロービング間隔が30秒の場合、1分間に各メトリクス値を2つ取得し、単純に大きい方が最大として扱われます。
  • プロービング間隔が1秒の場合、1分間に各メトリクス値を60個取得し、この中から最大を集計するため、瞬間的な急上昇を検知する可能性が高くなります。

メトリクスの種類ごとにプロービング間隔の設定が可能です

メトリクスの種類	最小（最高頻度）	最大（最低頻度）
ICMP	1 秒	10 分
UDP	100 ミリ秒	10 分
HTTP	30 秒	10 分
スピードテスト	右記の中から時間帯で設定	1, 6, 12, または 24 時間

時系列データベース内のメトリクス値

• メトリクス値は、集計単位の期間に合わせて時系列データベースに保存されます。
• データが取得されてから14日間のメトリクス値は、1分間の集計単位で保存されます。これは、この期間、ダッシュボードもしくはAPIから1分ごとのメトリクス値が閲覧・ダウンロード可能であることを意味します。
• この期間が過ぎると、1分単位のメトリクス値はより長い集計単位に集約されていきます。
• データが取得されてからの時間が経過するほど、集計期間は長くなっていきます。
• この集計単位の実装は、時系列データベースの動作の向上、APIによるデータ取得の高速化、ダッシュボードでのロバストなネットワークの可視化を提供し、拡張性・入手性の高いネットワークモニタリングやSaaSソリューションのトラブルシューティングに役立てることができます。

時系列データベース内のメトリクス値の集計単位

データの経過時間	集計単位
1分から14日	1分
15日から28日	3分
29日から42日	5分
43日から184日	1時間
185日から366日	3時間
367日から732日	6時間
733日から1463日	12時間
≥ 1464日	1日

データ保存期間

• エージェントのローカルに保存されるデータ
  • ローカルに保存されたデータはコントローラにアップロードされると削除されます。
  • ローカルのデータ保持期間の最大は1時間です。
  • エージェントがコントローラに1時間以上接続できない場合は、1時間を超えた古いデータから順に、新たに取得したデータで上書きされていきます。結果として、最新の1時間のデータのみがローカルに保存されます。
  • エージェントがコントローラに再接続されると、直近1時間のプロービングデータは時系列データベースにアップロードされた後ローカルのメモリから削除されます。
• 時系列データベースに保存されたデータ
  • 時系列データベースに保存されたデータの保持期間は、サービスプロバイダーのサービス規約によって定義されています。
  • 最も一般的なサービス規約では、保持期間は90日となっています。保持期間を過ぎると、メトリクス値は時系列データベースから削除されエクスポートすることができなくなります。
  • 前述の集計単位は固定値で定義されており、設定での変更はできません。