ぜんぶ timestamp value にする
Rustで作った障害調査用の小さなツール群を、過去の障害を題材に試している。
前回は incident-timeline を使って、いくつかの時系列データを同じ時間軸に並べてみた。数字だけ眺めていたときより、かなり分かりやすかった。「ある時間帯にエラーが増えたとき、ほかの指標はどう動いていたか」といったことが、形として見える。 こういうグラフを見るだけなら、AWSのダッシュボードでもできる。 では、わざわざ手元で見るツールを作った意味はなんだろう。
AWSのダッシュボードは、CloudWatchにあるメトリクスを見るのには当然よくできている。一方で、障害調査では、それ以外の数字も一緒に見たくなることがある。 たとえば、ログから数えた502の発生数。CloudWatch Logs Insightsで1秒ごとに数えた結果も、時系列データとして見れば、
2026-01-01T10:00:00+09:00 2
2026-01-01T10:00:01+09:00 5
2026-01-01T10:00:02+09:00 3という、ただの timestamp value になる。CPUも同じ形にできる。レイテンシもタスク数も同じ。 さらに、既存のデータから自分で計算した値も同じ形にできる。incident-align で2つの系列を時刻で揃えて、awk で計算する。その結果も timestamp value にすれば、CloudWatchから取ってきたメトリクスと同じように扱える。 ログなのか、メトリクスなのか、自分で計算した値なのかは、そのあとのツールにとってはあまり重要ではない。 ぜんぶ timestamp value の形で扱えばいい。
振り返ると、これは途中で incident-timeline の入力を種類ごとに分けず、全部 --series にした判断ともつながっていた。取得元をツールが知る必要はない。必要なデータを手元に持ってきて、同じ形にしてから、切ったり、並べたり、計算したりする。
window | burst
align | awk | series障害調査では、「この時間だけ見たい」「この2つを揃えたい」「ここから別の値を計算したい」ということを何度も繰り返す。そういう作業には、小さな処理をパイプでつないでいく形が合いそうだと思っている。 もうひとつ、手元に持ってくることでできることがある。 調査に使った入力ファイルと、incident-timeline が出力したHTMLを残しておけば、「そのとき何を見て判断したか」も残せる。これは生のログやメトリクスをずっと保存しておきたい、という話ではない。必要になったら元の場所からまた取ってくればいい。 でも、ひとつの障害を調べたときに使ったデータと、そのとき見ていたグラフは、ひとまとまりの成果物として残せる。incident-timeline のHTMLをJavaScriptや外部のライブラリに依存しない形にしたのも、結果的にはここにつながっていた。
こうして見ると、このツール群はAWSのダッシュボードを置き換えるものではなさそうだ。普段の観測は、AWSのダッシュボードでいい。 調査が必要になったときに、必要なデータを手元に持ってくる。出どころの違うデータを同じ形にして、切ったり、並べたり、重ねたりする。そして必要なら、そのとき見ていたものを残す。
最初からこういう設計を考えていたわけではない。入力を --series に揃えたり、HTMLをself-containedにしたり、表示する時刻だけoffsetを変えられるようにしたり、そのとき必要だったことをひとつずつ決めていった。 あとから並べてみると、それらが同じ方向を向いていた。 実際の障害調査で必要になったとき、どこまで使えるか試してみたい。