Object Storage Service:モニタリング、診断、トラブルシューティング

全体的なステータスの監視

• ユーザー別の可用性 /有効リクエスト比率 (%)

  ユーザーによる可用性 /有効なリクエストの割合は、OSSの安定性とOSSが正しく使用されているかどうかを示すために使用される最も重要な指標です。 100% 未満の割合は、一部のリクエストが失敗したことを示します。

  

  100% 未満の割合は、負荷分散のためのパーティション移行などのOSS最適化によって発生する可能性があります。 この場合、OSS SDKは、この一時的な最適化によるエラーリクエストを処理するための関連する再試行メカニズムを提供します。 このように、あなたのビジネスは影響を受けません。

  エラーリクエストの種類と原因を特定し、エラーのトラブルシューティングを行うには、OSSのCloud Monitorコンソールでリクエストステータスの詳細とリクエストステータスの分布に基づいてリクエストを分析します。

  さらに、いくつかのビジネスシナリオでは、有効な要求比率が100% 未満であることが予想される。 たとえば、一部のシナリオでは、オブジェクトを管理する前に、オブジェクトが存在するかどうかを確認する要求を送信する必要があります。 オブジェクトが存在しない場合、リクエストに対して404エラーが返されます。これにより、有効なリクエストの割合が100% 未満になります。 この場合、エラーは予想どおりに返され、実際の問題を示すものではありません。

  OSSの高可用性が必要なビジネスでは、メトリックが予想されるしきい値を下回ったときにトリガーされるアラートルールを設定できます。

• ユーザーによるリクエストの合計数 /有効数

  ユーザーごとの合計 /有効なリクエスト数メトリックは、リクエスト時間の側面でOSSの実行ステータスを示します。 有効なリクエストの数がリクエストの総数よりも少ない場合は、一部のリクエストが失敗したことを示します。

  

  有効なリクエスト数の変動、特にスパイクやディップを追跡し、原因を分析するために、タイムリーな通知を受け取るようにアラートルールを設定できます。 詳細については、「アラートサービス」をご参照ください。

• ユーザーによるリクエストステータスの配布

  可用性 /有効なリクエストの割合が100% 未満の場合、または有効なリクエストの数がリクエストの総数よりも少ない場合は、ユーザー別のリクエストステータスの分布を表示して、エラーリクエストの種類を判断できます。 ユーザーによるリクエストステータスの配布の詳細については、「メトリック」をご参照ください。

  

要求ステータスの監視

パフォーマンスの監視

OSSのパフォーマンスを示すメトリックでは、平均レイテンシの急上昇やリクエストの高レイテンシの延長など、異常な変動に焦点を当てる必要があります。 アラートルールがトリガーされたときに通知が送信されるように、パフォーマンスメトリックのアラートルールを設定できます。

請求可能なアイテムの監視

OSSモニタリングサービスを使用すると、ストレージ使用量、PUTリクエストとGETリクエストの数、インターネット経由のアウトバウンドトラフィック (CRRアウトバウンドトラフィックまたはCDNアウトバウンドトラフィックを含まない) を監視できます。 OSSモニタリングサービスは、請求可能なアイテムとOpenAPIの読み取りに関するアラート設定をサポートしていません。

OSSモニタリングサービスは、1か月あたりのユーザーおよびバケットごとのリソース使用量の統計を提供します。 Alibaba Cloudアカウントまたは特定のバケットのOSSリソース使用量は、1時間ごとに計算および更新されます。 この方法で、当月のストレージコストを計算できます。

問題の診断

• パフォーマンスの診断

  ビジネス要件に基づいて、アプリケーションパフォーマンスのベースラインを決定する必要があります。 クライアントから送信された失敗した要求は、OSSの過度の過負荷、クライアントのTCPの設定、ネットワークからのトラフィックのボトルネックなど、要求の送信リンク全体の1つまたは複数の要素によって引き起こされる可能性があることに注意してください。

  これにより、モニタリングサービスによって提供されるパフォーマンス指標に基づいて、考えられる問題を特定できます。 次に、ログに詳細情報を照会し、障害をさらに診断します。

• エラー診断

  クライアントアプリケーションは、要求エラーが発生したときにサーバからエラーメッセージを受信する。 モニタリングサービスは、さまざまなエラー要求の数と割合を記録および表示します。 サーバー、クライアント、およびネットワークの状態のログを確認して、特定のリクエストに関する詳細を取得できます。 一般に、HTTPステータスコード、エラーコード、およびレスポンス内のエラーメッセージは、エラー要求の考えられる原因を示しています。

  エラーコードの詳細については、「エラー応答」をご参照ください。

• ロギング機能を使用した診断

  OSSには、ユーザーからのリクエストのログ機能があり、クライアントアプリケーションとサーバー間の送信全体でリクエストの詳細を追跡できます。

  ロギングを有効にしてこの機能を使用する方法の詳細については、「ロギングの設定」をご参照ください。

  OSSログの命名規則と形式の詳細については、「ロギング」をご参照ください。

• ネットワーク状態のログを使用して診断する

  通常、サーバーとクライアントアプリケーションのログに基づいて、障害の原因を特定できます。 ただし、場合によっては、障害の原因を特定するために、このプロセスで送信されるトラフィックやデータなど、サーバーとクライアント間のネットワーク状態に関する情報を取得するためのネットワークログも必要です。 たとえば、ユーザーリクエストに対してエラーが報告されますが、アプリケーションサーバーではリクエストのログは生成されません。 この場合、OSSログを確認して原因がアプリケーションユーザークライアントにあるかどうかを判断するか、ネットワークモニタリングツールを使用してネットワーク状態を確認します。

  Wiresharkは、ログの監視と分析のための最も一般的なツールの1つです。 この無料ツールは、データパッケージのレベルで動作します。 このツールを使用して、すべてのプロトコルで送信されるデータパッケージの詳細を照会し、障害がパッケージの損失またはネットワーク接続によるものかどうかを判断できます。

  Wiresharkの使用方法の詳細については、Wiresharkユーザーズガイドをご覧ください。

E2E のトラッキングと診断

通常のプロセスでは、クライアントからOSSにリクエストが送信され、OSSサーバーはリクエストを処理してクライアントに応答を送信します。 クライアントとサーバー間のプロセス全体を追跡できます。 クライアントアプリケーション、ネットワーク、およびサーバーのログを使用して、潜在的な障害を特定できます。

パフォーマンス関連の問題

• 高い平均E2Eレイテンシと低い平均サーバーレイテンシ

  次の原因は、上記の平均E2Eレイテンシと平均サーバーレイテンシの説明から推測されます。

  • クライアントアプリケーションの応答が遅い

    • 利用可能な接続とスレッドは限られています。

      • 使用可能な接続が限られている場合は、関連するコマンドを実行して、多数の接続がTIME_WAIT状態にあるかどうかを確認できます。 多数の接続がTIME_WAIT状態にある場合、この問題を処理するためにCPUコアの数を調整できます。

      • 限られたスレッドの場合、クライアントCPU、メモリ、ネットワークなどのリソースにボトルネックが存在するかどうかを確認できます。 そうでない場合は、同時スレッドの数を適切に増やすことができます。

      • 問題が解決しない場合は、アプリケーションのコードを最適化する必要があります。 たとえば、非同期アクセスをサポートするようにアプリケーションのコードを最適化できます。 パフォーマンス分析機能を使用して、最もよく使用されるアプリケーション機能を特定し、クライアントアプリケーションを最適化することもできます。

    • CPU、メモリ、または帯域幅の限られたリソース

      この場合、関連システムのモニタリング機能を使用してリソースのボトルネックを特定する必要があります。 次に、アプリケーションのコードを最適化してリソースの制限を調整するか、CPUコアの数を増やしたり、メモリを増やしたりするなど、クライアントのリソースをスケールアップできます。

  • 悪いネットワーク条件

    一般に、高い平均E2Eレイテンシは、一時的な劣悪なネットワーク状態によって引き起こされる。 Wiresharkを使用して、データパッケージの損失などの偶発的で永続的なネットワーク問題を分析できます。

• 低い平均E2Eレイテンシ、低い平均サーバーレイテンシ、および高いクライアント要求レイテンシ

  クライアント要求レイテンシが高い場合、要求がアプリケーションサーバに到着する前に、高いレイテンシが発生する可能性が高い。 したがって、クライアントからのリクエストがサーバーに到着しない理由を分析することをお勧めします。

  次のシナリオでは、クライアント要求の待ち時間が長くなる場合があります。

  • 利用可能な接続とスレッドは限られています。

    • 使用可能な接続が限られている場合は、関連するコマンドを実行して、多数の接続がTIME_WAIT状態にあるかどうかを確認できます。 多数の接続がTIME_WAIT状態にある場合、この問題を処理するためにCPUコアの数を調整できます。

    • 限られたスレッドの場合、クライアントCPU、メモリ、およびネットワークリソースにボトルネックが存在するかどうかを確認できます。 そうでない場合は、同時スレッドの数を適切に増やすことができます。

    • 問題が解決しない場合は、非同期メソッドを使用したアクセスなど、アプリケーションのコードを最適化する必要があります。 パフォーマンス分析機能を使用して、最もよく使用されるアプリケーション機能を特定し、クライアントアプリケーションを最適化することもできます。

  • クライアントでリクエストに対して複数回の再試行が発生します。 この場合, リトライ情報に基づいて原因を分析する必要があります。 クライアントで再試行が発生したかどうかは、次の方法で確認できます。

    • クライアントログを確認して、再試行が発生したかどうかを確認します。 例としてJava用のOSS SDKを取り上げます。 警告レベルまたは情報レベルのログプロンプトを照会できます。同様のログが記録されている場合、クライアントまたはサーバーで再試行が行われる可能性があります。

      [サーバー] HTTPリクエストを実行できません:
        または
        [クライアント] HTTPリクエストを実行できません: 

    • 例としてJava用のOSS SDKを取り上げます。 クライアントログのレベルがdebugの場合は、次のログを照会できます。 同様のログが記録されている場合は、再試行が必要です。

      再試行

  クライアントに障害がない場合は、データパッケージの損失など、ネットワークの潜在的な問題を検討してください。 Wiresharkなどのツールを使用して、ネットワークの問題の原因を分析できます。

• 高い平均サーバーレイテンシ

  ダウンロードとアップロードの平均サーバー遅延が大きい場合は、次の原因を考慮してください。

  • 多数のクライアントが頻繁にオブジェクトにアクセスする。

    この場合、OSSログを表示して、オブジェクトまたはオブジェクトのグループが頻繁にアクセスされているかどうかを判断できます。

    ダウンロードのシナリオでは、パフォーマンスを向上させ、生成されるトラフィックを減らすために、バケットのContent Delivery Network (CDN) を有効にすることを推奨します。 アップロードのシナリオでは、ビジネス要件に影響を与えない場合、ユーザーがバケットまたはオブジェクトにデータを書き込むことができないように、バケットまたはオブジェクトのアクセス制御リスト (ACL) を変更することを推奨します。

  • OSSの内部問題

    OSSの内部問題については、アプリケーションのコードを最適化しても解決できない場合があります。 この場合、テクニカルサポートに連絡して、クライアントログまたは失敗したリクエストのリクエストIDをOSSログに提供します。

アプリケーションサーバーのエラー

ネットワークエラー

クライアントがリクエストをキャンセルするか、リクエストプロセス中に接続を失うと、ネットワークエラーが発生します。 クライアントがリクエストをキャンセルした場合は、アプリケーションのコードを確認し、クライアントがOSSを切断する理由とタイミングを取得する必要があります。 クライアントが接続を失った場合は、Wiresharkなどのツールを使用して考えられる原因を分析できます。

クライアントエラー

• クライアント認証エラー要求の増加

  クライアント認証エラー要求が増加した場合、またはクライアントアプリケーションが大量のHTTPステータスコード403を受信した場合は、次の原因を考慮してください。

  • 無効なバケットドメイン名

    • ユーザが第3レベルドメインまたは第2レベルドメインを使用してバケットにアクセスする場合、ドメイン名に含まれる領域は、バケットが位置する領域とは異なる可能性がある。 たとえば、アクセスされたバケットは中国 (杭州) リージョンにありますが、アクセスされたドメイン名はs Bucket.oss-cn-shanghai.aliyuncs.comします。 この場合、バケットが配置されているリージョンを確認し、アクセスしたドメイン名を修正する必要があります。

    • CDNを有効にしている場合、CDNにマップされているオリジンがバケットの間違ったドメイン名である可能性があります。 この場合、オリジンがバケットの第3レベルドメインであるかどうかを確認します。

    • ユーザーがJavaScriptのクライアントを使用し、403エラーが返された場合は、ユーザーがバケットにアクセスするために使用するwebブラウザーにCORSが設定されているかどうかを確認します。 この場合、ユーザーがwebブラウザーを使用してバケットにアクセスできるように、バケットのCORS設定を確認し、設定を修正してください。 クロスオリジンリソース共有 (CORS) を設定する方法の詳細については、「CORSの設定」をご参照ください。

  • アクセス制御

    • Alibaba CloudアカウントのAccessKeyペアを使用してバケットにアクセスする場合は、AccessKeyペアの有効性を確認してください。

    • RAMユーザーのAccessKeyペアを使用してバケットにアクセスする場合は、AccessKeyペアの有効性または権限を確認してください。

    • Security token Service (STS) によって生成されたトークンを使用する場合は、一時トークンの有効期限が切れるかどうかを確認します。 トークンの有効期限が切れている場合は、新しいトークンを申請します。

    • アクセスされたバケットまたはオブジェクトにアクセス制御リスト (ACL) が設定されている場合は、ACL設定に基づいてユーザーが特定の操作を実行できるかどうかを確認します。

  • 期限切れのURL

    サードパーティが署名付きURLを使用してバケットにアクセスしたときに403エラーが発生した場合、最も考えられる原因は、署名付きURLの有効期限が切れていることです。

  • RAMユーザーがossftp、ossbrowser、OSSコンソールなどのOSSツールにログインすると、403エラーが発生することがあります。 この場合、正しいAccessKeyペアを入力するかどうか、またはアカウントがRAMユーザーである場合はGetService操作を呼び出す権限があるかどうかを確認します。

• クライアント要求に対する404エラーの増加

  クライアント要求の404エラーは、ユーザーがアクセスするデータが存在しないことを示します。 クライアント要求の404エラーが増加した場合は、次の原因を考慮してください。

  • アプリケーションのビジネスロジック。 たとえば、アプリケーションは、OSS SDK For Javaが提供するdoesObjectExistメソッドを呼び出して、さらなるアクションの前にオブジェクトが存在するかどうかを確認します。 オブジェクトが存在しない場合、falseの値がクライアントに返され、サーバーで404エラーメッセージが生成されます。 したがって、ビジネスシナリオでは、404ステータスコードはエラーを示しません。

  • アクセスされたオブジェクトは、クライアントアプリケーションまたは他のプロセスによって削除される。 この場合、アクセスされたオブジェクトのOSSログを照会します。

  • ネットワーク障害による削除操作を繰り返します。 例えば、クライアントは、オブジェクトを削除する操作を開始する。 リクエストがサーバーに到着し、オブジェクトが削除されます。 ただし、ネットワーク障害のために応答がクライアントに到着しません。 その結果、クライアントはオブジェクトを削除するための別の要求を送信し、404エラーが発生します。 この場合、クライアントログとOSSログを照会および表示して、404エラーの原因を特定できます。

    • クライアントログを照会し、クライアントから繰り返しリクエストが送信されているかどうかを確認します。

    • OSSログを照会します。 次に、オブジェクトに対して2つの削除操作が開始され、最初の操作のHTTPステータスコードが2xxであるかどうかを確認します。

• 有効なリクエストの割合が低く、クライアントエラーのリクエストが高い

  有効リクエスト割合は、応答がHTTPステータスコード2xxまたは3xxである成功したリクエストの合計リクエストに対する割合です。 応答がHTTPステータスコード4xxまたは5xxであるリクエストは、失敗したリクエストとしてカウントされ、有効なリクエストの割合が低くなります。 ユーザーによるクライアントの他のエラー要求は、サーバーエラー要求、ネットワークエラー要求、クライアント許可エラー要求、リソースが見つからないエラー要求、およびクライアントのタイムアウトエラー要求以外のエラー要求を指します。 前述のエラー要求に対する応答は、それぞれ5xx、499、403、404、408、または400であり、対応するOSSエラーコードはRequestTimeoutです。

  OSSログを照会して、エラーの種類を特定できます。 次に、OSSエラーコードを参照し、アプリケーションのコードを変更してエラーを解決します。 詳細については、「エラー応答」をご参照ください。

ストレージ使用量の例外的な増加

その他のストレージサービスの問題