翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ステップ 4: 検証とトラブルシューティング
インスタンスのスケールアップをトリガーするジョブを送信したら、ログファイルが Amazon S3 バケットに表示されることを確認します。
ヒント
完全なロールアウトの前にログ収集をテストするには、 minvCpusをコンピューティング環境でゼロ以外の値に設定します。これにより AWS Batch 、ジョブの送信を待たずに少なくとも 1 つのインスタンスが強制的にスケールアップされます。不要なコストを避けるため、テスト後はゼロminvCpusに戻します。
ログが表示されない場合は、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 ライフサイクルルールを設定することをお勧めします。これにより、無制限のストレージの増加を防ぐことができます。