ログとメトリクス、どちらを使うべきか

どちらのログも同じトレースに紐づいているので、サインアップのトレースには両方がまとめて表示されます。

ログ側から始めて、user.id でフィルタリングすることもできます。探していたメールのステータスがそこに表示され、トレースへのリンクも付いています。

トレースからもこれらすべてがわかったはずですが、トレースはサンプリングされるので、このユーザーのトレースはおそらく破棄されています。一方、ログは残っています。

 

サインアップが失敗するのはなぜか

今朝のリリース後、何人かのユーザーから、サインアップフォームから先に進めないという報告が寄せられました。

サインアップを試みるたびに、成功・失敗にかかわらず、同じ user.signup ログが1回書き込まれます。失敗した場合は outcome: "failed"、warn レベル、そして理由が付きます。この時点ではまだユーザーは存在しませんが、signup.method と plan はすでにスコープに設定されています。

ここは判断が分かれるところです。普段なら、失敗したサインアップをカウントするメトリクスを作成するところです。ただし、このログ行が必ず出力されるのであれば、代わりにログをカウントすることもできます。

reason でグループ化して時系列でグラフにすれば、リリース後の captcha_failed の急増も、Counterと同じくらいはっきりわかります。

では、失敗したサインアップもメトリクスにすべきでしょうか。それは件数そのものよりも、その上に何を構築するかによります。

 

メトリクスの役割

ここまでの2つの問いは、どちらも何かがうまくいかない、少なくとも様子がおかしいところから始まっています。

ログは保険です。コードの分岐点でログを書いておけば、後になって誰かに何が起きたのかと聞かれたとき、自分（またはエージェント）が状況を再現できます。ほとんどのログは読まれることがありませんが、それで構いません。分岐点で何を書くべきか、何を省くべきかについては、Ben Coeのいつ、何をログに残すべきか？が参考になります。

そのため、ログは変更しやすいものでもあります。新機能やエッジケースを観察するために一時的に追加し、次のリリースで削除するものも少なくありません。メッセージはコードレビューで書き換えられますし、コスト削減のためにレベルごと送信をやめることもあります。デバッグしている間は、どれも問題になりません。しかし、ダッシュボードがそのログをカウントしている場合は大問題です。本番環境では info ログを送る価値がないと誰かが判断すれば、それをもとに作ったグラフはすべて止まってしまいます。

メトリクスは、あらかじめ決めておく問いです。何も問題がないときでも、意図して答えを見に行きます。メトリクスに名前を付けることは、ひとつのコミットメントです。その上にダッシュボードやアラートが構築され、誰も気まぐれに名前を変えたりせず、ログのフィルタリングの影響も受けません。

ですから失敗したサインアップについては、失敗率がチームで注視している数値なのであれば、同じ user.signup Counterと outcome: "failed" を使ってカウントもしておきましょう。

 

メトリクスにすべき問い

サインアップ数は増えているか

これは先ほど後回しにした問いで、すべてのサインアップを通した傾向に関するものです。

まさにこれが user.signup Counterの役割です。ログと同じスコープ属性を引き継ぐので、追加作業なしで plan や signup.method 別に分析できます。signup.method でグループ化すれば、ユーザーがどの方法でサインアップしているか、そして落ち込みが全体に起きているのか特定の方法だけなのかがわかります。

3つのCounterを並べてグラフにすれば、ファネル全体を1ステップずつ確認できます。

各ステップを plan でグループ化すると、有料プランでサインアップしたユーザーはほぼ全員がメール確認を済ませている一方、無料プランのユーザーはそうではない、といったことがわかるかもしれません。これはバグではありません。エラーも遅延も起きておらず、単に戻ってこなかったユーザーについてログが書かれることもありません。これはプロダクトに関する問いであり、自分から問うと決めなければ見えてこないものです。

代わりにリリースでグループ化すれば、再びエンジニアリングの問いになります。サインアップフォームの変更が、確認ステップに悪影響を与えたのではないか、という問いです。

メトリクスでは、1人のユーザーがこれらのステップをたどる様子を追ったり、コホートを作ったり、リテンションを把握したりすることはできません。それはプロダクト分析ツールの役割です。しかし「このステップは悪化しているか？」という問いであれば、ファネルをリリース、エラー、トレースと並べて見られるので、手軽に確かめられます。

 

メールキューが詰まっていないか

ここまでのメトリクスはすべてCounterでした。何かが起きたら1を加算するものです。Sentryにはほかに2種類のメトリクスタイプがあり、それぞれ異なる形の問いに答えます。

Gaugeはキューの深さやオープンしている接続数など、現時点の値を記録します。イベントをカウントするのではなく水準をサンプリングしているので、サンプルを合計しても意味はありません。知りたいのは、どこまで高くなったか、平均してどのあたりにあったかです。タイマーで、あるいはメールワーカーがキューをチェックするたびに送出しましょう。

確認メールが保留され始めた場合、キューが増えていく様子を見れば、次の「確認メールが届きません」という問い合わせが来る前に気づけます。

email.verified Counterと同じ場所で、同じ属性を付けて送出しましょう。プランでグループ化すると、中央値では有料ユーザーは約3分、無料ユーザーは約23分で確認しています。p95では、無料ユーザーは2時間近くかかっています。時間の計測が1つのリクエストで始まり、別のリクエストで終わるので、トレースではこれを示すことはできません。