こう
- 「ログ、
メトリクス、 トレースを、 どう 使い分けて 原因を 探しますか」 - 「エラーが
増えたと 知らせが 来ました。 どの 順で 何を 見ますか」 - 「ログを
全部出しておけば、 メトリクスや トレースは 要らないのでは」(裏から聞く形)
面接官が
- 3 つの
言葉の 意味ではなく、 症状から 原因へ 進む順番として 使い分けられるか - 3 つを
同じ 要求の 番号で つないで、 行き来できる 作りに しているか - 量を
増やすほど 費用が かかる ことを 知り、 何を 残すかを選べるか
短い答え
- まずメトリクスで、
いつから、 どの API や台で、 何が おかしいかを 見つけます。 数の 時系列なので、 全体の 変化に 早く 気づけます。 - 次に
トレースで、 遅い 要求や 失敗した 要求が、 どの サービスや DB の 呼び出しで 時間を 使い、 どこで 失敗したかを 絞ります。 - 最後に
ログで、 その 場所で その とき 何が 起きたか (入力、 エラーの 中身) を 読みます。 3 つは 同じ 要求の 番号 (トレース ID) で つないで おきます。
この
少し
症状から
3 つは、
- メトリクス 1 分ごとの
エラーの 数、 遅さ、 要求の 数のような、 数の 時系列です。 安く 長く 残せて、 全体の 変化と、 いつから 起きたかが 分かります。 ただし 「なぜ」は 分かりません - トレース 1 つの
要求が、 どの サービス、 どの DB の 問い 合わせを 通り、 それぞれ 何ミリ秒かかったかの 道筋です。 どこで 時間を 使い、 どこで 失敗したかが 分かります - ログ
その とき 何が 起きたかの 記録です。 入力の 値や エラーの 中身のような、 細かい 事情が 分かります
だから、
要求の
3 つを
ログは、
JSON
{"level":"error","traceId":"7f3a","route":"/orders","ms":2140,"msg":"payment timeout"}量と
3 つとも、
- メトリクスラベルに
利用者の ID のような 種類の 多い 値を 入れると、 時系列の 数が 爆発します。 ラベルは API の 名前や 状態の コードのような、 種類の 少ない 値にします - トレース全部の
要求を 残すと 高く つくので、 一部だけ残します (サンプリング)。 エラーや 遅い 要求は 優先して 残す形に すると、 調べたい 物が残ります - ログ成功した
要求の 細かい 記録は 減らし、 エラーと 判断の 分かれ目を 残します。 パスワードや 個人の 情報は 書きません
話すときは、
よく
- いきなりログを
検索し始める 量が 多すぎて、 どこを 見れば よいか 分から なくなります。 メトリクスで 範囲を 狭めてから読みます - ログに
要求の 番号が無い サービスを またいだ 1 つの 要求の ログを つな げられず、 原因が 追えません - メトリクスの
ラベルに 利用者の ID を入れる 時系列の 数が 爆発し、 費用も 重さも 跳ね 上がります - 全部の
要求の トレースを残す費用がかさみます。 一部を 残し、 エラーと 遅い物は 優先して残します
深掘りの問い
- 「どの
警報で 人を 呼びますか」 利用者に 出ている 症状で 呼ぶ、 と 1 文で 答え、 原因を 探す話に戻ります - 「トレースの
番号は、 サービスを またいで どう 渡しますか」 呼び出しの ヘッダーに 載せて 渡し、 受けた側は 同じ 番号を 使い続ける、と答えます - 「ログは
どれくらいの 期間残しますか」 調べるのに 要る 期間と、 費用、 個人の 情報の 扱いで 決め、 古い物は 安い 置き場へ 移すか消す、と答えます