コネクタのトラブルシューティング

原因: データが存在しません

ソースには、コネクタのソース構成の問合せに一致するデータが含まれていません。

データがソースに存在するかどうかを確認するには、次のいずれかを実行します。

• コネクタのサービス・ログを取得します。(必要に応じて、最初にログを有効化します。)次に、コネクタが正常に実行されたことを示すログ・メッセージの例を示します(移動されたデータの量を含む)。

  Service connector run succeeded - <number> messages (<number> bytes) written to target

• ソース・ログの場合は、コネクタのソース構成からの問合せを使用してログを検索します。
• ソース・メトリックの場合は、メトリックを問い合せる。
• ソース・ストリームの場合は、ストリームのデフォルト・プロデューサ・メトリックを問い合せます。

原因: サービス・レベルのエラー

ソース・サービス、ターゲット・サービスまたはコネクタ・ハブ・サービスのエラーにより、データの移動が妨げられています。

サービス・レベルのエラーが存在するかどうかを確認するには、次のいずれかを実行します。

• コネクタのサービス・ログを取得します。(必要に応じて、最初にログを有効化します。)次に、サービス・レベルのエラーを示すログ・メッセージの例を示します。

  Connector run failed due to <type> error, Error Code : XXX <exception>

• コネクタの次のメトリック・チャートを表示します:
  • ソースでのエラー
  • ターゲットでのエラー
  • コネクタ・ハブのエラー

原因: 承認がありません

ターゲット・サービスへの書込み権限がありません。

認可がないかどうかを確認するには、コネクタのサービス・ログを取得します。(必要に応じて、最初にログを有効化します。)次に、認可がないことを示すログ・メッセージの例を示します:

Connector run failed due to <type> error, Error Code : 404 NotAuthorizedOrNotFound

他のユーザーがコネクタを非アクティブ化しました

コネクタは他のユーザーによって非アクティブ化されました:

• 組織内の別のユーザー
• Oracle Cloud Infrastructure

  特定の障害状態の場合、継続的に障害が発生するコネクタは、Oracle Cloud Infrastructureのサービス・チームによって自動的に非アクティブ化されます。このような長期連続障害は、コネクタのソースまたはターゲットの無効な構成を示す可能性があります。

原因: 特定の障害状態の場合、継続的に障害が発生するコネクタは、Oracle Cloud Infrastructureのサービス・チームによって自動的に非アクティブ化されます。このような長期連続障害は、コネクタのソースまたはターゲットの無効な構成を示す可能性があります。

原因: コネクタに一貫して障害が発生しています。

原因: 問合せが複雑すぎます

問合せに、基本モードでサポートされていない次の項目の1つ以上が含まれています。

• OR演算子(監査ログのみ使用時のタイプベース・フィルタを除く)
• 関数(例: isNull())
• select
• summarize

コネクタに関する問題の次のインジケータを確認します。

• 1つのコネクタに対するデータの最新性:データ移動の間に予想外な時間間隔があります。
  1. ナビゲーション・メニューを開き、「アナリティクスとAI」をクリックします「メッセージング」で、「コネクタ・ハブ」をクリックします。
  2. 「コンパートメント」を選択します。
  3. 必要なコネクタの名前をクリックします。
  4. 「リソース」で、「メトリック」をクリックします。
  5. 「データの最新性」メトリック・チャートを確認します。
• コネクタ全体でのデータの最新性:データ移動の間に予想外の間隔が空いていることを確認します。
  1. ナビゲーション・メニューを開き、「監視および管理」をクリックします。「モニタリング」で、「サービス・メトリック」をクリックします。
  2. データの鮮度を表示しようとするコネクタを含むコンパートメントを選択します。

  3. 「メトリック・ネームスペース」で、oci_service_connector_hubを選択します。

  4. 次のメトリック・チャートを確認します: 
     • データの鮮度

• ロギング・ソース: コネクタがログからデータを取得する場合、コネクタ当たりの最大時間当たりのデータ取得量(1 GB)を超えて試行している可能性があります。この問題が過去24時間(以前の転送の欠落データをコネクタが捕捉するための最大期間)にわたって継続している場合、ターゲットのログ・データは配信されません。この問題が発生しているかどうかを判断するには、アラームを作成して次のインジケータをモニターします。

  ノート
  
  MQLでアラーム問合せを編集するステップは、アラーム更新時のMQL式の編集を参照してください。

  インジケータ(メトリック	MQLのアラーム問合せ(コメントあり)
  12時間よりも古いデータ(データの最新性)	DataFreshness[1h].mean() > 43200000 コメント: 値43200000は、12時間のミリ秒数です。 ときどき失敗を無視します。アラーム・トリガー遅延を30分以上に設定することをお薦めします。この構成では、指定された期間に複数の連続する障害が発生した場合にのみ、アラームが警告します。
  ソースでのエラー(すべてのエラー)(ソースでのエラー)	ErrorsAtSource[15m].groupby(errorCode,connectorId).min() > 0 コメント: ときどき失敗を無視します。アラーム・トリガー遅延を30分以上に設定することをお薦めします。この構成では、指定された期間に複数の連続する障害が発生した場合にのみ、アラームが警告します。 結果は、エラー コードとコネクタ別にグループ化されます。
  ソースでの内部エラーで15分後に解決していない(5xx)(ソースでのエラー)	ErrorsAtSource[15m]{errorCode =~ "5*"}.groupby(connectorId).sum() > 0 && ErrorsAtSource[15m].groupby(connectorId).min() > 0 コメント: 内部エラーはソースでの問題を示している場合があり、このためにデータの配信が遅延することがあります。 アラームをトリガーする間隔を短縮するには、間隔([15m])を変更します。 ときどき失敗を無視します。アラーム・トリガー遅延を30分以上に設定することをお薦めします。この構成では、指定された期間に複数の連続する障害が発生した場合にのみ、アラームが警告します。
  ソースでのスロットル・エラー(ソースでのエラー)	ErrorsAtSource[15m]{errorCode = "429"}.groupby(connectorId).sum() >0 && ErrorsAtSource[15m].groupby(connectorId).min() > 0 コメント: スロットル・エラーの詳細は、関連するサービスの制限の説明を参照してください。 たとえば、ストリーミング・ソースに関連するスロットル・エラーは、ストリーミング・リソースの制限を参照してください。ストリーミング・ソースでスロットルは、コネクタがパーティションからストリームの読取りを試行し、同じパーティションへの他のコールも発生して、コール数がサービスの制限を超えると発生します。 ときどき失敗を無視します。アラーム・トリガー遅延を30分以上に設定することをお薦めします。この構成では、指定された期間に複数の連続する障害が発生した場合にのみ、アラームが警告します。
  ソースでのサービス通信エラー(-1)(ソースでのエラー)	ErrorsAtSource[15m]{errorCode = "-1"}.groupby(connectorId).sum() >0 && ErrorsAtSource[15m].groupby(connectorId).min() > 0
  ソースでの404エラー(ソースでのエラー)	ErrorsAtSource[15m]{errorCode = "404"}.groupby(connectorId).sum() >0 コメント: コネクタがログにアクセスできないか、存在しません。 指定されたログにアクセスするためのポリシーが存在することを確認します。ソース、タスクおよびターゲット・サービスへのアクセスを参照してください。 ロギングでログを検索して、指定されたログが存在することを確認します。 ときどき失敗を無視します。アラーム・トリガー遅延を30分以上に設定することをお薦めします。この構成では、指定された期間に複数の連続する障害が発生した場合にのみ、アラームが警告します。
  ゼロ(0)バイトの読取り(データがあるはずの場合) (ソースからの読取りバイト数)	BytesReadFromSource[15m].groupby(connectorId).sum() == 0 コメント: ソース、ターゲットまたはタスクでエラーが発生していない場合は、ログが存在する可能性があります。ロギングでログを検索して、指定されたログが存在することを確認します。 ときどき失敗を無視します。アラーム・トリガー遅延を30分以上に設定することをお薦めします。この構成では、指定された期間に複数の連続する障害が発生した場合にのみ、アラームが警告します。