View a markdown version of this page

ステップ 4: 検証とトラブルシューティング - AWS Batch

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ステップ 4: 検証とトラブルシューティング

インスタンスのスケールアップをトリガーするジョブを送信したら、ログファイルが Amazon S3 バケットに表示されることを確認します。

ヒント

完全なロールアウトの前にログ収集をテストするには、 minvCpusをコンピューティング環境でゼロ以外の値に設定します。これにより AWS Batch 、ジョブの送信を待たずに少なくとも 1 つのインスタンスが強制的にスケールアップされます。不要なコストを避けるため、テスト後はゼロminvCpusに戻します。

AWS Console
  1. Amazon S3 コンソール (https://console.aws.amazon.com/s3/) を開きます。

  2. バケットを開き、 ecs-logs/ プレフィックスに移動します。

  3. インスタンス IDs を持つ という名前のフォルダが表示されることを確認します。各フォルダには、各ログソースのサブディレクトリが含まれます。

AWS CLI

次のコマンドを実行して、アップロードされたログオブジェクトを一覧表示します。

aws s3 ls s3://host-level-logs-bucket/ecs-logs/ --recursive

コマンドがインスタンス ID、日付、ソースタグ別に整理されたオブジェクトを返す場合、ログ収集は正常に機能しています。

ログが表示されない場合は、SSH または SSM セッションマネージャーを使用してインスタンスに接続し、Fluent Bitエージェントをデバッグします。でサービスステータスを確認しますsystemctl status fluent-bit。を確認して/var/log/cloud-init-output.log、user-dataスクリプトが正常に実行されたことを確認します。

スポットインスタンスと存続期間の短いインスタンスに関する考慮事項

スポットインスタンスまたは存続期間の短いコンピューティング環境を頻繁にゼロにスケールする場合は、ログデータの損失を避けるために以下の調整を検討してください。

  • スポット再利用リスク – ログデータをより頻繁にフラッシュfluent-bit.confするには、 の upload_timeoutおよび total_file_size値を低くします。これにより、インスタンスが再利用された場合に失われる可能性のあるデータのウィンドウが短縮されます。

  • 存続期間の短いインスタンス – がジョブ間でゼロに AWS Batch スケールする場合は、Flush間隔を短くして、インスタンスが終了する前に収集されたデータをアップロードupload_timeoutします。

  • Amazon S3 ライフサイクルルール – 古いログオブジェクトを期限切れにするか、低コストのストレージクラスに移行するように Amazon S3 ライフサイクルルールを設定することをお勧めします。これにより、無制限のストレージの増加を防ぐことができます。