ロギング・ソースを使用したコネクタの作成

コネクタ・ハブにコネクタを作成して、ロギング・サービスからターゲット・サービスにログ・データを転送します。

ロギング・サービスの詳細は、ロギングを参照してください。

ロギング・ソースおよびオプションのタスクで定義されたコネクタは、すべてのターゲットをサポートします。コネクタ・ハブのワークフローの例は、コネクタ・ハブの概要を参照してください。ロギングをソースとして使用し、ファンクション・タスクを使用するコネクタの例は、シナリオ: Autonomous Databaseへのログ・データの送信を参照してください。

コネクタ・ハブロギング・ソースの保持期間は24時間です。配信の詳細は、配信の詳細を参照してください。

新しいコネクタの最初の実行に成功すると、コネクタの作成時間からログ・データが移動します。最初の実行が失敗した場合(ポリシーが欠落している場合など)、解決後、コネクタは、現在時刻の24時間前(いずれか遅い方)のコネクタ作成時間からログ・データを移動します。

後で実行するたびに、次のログ・データが移動します。後で実行が失敗し、24時間の保存期間内に解決された場合、コネクタは次のログ・データを移動します。後で実行が失敗し、解決が24時間の保存期間外に行われると、コネクタは最新のログ・データを移動し、失敗した実行と最新のログ・データの間に生成されたデータは配信されません。

ソース・ログをフィルタ処理するためにサポートされている問合せを確認するには、コネクタ・ハブのログ問合せリファレンスを参照してください。

    1. ナビゲーション・メニューを開き、「アナリティクスとAI」をクリックします「メッセージング」で、「コネクタ・ハブ」をクリックします。
    2. 「コネクタ」ページで、コンパートメントを選択します。
    3. 「コネクタの作成」をクリックします。
    4. 「コネクタの作成」ページで、新しいコネクタのわかりやすい名前とオプションの説明を入力します。機密情報を入力しないでください。
    5. 新しいコネクタを格納するコンパートメントを選択します。
    6. 「コネクタの構成」「ソース」で、「ロギング」を選択します。
    7. 「ターゲット」で、ログ・データの転送先のサービスを選択します:
      • ファンクション: ログ・データをファンクションに送信します。
      • ログ・アナリティクス: ログ・データをログ・グループに送信します。
      • モニタリング: ログ・データをメトリック・データ・ポイントにモニタリング・サービスに送信します。
      • 通知: ログ・データをトピックに送信します。
      • オブジェクト・ストレージ: ログ・データをバケットに送信します。
      • ストリーミング: ログ・データをストリームに送信します。
    8. (オプション)新しいコネクタのサービス・ログを有効にするには、「ログ」スイッチをクリックし、次の値を指定します:
      • ログ・カテゴリ: 値「コネクタ・トラッキング」が自動的に選択されます。
      • コンパートメント: コネクタのサービス・ログを格納するコンパートメントを選択します。
      • ログ・グループ: サービス・ログを格納するログ・グループを選択します。新しいログ・グループを作成するには、「新規グループの作成」をクリックし、名前を入力します。
      • ログ名: オプションで、ログの名前を入力します。
      • 拡張オプションの表示:
        • ログ保持: オプションで、サービス・ログを保持する期間を指定します(デフォルト: 30日)。
    9. 「ソース接続の構成」で、ソース・ログを選択します:
      • コンパートメント名: 必要なログを含むコンパートメント。
      • ログ・グループ: 必要なログを含むログ・グループ。

        ログ入力スキーマについては、LogEntryを参照してください。

      • ログ: 必要なログ。このフィールドに表示されるログをフィルタするには、次のステップを参照してください。
    10. (オプション)「ログ・フィルタ・タスク」で、選択したログ・グループおよびログをフィルタする値を入力します。

      監査ログ(_Audit)の属性値を指定するには:

      • フィルタ・タイプ: 「属性」を選択します。
      • 属性名: 必要な監査ログ属性を選択します。
      • 属性値: 選択した監査ログ属性の値を指定します。

      監査ログ(_Audit)のイベントを指定するには:

      • フィルタ・タイプ: 「イベント・タイプ」を選択します。
      • サービス名: 目的のイベントを含むサービスを選択します。
      • イベント・タイプ: 必要なイベントを選択します。

      サービス・ログまたはカスタム・ログ(_Audit)のプロパティ値を指定するには:

      • プロパティ: 目的のプロパティを選択します。
      • 演算子: プロパティ値のフィルタリングに使用する演算子を選択します。
      • : 必要なプロパティ値を指定します。

      ソース・ログをフィルタリングするためにサポートされている問合せを確認するには、コネクタ・ハブのログ問合せリファレンスを参照してください。

    11. (オプション)「ファンクション・タスクの構成」で、ファンクション・サービスを使用してソースからのデータを処理するファンクション・タスクを構成します:
      • タスクの選択: 「関数」を選択します。
      • コンパートメント: 必要なファンクションを含むコンパートメントを選択します。
      • ファンクション・アプリケーション: 必要なファンクションが含まれるファンクション・アプリケーションの名前を選択します。
      • ファンクション: ソースから取得したデータの処理に使用するファンクションの名前を選択します。

        タスクとしてコネクタによって使用される場合は、次のいずれかのレスポンスを返すようにファンクションを構成する必要があります:

        • JSONエントリのリスト(レスポンス・ヘッダーContent-Type=application/jsonを設定する必要があります)
        • 単一のJSONエントリ(レスポンス・ヘッダーContent-Type=application/jsonを設定する必要があります)
        • 単一のバイナリ・オブジェクト(レスポンス・ヘッダーContent-Type=application/octet-streamを設定する必要があります)
      • 追加オプションの表示: このリンクをクリックして、関数に送信されるデータのバッチごとに制限を指定します。手動設定を使用する場合は、バッチ・サイズ制限(KB)およびバッチ時間制限(秒)の値を指定します。

      ファンクション・タスクの考慮事項:

      • コネクタ・ハブは、ファンクション・タスクの出力を解析しません。ファンクション・タスクの出力は、そのままターゲットに書き込まれます。たとえば、ファンクション・タスクで通知ターゲットを使用する場合、すべてのメッセージはRAW JSON BLOBとして送信されます。
      • ファンクションは、1回の呼出しで6MBのデータと同期するように呼び出されます。データが6MBを超えると、コネクタが再びファンクションを呼び出して制限を超えるデータを移動します。このような呼出しは順次処理されます。
      • ファンクションは最大5分間実行できます。
      • 関数タスクはスカラー関数に制限されます。
    12. ターゲットとして「ファンクション」を選択した場合は、「ターゲットの構成」で、ログ・データの送信先となるファンクションを構成します。ステップ17にスキップします。
      • コンパートメント: 必要なファンクションを含むコンパートメントを選択します。
      • ファンクション・アプリケーション: 必要なファンクションを含むファンクション・アプリケーションの名前を選択します。
      • ファンクション: データの送信先のファンクションの名前を選択します。
      • 追加オプションの表示: このリンクをクリックして、ファンクションに送信されるデータのバッチごとに制限を指定します。手動設定を使用する場合は、バッチ・サイズ制限(KBまたはメッセージ数)およびバッチ時間制限(秒)の値を指定します。

        たとえば、5,000KBまたは10メッセージを選択して、バッチ・サイズを制限します。バッチ時間制限の例は5秒です。

      ファンクション・ターゲットに関する考慮事項:

      • コネクタはソース・データをJSONリストとしてバッチでフラッシュします。最大バッチ(ペイロード)サイズは6MBです。
      • ファンクションは、1回の呼出しで6MBのデータと同期するように呼び出されます。データが6MBを超えると、コネクタが再びファンクションを呼び出して制限を超えるデータを移動します。このような呼出しは順次処理されます。
      • ファンクションは最大5分間実行できます。
      • ファンクション・ターゲットからコネクタにデータを返しないでください。コネクタ・ハブは、ファンクション・ターゲットから返されたデータを読み取りません。
    13. ターゲットとして「ログ・アナリティクス」を選択した場合は、「ターゲットの構成」で、ログ・データを送信するログ・グループを構成します。ステップ17にスキップします。
      • コンパートメント: 必要なログ・グループを含むコンパートメントを選択します。
      • ログ・グループ: 必要なログ・グループを選択します。
    14. ターゲットとして「モニタリング」を選択した場合は、「ターゲットの構成」で、ログ・データを送信するメトリックを構成します。ステップ17にスキップします。
      • コンパートメント: 必要なメトリックを含むコンパートメントを選択します。
      • メトリック・ネームスペース: 必要なメトリックが含まれるメトリック・ネームスペースを選択します。既存のネームスペースを選択するか、新しいネームスペースを入力できます。

        新しいネームスペースを入力したら、[Enter]を押して送信します。

        新しいメトリック・ネームスペースの場合は、予約済oci_接頭辞を使用しないでください。予約済プリフィクスが使用されると、メトリックが取得されません。カスタム・メトリックの公開およびPostMetricDataリファレンス(API)を参照してください。

      • メトリック: データの送信先のメトリックの名前を選択します。既存のメトリックを選択するか、新しいメトリックを入力できます。

        新しいメトリック名を入力したら、[Enter]を押して送信します。

        新しいメトリックの場合は、予約済oci_接頭辞を使用しないでください。予約済プリフィクスが使用されると、メトリックが取得されません。カスタム・メトリックの公開およびPostMetricDataリファレンス(API)を参照してください。

      • ディメンションの追加: オプションで、このボタンをクリックしてディメンションを構成します。「ディメンションの追加」パネルが開きます。

        ログ・データの最新の6行が、「ソースの構成」で指定されたログから取得されます。

        データの送信先ディメンションごとに、名前と値のキー・ペアを指定します。名前はカスタムにすることができます。また、値は静的にするか評価対象のパスにすることができます。ディメンションを使用して、ログ・データがメトリックに移動された後にデータをフィルタ処理します。ディメンションのユースケースの例は、シナリオ: モニタリング・ターゲットのディメンションの作成を参照してください。

        データ(パス値)を抽出するには
        1. 「パスの選択」で、目的のログの下矢印をクリックします。

          拡張ログのパスがリストされます。

        2. 必要なパスのチェック・ボックスを選択します。

          次の図は、選択したパス(bucketName)および選択していないパス(eTag)の例を示しています。

          選択したパスと選択していないパス

          「パスの編集」では、「ディメンション名」および「値」フィールドは、選択したパスから自動的に移入されます。

          使用可能なログ・データがない場合は、「パスの編集」にカスタム・ディメンション名のパス値を手動で入力できます。パスはlogContentから開始し、ドット(.)またはインデックス([])表記のいずれかを使用する必要があります。ドットとインデックスはサポートされている唯一のJMESPathセレクタです。たとえば、次のとおりです。
          • logContent.data (ドット表記法)
          • logContent.data[0].content (インデックス表記法)

          有効なパス表記法の詳細は、JmesPathDimensionValueを参照してください。

        3. オプションで、ディメンション名を編集します。

        データにタグ付けするには(静的値)

        • 「静的値」で、「+別の静的値」をクリックし、ディメンション名と値を入力します。たとえば、trafficおよびcustomerと入力します。

      ノート

      新規(カスタム)メトリックの場合、指定したメトリック・ネームスペースおよびメトリックは、コネクタがソースからモニタリング・サービスにデータを初めて移動したときに作成されます。移動されたデータの存在を確認するには、コンソール、CLIまたはAPIを使用して新しいメトリックを問い合せます。カスタム・メトリックの問合せの作成を参照してください。

      メトリックに含まれる内容

      「ディメンションの構成」で指定したディメンションの名前と値のキー・ペアに加え、次のディメンションがメトリックに含まれます:
      • connectorId: メトリックが適用されるコネクタのOCID。
      • connectorName: メトリックが適用されるコネクタの名前。
      • connectorSourceType: メトリックが適用されるソース・サービス。

      各メトリック・データ・ポイントのタイムスタンプは、対応するログ・メッセージのタイムスタンプです。

    15. ターゲットとして「通知」を選択した場合は、「ターゲットの構成」で、ログ・データの送信先となるトピックを構成します。ステップ17にスキップします。
      • コンパートメント: 目的のトピックを含むコンパートメントを選択します。
      • トピック: データの送信先のトピックの名前を選択します。
      • メッセージ形式: 必要なオプションを選択します:
        ノート

        「メッセージの書式」オプションは、ロギング・ソースのコネクタでのみ使用できます。これらのオプションは、ファンクション・タスクのあるコネクタでは使用できません。「メッセージ書式」オプションが使用できない場合、メッセージはRAW JSON BLOBとして送信されます。
        • フォーマットされたメッセージの送信: 簡単でわかりやすいレイアウト。

          フォーマットされたメッセージに対してサポートされているサブスクリプション・プロトコルとメッセージ・タイプを確認するには、わかりやすいフォーマットを参照してください。

        • RAWメッセージの送信: RAW JSON BLOB。

      通知ターゲットに関する考慮事項:

      • 通知ターゲットの最大メッセージ・サイズは128KBです。最大サイズを超えるメッセージは削除されます。
      • SMSメッセージでは、特定のコネクタ構成の場合に予期しない結果が生成されます。この問題は、指定されたコネクタ構成でSMSサブスクリプションを含むトピックに限定されます。詳細は、1つの通知に対する複数のSMSメッセージを参照してください。
    16. ターゲットとして「オブジェクト・ストレージ」を選択した場合は、「ターゲットの構成」で、ログ・データの送信先となるバケットを構成します。ステップ17にスキップします。
      • コンパートメント: 目的のバケットを含むコンパートメントを選択します。
      • バケット: データの送信先のバケットの名前を選択します。
      • オブジェクト名の接頭辞: オプションで、接頭辞値を入力します。
      • 追加オプションの表示: このリンクをクリックし、オプションでバッチ・サイズ(MB)およびバッチ時間(ミリ秒)の値を入力します。

      オブジェクト・ストレージ・ターゲットに関する考慮事項:

      • バッチ・ロールオーバーの詳細:

        • バッチ・ロールオーバー・サイズ: 100MB
        • バッチ・ロールオーバー時間: 7分
      • オブジェクト・ストレージに保存されるファイルは、gzipを使用して圧縮されます。

    17. ターゲットとして「ストリーミング」を選択した場合は、「ターゲットの構成」で、ログ・データの送信先となるストリームを構成します。
      • コンパートメント: 必要なストリームを含むコンパートメントを選択します。
      • ストリーム: データの送信先のストリームの名前を選択します。

      プライベート・エンドポイント構成はサポートされていません。ストリーム・プール構成の詳細は、ストリーム・プールの作成を参照してください。

    18. デフォルト・ポリシーを受け入れるには、各デフォルト・ポリシーに用意されている「作成」リンクをクリックします。

      デフォルト・ポリシーは、このコネクタがソース、タスクおよびターゲット・サービスにアクセスするために必要な認可のために提供されます。

      この認可は、このようなデフォルト・ポリシーまたはグループベースのポリシーから取得できます。デフォルト・ポリシーは、コンソールを使用してコネクタを作成または編集する際に必ず提供されます。唯一の例外は、一致するポリシーがIAMにすでに存在する場合です。この場合、デフォルト・ポリシーは提供されません。この認可要件の詳細は、認証と認可を参照してください。

      • デフォルト・ポリシーを受け入れる権限がない場合は、管理者に連絡してください。
      • 自動的に作成されたポリシーは、コネクタが削除されてもそのままです。ベスト・プラクティスとしては、コネクタを削除するときに関連するポリシーを削除してください。

      新しく作成したポリシーを確認するには、関連するビュー・リンクをクリックします。

    19. (オプション)コネクタにタグを割り当てます。「拡張オプションの表示」をクリックし、タグ付けフィールドの値を指定します。
      • タグ・ネームスペース: 定義済タグを追加するには、既存のネームスペースを選択します。free-fromタグを追加する場合は、空白のままにします。
      • タグ・キー: 定義済タグを追加するには、既存のタグ・キーを選択します。フリーフォーム・タグを追加するには、必要なキー名を入力します。
      • タグ値: 必要なタグ値を入力します。
      • タグの追加: クリックして別のタグを追加します。
    20. 「作成」をクリックします。
  • oci sch service-connector createコマンドおよび必須パラメータを使用して、ロギング・ソースでコネクタを作成します:

    oci sch service-connector create --display-name "<display_name>" --compartment-id <compartment_OCID> --source [<logging_source_in_JSON>] --target [<target_in_JSON>]

    CLIコマンドのパラメータおよび値の完全なリストは、CLIコマンド・リファレンスを参照してください。

  • CreateServiceConnector操作を実行してコネクタを作成します。

    ロギング・ソースを使用してコネクタを作成するには、リクエスト(CreateServiceConnectorDetails)のsourceにロギングの詳細を移入します。例については、LoggingSourceDetailsを参照してください。

新規コネクタによるデータの移動の確認

コネクタを作成したら、データが移動していることを確認します。

  • コネクタでデータ・フローの詳細を取得するためのログの有効化
  • ターゲット・サービスで予想される結果を確認します。

データが移動されていることを確認すると、自動非アクティブ化を回避できます。これは、コネクタに長時間障害が発生した場合に発生します。