mtr の結果を残すには、対話画面ではなく --report などの出力モードで実行し、標準出力をファイルに書き出します。この記事では、テキスト・JSON・CSV それぞれの保存方法、日時入りのファイル名の付け方、cron で定期的に記録する方法、保存したログを共有するときの注意点までを順に説明します。「回線が不安定なときの証拠を残したい」「プロバイダーやホスティング会社に調査を依頼したい」という場面を想定しています。
なぜ対話画面のままでは残せないのか
mtr example.com と実行すると、画面が一定間隔で書き換わる対話モードになります。この画面は端末の描画であり、終了すると何も残りません。スクリーンショットで代用することもできますが、時刻や測定回数が分からず、あとから比較もしにくくなります。
そこで、決まった回数だけ測定して結果をまとめて出力する「レポートモード」を使います。レポートモードは測定が終わってから一度だけ結果を出力するため、リダイレクトでそのままファイルに保存できます。
テキストレポートとして保存する
最も基本的な形は次のとおりです。
mtr --report --report-wide --report-cycles 100 example.com > mtr_example.txt短いオプションで書くと mtr -r -w -c 100 example.com です。それぞれの意味は次のとおりです。
--report（-r）: レポートモードで実行し、終了時に結果を出力します。--report-wide（-w）: ホスト名を省略せずに表示します。長いホスト名が途中で切れると、どの事業者のルーターかが分からなくなるため、保存用には付けておくと便利です。--report-cycles 100（-c 100）: 各ホップに 100 回ずつ問い合わせます。既定の回数は少なめ（多くの環境で 10 回）なので、ロス率を見たいなら回数を増やします。
既定の送信間隔は1秒なので、100 回なら測定には 100 秒ほどかかります。その間、画面には何も出ないため、止まったように見えても待ちます。
名前解決を止める・IP とホスト名を両方残す
-n を付けると逆引きをせず IP アドレスだけを表示します。逆引きに時間がかかる環境で測定が遅れるのを防げます。一方、報告用には -b（--show-ips）でホスト名と IP の両方を残しておくと、相手側が経路を特定しやすくなります。AS 番号も残したい場合は -z（--aslookup）が使えます。
mtr -r -w -b -z -c 100 example.com > mtr_example.txt測定日時をファイルに含める
レポートの見出しに開始時刻が入るバージョンもありますが、表記はバージョンによって異なります。バージョンに左右されずに日時を残すには、ファイル名と中身の両方に入れておくのが分かりやすい方法です。
{
date '+%Y-%m-%d %H:%M:%S %z'
mtr -r -w -b -c 100 example.com
} > "mtr_example_$(date +%Y%m%d_%H%M).txt" 2>&12>&1 を付けておくと、名前解決の失敗などのエラーメッセージも同じファイルに残ります。
JSON・CSV で保存して集計しやすくする
継続的に記録してグラフにしたり、表計算ソフトで比べたりするなら、機械が読みやすい形式が向いています。
mtr --json -c 100 example.com > mtr_example.json
mtr --csv -c 100 example.com > mtr_example.csv--json（-j）と --csv（-C）はレポートモードと同じく、測定が終わってから結果をまとめて出力します。ほかに --xml（-x）や、測定の生データを1行ずつ出す --raw（-l）もあります。どの形式が使えるかはバージョンとビルドによって異なるため、mtr --help で確認してください主要ディストリビューションで配布されている mtr 0.9 系では、JSON と CSV が使えます（2026年10月現在）。
JSON は jq で必要な項目だけ取り出せます。
jq -r '.report.hubs[] | [.count, .host, ."Loss%", .Avg, .Wrst] | @tsv' mtr_example.jsonキー名（hubs、Loss% など）はバージョンによって違う可能性があるため、最初に jq . mtr_example.json で全体の構造を確認してから抽出式を書いてください。
cron で定期的に記録する
「夜だけ遅くなる」「ときどき途切れる」といった症状は、発生しているときの記録がないと説明が難しくなります。数分おきに自動で記録しておくと、症状が出た時間帯の結果を後から取り出せます。
記録用スクリプトを用意する
crontab に長いコマンドを直接書くと、% の扱い（cron では改行として解釈されるため \% にする必要がある）でつまずきやすいため、スクリプトにまとめます。
#!/bin/sh
# /usr/local/bin/mtr-log.sh
TARGET="example.com"
LOGDIR="/var/log/mtr"
STAMP=$(date +%Y%m%d_%H%M)
mkdir -p "$LOGDIR"
{
date '+%Y-%m-%d %H:%M:%S %z'
/usr/bin/mtr -r -w -b -c 60 "$TARGET"
} > "$LOGDIR/mtr_${TARGET}_${STAMP}.txt" 2>&1sudo chmod 755 /usr/local/bin/mtr-log.sh
sudo /usr/local/bin/mtr-log.sh # まず手動で1回動かして中身を確認するcron は環境変数 PATH が最小限のため、mtr はフルパスで書いておきます。場所は command -v mtr で確認できます。
crontab に登録する
*/10 * * * * flock -n /tmp/mtr-log.lock /usr/local/bin/mtr-log.sh10 分ごとに実行する例です。flock -n を付けると、前回の測定がまだ終わっていないときに次の測定が重なって起動するのを防げます。測定回数 60 回なら1回あたり約1分で終わるため、間隔に十分な余裕があります。間隔を短くしすぎると、相手先への問い合わせが増え、帯域やログ容量も消費する点に注意してください。
古いログを整理する
放置するとファイルが増え続けます。保存期間を決めて、古いものから削除します。
# 30日より古い mtr ログを一覧で確認してから、問題なければ削除する
find /var/log/mtr -name 'mtr_*.txt' -mtime +30 -print
find /var/log/mtr -name 'mtr_*.txt' -mtime +30 -deleteこの行も cron に1日1回登録しておけば、手作業は要りません。1つのファイルに追記していく方式にする場合は、logrotate で圧縮とローテーションを任せる方法もあります。
保存したログを共有するときの注意
- 自分側の情報が含まれる: 最初の数ホップには、自宅や社内のルーターのアドレス、契約回線の情報が出ます。社外に送る前に、伏せてよい箇所を確認します。
- 片方向だけでは足りないことがある: 経路は往きと帰りで異なる場合があります。可能であれば相手側（サーバー側）からこちらへの mtr も記録してもらうと、原因の切り分けが進みます。
- 測定条件を添える: 測定日時、回数、ICMP か TCP か（
-T -P 443などを使ったか）、どこから測ったかを一緒に伝えると、受け取った側が同じ条件で再現できます。 - 途中ホップだけのロスは誤解されやすい: 中継ルーターが ICMP への応答を絞っているだけでも、途中の行にロスが出ます。最終ホップまでロスが続いているかどうかを確認したうえで共有します。
まとめ
- 対話画面は残らないため、
--report（-r）・--json・--csvで実行して標準出力をファイルに保存します。 - 保存用には
-w（ホスト名を省略しない）と-c（測定回数）を指定し、-bで IP とホスト名を両方残すと報告に使いやすくなります。 - 日時はファイル名と中身の両方に入れ、エラーも
2>&1で残します。 - 定期記録はスクリプト化して cron に登録し、
flockで重複起動を防ぎ、保存期間を決めて古いログを削除します。 - 共有時は自分側のアドレスなどの扱いに注意し、測定条件を添えます。