従来のアプリケーションと比較し、インフラストラクチャ構築と O&M クラウドアプリケーションのユーザーのコストは削減されているにもかかわらず、クラウドアプリケーションは複雑なモニタリング、診断、トラブルシューティングを行います。 OSS ストレージサービスでは、各種モニタリングおよびログ情報を提供しているため、プログラムの動作全体を把握し、問題を迅速に発見および特定するのに役立ちます。

概要

本ページでは、OSS モニタリングサービス、ログ、およびその他のサードパーティーのツールを使用して、OSS の問題のモニタリング、診断、およびトラブルシューティングを行う方法について説明します。

  • OSS の実行ステータスとパフォーマンスをリアルタイムでモニターし、迅速なアラーム通知を提供します。
  • 問題の特定に役立つ効果的な方法とツールを提供します。
  • 一般的な OSS 関連の問題を迅速に解決するための方法を提供します。

本ページは次のように構成されています。

  • OSS リアルタイムモニタリング: OSS モニタリングサービスを使用して、OSS の実行ステータスとパフォーマンスを継続的にモニターする方法について説明します。
  • トラッキングと診断: OSS モニタリングサービスおよびログ機能を使用して問題を診断する方法、およびトラッキングおよび診断を行うにあたり、関連情報をログファイルに関連付ける方法について説明します。
  • トラブルシューティング: 一般的な問題と対応するトラブルシューティング方法について説明します。


OSS モニタリング

運用状況の概略
  • 有効なリクエストの可用性と割合

    これは、システムの安定性とユーザーがシステムを正しく使用できるかどうかを示す重要なインジケーターです。 100 %より低い値は、一部のリクエストが失敗したことを示します。

    可用性は、負荷分散のためのパーティション移行などのシステム最適化要因により、一時的に 100% を下回る可能性があります。 このような場合、OSS SDK は、このタイプの断続的な障害を処理するための関連する再試行メカニズムを提供し、サービスを終了しないでおくことができます。

    また、有効なリクエストの割合が 100 %を下回る場合、使用状況に基づいて問題を分析する必要があります。 リクエスト分散統計またはリクエスト状況詳細を使用することで、リクエストエラーの実際のタイプを判別します。 「トラッキングと診断」を使用することにより、問題の原因を特定しトラブルシューティングを実行することができます。 一部のビジネスシナリオでは、有効なリクエスト率は 100 %を下回ることが予想されます。 たとえば、まずオブジェクトが存在することを確認してから、そのオブジェクトの存在に基づいて特定の操作を実行する必要があります。 オブジェクトが存在しない場合、その存在を検査する読み取りリクエストは、404 エラーコード (リソースが存在しないエラー) を返します。 これにより、必然的に有効リクエスト率は 100 %未満になります。

    高いシステム可用性を必要とする企業では、予想されるしきい値をインジケーターが下回ったとき、トリガーされるアラームルールを設定することができます。

  • リクエスト合計数と有効リクエスト数

    このインジケーターは、トラフィックの合計量の分析観点からシステム運用状況を示します。 有効なリクエスト数がリクエストの合計数と等しくない場合、一部のリクエストが失敗したことを示します。



    特にリクエスト数が急激に増減する場合、リクエスト合計数と有効リクエスト数の変動を見ることができます。 そのような場合、フォローアップ操作が必要です。 アラームルールを設定することで、プロンプト通知を確実に受け取れるようにすることができます。 定期的なビジネスの場合、定期的なアラームルールを設定します (定期的なアラームはすぐに使用可能になります)。 詳しくは、「アラームサービスユーザーガイド」をご参照ください。

  • ステータス分散統計情報のリクエスト

    可用性または有効リクエスト率が 100 %を下回る場合 (または有効リクエスト数が全体のリクエストの合計数と等しくない場合) 、リクエスト状況の分散統計を調べて、リクエストのエラータイプを迅速に判別することできます。 このメトリックインジケーターの詳細については、「モニタリングインジケーターリファレンス」をご参照ください。



リクエストステータスの詳細なモニタリング

リクエスト状況の詳細では、リクエスト状況の分散統計に基づき、リクエストのモニタリングステータスについての詳細を提供します。 特定のタイプのリクエストを、より詳細にモニターすることができます。



パフォーマンスモニタリング

モニタリングサービスでは、パフォーマンスのモニタリングのインジケーターとして使用される以下のメトリック項目を提供します。

  • 平均レイテンシ: E2E 平均レイテンシとサーバー平均レイテンシ

  • 最大レイテンシ: E2E 最大レイテンシとサーバー最大レイテンシ

  • 成功したリクエストの分類項目

  • トラフィック

    前述のメトリック項目 ("トラフィック" を除く) では、API 操作タイプに基づいて分類されたモニタリングを実装しています。

    • GetObject
    • HeadObject
    • PutObject
    • PostObject
    • AppendObject
    • UploadPart
    • UploadPartCopy

    レイテンシインジケーターは、API 操作タイプがリクエストを処理するために必要な平均時間または最大時間を示します。 E2E のレイテンシは、端末相互間のレイテンシのインジケーターです。 リクエストを処理するために必要な時間に加え、リクエストの読み取りに必要な時間、応答の送信に必要な時間、およびネットワーク転送による遅延時間が含まれます。 サーバーのレイテンシには、サーバー側のリクエストを処理するために必要な時間だけが含まれ、クライアント側のネットワークのレイテンシは含まれません。 したがって、E2E レイテンシが突如増加したものの、サーバーのレイテンシに大きな変化がない場合、OSS システムの障害が原因ではなく、ネットワークの不安定性によってパフォーマンスが低下していると判断することができます。

    前述の API に加えて、"成功したリクエスト操作分類項目" では、次の 2 つの API 操作タイプのリクエスト数もモニターされます。

    • DeleteObject
    • Deleteobjects

    トラフィックインジケーターは、ユーザーまたは特定のバケットの全体的な状況をモニターするために使用されます。 インターネット、イントラネット、CDN オリジン検索、ドメイン間レプリケーションなどのシナリオにおける、ネットワークリソースの使用状況をモニターします。

    パフォーマンスタイプのインジケーターでは、平均レイテンシが急激に増加したり、通常のリクエストレイテンシベースラインを長期間にわたって維持したりするなど、突然の変化や異常な変化に注視する必要があります。 パフォーマンスインジケーターに対応するアラームルールを設定することにより、インジケーターがしきい値を下回った場合、またはしきい値を超えた場合に、関係している担当者にすぐに通知されるようにすることができます。 定期的なピークと谷があるビジネスでは、週ごと、曜日ごと、時間ごとの比較に定期的なアラームルールを設定することができます (定期的なアラームはすぐに使用できます)。

課金情報のモニタリング

プレス時は、OSS モニタリングサービスは、ストレージスペース、アウトバウンドインターネットトラフィック、Put リクエスト、および Get リクエスト (ドメイン間レプリケーションアウトバウンドトラフィックと CDN アウトバウンドトラフィックを除く) のみをモニタリングします。 課金情報データのアラーム設定、または API 読み取り操作はサポートされていません。

OSS モニタリングサービスでは、1 時間ごとにバケットレベルの課金情報モニタリングデータを収集します。 特定のバケットのモニタリングビューでは、継続的なモニタリング傾向のグラフを確認することができます。 モニタリングビューを使用することで、ビジネスの OSS リソース使用量の傾向を分析し、将来のコストを見積もることができます。 次の図をご参照ください。



また、OSS モニタリングサービスは、毎月消費されるユーザーおよびバケットレベルのリソースの量に関する統計も提供します。 たとえば、月の最初の日から開始されたアカウントまたはバケットによって消費された OSS リソースの合計量があります。 これらの統計は毎時更新されます。 これにより、次の図に示すように、当月のリソース使用量と計算コストをリアルタイムで把握することができます。

モニタリングサービスでは、提供された課金情報データは最大限プッシュされますが、実際の請求額とは若干の差異が生じる可能性があります。 課金情報センターのデータが、実際の請求額として使用されることをご了承ください。

トラッキングと診断

問題の診断
  • パフォーマンスの診断

    アプリケーションパフォーマンスの決定には、多くの主体的要因が関係しています。 特定のビジネスシナリオでのビジネスニーズの満足度をベースラインとして使用して、パフォーマンスの問題が発生するかどうかを判断する必要があります。また、クライアントがリクエストを開始すると、パフォーマンス上の問題を引き起こす可能性のある要因が、リクエストチェーンのどこからでも発生する可能性があります。たとえば、OSS の過負荷、クライアントの TCP 設定の問題、または基本的なネットワークアーキテクチャのトラフィックのボトルネックにより、問題が発生する可能性があります。

    したがって、パフォーマンスの問題を診断するときは、最初に合理的なベースラインを設定する必要があります。 次に、モニタリングサービスが提供するパフォーマンスインジケーターを使用して、パフォーマンス上の問題の潜在的な根本原因を特定します。 次に、関連するログで詳細な情報を探し、障害をさらに診断してトラブルシューティングを行います。

    トラブルシューティングのセクションでは、パフォーマンスに関する一般的な問題と、トラブルシューティング方法の例を多く挙げています。 こちらは参考用としてご利用ください。

  • エラー診断

    クライアントアプリケーションからのリクエストに障害が発生すると、クライアントはサーバーからエラー情報を受け取ります。 モニタリングサービスは、これらのエラーを記録し、リクエストに影響を与える可能性のある各種エラーの統計を表示します。 サーバーログ、クライアントログ、およびネットワークログから個々のリクエストに関する詳細情報を取得することもできます。 一般的に、返された HTTP ステータスコード、OSS エラーコード、および OSS エラー情報は、リクエストの失敗の原因を示しています。

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

  • ログ機能の使用

    OSS は、ユーザーリクエストに対してサーバーログ機能を提供します。 この機能は、端末相互間の詳細なリクエストログをトラッキングするのに役立ちます。

    ログ機能の有効化と使用方法については、「ログの設定」をご参照ください。

    ログサービスの命名規則とレコード形式の詳細については、「サーバーアクセスログ」をご参照ください。

  • ネットワークログツールの使用

    多くの状況において、ログ機能を使用してストレージログとクライアントアプリケーションのログデータを記録することで、問題を診断することができます。 ただし、状況によっては、ネットワークログツールを使用し、詳細情報を取得することが必要になる場合があります。

    これは、クライアントとサーバー間で交換されるトラフィックをキャプチャすることで、クライアントとサーバー間で交換されたデータと、その基礎的なネットワークステータスに関する詳細情報を得られるため、問題の調査に役立つからです。 たとえば、ユーザーのリクエストによってエラーが報告されたにもかかわらず、サーバーログにリクエストが表示されない場合もあります。 このような場合、OSS ログ機能によって記録されたレコードを使用して、問題の原因がクライアントにあるかどうかを確認したり、またはネットワークモニタリングツールを使用してネットワークの問題をチェックすることができます。

    Wireshark は、最も一般的なネットワークログ分析ツールの 1 つです。 このフリープロトコルアナライザーは、パケットレベルで動作し、各種ネットワークプロトコルの詳細なパケット情報を表示します。 Wireshar は、パケットの損失や接続の問題をトラブルシューティングするのに役立ちます。

E2E のトラッキングと診断

リクエストはクライアントアプリケーションプロセスによって開始され、ネットワーク環境を介して OSS サーバーに渡され、そこで処理されます。 次に、ネットワーク環境を介してサーバーから応答が送信され、クライアントによって応答が受信されます。 これは端末相互間でのトラッキングプロセスです。 クライアントアプリケーションログ、ネットワークトラッキングログ、およびサーバーログを関連付けることで、問題の根本原因をトラブルシューティングし、潜在的な問題を発見するための詳細な情報が提供されます。

OSS では、提供される RequestID は、各種ログからの情報の関連付けに使用される識別子として機能します。 また、ログのタイムスタンプでは、特定のログの時間範囲を迅速に照会できるだけでなく、この期間中における、リクエストイベントやその他のクライアントアプリケーション、ネットワーク、サービスシステムイベントの発生時点を確認することもできます。 ログのタイムスタンプは、問題の分析と調査に役立ちます。

  • RequestID

    OSS はリクエストを受け取るたびに、一意のサーバーリクエスト ID と、その RequestID を割り当てます。 異なるログでは、RequestID はさまざまなフィールドにあります。

    • OSS ログ機能によって記録されたサーバーログでは、RequestID は "Request ID" 欄にあります。
    • ネットワークトラッキングのプロセス (たとえば、データストリームをキャプチャするために Wireshark を使用する場合) では、RequestID は応答メッセージの x-oss-request-id ヘッダー値です。
    • クライアントアプリケーションでは、クライアントコードを使用し、クライアントログに RequestID を手動で出力する必要があります。 最新の Java SDK バージョンでは、プレス時における通常のリクエストに対する RequestID 情報の出力がすでにサポートされています。 getRequestId 操作を使用することで、各種 API によって返された結果から RequestID を取得することができます。 すべての OSS SDK バージョンでは、異常なリクエストに対する RequestID を出力することができます。 この情報を取得するには、OSSException の getRequestId メソッドを呼び出します。
  • タイムスタンプ

    タイムスタンプを使用することで、関連するログエントリを検索することができます。 クライアントの時間とサーバーの時間との間には、多少のずれがある可能性に注意する必要があります。 クライアントでは、タイムスタンプを使用することで、ログ機能によって記録されたサーバーログエントリを検索します。 検索の際には、15 分を加算または減算する必要があります。

トラブルシューティング

一般的なパフォーマンス関連の問題
  • 低い平均サーバーレイテンシかつ高い平均 E2E レイテンシ

    平均 E2E レイテンシと平均サーバレイテンシの違いについてはすでに説明しました。 したがって、高い E2E レイテンシと低いサーバーレイテンシは、次の 2 つの原因が考えられます。

    • クライアントアプリケーションの応答速度が遅い
    • ネットワーク要因
    クライアントアプリケーションの応答速度が遅いのには、いくつかの原因が考えられます。
    • 使用可能な接続数またはスレッド数が制限されている

      • 関連するコマンドを使用して、TIME_WAIT ステータスにシステムに多数の接続があるかどうかを確認します。 多数の接続がある場合、この問題を解決するため、コアパラメーターを調整します。
      • 使用可能なスレッド数が制限されている場合、まずクライアント CPU、メモリ、ネットワーク、またはその他のリソースに影響を与えるボトルネックをチェックします。 ボトルネックが見つからない場合は、同時スレッド数を適切に増やします。
      • 問題が解決しない場合、クライアントコードを最適化する必要があります。 たとえば、非同期アクセスメソッドを使用します。 また、パフォーマンス分析機能を使用してクライアントアプリケーションのホットスポットを分析し、必要な最適化を実行することもできます。
    • CPU、メモリ、帯域幅などのリソースが不足している

      • この種の問題の場合、まず関連するシステムモニタリング機能を使用し、クライアントリソースのボトルネックを検出する必要があります。 次に、クライアントコードを最適化してリソースの使用を合理化するか、クライアントリソースを増やします (コア数またはメモリを増やします)。

    ネットワークレイテンシの問題の調査

    一般的に、ネットワーク要因による高い E2E レイテンシは一時的です。 Wiresharkを使用することで、パケット損失の問題など、一時的および持続的なネットワークの問題を調査できます。

  • 低い平均 E2E レイテンシかつ低い平均サーバーレイテンシであるものの、高いクライアントリクエストレイテンシの場合

    クライアントのリクエストレイテンシが長い場合、最も可能性の高い原因は、リクエストがサーバーに届いていないためです。 そのため、クライアントリクエストがサーバーに届いていない理由を調べる必要があります。

    2 つのクライアント側の要因により、クライアントリクエストの送信レイテンシが長くなる可能性があります。

    • 使用可能な接続またはスレッドの数が限られている場合: 前のセクションで説明した解決策をご参照ください。
    • クライアントリクエストが複数回再試行される場合: この場合、再試行情報に基づき、リクエストが再試行された原因を見つけて解決する必要があります。 次の手順を実行して、クライアントに再試行の問題があるかどうかを判断します。

      • クライアントログを確認します。 詳細なログエントリは、再試行が発生したかどうかを示します。 例として、OSS Java SDK を使用すると、次の警告レベルまたは情報レベルのログエントリを検索することができます。 そのようなエントリがログに見つかった場合、リクエストが再試行されたことを示します。

        [Server]Unable to execute HTTP request:
           Or
          [Client]Unable to execute HTTP request:
      • クライアントのログレベルがデバッグの場合は、次のログエントリを検索します (ここでも、例として OSS Java SDK を使用しています)。 そのようなエントリが存在する場合、リクエストが再試行されたことを示します。
        Retrying on

    クライアントに問題がない場合は、パケット損失などの潜在的なネットワークの問題をチェックする必要があります。 Wireshark などのツールを使用することで、ネットワークの問題を調査することができます。

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

    ダウンロードまたはアップロード中のサーバーのレイテンシが長い場合は、次の 2 つの要因が考えられます。

    • 多数のクライアントが同一の小さなオブジェクトに頻繁にアクセスしている

      この状況では、ログ機能によって記録されたサーバーログを表示して、小さなオブジェクトまたは小さなオブジェクトグループが短期間に頻繁にアクセスされているかどうかを判断します。

      ダウンロードシナリオでは、パフォーマンスを向上させるため、このバケットの CDN サービスを有効化することを推奨します。 これにより、トラフィックの使用料を削減できます。 アップロードシナリオの場合、これがビジネスに影響を与えないのであれば、このオブジェクト (バケット) に対する書き込み権限を取り消すことを検討してください。

    • 内部システム要因

      内部システムの問題や最適化では解決できない問題については、クライアントログまたはログ機能で記録されたログにある RequestID を弊社システムスタッフにご提出ください。ご提出いただいた RequestID は問題解決に役立てることができます。

サーバーエラー

サーバー側エラーの数が増加した場合、2 つのシナリオを考慮する必要があります。

  • 一時的な増加

    この種の問題では、クライアントプログラムで再試行ポリシーを調整し、指数関数的バックオフなどの合理的な譲歩メカニズムを採用する必要があります。 これにより、システムの最適化、アップグレード、およびその他の操作 (システム負荷分散のためのパーティション移行など) により、一時的にサービスが利用できなくなるのを回避できるだけでなく、ビジネスピーク時の高いプレッシャーも回避することができます。

  • 持続的な増加

    サーバー側のエラーの数が持続的に増加する場合、バックエンドのスタッフにクライアントログ、またはログ機能によって記録されたログの RequestID をご提供ください。問題の発見に役立てることができます。

ネットワークエラー

サーバーがリクエストを処理しているときに接続が失われると (サーバー側の問題によるものではない)、ネットワークエラーが発生するため、HTTP リクエストヘッダーを返すことができません。 そのような状況では、システムはこのリクエストに対して 499 の HTTP ステータスコードを記録します。 次の状況では、サーバーはリクエストステータスコードを 499 に変更する可能性があります。

  • 受信した読み取り/書き込みリクエストを処理する前に、サーバーが接続が利用できないことを検出すると、そのリクエストは 499 として記録されます。
  • サーバーがリクエストを処理しているときにクライアントが優先的に接続を閉じると、リクエストは 499 として記録されます。

要約すると、クライアントが自主的にリクエストを閉じるか、またはクライアントがネットワークから切断された場合、リクエストプロセス中にネットワークエラーが発生します。クライアントが自主的にリクエストを閉じた場合、クライアントコードをチェックすることで、クライアントが OSS から切断された原因と時間を特定することができます。 クライアントがネットワーク接続を失った場合は、Wireshark などのツールを使用してネットワーク接続の問題を調査します。

クライアントエラー
  • クライアント権限付与エラーの増加

    クライアント権限付与エラーの増加を検出した場合、またはクライアントが多数の 403 リクエストエラーを受信した場合、一般的に以下の問題が原因です。

    • ユーザーがアクセスしたバケットドメイン名が正しくない

      • ユーザーが第 3 レベルまたは第 2 レベルドメイン名を使用してバケットにアクセスする場合、ドメイン名で示されるリージョン内にそのバケットがないと、403 エラーが発生する可能性があります。 たとえば、杭州リージョンでバケットを作成したけれども、あるユーザーがドメイン名 Bucket.oss-cn-shanghai.aliyuncs.com を使用してバケットへのアクセスを試みたとします。 この場合、バケットのリージョンを確認し、ドメイン名の情報を修正する必要があります。
      • CDN アクセラレーションサービスを有効化した場合、CDN が正しくないオリジン取得ドメイン名をバインドすると、この問題が発生することがあります。 この場合、CDN オリジン取得ドメイン名がバケットの第 3 レベルドメイン名であることをチェックします。
    • JavaScript クライアントを使用しているときに 403 エラーが発生した場合、Web ブラウザーで "同一ソースポリシー" のセキュリティ制限が実装されているため、CORS (クロスオリジンリソース共有) 設定の問題が原因である可能性があります。 この場合、バケットの CORS 設定をチェックし、エラーを修正する必要があります。 CORS 設定については、「CORS」をご参照ください。
    • アクセス制御の問題は、4 つのタイプに分けられます。

      • アクセスにプライマリ AK を使用する場合、AK が無効な場合は、AK設定でエラーをチェックする必要があります。
      • アクセスに RAM サブアカウントを使用する場合は、そのサブアカウントが正しいサブアカウント AK を使用していることと、そのサブアカウントに適切なアクセス許可があることを確認する必要があります。
      • アクセスに一時的な STS トークンを使用する場合は、一時的なトークンが有効期限切れになっていないことを確認する必要があります。 トークンの有効期限が切れている場合は、新しいトークンを申請します。
      • アクセス制御にバケットまたはオブジェクト設定を使用する場合は、アクセスするバケットまたはオブジェクトが関連操作をサポートしていることをチェックする必要があります。
    • サードパーティーのダウンロード (署名付き URL を使用してOSSリソースにアクセスする) を許可した際、以前はアクセスが正常だったのに突然 403 エラーが報告された場合、URL が有効期限切れになっている可能性があります。

    • RAM サブアカウントで OSS ユーティリティを使用すると、403 エラーが発生することもあります。 これらのユーティリティには、ossftp、ossbrowser、および OSS コンソールクライアントが含まれます。 ログイン時に関連する AK 情報を正しく入力したにもかかわらず、システムがエラーをスローした場合、AK がサブアカウント AK であり、このサブアカウントが GetService およびその他の操作に対するアクセス許可を持っていることをチェックする必要があります。
  • クライアント側の "存在しないリソース" エラーの増加

    クライアントが 404 エラーを受け取った場合、存在しないリソースまたは情報にアクセスしようとしていることを意味します。 モニタリングサービスが「リソースが存在しません」エラーの増加を検出した場合、おそらく次のいずれかの問題が原因になっています。

    • サービスの使用方法: たとえば、別の操作を実行する前に、まずオブジェクトが存在することをチェックする必要があり、doesObjectExist メソッドを呼び出したとします (例としてJava SDK を使用)。ここでオブジェクトが存在しない場合、クライアントは値 "false" を受け取ります。 しかしながら、サーバーは実際には 404 リクエストエラーを生成します。 そのため、このビジネスシナリオでは、404 エラーは正常です。

    • クライアントまたは他のプロセスが、以前にこのオブジェクトを削除: ログ機能によって、記録されたサーバーログの関連するオブジェクト操作を検索することにより、この問題を確認します。

    • ネットワーク障害によるパケット損失と再試行:例えば、クライアントは、特定のオブジェクトを削除するため、削除操作を行うことがあります。 そのリクエストはサーバーに届き、削除操作を正常に実行します。 しかしながら、ネットワーク上での送信中に応答パケットが失われると、クライアントは再試行を開始します。 この 2 番目のリクエストは 404 エラーを生成します。クライアントログとサーバーログを使用することで、ネットワークの問題が 404 エラーを生成していることを確認できます。

      • クライアントアプリケーションログの再試行リクエストをチェックします。
      • このオブジェクトに対する 2 つの削除操作がサーバーログに表示されていること、および最初の削除操作の HTTP ステータスが 2xx であることをチェックします。
  • 低い有効リクエスト率、およびその他の多数のクライアント側リクエストエラー

    有効リクエスト率とは、2xx / 3xx の HTTP ステータスコードを全体のリクエストの割合として返すリクエストの数です。 4XX または 5XX のステータスコードは失敗したリクエストを示し、有効リクエスト率を下げます。 他のクライアント側のリクエストエラーは、以下のエラーを除くリクエストエラーを示します。: サーバーエラー (5xx)、ネットワークエラー (499)、クライアント許可エラー (403)、存在しないリソースエラー (404)、クライアントタイムアウトエラー (408 または OSS エラーコード: RequestTimeout 400)。

    ログ機能によって記録されたサーバーログをチェックし、これらのリクエストによって発生した特定のエラーを判別します。 OSS エラー応答を確認し、OSS から返される一般的なエラーコードの一覧を参照します。 次に、クライアントコードを調べて、これらのエラーの具体的な原因を発見し、解決します。

ストレージ容量の異常な増加

アップロードリクエスト内の対応する増加なしに、ストレージ容量が異常に増加した場合、これは一般的に削除の問題により引き起こされています。 このような場合は、次の 2 つの要素をチェックします。

  • クライアントアプリケーションがストレージオブジェクトを定期的に削除し、領域を解放するために特定のプロセスを使用する場合: このリクエストの調査プロセスは次のとおりです。
    1. 削除リクエストが失敗すると、ストレージオブジェクトが予期したとおりに削除されない可能性があるため、有効リクエスト率が減少したかどうかを確認します。
    2. リクエストのエラータイプを調べて、有効リクエスト率が低下した具体的原因を見つけます。 その後、特定のクライアントログをまとめて、詳細なエラー情報を確認します (たとえば、ストレージスペースを解放するために使用される STS の一時的なトークンが期限切れになっている可能性があります)。
  • クライアントがストレージオブジェクトを削除するために LifeCycle を設定した場合: コンソールまたは API を使用して、現在のバケットの LifeCycle 値が以前と同じであることをチェックします。 以前と同じではない場合は、構成を変更し、ログ機能によって記録されたサーバーログを使用して、この値の以前の変更に関する情報を見つけます。 LifeCycle が正常であるものの非アクティブである場合は、チケットを起票し、サポートセンターへお問い合わせください。
その他の OSS の問題

トラブルシューティングのセクションで問題が解決されなかった場合は、次の方法のいずれかを使用し問題を診断してトラブルシューティングを行います。

  1. OSS モニタリングサービスを表示し、予想されるベースライン動作と比較して何らかの変更があったかどうかを確認します。 モニタービューを使用することで、この問題が一時的なものか持続的なものか、およびどのストレージ操作が影響を受けているのかを判別することができます。
  2. モニタリング情報は、ログ機能によって記録されたサーバーログデータを検索し、問題の開始時に発生した可能性のあるエラーに関する情報を検索するのに役立ちます。 モニタリング情報は、問題の発見と解決に役立つ可能性があります。
  3. サーバーログの情報が不十分な場合は、クライアントアプリケーションを調査するためにクライアントログを使用するか、または Wireshark などのネットワークツールを使用してネットワークに問題がないかをチェックします。