すべてのプロダクト
Search
ドキュメントセンター

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

最終更新日:Dec 15, 2023

従来のアプリケーションと比較して、クラウドアプリケーションはインフラストラクチャへの投資とO&Mのコストが低くなります。ただし、クラウドアプリケーションの実行ステータスとパフォーマンスを監視し、障害を特定し、障害のトラブルシューティングを行うことはより困難です。 この問題を解決するために、Object Storage Service (OSS) は、アプリケーションのパフォーマンスを監視して障害を特定するための監視サービスとログ機能を提供しています。

このトピックでは、OSSを使用してビジネスのデータを保存するときに、OSSモニタリングサービス、ログ機能、およびサードパーティツールを使用して問題を監視、診断、およびトラブルシューティングする方法について説明します。 OSSモニタリングサービスは、次の目的を果たします。

  • OSSの実行ステータスとパフォーマンスをリアルタイムで監視し、アラート通知を送信します。

  • 問題を見つけるための効果的な方法とツールを提供します。

  • 関連ガイドに基づいて問題を解決します。

このトピックには、次のセクションが含まれます。

  • モニタリングサービス: OSSモニタリングサービスを使用して、OSSの実行状態とパフォーマンスをモニタリングする方法について説明します。

  • 追跡と診断: OSSモニタリングサービスとロギング機能を使用して障害を追跡および診断する方法について説明します。

  • トラブルシューティング: 一般的な問題とこれらの問題の解決策について説明します。

モニタリングサービス

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

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

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

      UserAbility

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

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

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

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

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

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

      count

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

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

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

      request

  • 要求ステータスの監視

    リクエストステータスの詳細は、さまざまなタイプのリクエストを監視し、リクエストステータスの分布に基づいて監視の詳細を提供します。 status

  • パフォーマンスの監視

    モニタリングサービスは、OSSのパフォーマンスのモニタリングに役立つ次のメトリックを提供します。

    • 平均E2Eレイテンシと平均サーバーレイテンシimage.pngを含む平均レイテンシ

      レイテンシメトリックは、API操作を呼び出すことによって生成されたタイプの要求を処理するために消費される平均時間と最大時間を示します。 E2Eレイテンシメトリックは、クライアントとサーバー間で要求を送信するために使用される時間を示します。これには、要求の処理、読み取り、および応答に使用される時間と、このプロセスでのネットワークレイテンシが含まれます。 サーバー待ち時間は、サーバー側で要求を処理するために使用される時間であり、サーバーとクライアント間の通信中のネットワーク待ち時間は含まれません。 したがって、E2Eレイテンシがジャンプし、サーバーのレイテンシが安定している場合、ネットワーク状態が悪いためにE2Eレイテンシが増加していると判断し、OSS障害の可能性を排除することが合理的です。

    • 最大E2Eレイテンシと最大サーバーレイテンシを含む最大レイテンシ

    • 成功したリクエストカテゴリ

    • ユーザー別のトラフィック

      ユーザー別トラフィック指標は、インターネット経由のリクエスト、内部ネットワーク経由のリクエスト、CDN (Content Delivery network) back-to-origin、およびCRR (cross-region replication) で使用されるトラフィックを示します。 モニタリングサービスは、ユーザーごとのトラフィックのメトリックとバケットごとのトラフィックのメトリックを提供します。

    OSSは、次のAPI操作を呼び出して送信されるリクエストの種類によって、トラフィックを除く前述のメトリックを監視します。

    • GetObject

    • HeadObject

    • PutObject

    • PostObject

    • AppendObject

    • UploadPart

    • UploadPartCopy

    さらに、成功したリクエストカテゴリには、次のAPI操作を呼び出して送信されたリクエストも含まれます。

    • DeleteObject

    • オブジェクトの削除

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

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

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

    OSSモニタリングサービスは、1時間ごとにバケットごとにモニタリングデータを収集します。 特定のバケットのグラフを表示して、バケットの連続データトレンドを取得できます。 監視グラフに基づいて、ビジネスのストレージ使用量の傾向と将来のストレージコストを予測できます。

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

    OSSの課金対象項目と課金方法の詳細については、「概要」をご参照ください。

    説明

    監視サービスによって提供される統計は、請求書の実際の使用とは異なる場合があります。 請求管理によって提供された請求書の実際の使用量に基づいて請求されます。

トラッキングと診断

  • 問題の診断

    • パフォーマンスの診断

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

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

    • エラー診断

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

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

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

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

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

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

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

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

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

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

  • E2E のトラッキングと診断

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

    OSSは、受信したすべてのリクエストに一意のリクエストIDを割り当てます。これは、リクエストに対して生成されたログを区別するための識別子として使用できます。 さらに、ログのタイムスタンプを使用すると、リクエストの処理中にクライアント、ネットワーク、およびアプリケーションサーバーで発生した他のイベントに関する情報を取得できます。 これは、障害の原因を分析して調査するのに役立ちます。

    • RequestID

      異なるログでは、リクエストのリクエストIDは異なるフィールドに含まれています。

      • OSSログでは、リクエストIDはリクエストIDフィールドにあります。

      • Wiresharkによってキャプチャされたデータフローなどのネットワークデータを追跡する場合、リクエストIDは標準のHTTPヘッダーx-oss-Request-idとしてレスポンスに含まれます。

      • クライアントアプリケーションでは、リクエストIDがクライアントのログに自動的に表示されます。これは、アプリケーションのコードを使用して実装されます。 OSS SDK for Javaの最新バージョンでは、レスポンスにリクエストのリクエストIDを表示できます。 getRequestIdメソッドを使用して、レスポンスからリクエストIDを取得できます。 さまざまなプログラミング言語向けのOSS SDKの各バージョンは、例外リクエストのリクエストIDの表示をサポートしています。 OSSException操作のgetRequestIdメソッドを呼び出すことで、リクエストのリクエストIDを取得できます。

    • ログのタイムスタンプを使用する

      ログのタイムスタンプを使用してログを照会できます。 イベントは、クライアント上およびアプリケーションサーバ上で異なる時点で発生し得ることに留意されたい。 したがって、イベントのOSSログとクライアントのログのタイムスタンプが異なる場合があります。 クライアントのログのタイムスタンプに基づいてサーバーのログを照会する場合は、タイムスタンプに15分を加算するか、15分を減算します。

トラブルシューティング

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

    • 高い平均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負荷分散の最適化、アップグレード、およびデータ移行によって引き起こされるサービスの利用不能を防ぐことができます。 さらに、ピーク時のビジネスのプレッシャーを減らすことができます。

    • 持続的な増加

      サーバーエラーが依然として高い場合は、テクニカルサポートに連絡して、クライアントログまたは失敗したリクエストのリクエストIDをOSSログに提供してください。

  • ネットワークエラー

    サーバがリクエストを処理している間に、クライアントまたはネットワークとの接続が切断され、サーバがリクエストに応答できない場合、ネットワークエラーが発生します。 この場合、リクエストに対してHTTPステータスコード499が記録されます。 ステータスコード499には、次の原因が考えられます。

    • サーバーがデータの読み取りと書き込みの要求を受信する前に、サーバーは接続が利用可能かどうかをチェックします。 そうでない場合、HTTPステータスコード499が要求に対して記録される。

    • HTTPステータスコード499は、サーバーが要求を処理しているが、クライアントが接続を無効にしている場合に、要求に対して記録されます。

    クライアントがリクエストをキャンセルするか、リクエストプロセス中に接続を失うと、ネットワークエラーが発生します。 クライアントがリクエストをキャンセルした場合は、アプリケーションのコードを確認し、クライアントが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エラーコードを参照し、アプリケーションのコードを変更してエラーを解決します。 詳細については、「エラー応答」をご参照ください。

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

    ストレージの使用量が劇的に増加した場合、原因はクリーニング操作の失敗である可能性があります。 次の面でトラブルシューティング:

    • クライアントアプリケーションが特定のプロセスを使用してストレージを解放するための定期的なクリーニング操作を実行する場合は、次の手順で原因を調べます。

      1. 失敗したクリーニング操作が有効なリクエストの割合を低下させるため、有効なリクエストの割合が減少するかどうかを確認します。

      2. 有効なリクエストの割合の減少の具体的な原因とエラーリクエストの種類を特定して特定します。 その後、クライアントログからエラーに関する詳細を取得できます。

    • クライアントアプリケーションは、ライフサイクルルールを設定してバケットストレージをクリアします。 ライフサイクルルールによってトリガーされるクリーニング操作では、OSSコンソールを使用するか、API操作を呼び出して、ライフサイクルルールが正しく設定されているかどうかを確認する必要があります。 そうでない場合は、OSSコンソールでライフサイクルルールを変更できます。 ライフサイクルルールが変更されたかどうかを確認するには、OSSログを照会します。 ライフサイクルルールが正しく設定されていても有効にならない場合は、OSSテクニカルサポートにお問い合わせください。

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

    このトピックのトラブルシューティングセクションでストレージサービスの問題が解決されない場合は、次の方法を使用して問題を診断およびトラブルシューティングします。

    1. Cloud MonitorコンソールでOSSのモニタリングサービスを表示し、メトリクスのベースラインが変更されているかどうかを確認します。 問題が一時的なものか永続的なものか、およびこの問題の影響を受けるストレージ操作を判断できます。

    2. OSSログを照会して、問題の特定と解決に役立つ可能性のあるモニタリング情報に基づいて、同時に発生したすべてのエラーを取得します。

    3. OSSサーバーのログがトラブルシューティングに十分な情報を提供できない場合は、クライアントログを使用してクライアントアプリケーションまたはWiresharkなどのネットワークツールを調査し、ネットワーク障害を調査します。