Content last updated 2025-05-09

CustomersDot で購入時に発生するエラーのトラブルシューティング

CustomersDot 上のエラーに関するトラブルシューティングガイド

概要

このガイドは CustomersDot で発生するエラーをトラブルシューティングするためのものです。

住所またはクレジットカードに関するエラー

CustomersDot からサブスクリプションを購入する際、住所やクレジットカードに関するエラーをユーザーが受け取った場合は、CustomersDot の My Account セクションに記載されている住所を確認してください。これは通常、住所の不備(市区町村、都道府県、郵便番号)が原因です。住所が正しくてもエラーが続く場合は、Sentry で関連するエラーを確認し、必要に応じて CustomersDot トラッカー に Issue を起票してください。

3D Secure 認証 3DS

Transaction declined.generic_decline - Your card was declined

GitLab の Zuora との購入連携は、すべての取引で 3DS 認証を必須とする 支払い方法の認可をサポートしていません。

現時点での代替策として、ユーザーに別のカードを使うよう依頼します。さらに、セールスに連絡 して、ユーザーに 請求書による支払い を提案できます。

card_error/authentication_required/authentication_required

GitLab の Zuora との購入連携は、すべての取引で 3DS 認証を必須とする 支払い方法の認可をサポートしていません。そのような取引は、カード追加後に失敗します。

現時点での代替策として、ユーザーに別のカードを使うよう依頼します。さらに、セールスに連絡 して、ユーザーに代替の支払い方法を提案できます。

invalid_request_error/setup_intent_authentication_failure

3DS 認証が失敗しました。

最初のオプションは、ユーザーに再試行するよう、または別のカードで試すよう依頼することです。 セールスに連絡 して、ユーザーに代替の支払い方法を提案することもできます。

インドで発行されたカード

Transaction declined.402 - [card_error/card_declined/transaction_not_allowed] Your card does not support this type of purchase.

顧客に トラブルシューティングページ を案内してリセラーから購入してもらうか、セールスに連絡 して 請求書による支払い を提案してください。

Sentry からのエラーメッセージを取得する

Sentry で特定の顧客に関連するエラーを見つけるには、次の手順を試してください:

  1. CustomersDot から顧客 ID を取得する:
    • https://customers.gitlab.com/admin にログインします
    • 左パネルの Customers をクリックして Customers 検索ページに移動します
    • 顧客を次のいずれかで検索します: メール、ドメイン、または名前 / 姓(顧客が異なるメールで登録した場合)
    • 結果のうち、情報、鉛筆、または人物のアイコンのいずれかをクリックします
    • URL から顧客 ID を取得します: https://customers.gitlab.com/admin/customer/customerID/pagepath
  2. Sentry で顧客のエラーメッセージを見つける:
    • https://new-sentry.gitlab.net/organizations/gitlab/issues/?project=8 に移動します
    • user.id:customerID を使います(customerID は CustomersDot から取得した実際の customerID に置き換えます)
    • Sentry の Issue を開く → All Events をクリックします
    • 再度 user.id:customerID で特定のユーザーをフィルタします
    • 任意のイベントをクリックすると、エラーメッセージの詳細が表示されます
    • 顧客のメールアドレスを使って user.email:customerFullEmail で同じ検索を繰り返すこともできます

CustomersDot Kibana ログからエラーメッセージを取得する

Kibanaprdsub* または stgsub* でフィルタすることで、それぞれ CustomersDot の本番ログまたはステージングログにアクセスできます。

Kibana の使い方や検索方法のアイデアを得るには、サポートワークフローの Kibana ページを確認してください。

CustomersDot で行われた購入の試行については、Kibana の CustomersDot 購入エラー のヒントを参照してください。

GCP Logs Explorer からエラーメッセージを取得する

Logs Explorer の Google 公式ドキュメントは https://cloud.google.com/logging/docs/view/logs-explorer-interface にあります。より高度な検索のためのクエリ構築の理解を深めるために、これらのドキュメントを確認すると役立ちます。

GCP Logs Explorer ダッシュボード にログインします(gitlab-subscriptions-prod を表示していることを確認してください)。

  1. Resource Type で VM Instance を選択します
    • 必要に応じて、LOG NAME から特定のログファイルを選んでクエリの範囲を絞れます
    • 既定では、ログは 1 時間に制限されています。Kibana の検索と同様に、検索ボックスの左側に表示される Duration をクリックすることで時間枠を広げられます
  2. 多くの場合、特定のクエリを構築することなく、顧客 ID やサブスクリプション名を検索するだけで必要な情報を見つけられます。

高度な検索のヒント

ログクエリ言語では、ログ自体から動的に構築されたきめ細かい属性で検索できます。たとえば、探している重要情報のほとんどは、任意のログエントリの jsonPayload オブジェクトにスコープされています。CustomersDot のコード内でこれらのオブジェクトがどう表現されているかを理解しておくと、構築するクエリの種類を予測しやすくなります。ただし、欲しい情報のほとんどはクエリを構築しなくてもかなり簡単に見つけられます。

  1. 検索ボックスの右側に「Show Query」のトグルスイッチがあります。これを ON にします。
  2. Query Builder では、検索可能な属性を候補として表示します。たとえば jsonPayload と入力すると、検索可能な属性候補のポップアップが表示されます。
  3. クエリ条件を更新したら、右側の Run Query をクリックします。
  4. たとえば、特定の顧客のイベントを見つけるクエリを構築するには:
    • 顧客 ID を取得し、Query フィールドに入力します
    • jsonPayload.customer_id="customerID"
  5. サブスクリプションでも同じことができますが、エラーの場合は order_params 属性にスコープされている可能性があります:
    • jsonPayload.order_params.subscription_name="A-S00000000"
    • エラー以外の場合は jsonPayload.subscription_name="A-S00000000"
  6. 指定された名前空間のエラーを見つける
    • jsonPayload.order_params.gl_namespace_id="xxxxxxxx"

Log Fields パネルでは、特定のログファイルや、InfoError などの重要度ラベルを選択することもできます。これらをクエリビルダーに含めることもできます:

  1. severity=ERROR はエラーのみを返します。
  2. severity=INFO はエラー以外のみを返します。

CustomerDot からのメール配信のトラブルシューティング

ときどき、顧客がパスワードリセットリクエストや新規アカウント確認メールなど、ポータルからのメールを受け取らなかったと報告します。GitLab は送信メール用のサービスとして Mailgun を使っています。Mailgun にログインしてメッセージログを表示し、必要に応じてサプレッションを削除できます。

サポートがこのプロセスで使用する一般的なワークフローは、サポートハンドブックの確認メール ページに記載されており、そのページに Mailgun ダッシュボードのナビゲートとログ検索の詳細な説明があります。

ここでのプロセスはほぼ同じですが、CustomerDot からのメールを調査するため、一般的なワークフローのステップ 4 では検索対象ドメインとして customers.gitlab.com を選択していることを確認してください。

顧客が customers.gitlab.com にアクセスできるかを確認するには、顧客レコードの Edit ページ(顧客レコード右側のペンアイコン)に移動し、Login activated チェックボックスを確認します。チェックされていれば顧客はアクセスできます。チェックされていなければ顧客はアクセスできず、パスワードリセットメールも受け取れません。

リセラーの顧客は、リセラーまたは GitLab セールスチーム経由で購入する必要がある点に注意してください。

過去のチケット例

  1. 期限切れのサブスクリプションのために新しいサブスクリプションを購入できない顧客:
  2. AddressCityPostal code に無効な情報があるために購入できない顧客:
  3. CustomersDot で State が提供されていないために compute 分数を購入できない顧客: