集計の前提を確かめる

ログを取得して集計するとき、計算自体は正しくても、その前提になるデータや集計方法によって、結果の解釈が変わってしまうことがある。 最近の分析で気になったことが2つあったので、それぞれ小さなツールとして切り出してみた。

取得したデータを確認する

障害調査などでCloudWatch Logs Insightsからログを取得するとき、結果が10,000件の上限に達していないかを、その都度確認していた。 指定した時間範囲のログを取得しても、その範囲のデータがすべて取れているとは限らない。件数の上限に達していれば、クエリのソート順によっては、時間範囲の一部に偏っている可能性もある。 そこで、Rustで作っている tskit に window-audit を追加した。

jq -r .time alb.jsonl |
  incident-window-audit \
    --from 2026-09-03T10:20:00+09:00 \
    --to 2026-09-03T10:30:00+09:00 \
    --limit 10000

指定した時間範囲と、実際に観測された最初と最後の時刻を比較し、両端の差や取得件数を表示する。 例えば、入力件数が指定した上限に達していれば LIMIT_REACHED を出す。 ただし、上限に達したからといって、実際にデータが打ち切られたとは限らない。逆に、観測範囲が指定した時間範囲の両端に届いていても、途中のデータがすべて取得できている保証はない。 あくまで取得したデータから確認できることを表示して、原因の判断はクエリの条件やソート順と合わせて考える。

集計単位を確認する

もう一つは、イベントログをセッション単位で集計していたときのこと。 セッションという単位は、もともとのイベントログに存在しているわけではない。一定時間イベントがなければ別のセッションとして扱う、というルールをこちらで決めている。 例えば、30分空いたら別のセッションとするのか、90分空いたら別のセッションとするのか。それによってセッション数も変わるし、セッションを分母にした指標も変わってくる。

そこで、セッション化の処理を sessionize というCLIツールとして切り出した。

sessionize --key user_id --time timestamp --gap 30m < events.tsv

キーとタイムスタンプを持つイベントに対して、指定したアイドルギャップに基づいてセッションIDを付ける。 入力はTSVで、出力もTSV。元の行順を維持したまま session_id 列を追加する。やっていることはそれだけ。 例えば、アイドルギャップを30分から90分に変えて、それぞれの結果を集計すれば、セッションの区切り方によって数字がどのくらい変わるのかを確認できる。 もちろん、どちらの区切り方が正しいかを、このツールが判断するわけではない。指定したルールに従ってセッションIDを付けるだけで、集計や比較は後段の処理に任せている。

今回作った2つのツールは、どちらも集計結果の正しさを保証するものではない。 取得したデータがどの時間範囲を表しているのか。イベントをどんなルールで区切っているのか。 集計された数字を見る前に、そうした前提を確認するためのもの。

やっていることは単純だけれど、実際の分析で使いながら、少しずつ検証していきたい。

← Back to posts