運用とログ

アラート起因で調べるベースの運用とログの話を書いておく。

状況確認

状況確認は大事。ひとまず初動で原因が分かると嬉しいので ざっくり状況確認。

  • ログを読む
    • エラーログを読む
    • なにも出てなかったらWARNを読む
  • メトリクスを見る
    • 5xxエラーを見る
      • どのサービスがダメになってる?

状況別調査

状況別に自分が見ているところをざっくりメモベースで書いておいた。

  • 変なレスポンスが返っている
    • ログを見る
    • リクエストに紐付いた一意なIDを元にログで処理を追いかける
      • 外部通信した時はこの一意なIDと一緒にログに出力しておきたい
  • レスポンスが遅い
    • レスポンスタイムを見る
      • 特定のリクエストだけ遅い場合があるので、基本的にAverageじゃなくてPercentileを使う
      • 依存先のサービスも見る
    • サービスのCPU使用率見る
    • 特定のインスタンスのCPU使用率を見る
    • RDBやバックエンドのCPU使用率を見る
    • IOが多い可能性?ネットワーク帯域とかディスクIOを見る
    • 見れるなら、S3などの通信で使っている通信時間の合計も見る
      • S3なら、S3側に設定を追加するだけで見えるようになるはず。(ちょっと時間は掛かるけど)
    • ログを読む
    • コードを読む
  • 動作がおかしい・動かない
    • 対象のサービスのログを読む
    • 担当していないサービスでもコードを読む
    • 「アプリケーションそもそも起動してる?再起動繰り返してない?」か調べる
  • 何も分からん
    • ログとメトリクスをひたすら読む
    • SSHしてDockerコンテナのホストOSに入ってでも見る
      • サルベージ出来た情報は出来るだけ後から参照できるようにする
    • ログを送る手前で死んでる可能性があるなら、ログを送るミドルウェアのログを見る
    • ググる
      • 英語でも読む
      • GitHubのIssueとかPull Requstも探す
    • どうしても分からないなら
      • 知ってそうな仲間を頼る

まとめ

  • ひたすら読む
    • ログやメトリクスで状況確認
    • コードを読んで実装確認
    • 分かる範囲で切り分けした後、知ってそうな人に聞く
      • 知ってそうな人を頭に入れておくため、チャットなどで情報収集は欠かさない
      • ここで分からなかったことは確認して振り返って忘れずに
    • 状況から見るべきメトリクスを狭めて、メトリクスやログで原因を絞っていく
    • 変なログがあって情報量がゼロならログを見直す
      • 適切な箇所で必要なログが出るようにコードを弄る