SpeedData

Tracerouteを始めるには

Tracerouteを始めるには

見えない障害を可視化せよ

2025年4月6日
著者: Leon Adato
翻訳: 逆井 晶子

この記事は米Catchpoint Systems社のブログ記事「Getting Started with Traceroute」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。

Traceroute？
コマンドラインで入力するやつのこと？
そんなもののテストをわざわざ設定する必要なんてあるの？

信じられないかもしれませんが、これはCatchpointでよく耳にするコメントです。
特に、技術やモニタリング、あるいはCatchpoint自体に不慣れな方々（もしくはそのすべて）の間ではよくある誤解です。

ただし、このブログではTracerouteの有用性について長々と説明するつもりはありません。
Tracerouteが非常に役立つツールであることに異論はありませんが、その点について知りたい方はHow to Read a Tracerouteという記事をおすすめします。
この技術の歴史や、Tracerouteが現代でどのように活用されているかについて詳しく解説されています。

このガイドの目的は一つです。
最初の、あるいは次のTracerouteテストを構築するための手順を素早く理解していただくことです。
ここでは、作業を完了するための最低限のステップに焦点を当てつつ、任意で設定できる（でも興味深い）項目についても少し触れていきます。

それでは始めましょう。

CatchpointでTracerouteテストを設定するにはどうすればよいですか？

始める前に、以下の2つを準備してください。

お知らせ
オフィスのプリンタは有効なターゲットではありません。
もしそれがインターネットに接続されているなら、やめてください。
なぜそんなことをしたくなるのでしょうか……？
いや、やめておきましょう。本当に。

えー、気を取り直して。
ProductやFolderの場所について詳しく知りたい場合は、こちらをご覧ください。
Catchpointポータルにアクセスし、左側のナビゲーションからControl Centerをクリックします。

Control Centerの図

ProductまたはFolderを選択します（ここで選択しなくても、次のステップの後に選択を求められます）。
「Traceroute」の下に、5つのオプションが表示されます。

Tests設定画面

以下の通りです。

どれを選べば良いかわからない場合は、各リンクをクリックして違いを確認してください。

ちなみに、Traceroute InSessionはCatchpoint独自のソリューションで、従来のTracerouteが抱える複数の問題を解決しています。
Catchpointが特許を取得している方法であり、詳細は別記事をご参照ください。

注：心配無用です。
テストタイプは後から変更可能なので、今の段階で決定する必要はありません。

もしまだProductやFolderを選択していなければ、ここで選ぶことになります。

Tests location画面

それが終わると、TracerouteテストのProperty画面が表示されます。

Traceroute Test Property画面

Tracerouteテストに必要な項目は何ですか？

テストに必要な要素は以下の通りです。

Test name
これはテストの名前です。
特に説明は不要ですね。
Monitor
どの種類のTracerouteテストを実行するかを指定します。
先ほど選択しましたが、ここで変更することもできます。
Test Location
Tracerouteの宛先を指定します。
IPアドレス（例：1.2.3.4 - ですが、そのIPを使うのはやめましょう）やドメイン名（例：catchpoint.com）が使用できます。
Run From
テストの開始日と終了日を設定します。
終了日時の指定は必須です。
ちなみに、野菜もちゃんと食べてください。
……まあ、ルールなので仕方ないんです。
Nodes (Agents)
テストをどこから実行するかを指定します。
Catchpointには、世界中に配置された3,000以上のエージェントがあります。
注：PropertyまたはGroupの設定によって、自動的に適用される場合もあります。

これらが、このテストに必要な唯一の項目です。
ただし、他にも入力しておくと便利な項目がいくつかあります。
画面左側に注目してください。

Traceroute Test Property画面

CatchpointでTracerouteテストのコストはどうやって計算されますか？

たぶん、あなたが会社の請求処理をしているわけではないと思いますが、コストに関心のある人は社内にいるはずです。
Catchpointが高額というわけではありません。
むしろ逆です。
ただし、購買担当者は予想外の出費を嫌うものです。
たとえ費用が50ドルから100ドルに倍増する程度のことでも、事前に把握しておけば、購買担当からの問い合わせメールを避けることができます。

詳細は省きますが、Catchpointはポイント制の料金モデルを採用しています。
各テストは、以下のような要素に応じて一定のポイントを消費します。

例えば

ヒント：Catchpointには、アカウント全体のポイント消費を可視化するダッシュボードが用意されています。
とはいえ、テストごとの相対的なコストを事前に意識しておくことは、コスト管理の観点でも非常に重要です。

テスト設定の「Inherit / Inherit & Add / Override」とは何ですか？

inherit表示の図

いくつかのセクションは、「Inherit」を他のオプションに変更しない限り、表示されません。
これは文字通り、「Property」レベルなどで設定されたデフォルトの設定を継承しているためです。

各オプションの意味は以下の通りです。

Inherit
他の場所（多くはPropertyレベル）で設定された内容をそのまま使用します。
Override
既存の設定を無視して、このテスト専用の別設定を適用できます。
Inherit & Add
このオプションは常に表示されるわけではありません。
表示されないからといって、慌てて視力検査を受ける必要はありません。
これは、一部の設定だけを上書きできるオプションです。

追加のオプション項目

簡単でしょう？
では、本題に戻りましょう！
必須とされていますが、通常は触れる必要のない項目がいくつかあります。

Description
深く考える必要はありません。
自分が分かればOKです。
Status
テストをアクティブにするかどうかを切り替えられます。
Index
複数のテストをグループ化し、個々のテストをテストグループの平均値と比較して表示することができます（つまり「インデックス」です）。
Labels
ダッシュボードやレポート、アラートなど他のCatchpoint機能で活用できる自由形式のラベルです。
if/thenトリガーを設定したり、画面上の要素をグループ化したりできます。
Test Data Webhook
APIを使って、他のツールやグラフシステムにテスト結果を連携するためのWebhookを指定します。
Thresholds
テストが「Warning」状態とみなされる条件を設定します。
しきい値は、応答時間（ms）や可用性（%）、またはその両方に対して設定できます。

パフォーマンスのしきい値はどう設定しますか？

Thresholdは、テストが「Warning」または「Critical」状態とみなされるタイミングを定義します。
以下の点に注意してください。

これらのしきい値は、ダッシュボード上の視覚的なインジケータや、アラートのトリガーとして使用されます。

テストの実行タイミングと場所はどう制御しますか？

複数の場所からテストを実行する場合、Catchpointではテストの実行方法に柔軟性があります。

Run On
複数のエージェントを設定している場合は、毎回すべてのエージェントで実行するか、ランダムに一部のエージェントで実行するかを選べます。
ポイント消費を抑えつつ、広い範囲をカバーするのに有効です。
Agent Distribution
「Run On」の設定に応じて、すべてのノードで同時に実行するか、タイミングをずらして分散実行するかを選べます。
Run Schedule
テストをどれくらいの頻度で実行するかを設定します。
Maintenance Schedule
テストの一時停止や無効化を行うスケジュールを設定できます。

基本的なテスト設定におけるアラートはどう動作しますか？

アラートは、しきい値を超えたときに通知を行います。
基本設定では、以下を定義できます。

Recipients
しきい値を超えたときに通知を受け取るメールアドレスをカンマ区切りで指定します。
Subject
通知メールの件名を設定します。
このフィールドでは、「マクロ」と呼ばれる変数を使用することができます。
使用可能なマクロの一覧については、Catchpointのドキュメントをご参照ください。

注：これは基本アラートのデフォルト設定に過ぎません。
Catchpointでは、アラートに関してはるかに多くのカスタマイズが可能ですが、それについてはこのブログの範囲を超えます。
詳細は今後の記事で詳しく解説します。

Tracerouteテストを作成した後はどうなりますか？

ここまでの手順に従っていれば、Tracerouteテストは正常に作成されているはずです。
あとは「保存」をクリックし、達成感に浸ってください。

さて…保存したあとには、何ができるのでしょう？

もちろん、テストはデータを収集しています。
では、そのデータはどこにあるのでしょう？
どうやって確認すればいいのでしょう？
そして―ただ眺めるだけでなく―そのデータをどのように活用すればよいのでしょうか？

SmartboardやExplorerでTracerouteテストの結果を表示・分析するにはどうすればよいですか？

あらゆるテストのデータを確認する最初の方法の一つが、Smartboardsです。
テスト画面の左上にSmartboardオプションが表示されています。

Smartboard画面

でも、それだけではありません。
画面上部の「Summary」「Network」「Routing」などのタブをクリックすることで、他の表示オプションを切り替えることができます。

Performance

Smartboardのデフォルトビューです。
以下の情報が表示されます。

% Downtime
ターゲットの宛先が利用できなかった頻度を示します。
Network Metrics (ms)
ラウンドトリップ時間（基本的にはping）とジッターの量をミリ秒単位で表示します。
Network Metrics (%)
転送されたパケット全体に対するパケット損失の割合を示します。
Experience Score
個別のテストまたはテストグループ全体のデジタル体験を、0〜100のスケールで評価する複合指標です。
Event summary
エラー、アラートの発生などの主要なイベントを表示します。

Scatterplot

これは「Performance」ビューと似ていますが、折れ線がない点が異なります。
Tracerouteではあまり派手なグラフにはなりませんが、他の種類のデータでは非常に有用な可視化になります。

Scatterplot表示

表示される項目は

グラフエリアの下部には、少し目立たないものの、見逃せない重要なセクションがあります。
他のグラフでも表示される領域ですが、ここで特に取り上げておきたいと思います。

Summary Table図

中央にある二重線を上にドラッグすることで、このエリアを展開できます。
表示しているグラフの種類に応じて、Summary Table, Errors, Purgeなどのタブが表示されます。

Summary Tableとは何か、そしてそれがなぜ有用なのか？

Summary Table
以下のような列と行形式でのデータ表示を提供します。
  • グラフに表示されているテスト（実行回数）の数
  • その他の指標（テスト時間、可用性など）の全体平均
Errors
その名の通り、このテストに関連して発生したエラーの詳細が表示されます。
Purge Summary
削除対象として選択されたデータの一覧が表示されます（この機能については別途解説があります）。

Summary Tableビューは、テストの動作、エラー、データの削除履歴に関するコンパクトかつ実用的なスナップショットを提供します。
データの検証や、迅速なトラブルシューティングに役立ちます。

ExplorerのStatisticalビューとRecordsビューでは何が確認できますか？

Statistical View
このビューでは、1つのグラフの代わりに3つのグラフが表示されます。
  • テスト時間の95パーセンタイル（ms）
  • テスト時間の中央値（ms）
  • テスト時間の幾何平均（Geometric Mean, GM）（ms）
Statistical View
Statistical View
このビューにも、Scatterplotと同様にSummary Tableエリアがあります。
Records View

新しいグラフエリアではなく、直近の数回のテスト結果（成功・失敗、成功時のテスト時間）をサブパネルとして表示します。
このビューは、テスト作成直後や、テストに問題が発生した際のトラブルシューティングに最適です。

Records List
Records List

StatisticalビューとRecordsビューは、テストの安定性やパフォーマンスの傾向を把握するために役立ちます。
トレンドの特定、問題の原因特定、テストの正常性確認などにご活用ください。

ダッシュボード構築については多くの情報がありますが、それはこのブログの範囲を超えています。
今後の記事で詳しくご紹介する予定ですので、ぜひご注目ください。

Tracerouteテストをダッシュボードやアラートに追加できますか？

壊れたレコードのように繰り返すつもりはありませんが……（この表現、もはや古いですね）。
「最安プランのSpotifyのように？」いや、それもしっくりこない……
よければ、「壊れたレコード」の代わりになる良い表現をコメントで教えてください。

さて、本題に戻ります。
Tracerouteテストをダッシュボードに追加したり、アラートに組み込んだりすることは可能です。
ただし、その具体的な方法はこのブログの範囲外です。

新しく作成したTracerouteテストは、見た目にも美しい新しいダッシュボードにも、実用的な既存のダッシュボードにもピッタリ合います。
ですが、その統合方法については、別の機会に詳しく解説する予定です。

同様に、情報性が高く、実用的で、アクションにつながるアラートを作るための詳細な方法も、今回は取り上げません。
このブログはすでに長くなってしまいましたからね。

Tracerouteにおけるテストロケーションの多様性が重要な理由とは？

Tracerouteを自分で実行する場合の明らかな欠点のひとつは、自分の使っているシステムからしかテストできないことです。
これは、包括的な可視性とはとても言えません。

Traceroute（あるいはあらゆるモニタリングテスト）を本当に効果的にするには、複数の場所から実行する必要があります。
たとえば、ClevelandからはWebサイトがダウンしているように見えても、BengaluruやIstanbulからは問題なく見えている - そんな状況では、それは「完全にダウン」しているとは言えません。
それは「down-ish（ダウンっぽい）」という状態です。（この表現、今作りましたが、気に入っていただければうれしいです。）

マルチロケーションテストの一般的なアプローチ

多くのモニタリングツールでは、「複数の場所からのテスト」を次のように実現しています。

1. ユーザ自身に、各拠点のシステムにエージェントをインストールさせる方法
これでは、エンドユーザ（社内のデータセンタ外にいることが多い）がアクセスできるかどうかの判断ができません。
2. クラウドプロバイダ（3社…いや5社…いやそれ以上）にエージェントを設置して、そこから監視する方法
しかし、ユーザがそのクラウド内にいるわけでなければ、それも一部しか見えていない状態です。

Catchpointの違いとは何か？

Catchpointには、ロケーションがなんと3,000もあるんです！
このカバレッジを持つモニタリングソリューションは、他に存在しません。
さらに重要なのは、それらのロケーションが「実在する」という点です。

単なるクラウドやコロケーションの拠点にとどまらず、世界中の主要なISPに複数のエンドポイントが組み込まれています。
また、「ラストマイル」ロケーションも数百カ所あり、可能な限りご自宅に近い場所からの観測が可能です（下着の引き出しに端末を入れるレベルではありませんが、それに近いくらいです）。
この違いは非常に重要であり、Tracerouteに限らず、Catchpointのすべてのテストに共通しています。
そのため、この点だけで1セクションを割く価値があると考えました。

Tracerouteテストを設定する価値はあるのか？

あります！

このブログから一つだけ持ち帰ってほしいことがあるとすれば、それはTracerouteテストの設定は「簡単」でありながら「効果的」だという点です。
「簡単」というのは、テストを立ち上げるまでのステップがそれほど多くないという意味です。
そして「効果的」というのは、Tracerouteが - 古い、いや「尊敬されている」ツールではありますが、今でもアプリケーション、ネットワーク、インフラストラクチャのパフォーマンスを理解するうえで非常に重要で意味のある存在だからです。

さらに詳しく知るには

テストが実行されるようになった今、Tracerouteの読み方に関する包括的なガイドをご覧ください。
実践的なヒント、現実の例、よくある落とし穴などを解説しています。