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

全体の健全性をモニタリング

• 可用性と有効リクエストレート

  可用性と有効リクエストレートは、システムの安定性とユーザーのアクティビティを測定します。100 % を下回る場合は、失敗したリクエストが発生していることを示します。

  パーティション移行などのシステム最適化中に、一時的に 100 % を下回ることがあります。このような一時的な障害は、OSS SDK のリトライ機構によって自動的に処理されます。

  レートが 100 % を下回った場合は、リクエストディストリビューション統計またはリクエスト状態の詳細を確認して、エラーの種類と原因を特定してください。

  一部のシナリオでは、レートが 100 % を下回ることが想定されます。たとえば、オブジェクトの存在確認時にオブジェクトが見つからない場合、404 エラーが返されます。

  しきい値を下回った際に通知をトリガーするよう、アラートルールを設定してください。

• 総リクエスト数と有効リクエスト数

  このメトリックは、アクセス総量を通じてシステムの状態を反映します。有効リクエスト数と総リクエスト数に不一致がある場合は、失敗が発生していることを示します。

  リクエスト数の変動、特に急激な増加や減少をモニターしてください。アラートサービスユーザーガイドでアラートルールを設定し、タイムリーに通知を受け取るようにしてください。

• リクエスト状態ディストリビューション統計

  可用性または有効リクエストレートが 100 % を下回っている場合（または有効リクエスト数が総リクエスト数と一致しない場合）、リクエスト状態ディストリビューションを確認してエラーの種類を特定してください。OSS 監視メトリクスリファレンス。

リクエスト状態の詳細モニタリング

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

遅延時間の急上昇やベースラインからの持続的な逸脱など、パフォーマンスメトリクスの急激な変化に注意してください。メトリクスがしきい値を超えた際に担当者に通知するよう、アラートルールを設定してください。

メータリングの監視

現在、OSS モニタリングは、バケットサイズ、パブリックアウトバウンドトラフィック、Put 系リクエスト、Get 系リクエストのメータリングをサポートしています。クロスリージョンレプリケーションのアウトバウンドトラフィック、CDN アウトバウンドトラフィック、アラートルール、OpenAPI によるメータリングデータ取得はサポートされていません。

OSS はユーザーおよびバケット単位で月次リソース消費量の統計も提供しており、これは 1 時間ごとに更新されます。

問題の診断

• パフォーマンスの診断

  ビジネスシナリオに応じたパフォーマンスベースラインを確立してください。パフォーマンスの問題は、OSS サービスの負荷、クライアントの TCP 設定、またはネットワークボトルネックに起因する可能性があります。監視メトリクスを使用して根本原因を特定し、その後ログを確認して詳細を調査してください。

  まとめると、ベースラインを設定し、監視メトリクスを使用して原因を絞り込み、その後ログを確認して詳細を調べます。

• エラーの診断

  リクエストが失敗すると、クライアントはエラーメッセージを受信し、モニタリングサービスはエラーの種類を記録します。詳細を確認するために、サーバー側、クライアント側、およびネットワークログをチェックしてください。HTTP ステータスコードおよび OSS エラーコードは、失敗の理由を示します。

  エラー応答の詳細は、OSS エラー応答に記載されています。

• ログ機能の使用

  OSS は、詳細なリクエストログを記録するためのサーバー側ログ機能を提供します。

  この機能を有効にするには、ログの構成およびアクセスログの構成をご参照ください。

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

  サーバー側ログに十分な詳細がない場合は、ネットワークログツールを使用してクライアントとサーバー間のトラフィックをキャプチャしてください。Simple Log Service を使用して調査することもできます。Wireshark は、パケットレベルのプロトコルデータを表示するための一般的なツールです。Wireshark のインストール。Wireshark の使用。

E2E 追跡と診断

クライアント、ネットワーク、およびサーバー側のログを相関付けて根本原因を特定します。OSS は各リクエストに一意の RequestID を割り当て、ログの相関付けを可能にします。タイムスタンプを使用してログの範囲を絞り込み、関連イベントを特定してください。

一般的なパフォーマンスの問題

• 平均エンドツーエンド (E2E) 遅延時間が高く、平均サーバー遅延時間が低い

  考えられる原因は以下のとおりです。

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

    • 利用可能な接続数またはスレッド数が制限されている

      • 関連コマンドを使用してシステムの接続状態を確認し、カーネルパラメータを調整できます。

      • クライアント側のリソースボトルネックを確認し、必要に応じて並行スレッド数を増やしたり、クライアントコードを最適化したりできます。

    • CPU、メモリ、ネットワーク帯域幅などのリソースが不足している

      リソースモニタリングツールを使用してリソースボトルネックを確認できます。また、コードを最適化するか、リソースをスケールアウトすることも可能です。

  • ネットワークの問題

    Wireshark を使用してネットワークの問題を調査できます。

• 平均 E2E 遅延時間および平均サーバー遅延時間が低くても、クライアントリクエストの遅延時間が高い

  クライアント側の遅延時間が高くなるのは、通常、リクエストがサーバーに到達する前に遅延が発生していることを示します。リクエストが遅延する原因を調査してください。

  考えられる原因：

  • 利用可能な接続数またはスレッド数が制限されている

    • システムの接続状態を確認し、カーネルパラメータを調整できます。

    • クライアント側のリソースボトルネックを確認し、必要に応じて並行スレッド数を増やしたり、クライアントコードを最適化したりできます。

  • クライアントリクエストが複数回リトライされている

    クライアントログを確認してリトライの原因を調査できます。また、Wireshark を使用してネットワークの問題を調査することも可能です。

    • クライアントログを確認してください。詳細ログにはリトライが発生したかどうかが記録されています。たとえば、OSS Java SDK では、WARN または INFO レベルで以下のログメッセージを検索できます。これらのログが存在する場合、リトライが発生している可能性があります。

      [Server]Unable to execute HTTP request:
        or
        [Client]Unable to execute HTTP request:

    • クライアントのログレベルが DEBUG に設定されている場合、OSS Java SDK で以下のログメッセージを検索できます。このログメッセージが存在する場合、リトライが発生しています。

      Retrying on

• 平均サーバー遅延時間が高い

  アップロードまたはダウンロード時のサーバー遅延時間が高くなる原因として、以下が考えられます。

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

    サーバー側ログを確認し、CDN を有効にするか、アクセス権限を調整することを検討してください。

  • 内部システム要因

    クライアントログを提供し、テクニカルサポートまでご連絡ください。

サーバー側エラー

ネットワークエラー

クライアントが接続を積極的に閉じている場合は、クライアント側のコードを調査してください。ネットワーク接続が失われている場合は、Wireshark を使用して接続性の問題を診断してください。

クライアント側エラー

• クライアントの権限付与エラーのリクエストが増加している

  403 エラーが増加する主な原因：

  • バケットドメイン名が正しくない

    • 第 3 レベルまたは第 2 レベルドメイン名を直接使用してバケットにアクセスしている場合、そのドメイン名で示されるリージョンにバケットが存在していない可能性があります。たとえば、中国 (杭州) リージョンにあるバケットに Bucket.oss-cn-shanghai.aliyuncs.com を通じてアクセスしようとした場合です。バケットのリージョンを確認し、ドメイン名を修正してください。

    • CDN アクセラレーションが有効になっている場合は、CDN オリジンドメインがバケットの第 3 レベルドメイン名と一致していることを確認してください。

    • JavaScript クライアントから 403 エラーが発生する場合は、通常 CORS 構成の問題を示します。バケットの CORS 設定を確認し、必要に応じて修正してください。クロスオリジンリソース共有。

  • アクセスの制御に関する問題

    • プライマリ AccessKey を使用している場合は、正しく構成されており有効であることを確認してください。

    • RAM ユーザーを使用してアクセスしている場合は、正しい AccessKey が使用されており、必要な操作に対する権限がユーザーに付与されていることを確認してください。

    • STS 一時トークンを使用してアクセスしている場合は、トークンの有効期限が切れていないことを確認してください。必要に応じて新しいトークンを要求してください。

    • アクセスの制御が構成されている場合は、対象のバケットまたはオブジェクトに対する必要な権限が付与されていることを確認してください。

  • URL の有効期限切れ

    署名付き URL によるアクセスの場合、突然 403 エラーが発生するのは、通常 URL の有効期限が切れているためです。

  • OSS 開発者ツール (ossftp、ossbrowser、OSS コンソールクライアント) は、RAM ユーザーに対して 403 エラーを返すことがあります。AccessKey が正しいこと、および RAM ユーザーに GetService などの必要な権限が付与されていることを確認してください。

• クライアントの「リソースが見つかりません」エラーのリクエストが増加している

  404 エラーは、要求されたリソースが存在しないことを示します。404 エラーが増加する主な原因：

  • オブジェクトの存在確認を行うアプリケーションロジック（たとえば、Java SDK の doesObjectExist）は、オブジェクトが見つからない場合に `false` を返しますが、サーバー側では 404 リクエストが生成されます。これは期待される動作です。

  • オブジェクトがクライアントまたは他のプロセスによって削除されました。サーバー側ログを確認し、オブジェクトに対する削除操作を確認してください。

  • ネットワークパケット損失によりリトライがトリガーされた。たとえば、削除成功の応答が失われ、クライアントがリトライして 404 エラーを受け取る場合があります。ネットワークに起因する 404 エラーを特定するには、クライアントおよびサーバーログの両方を確認してください。

    • クライアントアプリケーションログでリトライリクエストを確認してください。

    • サーバー側ログを確認し、オブジェクトに対して 2 回の削除操作が存在し、最初の削除操作が 2xx 範囲の HTTP ステータスコードを返しているかどうかを確認してください。

• 有効リクエストレートが低く、その他のクライアントエラーのリクエスト数が多い

  有効リクエストレートは、2xx/3xx 応答数を総リクエスト数で割った比率です。「その他のクライアントエラー」には、5xx (サーバー)、499 (ネットワーク)、403 (権限付与)、404 (見つかりません)、および OSS エラーコード RequestTimeout を伴う 408 または 400 (タイムアウト) エラーは含まれません。

  サーバー側ログを確認してエラーの種類を特定し、その後OSS エラー応答を使用して原因を特定し、問題を解決してください。

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

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