運用を支えるためのログを出すにはどうするか? #jjug_ccc #ccc_m3

1554a30ab4d3737351b4e44ad557754e?s=47 Masaya Saito
November 23, 2019

運用を支えるためのログを出すにはどうするか? #jjug_ccc #ccc_m3

JJUG CCC 2019 Fallで話した時のスライドです。

1554a30ab4d3737351b4e44ad557754e?s=128

Masaya Saito

November 23, 2019
Tweet

Transcript

  1. 7.

    運用では色々なことが起きる • 色々なことが起きる ◦ バグ ◦ 問い合わせ ◦ パフォーマンス劣化 •

    障害は必ず起きる ◦ 100%の可用性はありえない • でも出来る限りサービスを提供したい ◦ 障害の調査時間・復旧時間を短くして機会損失を減らす 7
  2. 16.

    関数の最初でログを出力しない • やりがち • どうしてもほしいならDEBUGレベルで • 関数の最後に、どういう結果になったかをログに吐く方がいい ◦ 最初に吐くより情報量が多い ◦

    関数の最初: 「ユーザを作成しようとしています。」 ◦ 関数の最後:「◦◦というユーザIDのユーザを作成しました」 • AOPで出力するログはオススメしない ◦ ログ量が多くなってノイズになりがち ◦ 業務的な情報がないログが出がち ◦ 個人情報がログに出てしまったりも・・・ 16
  3. 22.

    ログは多すぎてはいけない • Ex. ◦ 繰り返し回数の多いループ内でのログ ◦ そもそも単純に吐いてるログが多い • ログが多いと読むのに時間がかかる •

    ディスクを食いつぶしたり・・・ ◦ 別の障害に繋がる可能性も・・・? • ログを保持するコストに跳ね返る 22
  4. 30.

    ログレベルを使い分ける • 適切にログレベルを選ぶ • 基本出力するログレベルはINFOレベル以上にする ◦ DEBUG以下はフレームワークのログとかも出てしまう • INFOで出力する例 ◦

    ビジネスロジックで発生したイベントの結果 ◦ 外部通信の結果 ◦ バッチ処理の周期的なサマリ ▪ 「何件処理しました。そのうち何件は失敗しました」 ◦ など 30
  5. 31.

    ログレベルを使い分ける • ERROR ◦ 運用の継続が困難な問題が発生した時 ◦ 人の介入が必要な場合は出力する ▪ Ex. データベースの名前解決に失敗

    • WARN ◦ 一時的な問題が発生した時や予期せぬ状態 ▪ Ex. リトライ可能な問題, 一時的なキャパシティ不足 • INFO ◦ 基本的なログのレベル • DEBUG ◦ デバッグの為に使われるログ 31
  6. 40.

    ログにコンテキストを付与する • どうやってコンテキストを付与するか ◦ MDC(Mapped Diagnostic Context) ▪ 診断コンテキスト from

    logback ◦ logstash-logback-encoder(今回は話しません) • 付与する内容例 ◦ ユーザID ◦ リクエストされたパス ◦ リクエストID(後述) 40