🔔 あなたへのおすすめ記事「For you（β）」をリリースしました
Zenn
NCDCエンジニアブログ
🪵

実務で使えるログ設計入門以前

ratmie
2025/03/27に公開
logging
CloudWatch
tech

Loggingについて考える

目的

ログについての考え方を整理して、実務で使える最低限の知識を得る

前提

筆者はAWSなどクラウドでのWebアプリケーションの人間であるため、例示などはそれに準じて書く。

ログって

Wikipediaの記事によると

履歴、情報を記録に残すこと。また、その記録自体を指す。特に無線局での交信記録や電子掲示板でのログなどに用いられる。元々は航海日誌の意味であり、語源は「丸太」を船の船首から海に流して、船尾まで流れる時間を砂時計や初期の機械式時計で計測し、船の速さを測ったことからその記録をログと呼ぶようになった。

ログとログでないもの

監視において、データは大きく２つに分けられる

  • ログ: 連続した文字列により、いつどんなイベントが発生したかを記録する
  • メトリクス: 次の２つに分けられる
    • ゲージ： 特定時点の値を記録する。CPU使用率など
    • カウンタ： 増加していく値を記録する。webサイトの来訪累計人数など。

Observabilityの文脈[1]ではシステムから発信されるテレメトリを3つの形としている

telemetry 説明
trace 分散システムなどでリクエストがどのように渡り歩いて処理されたかを可視化するための情報
metrics 先述
logs 先述

ログを取る目的

「何のログを取るのか」の前に「なんのために取るのか」を考えておく

主な目的 説明
障害対応 システムに問題が発生した時に、「何があったか」を知るためにある。
セキュリティ監査 不正アクセスがあったときの調査や、ISMS監査で証跡ログを提出するなど
ユーザー行動分析 どの機能がどれだけ使われているかなどの利用状況把握
パフォーマンス改善 どの処理が時間を要しているか探る

ログの種類

種類 説明
アプリケーションログ 特定のソフトウェアアプリケーション内での動作や処理に関する記録
システムログ OSやサーバーの稼働状況、起動・シャットダウン情報などを記録
セキュリティログ アクセス試行、認証成功/失敗、権限変更などのセキュリティ関連イベント
ネットワークログ ネットワークトラフィック、接続、ルーティング情報
トランザクションログ データベースの変更履歴、トランザクション処理状況
イベントログ システム全体のイベント記録（Windows Event Logなど）
監査ログ コンプライアンスやポリシー遵守の検証用の記録
アクセスログ Webサーバーなどへのアクセス記録（訪問者のIP、時間、リクエスト内容など）
パフォーマンスログ システムリソース使用状況、応答時間などのパフォーマンス指標
デバッグログ 開発・テスト中の詳細な動作情報
変更ログ システム設定や環境の変更履歴

何をロギングするか

アプリケーションログについて

大喜びしてロギング文をあちこちにばらまくより、ちょっと落ち着いてアプリケー
ションの振る舞いについて考えてみましょう。何かがおかしくなった時に、最初にす
る質問は何でしょうか。トラブルシューティングあるいは単なる仕組みの説明時に、
あったらとても便利な情報とは何でしょうか。その質問から始めましょう。つまり、
あなたが完全に理解していないシステムのログ（あるいは監視）を設定するのは無理
だということです。アプリケーションを考えるのに時間を使えば、必要なログ（およ
びメトリクスやアラート）は自ずと明らかになります。

  • 入門監視より

どうロギングするか

ログ設計

ログフォーマット

大きく構造化ログ・非構造化ログの2形式がある。
構造化ログ（json）が使いやすいことが多い。
cloudwatchなども構造化ログに対応している。
ロガーの設定でどちらか選択できるものが多い。

構造化ログの例

{
  "timestamp": "2025-01-01T12:34:56Z",
  "level": "INFO",
  "message": "User login",
  "user_id": 1234
}
  • pros: マシンリーダブル
  • pros: 情報が密なので検索・フィルタがかけやすい
  • cons: データ量が増える

非構造化ログの例

<6>Feb 28 12:00:00 192.168.0.1 fluentd[11111]: [error] Syslog test

メリデメはだいたい構造化ログの逆

ログレベル

ログの重要性(Severity)を判別するために、ログレベルを用いることが多い。
ログレベルの段階の定義は複数あり、プロトコルやロガーによって用いているものが異なる。

tool levels
Log4j, Lambdaのapplication log TRACE, DEBUG, INFO, WARN, ERROR, FATAL
SLF4J/Logback TRACE, DEBUG, INFO, WARN, ERROR
Python logging DEBUG, INFO, WARNING, ERROR, CRITICAL
Syslog (RFC5424), winston Emergency, Alert, Critical, Error, Warning, Notice, Informational, Debug

どの定義を選ぶかについては、次のような観点がある。

  • ライブラリやフレームワークのルールに則る
  • チームで一貫したルールがあれば従う
    • マイクロサービスで各サービスが違うロガーでもレベル定義は揃えるべき、など
    • 複数のサービスを横断してログを検索したり、ログレベルごとに一括管理したりするときに混乱を避ける
  • アプリケーション特性
    • シンプルなアプリでは定義は少なくても困りにくい
    • 高い可用性を求められるシステムでは、アラート制御が細かくなるためレベルも細分化される
    • ex. Errorではメール通知、CriticalはオンコールへSMS通知をする、など

Lambdaでのログドキュメント

ログの運用

  • ログローテーション：１つのログファイルに追記し続けると肥大するので、一定の容量や期間で別ファイルに切り替える
  • 保存期間：要件を満たすためにどれだけ保存するのか、コストとの兼ね合いで検討する。データのサンプリング（間引く）処理が必要かどうか
    • 監査ログはセキュリティポリシーなどから決まることが多い
    • 障害調査のためのログは、正常時と異常時の比較ができることが前提
      • ex.月次処理があるのに１ヶ月しか保管しなければ前回と比較ができない
  • アクセス制御
    • ログの種類によって権限が変わることがある
      • ex. 本番環境のアクセスログは運用チームが見られるようにする
      • ex. 監査ログは監査用ユーザーが閲覧できる
  • 検索・可視化
    • Elasticsearch + Kibana
    • Grafana Loki
    • Datadog
    • Splunk
    • AWS CloudWatch Insights など
  • ログの提出
  • ログを利用した調査

cloudwatchでの設計

ロググループの設計

Q. ひとつのサーバー（ex. ECS）上から複数種類のログを出力するとき、ロググループを分けるのか？まとめたうえでfilterするべきか？

保持期間・アクセス制御・セキュリティ要件などが異なる場合は必然的に別のロググループにわける

  • /ecs/production/application-log
  • /ecs/production/access-log
  • /ecs/production/security-log

そうでない場合は、分ける方法もあるが、ログ内に{"logType": "access"}など判別するフィールドを持たせて、view側で処理することもできる

個人情報・機密情報の扱い

Q. 個人情報や機密情報をログに記録していいのか?

原則として個人情報にあたるものはできるだけログに書かない
デバッグや、監査のためにどうしても必要なものは状況に応じて以下の対応を取る

  • 最低限の情報を残し、残りは削除かマスクする

    • ex. フォームでのエラーの場合、ユーザーidとエラーがおきた入力項目、エラー内容だけあれば、入力データがすべてなくてもよい
    • ex. クレジットカード番号の下4桁以外をマスクするなど

  • デバッグレベルのログとして開発環境のみで表示する

    • 「フォームの入力内容をそのまま確認したい」 などのケース
    • 開発環境であれば実際の個人情報を扱うことはない
    • 実データを扱うテストがあると危険
      • 試験前にstaging環境でのログ設定を確認し、残る場合はアクセス制限する・マスクするなどの対応を取る

  • セキュアなデータは通常のログと別のデータソースに保管する

これちゃんとしてないとどうなるの？
  • 漏洩のリスク
  • 個人情報保護法・GDPRで個人情報を削除するときに、ログもその対象となる
    • 対象ユーザーの情報を調べて削除する必要が出てくる、しかも証跡としての有 効性を担保するのは大変
    • 例外規定の対象になる可能性もあるが...
    • はじめから記録しないほうがいい

参考文献

IPAのガイド

脚注

  1. https://opentelemetry.io/docs/concepts/observability-primer/ ↩︎

NCDCエンジニアブログ
NCDCエンジニアブログ

NCDC株式会社( ncdc.co.jp/ )のエンジニアチームです。 募集中のエンジニアのポジションや、採用している技術スタックの紹介などはこちら( github.com/ncdcdev/recruitment )をご覧ください！ ※エンジニア以外も記事を投稿することがあります

Discussion