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

全体的な正常性のモニタリング

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

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

  パーティション移行などのシステム最適化の実施中は、率が一時的に 100% を下回る場合があります。OSS SDK のリトライメカニズムは、こうした断続的な失敗を自動的に処理します。

  率が 100% を下回る場合は、リクエスト分布統計またはリクエストステータスの詳細を確認して、エラーの種類と原因を特定してください。

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

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

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

  このメトリックは、合計アクセス量でシステムの状態を示します。有効リクエスト数と合計リクエスト数が一致しない場合、失敗が発生していることを示します。

  リクエスト数の変動、特に急増や急減に注意してください。速やかに通知を受け取るには、Alert service user guide でアラートルールを設定してください。

• リクエストステータス分布統計

  可用性または有効リクエスト率が 100% を下回る場合 (または有効リクエスト数が合計リクエスト数と一致しない場合) は、リクエストステータスの分布を表示してエラーの種類を確認するには、OSS monitoring metrics reference をご参照ください。

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

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

レイテンシーの急増やベースラインからの継続的な乖離など、パフォーマンスメトリックの急激な変化に注意してください。メトリックがしきい値を超えた場合に担当者へ通知するよう、アラートルールを設定してください。

使用量のモニタリング

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

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

問題の診断

• パフォーマンスの診断

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

  要約：ベースラインを設定し、モニタリングメトリックで原因を絞り込み、ログで詳細を確認します。

• エラーの診断

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

  エラーレスポンスの詳細については、OSS error responses に記載されています。

• ロギング機能の使用

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

  この機能を有効にするには、Configure logging および Configure access logging に従ってください。

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

  サーバー側ログの情報が不足している場合は、ネットワークロギングツールを使用してクライアントとサーバー間のトラフィックをキャプチャします。Simple Log Service を使用して調査することもできます。Wireshark は、パケットレベルのプロトコルデータを表示するための一般的なツールです。Wireshark のインストールと使用方法については、Install Wireshark および Use 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 設定を確認し、必要に応じて修正してください。オリジン間リソース共有 (CORS)。

  • アクセス制御の問題

    • プライマリ AccessKey を使用する場合は、正しく設定されており有効かを確認してください。

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

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

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

  • URL の有効期限切れ

    署名付き URL アクセスの場合、403 エラーが突然発生するのは、通常 URL の有効期限が切れていることを意味します。

  • OSS 開発者ツール (OSS FTP、ossbrowser、OSS console client) では、RAM ユーザーに対して 403 エラーが返される場合があります。AccessKey が正しいこと、また RAM ユーザーが GetService などの必要な権限を持っていることを確認してください。

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

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

  • オブジェクトの存在を確認するアプリケーションロジック (たとえば Java SDK の doesObjectExist) は、オブジェクトが見つからない場合に false を返しますが、サーバーは 404 リクエストを生成します。これは想定どおりの動作です。

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

  • ネットワークパケット損失によってリトライが発生します。たとえば、削除の成功レスポンスが失われたためにクライアントがリトライし、404 エラーを受信する場合があります。クライアントとサーバーの両方のログを確認して、ネットワーク起因の 404 エラーを特定してください：

    • クライアントアプリケーションログでリトライリクエストを確認します。

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

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

  有効リクエスト率は、合計リクエスト数に対する 2xx/3xx レスポンスの比率です。「その他のクライアントエラー」には、5xx (サーバー)、499 (ネットワーク)、403 (認可)、404 (見つかりません)、や 408 または OSS エラーコード RequestTimeout (タイムアウト) を伴う 400 のエラーは含まれません。

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

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

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