一般的な問題のトラブルシューティング
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
問題が発生した場合は、以下のセクションをご覧ください。
Fleet Engine の Lost 状態
Fleet Engine を使用する場合は、障害を想定して実装を設計します。たとえば、Fleet Engine に車両の更新リクエストを発行すると、車両が存在しないことを示すエラーが返されることがあります。実装では、新しい状態の車両を再作成する必要があります。
Fleet Engine で壊滅的な障害が発生する可能性は非常に低いですが、その場合は、ほとんどまたはすべての車両とタスクを再作成する必要があります。作成率が高すぎると、サービス拒否（DOS）攻撃を防ぐために割り当てチェックが行われるため、割り当ての問題により一部のリクエストが再び失敗する可能性があります。この場合は、再試行のバックオフ戦略を使用して再作成率を下げます。
再試行数
Fleet Engine へのリクエストは失敗することがあるため、システムでリクエストの再試行を実装してください。Fleet Engine クライアント ライブラリは、デフォルトで再試行を発行します。
ドライバー アプリで状態が失われる
ドライバー アプリがクラッシュした場合、アプリは Driver SDK 内で現在の状態を再作成する必要があります。アプリは、タスクが存在することを確認し、現在の状態を復元するために、タスクの再作成を試みる必要があります。また、アプリは Driver SDK の経由地のリストを再作成して明示的に設定する必要があります。
注: これらの復元は、エンティティがデータベースにすでに存在するかどうかを示すエラーを除き、Fleet Engine からの情報に依存することなく自律的に行う必要があります。エンティティがすでに存在する場合は、そのエラーを吸収して、ID を使用してエンティティを更新できます。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-08-31 UTC。
[null,null,["最終更新日 2025-08-31 UTC。"],[[["\u003cp\u003eFleet Engine implementations should be designed to handle failures and potential data loss by recreating vehicles and tasks when necessary.\u003c/p\u003e\n"],["\u003cp\u003eIn case of Fleet Engine failures, use a backoff strategy to manage the recreation rate and avoid quota issues.\u003c/p\u003e\n"],["\u003cp\u003eImplement retries for Fleet Engine requests to address occasional failures, leveraging client library defaults or custom mechanisms.\u003c/p\u003e\n"],["\u003cp\u003eDriver apps should autonomously restore state after crashes by recreating tasks and stops within the Driver SDK, relying on error handling for existing entities.\u003c/p\u003e\n"]]],["Implement error handling for Fleet Engine failures, such as vehicle non-existence, by recreating entities. In catastrophic failures, recreate vehicles and tasks, using a backoff strategy if quota issues arise. Implement request retries, as provided by Fleet Engine client libraries. If the driver app crashes, autonomously recreate tasks and stop lists within the Driver SDK, relying only on Fleet Engine errors to determine if entities already exist for update purposes.\n"],null,["# Troubleshoot common issues\n\nCheck the following sections for help if you experience any issues.\n\nLost state in Fleet Engine\n--------------------------\n\nWhen working with Fleet Engine, design your implementation to anticipate\nfailures. For example, if you issue a request to Fleet Engine to update a\nvehicle, it might respond with an error indicating that the vehicle does not\nexist. Your implementation should then recreate the vehicle in the new state.\n\nIn the extremely unlikely scenario of a catastrophic failure of Fleet Engine,\nyou may need to recreate most or all vehicles and tasks. If the creation rate\nbecomes too high, some requests may fail again due to quota issues since quota\nchecks are in place to avoid denial of service (DOS) attacks. In this case, slow\ndown the recreation rate using a backoff strategy for reattempts.\n\n### Retries\n\nBe sure your system implements retries for requests to Fleet Engine since they\nmight fail occasionally. Fleet Engine client libraries issue retries by default.\n\nLost state in the driver app\n----------------------------\n\nIf the driver app crashes, the app must recreate the current state within the\nDriver SDK. The app should attempt to recreate tasks to ensure that they exist\nand to restore their current states. The app should also recreate and explicitly\nset the list of stops for the Driver SDK.\n\n**Note**: These restorations must be done autonomously without relying on\ninformation from Fleet Engine, other than errors indicating if and when an\nentity already exists in the database. If an entity does already exist, then\nthat error can be absorbed and the entity can be updated using its ID."]]
