- コンテナの内部で集約する
- e.g. fluentd、rsyslog等を各コンテナ内に立てる
- e.g. 単純にファイルに保存する
- コンテナの外部で集約する
- e.g. ホスト側にfluentd、rsyslog等を起動して、各コンテナがマウントしたログファイルをtail等で読む
- e.g. ホスト側にマウントしてファイルに保存する
- Log driverを利用して集約する
- 集約用のコンテナを立てる
- e.g. --volume-from による指定をともなう方法: logstash-forwarder
- e.g. docker.sock等によるstdout/stderrのみを対象とした収集: logspout
- コンテナ内で複数プロセスを起動しない
- ホスト側に複雑な設定をしない
- メリット
- Dockerを使わない場合とほぼ同じなので、導入がやや簡単
- デメリット
- コンテナ破棄によるデータ損失の可能性
- rotateについて考える必要がある
- Dockerのベストプラクティスに沿わない
- メリット
- 各コンテナへのマウント設定とホスト側に集約ツールを導入するだけ
- 同一コンテナ上のログ（e.g. 課金ログ、アクセスログ）の切り分けがしやすい
- コンテナ破棄時もデータ損失の可能性が低い（永続化しやすい）
- デメリット
- ホスト側の対応が必要であり、Dockerのベストプラクティスに沿わない
- ログ出力をする新規・既存コンテナすべてで対応が必要になる
- rotateについて考える必要がある
- メリット
- 標準で用意されたドライバを導入するだけでfluentd等に対応できる
- コンテナ破棄等に強い
- 転送サービスのダウン等への対応がしやすい
- デメリット
- stdout/stderr以外のログは扱えない
- Log driver自体でログの切り分けができない
- （転送先によるが）rotateについて考えなくても良い
- メリット
- （場合によるが）ログ出力する新規・既存コンテナに手を加えなくて良い
- Dockerのベストプラクティスに沿いやすい
- デメリット
- 新しいツールの学習が必要になる
- （転送先によるが）rotateについて考えなくても良い
- ログ集約用のコンテナが落ちた場合にログが欠損する
- 他コンテナを読む機構を持っている場合にセキュリティリスクが上る可能性がある
- マウント等でコンテナ外にまとめる
- インスタンス外への転送を考えない場合のみ
- Log driverでサービスに転送
- 扱うコンテナ全てに対応が可能な場合のみ
- logspout + マウント or ボリューム化
- logspoutコンテナが落ちた場合でもデータ欠損を出来る限り防ぐ必要がある
- docker.sockをマウントするリスクをきちんと考慮する
- マウント等でコンテナ外にまとめる
- インスタンス外への転送を考えない場合のみ
- Log driver + fluentd自体の機能でタグによる切り分け
- ログ出力自体にタグ付けするなどの手を入れられる場合のみ
- logspout（転送先でタグ等で切り分け） + マウント or ボリューム化
- Log driverのパターンと同じ
- logspoutコンテナが落ちた場合でもデータ欠損を出来る限り防ぐ必要がある
- docker.sockをマウントするリスクをきちんと考慮する
- オートスケールでインスタンスごと作成・破棄されるパターン
- ボリューム・マウント等で永続化できなくなる
- 集約にリアルタイム性がもとめられているか
- バッファリングされる等で遅延がある方法を採用できない
- ツール選定時に気をつける
- 利用しているデプロイ方式（swarm mode や kubernetes 等）に対応できるか
- 集約用コンテナを利用するパターンでは特に注意が必要になる
- 欠損が許されないかどうか
- 欠損が許されない場合は、logspoutなどでは欠損しても大丈夫なバックアップとなるデータを残す必要が出る
- オートスケールするインスタンス上にあるコンテナ内やマウントしたログファイルも同じ