業務システムの運用で夜間アラートを受けた経験がある方に向けた内容です。サーバーが無応答になったとき、まずどう調査するかを整理します。
本番環境で突然APIが応答しなくなったとします。SSHセッションも固まり、手元では条件反射的にping example.comを叩きます。返ってくるのは「Request timed out」の一行だけです。
ここから先が厄介です。サーバー自体が落ちているのか、ICMP（ネットワーク疎通確認に使われる通信プロトコル）がファイアウォールで遮断されているのか、DNS（ドメイン名をIPアドレスに変換する仕組み）がおかしいのか、手元の回線が切れているのか。従来のpingはパケットが返ってこない事実しか教えてくれません。次に何を調べるべきかは、運用者の経験と勘に委ねられてきました。
この課題に対して、Rust（メモリ安全性を重視したシステムプログラミング言語）製のオープンソース診断ツールspingが、バージョン1.7.1で--diagnoseという新しい実験的モードを追加しました。障害の一次切り分けを自動化する試みとして、企業システムの運用現場でも参考になる設計です。
--diagnoseモードが何をするか
spingはもともと、レイテンシ（応答までの遅延時間）やジッター（遅延のばらつき）、パケットロス率を可視化する「モダンなping」として作られたツールです。単一のホストだけでなく複数ターゲットの同時監視や、TCPポートへの疎通確認（TCP probe）にも対応していました。
1.7.1で追加された--diagnoseは、監視中のターゲットが応答しなくなった瞬間に、追加の調査を自動で始める機能です。使い方はシンプルです。
sping example.com --diagnoseこのコマンドを実行すると、通常どおりリアルタイム監視が始まります。そしてターゲットが「オフライン」と判定された時点で、以下の追加チェックが自動で走ります。
- IPv4とIPv6の両方で同じホスト名に到達できるか比較する
- ICMPが失敗していてもTCPの443番・80番ポートに応答があるか確認する
- traceroute（経路上の各ルーターへの到達を確認するコマンド）でどこまでパケットが届いているか調べる
- ローカル側に宛先へ到達できる適切なソースアドレスがあるか確認する
- 直近のDNS名前解決が失敗していないか、対象アドレスファミリの応答が得られたかを確認する
重要なのは、「オフライン」と判定する基準が明確に定義されている点です。3回連続でプローブ（疎通確認パケット）が失敗するか、1回の実行で応答が一切得られなかった場合にのみ、追加調査が発動します。これにより、たまたま1回パケットが遅れただけで過剰な診断トラフィックが発生することを防いでいます。
なぜこの設計が業務システムの運用に効くか
タイムアウト即「サーバーダウン」と判断するのは危険です。たとえばICMPへの応答が止まっていても、TCPの443番ポートには応答があるケースは珍しくありません。これは、アプリケーションが完全に健全だとは言い切れないものの、少なくとも経路上の何かがまだ生きている証拠になります。
逆にIPv4では失敗するのにIPv6では通る、traceroute上ではいくつかのルーターまで到達してからパケットが消える、といったパターンも実際にあり得ます。通常であればping、traceroute、nslookupやTCP接続確認コマンドを個別に手打ちして突き合わせる作業です。--diagnoseは、これらを同じ監視セッションの中で証拠(evidence)として集約します。
ここで強調しておきたいのは、このツールが「根本原因を特定した」と主張しない設計になっている点です。あくまで「観測された事実」を報告するだけで、推測による断定は避けています。業務システムの障害対応では、誤った一次切り分け情報がエスカレーション先の判断を誤らせるリスクがあります。事実と推測を分けて報告する設計思想は、インシデント対応のポストモーテム(事後検証)でも評価されやすい考え方です。
もう1つの追加機能が、ネットワークコンテキストの変化検知です。Ethernet接続からWi-Fiへの切り替えや、VPN経由でデフォルトルートが変わった場合に、変化そのものを明示的に報告します。
context changed 00:03 ago: interface eth0 → wlan0ソースアドレスやネットワークプレフィックス、デフォルトゲートウェイの変化も追跡対象です。間欠的な障害の調査では「レイテンシが上がったか」より「レイテンシが上がる直前に何が変わったか」を知りたい場面が多く、この機能はその問いに直接応えます。
既存の監視・診断ツールとの位置づけ
企業のインフラ運用では、すでにZabbixやDatadog、PrometheusといったSRE(Site Reliability Engineering、信頼性担保のための運用手法)向けの監視基盤を導入しているケースが一般的です。spingはこれらの代替ではなく、現場のエンジニアが手元で一次切り分けをする際の補助ツールと位置づけるのが適切です。
監視基盤がアラートを発報した後、担当者が実際にSSHでログインしてpingやtraceroute、curlを手打ちで組み合わせる作業は、今も多くの現場で残っています。--diagnoseはこの手作業の一部を自動化し、障害発生直後の数分間で集められる情報量を増やす狙いがあります。追加の診断トラフィックには同時実行数やプローブ数の上限が設けられており、traceroute自体にもホップ数とタイムアウトの制限があります。障害調査のための通信が、かえって輻輳を悪化させない配慮がされています。
導入前に確認できること
実際に試す前に、以下の点を確認しておくと判断しやすくなります。
- 手元の環境でRustのツールチェーンやバイナリ配布が利用可能か(GitHubリリースページでOS別バイナリの有無を確認)
- 社内ネットワークでICMP・traceroute・任意ポートへのTCP接続が許可されているか(ゲートウェイやファイアウォールのポリシーを事前に確認)
- 本番環境に近いステージング環境で、
--diagnoseなしの通常モードから試し、挙動に慣れてから有効化する - 診断結果を障害報告テンプレートにどう組み込むか、既存のインシデント対応フローと照らし合わせる
自社の障害対応フローにまだ「一次切り分けの標準手順」が文書化されていない場合、sping --diagnoseが出力する項目(IPv4/IPv6比較、TCP到達性、traceroute、ローカルネットワーク情報、DNS結果)をそのままチェックリストの叩き台にするのも現実的な使い方です。
まとめ
sping 1.7.1の--diagnoseは、タイムアウト発生後に人間が手で行っていた一次切り分けの一部を自動化する機能です。IPv4/IPv6比較、TCP疎通、traceroute、DNS結果という複数の証拠を1つのセッションで集約し、根本原因の断定は避けて事実のみ報告する設計になっています。
既存の監視基盤を置き換えるものではなく、障害発生直後の数分間を補助する現場ツールとして試す価値があります。まずはステージング環境でsping <対象ホスト> --diagnoseを実行し、出力される項目が自社の障害報告フォーマットに合うか確認してみてください。