置き換えられた名前空間

スタック・モニタリングでは、次のOCIメトリック・ネームスペースがサポートされます:

UIを使用したOCIリソースのインポート

OCIリソースをインポートするには、次のステップに従います:

1. 「スタック・モニタリング」で、「リソースのインポート」ページに移動し、「リソースのインポート」をクリックします。

2. ソースとして「OCIネイティブ・サービス」を選択します。

OCIサービス・インポート入力

UI作業要求のインポート

コマンドラインを使用したOCIリソースのインポート

OCIネイティブ・リソースをスタック監視にインポートするには、import-telemetry-resourcesまたはcreate OCI CLIコマンド構文を使用します:

• インポートコマンドの使用:

  oci stack-monitoring resource-task import-telemetry-resources 
          --compartment-id "<Compartment_OCID>" 
          --name <Request_name> 
          --namespace <OCI_monitoring_namespace>
          --source <source-of-resource>

• createコマンドの使用:

  oci stack-monitoring resource-task create
      --compartment-id  "<Compartment_OCID>"     
      --name <Request_name> 
      --task-details file://<JSON_INPUT_FILE>

コマンドラインを使用したOCIリソースのインポートのJSONの例

{    
    "type": "IMPORT_OCI_TELEMETRY_RESOURCES",    
    "source": "<source-of-the-resource>"    
    "namespace": "<OCI-Monitoring-namespace>"
}

JSONの入力パラメータ:

スタック・モニタリングでは、Prometheus形式のリソースおよびメトリックのモニタリングがサポートされます。これは、エージェントをスクレイプしてテレメトリにアップロードし、スタック・モニタリングにリソースをインポートする2つのステップ・プロセスです。

前提条件

コンパートメント内にPrometheusベースのリソースをインポートできるように、必要なポリシーを作成します。詳細は、Prometheusベースのリソースを監視するためのポリシーの作成を参照してください。

Prometheusベースのリソースの可用性ステータスは、次のように決定されます。

• 可用性プロキシ・メトリック入力で選択したメトリックの少なくとも1つに、指定された間隔中にテレメトリ(0を含む)のデータポイントがある場合、リソースは稼働中とみなされます。
• 可用性プロキシ・メトリック間隔が管理エージェントで構成されている間隔(scheduleMins)より小さい場合、UIはリソースを「レポートなし」として表示します。エージェント構成ファイルでscheduleMinsに指定された値(秒に変換)と同じ値を入力することをお薦めします。
  • たとえば、管理エージェントの構成時に、scheduleMinsの値が5 (分)に設定されている場合、可用性プロキシのメトリック間隔は300 (秒または5分)以上である必要があります。可用性プロキシ・メトリックが300秒未満に設定されている場合、リソースには「レポートなし」のステータスが表示されます。

UIを使用したPrometheusベースのリソースのインポート

• 管理エージェントの構成
• Prometheusベースのリソースのインポート

CLIを使用したPrometheusベースのリソースのインポート

• 管理エージェントの構成
• Prometheusベースのリソースのインポート

スタック・モニタリングでは、Telegrafベースのリソースのモニタリングがサポートされるようになりました。これは3つのステップのプロセスです。

1. エージェントのメトリック・レシーバを有効にして、エージェントがTelegrafサード・パーティ・コレクタからメトリックを受信する準備をできるようにします。
2. Telegrafを構成して、エージェントをリスニングしているメトリック受信者にメトリックをアップロードし、メトリックをテレメトリにアップロードします。
3. Telegrafリソースをテレメトリからスタック・モニタリングにインポートします。

前提条件

• 管理エージェントの最小バージョン: 250214.1645
• Telegrafは、様々なターゲットのメトリック情報を構成および受信します。

• Telegrafベースのリソースをコンパートメント内にインポートできるようにするために必要なポリシーを作成します。詳細は、Telegrafベースのリソースを監視するためのポリシーの作成を参照してください。

Telegrafメトリックを受け入れるためのメトリック受信者およびハンドラを使用可能にします

「リソースのインポート」メニューで、表の左上隅にある「リソースのインポート」を選択します。入力が入力されたら、「リソースのインポート」をクリックします。パネルが閉じ、新しく作成された作業リクエストがリストに表示されます。作業リクエストの一部として、受信者はTelegrafによって投稿されたメトリックのエージェントでのリスニングを開始するように設定されます。有効化エージェントの一部として、エージェント・ディレクトリ<agent_state_directory>/extension_state/StackMonitoringMetricReceiver/certs/clientCerts/stackmonitoring-ca.crtに証明書が生成されます。この証明書は、Telegrafがアクセスできるパスにコピーする必要があります。

ログを表示するには、作業リクエストの「ステータス」リンクを選択します。

作業リクエストが完了すると、スタック・モニタリングに2つの新しいリソースが作成されます

1. 受け側リソース:
   • 名前: <agent_name>_receiver
   • 型: stackmon_receiver
2. Telegrafハンドラ・リソース:
   • 名前: <agent_name>_handler
   • 型: stackmon_handler

これらのリソースには、関連するハンドラ・メトリック、拒否されたメトリック数などが含まれます。

作業リクエストの一部として、ユーザーがリソースのインポートを手動で実行していない場合でも、スケジューラがこのエージェントのテレメトリからテレグラフベースのリソースをインポートするためのエントリが24時間ごとに発行されます。

Telegrafベースのリソースのデフォルトのメトリック・ネームスペースは、oracle_appmgmt_telegrafです。

Telegrafの構成

有効化時に受信者によって生成されたメトリックおよび証明書パスをアップロードするための受信者URLを追加します。これらの構成は、telegraf.confに追加する必要があります。

[[outputs.http]]
## URL is the address to send metrics to
url = "https://<agent-host-name>:3872/receiver/telegraf?id=<telegraf_instance_id>"
 
#   TLS Config
insecure_skip_verify = true
tls_ca="/home/mcollector/sar_test/certs/stackmonitoring-ca.crt"

スタック・モニタリングでは、収集ベースのリソースのモニタリングがサポートされるようになりました。これは3ステップのプロセスです。

1. エージェントのメトリック・レシーバを有効にして、収集したサード・パーティ・コレクタからメトリックを受信する準備をエージェントにします。
2. エージェントをリスニングするメトリック・レシーバにメトリックをアップロードするように収集されるように構成します。これにより、メトリックがテレメトリにアップロードされます。
3. 収集したリソースをテレメトリからスタック・モニタリングにインポートします。

前提条件

• 管理エージェントの最小バージョン: 250214.1645
• CollectDは、様々なターゲットのメトリック情報を構成して受信します。
• コンパートメント内の収集ベースのリソースのインポートを許可するために必要なポリシーを作成します。詳細は、収集ベースのリソースを監視するためのポリシーの作成を参照してください。

収集したメトリックを受け入れるためのメトリック・レシーバおよびハンドラの有効化

「リソースのインポート」メニューで、表の左上隅にある「リソースのインポート」を選択します。入力が入力されたら、「リソースのインポート」をクリックします。パネルが閉じ、新しく作成された作業リクエストがリストに表示されます。作業リクエストの一部として、受信者はcollectdによって投稿されたメトリックのエージェントでのリスニングを開始するように設定されます。有効化エージェントの一部として、エージェント・ディレクトリ<agent_state_directory>/extension_state/StackMonitoringMetricReceiver/certs/clientCerts/stackmonitoring-ca.crtに証明書が生成されます。この証明書は、collectdがアクセスできるパスにコピーする必要があります。

ログを表示するには、作業リクエストの「ステータス」リンクを選択します。

作業リクエストが完了すると、スタック・モニタリングに2つの新しいリソースが作成されます

1. 受け側リソース:
   • 名前: <agent_name>_receiver
   • 型: stackmon_receiver
2. Telegrafハンドラ・リソース:
   • 名前: <agent_name>_handler
   • 型: stackmon_handler

これらのリソースには、collectDからの関連するハンドラ・メトリック、拒否されたメトリック数などが含まれます

作業リクエストの一部として、ユーザーがリソースのインポートを手動で実行していない場合でも、スケジューラがこのエージェントのテレメトリから収集ベース・リソースをインポートするためのエントリが24時間ごとに発行されます。

collectdベースのリソースのデフォルトのメトリック・ネームスペースは、oracle_appmgmt_collectdです。

収集済の構成

有効化時に受信者によって生成されたメトリックおよび証明書パスをアップロードするための受信者URLを追加します。これらの構成は、collectd.confに追加する必要があります。

LoadPlugin write_http
<Plugin write_http>
      <Node "example">
                URL "https://<agent-host-name>:3872/receiver/collectd?id=<collectd_instance_id>"
                CACert "/home/mcollector/sar_test/certs/stackmonitoring-ca.crt"
                VerifyHost false
                VerifyPeer false
                Header "Content-Type: application/json; charset=utf-8"
                Format "JSON"
                Metrics true
        </Node>
</Plugin>

インポートしたリソースと既存のリソースの関連付け

インポートされたリソースをスタック・モニタリング内の別のリソースに関連付けるには、次のステップに従います。

1. リソース・ホームページで、「トポロジ」をクリックします。
2. 「アソシエーションの追加」ボタンをクリックします。
3. 「関連リソースの追加」ポップアップで、次のフィールドに入力します:
   1. リレーション- 「使用」と「使用者」の2つのアソシエーションから選択します。選択した関連リソースは、それに応じてソースまたは宛先になります。アソシエーションが「使用」の場合、関連リソースはアソシエーション・ペアの宛先になります。アソシエーションが「使用者」の場合、関連リソースはアソシエーション・ペアのソースになります
   2. リソース・タイプ- 関連付けるリソース・タイプを選択します。
   3. リソース- 関連付けるリソースを選択します。選択したリソース・タイプに基づいて、「リソース」リストに使用可能なオプションが移入されます。
4. 「リソースの追加」をクリックします

アソシエーションが追加されると、関連付けられたリソースが「トポロジ」表に表示されます。誤った関連付けが作成された場合は、削除アイコンをクリックして関係を削除します。

CLIを使用してアソシエーションを作成するには、アプリケーション・トポロジを参照してください。

インポート済リソースの可用性ステータス計算

インポートされたリソースの可用性ステータスは、次のように決定されます。

• OCIサービスのメトリック・データがある場合、リソースは稼働中(使用可能)とみなされます。メトリック・データがない場合、停止中とみなされます。
• 停止しているOCIサービスが引き続きOCIモニタリングにメトリック・データを生成する場合は、そのライフサイクル状態属性を使用してその可用性ステータスが決定されます。

MySql DBシステムなどの他の場合、可用性ステータスは、事前に決定されたメトリックの存在に基づいて計算されます。指定された期間中にメトリックがOCIモニタリング・ネームスペースに存在する場合、インポートされたリソースは稼働中とみなされます。この期間中にメトリック・データがない場合、リソースは停止中とみなされます。

スタック・モニタリング・エンタープライズ・サマリーでのOCIリソースの表示

スタック・モニタリングでは、エンタープライズ・サマリーで、インポートされたOCIリソースの可用性ステータスおよびパフォーマンス・メトリックを監視できます。

エンタープライズ・サマリーでのリソースのステータスの監視の詳細は、エンタープライズのステータスおよびパフォーマンスのモニターを参照してください。

アプリケーションやアプリケーション・インフラストラクチャなどのカスタム・リソースは、リソースを構成するプロセスとリソースが実行されているホストを識別することで、ホストで実行されているものを監視できます。定義すると、スタック・モニタリングによってカスタム・リソースの新しいリソース・インスタンスが作成され、組込みホームページを使用してモニターできます。このカスタム・リソースがスタック・モニタリングでモニターされるアプリケーションによって使用されている場合、このカスタム・リソースとアプリケーションの間のアソシエーションを簡単に作成できるため、アプリケーション・トポロジがエンリッチされます。

カスタム・リソースに対応するプロセス・セットごとに、次のメトリックが収集されます。これらのメトリックは、プロセス・セット全体の集計として使用できますが、識別されたプロセス名と所有者、ラベル(指定されている場合)ごとに別々に使用できます。

• モニタリング・ステータス
• 使用済メモリー(物理/仮想)
• メモリー使用率
• CPU使用率
• CPU使用率
• プロセス合計数

カスタム・リソースを構成する特定のプロセス・セットを識別するには、プロセス・セットを定義します。プロセス・セットを定義する場合は、プロセス名、プロセス所有者またはプロセス行の正規表現で構成されるフィルタを指定します。この正規表現は、リソースの実行中のプロセスとの照合に使用されます。各フィルタには、少なくとも1つのフィールドが存在する必要があります。フィルタで一致したプロセスへのシンボリック参照として機能するオプションのラベルを追加できます。たとえば、nginxアプリケーション・サーバーをカスタム・リソースとしてモニターするには、nginx processesというプロセス・セットを作成します。このプロセス・セットには、プロセス名nginxを指定するフィルタがあり、プロセス行の正規表現nginx: mainとラベルnginx main processがあります。

入力として使用されるプロセス

Linuxでは、次のコマンドライン・コマンドを使用して、使用されるプロセスを取得します。

ps -ww -e -o comm:32,user:32,args

このコマンドの出力をgrepなどの検索ツールにパイプすると、目的のプロセスを分離し、プロセス・セットの構成方法を決定できます。次のコマンドは、キーワードnginxを含むプロセス行を表示します。

ps -ww -e -o comm:32,user:32,args | grep nginx

このコマンドを実行すると、COMMAND、USERおよびCOMMANDという3つの列を含む次の表が出力されます。表の列からプロセス・セット・フィルタのフィールドへのマッピングは次のとおりです。フィルタのprocessCommandフィールドが最初のCOMMAND列に適用され、processUserフィールドがUSER列に適用され、正規表現が最後のCOMMAND列に適用されます。いずれかのフィールドが指定されていない場合、その特定のフィルタの列は無視されます。

マスター・プロセスとワーカー・プロセスを個別にモニターする場合、プロセス・セット・ペイロードは次のようになります。ラベルnginx-main-processを持つフィルタは、テーブル内の最初のプロセスに一致し、ラベルnginx-workerを持つフィルタは他のプロセスを処理します。

{
    "compartmentId": "<Compartment_OCID>",
    "displayName": "nginx processes",
    "specification": {
        "items": [
            {
                "label": "nginx-main-process",
                "processCommand": "nginx",
                "processLineRegexPattern": "nginx: master.*"
            },
            {
                "label": "nginx-worker-processes",
                "processCommand": "nginx",
                "processLineRegexPattern": "nginx: worker.*"
            }
        ]
    }
}

2つのフィルタを持つプロセス・セットを作成することで、「プロセスのモニター」ページでも同じことが可能です。

UIを使用したプロセス・セットの作成

プロセス・セットは、カスタム・リソースを構成するホストで実行されているプロセスを識別するための仕様を表し、ホストで実行されている一連のプロセスを指定する1つ以上のフィルタで構成されます。

ホスト プロセスは、プロセス セットのフィルタの1つで定義された条件を満たす場合、プロセス セットと照合されます。

1. 「スタック・モニタリング」メニューから、「プロセスのモニター」を選択します

2. 「プロセス・セットの作成」をクリックします。「プロセス・セットの作成」UIパネルが表示されます。

3. 各フィールドの詳細は、「UI検出入力」を参照してください。必須フィールドに入力します。
4. プロセス・セットの作成およびマップまたは作成:
   • 作成およびマップでは、プロセス・セットを作成し、選択したホストのモニタリングを1ステップで開始できます。
   • 「作成」では、ホストにマッピングせずにプロセス・セットが作成されます。

プロセス セットの更新

1. 「スタック・モニタリング」メニューから、「プロセスのモニター」を選択します

2. プロセス・セットのリストからプロセス・セットを選択します。

3. プロセス・セットのプロパティまたは仕様に必要な調整を行います。
4. 「ターゲット・ホスト」でモニターする追加の「ホスト」を選択します。
5. 変更を保存すると、次のようになります。
   1. 既存のプロセスベースのカスタム・リソースのプロセス・セットを更新します。
   2. 更新されたプロセス・セットを選択したホストにマップします。

OCI-CLIを使用したプロセス・セットの作成

プロセス・セットは、カスタム・リソースを構成するホストで実行されているプロセスを識別するための仕様を表し、ホストで実行されている一連のプロセスを指定する1つ以上のフィルタで構成されます。

ホスト プロセスは、プロセス セットのフィルタの1つで定義された条件を満たす場合、プロセス セットと照合されます。

プロセス・セットは、OCI-CLIコマンドとJSONペイロードを使用して作成されます。JSONファイルには、目的のプロセスをフィルタで除外するための文字列および正規表現(regex)を使用して構築されたフィルタ定義のリストが含まれています。プロセス・セットは、OCI-CLIコマンド(プロセス・セットを作成したOCI stack-monitoring process-set.Once)を使用して定義し、次にpを実行するOCI-CLIコマンドを実行できます

プロセス・セットを作成したら、プロセスベースのカスタム・リソースの設定および構成操作を実行するOCI-CLIコマンドを実行できます。

プロセス・セットのペイロードには、次の必須フィールドがあります。

• compartmentId - コンパートメントのOCID
• displayName - プロセス・セットのシンボリック名
• 仕様 - フィルタのリスト。

各フィルタ項目には、次のオプションフィールドがあります。ただし、processCommand、processUserおよびprocessLineRegexPatternの少なくとも1つを指定する必要があります。フィルタは、プロセス セットに含まれるプロセスを選択するために使用します。プロセスは、選択する1つのフィルタのすべての指定フィールドと一致する必要があります。

• labelは、このフィルタに一致するプロセスを説明するラベルです。
• processCommandは、コマンド名を指定します。コマンド名がこの値と完全に一致するプロセスのみが含まれます。この値を指定しない場合、コマンド名のフィルタリングは行われません。
• processUserは、プロセスを実行しているユーザーの名前を指定します。ユーザー名がこの値に完全に一致するプロセスのみが含まれます。この値を指定しない場合、起動ユーザーのフィルタリングは実行されません。

• processLineRegexPatternは、プロセスのコマンドラインと照合される正規表現パターンを指定します。通常、コマンド行には、プロセスの起動時に渡されるコマンド名と引数の両方が含まれます。regexが(javascript regexルールを使用して)コマンドラインの任意の部分文字列と一致する場合、プロセスが含まれます。この正規表現が指定されていない場合、コマンド行でのフィルタリングは行われません(ただし、コマンド名のフィルタリングは、指定されている場合は引き続き実行されます)。

  ノート
  
  プロセスが複数のフィルタと一致する場合(正規表現が重複しているなど)、一致した最初のフィルタに対してのみ照合されます。
  ノート
  
  リソースのステータスを稼働中としてレポートするには、各フィルタ・アイテムで少なくとも1つのプロセスが一致している必要があります。

次のOCI-CLI createコマンドを使用して、次のいずれかのnginxペイロードを使用してプロセス・セットを作成します。

CLI createコマンドの例:

oci stack-monitoring process-set create --compartment-id "<Compartment_OCID>" --from-json file://<JSON_INPUT_FILE>

• {
      "compartmentId": "<Compartment_OCID>",
      "displayName": "nginx processes",
      "specification": {
          "items": [
              {
                  "processCommand": "nginx",
              }
          ]
      }
  }

  これにより、少なくとも1つのプロセスが稼働しているかどうかが監視されますが、nginxのすべての必須プロセスが稼働しているかどうかはチェックされず、特にそれらのメトリック(nginxプロセス・コマンド・ディメンションの合計のみ)もチェックされません。

• {
      "compartmentId": "<Compartment_OCID>",
      "displayName": "nginx processes",
      "specification": {
          "items": [
              {
                  "processCommand": "nginx",
                  "processLineRegexPattern": "nginx: master."
              },
              {
                  "processCommand": "nginx",
                  "processLineRegexPattern": "nginx: worker."
              }
          ]
      }
  }

  これにより、nginxに必要なすべてのプロセスが監視され、MonitoringStatusはマスター・プロセスと少なくとも1人のワーカーがある場合にのみ稼働します。メトリックの粒度の量は最初の例と同じです。ディメンションProcessCommandは同じで、正規表現はメトリックのディメンションとしてレポートされないためです。

• {
      "compartmentId": "<Compartment_OCID>",
      "displayName": "nginx processes",
      "specification": {
          "items": [
              {
                  "label": "nginx-main-process",
                  "processCommand": "nginx",
                  "processLineRegexPattern": "nginx: master."
              },
              {
                  "label": "nginx-worker-processes",
                  "processCommand": "nginx",
                  "processLineRegexPattern": "nginx: worker."
              }
          ]
      }
  }

  ラベルを追加すると、ユーザーはメトリックのマスター・プロセスとワーカー・プロセスを区別できます。

  nginxの場合、プログラムは常にnginxであるため、従業員とマスターを区別するラベルを追加します(正規表現または完全なプロセス・ラインはディメンションとしてレポートされます)。

前述の例では、プロセスを所有するユーザーに関係なく、プロセス・ユーザー・フィールドprocessUserはすべてのプロセスに一致するように省略されています。

レスポンスにはプロセス・セットが含まれ、プロパティidにはprocess_set_idが含まれます。

カスタム・リソースをモニターするホストの識別

プロセス・セットが正常に作成されたため、カスタム・リソースを作成して、特定のホストでこのプロセス・セットを監視できます。これは、スタック・モニタリング検出ジョブを起動し、スタック・モニタリングのDiscoveryJobs APIを介してCUSTOM_RESOURCEタイプのリソースを作成することによって行われます。例については、次のペイロードを参照してください。

この例では、カスタム・リソースをモニターするエージェントおよびホストを指定します。

JSONペイロードでは、ライセンスはENTERPRISE_EDITIONである必要があります。

{
    "discoveryType": "ADD",
    "discoveryClient": "APPMGMT",
    "compartmentId": "<Compartment_OCID>",
    "discoveryDetails": {
        "agentId": "<Agent_OCID>",
        "resourceType": "CUSTOM_RESOURCE",
        "resourceName": "nginx processes",
        "properties": {
            "propertiesMap": {
                 "host_ocid": "<Host_OCID>",
                 "process_set_id": "<ProcessSet_OCID>"
            }
        },
        "license": "ENTERPRISE_EDITION"
    },
    "freeformTags": {},
    "definedTags": {}
}

JSONファイルを定義したら、次のコマンドを実行してカスタム・リソース検出ジョブを作成します:

oci stack-monitoring discovery-job create --compartment-id "<Compartment_OCID>" --from-json file://<JSON_INPUT_FILE>

検出ジョブが完了すると、nginxプロセスという名前のCUSTOM_RESOURCEタイプのスタック・モニタリング・リソースおよび対応するホームページが使用可能になります。

プロセス セットの更新

プロセス・セットの更新は、プロセス・セットの作成に似ています。更新するプロセス・セットのOCIDを決定し、作成ペイロードと同様に構造化されたペイロードを使用して更新を実行します。更新が完了すると、プロセス・セットのリビジョンが増分されたことがわかります。これは、モニター対象のホストに現在存在しているプロセス・セット仕様のバージョンを追跡するために使用されます。OCI-CLIまたはRESTコールを介してプロセス・セットを更新しても、ホスト上のプロセスの監視に使用される仕様は更新されないことに注意してください。

次の CLIコマンドを使用して、プロセスサービスを更新します。

oci stack-monitoring process-set update --process-set-id <ProcessSet_OCID> --from-json file://<JSON_INPUT_FILE>

/processSets/<ProcessSet_OCID>へのRAWリクエストまたはPUTリクエストの使用:

{
    "compartmentId": "<Compartment_OCID>",
    "displayName": "nginx processes",
    "specification": {
        "items": [
            {
                "processCommand": "nginx",
                "label": "all nginx processes filter"
            }
        ]
    }
}

カスタム・リソースのリフレッシュ

プロセス・セットが変更されたら、REFRESH Discovery Jobコマンドを使用してカスタム・リソースに設定されたプロセスを更新します。

oci stack-monitoring discovery-job create  --compartment-id "<Compartment_OCID>" --from-json file://<JSON_INPUT_FILE>

REFRESH JSONペイロードの例:

{
    "discoveryType": "REFRESH",
    "discoveryClient": "APPMGMT",
    "compartmentId": "<Compartment_OCID>",
    "discoveryDetails": {
        "agentId": "<Agent_OCID>",
        "resourceType": "CUSTOM_RESOURCE",
        "resourceName": "nginx processes",
        "properties": {
            "propertiesMap": {
                 "resource_id": "<Resource_OCID>",
                 "host_ocid": "<Host_OCID>",
                 "process_set_id": "<ProcessSet_OCID>"
            }
        },
        "license": "ENTERPRISE_EDITION"
    }
}

検出ジョブのステータスのチェック

コマンドが実行されると、ジョブのステータスおよびログは、「リソース検出」ページのスタック・モニタリング内で表示できます。「リソース検出」ページで、「リソース名」が「カスタム・リソース」の名前、リソース・タイプが「カスタム・リソース」で、ジョブ・タイプがAddである送信済ジョブを検索します。ジョブ・ステータスが「成功」になったら、「リソース名」の下にあるカスタム・リソースの名前をクリックして、リソースのホームページに移動します。