Amazon Web Services ブログ

Tag: logging

AWSLogs コンテナログドライバーのノンブロッキングモードによるログ損失の防止

可観測性の向上とトラブルシューティングのために、コンテナログをコンピューティングプラットフォームから、ログ集約サーバーに転送することをお勧めします。実際には、ログサーバーが到達不能になったり、ログを受け入れられなくなる場合があります。ログサーバーの障害に対するアーキテクチャ設計には、トレードオフがあります。サービス所有者は、次の点を検討する必要があります。

アプリケーションは、トラフィックへの応答 (または作業の実行) を停止し、ログ集約サーバーが復旧するのを待つべきでしょうか? (正確な監査ログがサービスの可用性よりも優先されますか?)
アプリケーションは、ログサーバーがバッファを使い切る前に復旧することを期待してログをバッファリングしながらトラフィックに対応し続けるべきでしょうか? ログ送信先が利用できないレアケースにおいてログが失われるリスクを受け入れるべきでしょうか?

コンテナのログドライバーでは、このトレードオフは上記 1 の考慮事項に対して「ブロッキング」の設定パラメータ、2 の考慮事項に対して「ノンブロッキング」の設定パラメータで実装されています。AWS ブログの「Choosing container logging options to avoid backpressure」では、Rob Charlton がこのトレードオフを探求し、AWSLogs コンテナログドライバーのデフォルトの「ブロッキング」モードでアプリケーションがどのように動作するかをテストする方法を説明しています。

この記事では、「ノンブロッキング」 について詳しく説明し、AWSLogs ログドライバーを使用したログ損失の試験結果を示します。

Implementing AWS Session Manager logging guardrails in a multi-account environment

マルチアカウント環境での AWS Session Manager ロギングガードレールの実装

Session Manager では、IAM ロールを使用しながら、インバウンドポートを開かずに EC2 インスタンスにアクセスできます。このブログ記事では、脅威の検出、インシデント対応、フォレンジック、ログのアーカイブを目的として、すべてのセッションアクティビティが中央アカウントに記録されるように、Session Manager に追加のガードレールを適用する方法を説明します。

Amazon EKS でコントロールプレーンイベントを管理する

この記事では、Kubernetes イベントをフィルタリングしつつ、Amazon CloudWatch にエクスポートして永続化する方法について説明します。また、CloudWatch に保存されたイベントを調査するユースケースの例も取り上げます。読者はこの例を参考にし、要件に応じて変更することが可能です。