管理エージェントの管理タスク

管理エージェントは、様々なソースからログおよびメトリック・データを収集するためにデプロイされます。場合によっては、そのために、いくつかの管理タスクを実行する必要があります。

次の項では、共通の管理タスクをいくつか説明します。

管理エージェント・コンソールの概要

管理エージェント・コンソールは、管理エージェントおよび管理ゲートウェイを表示および管理できるOCI Management Agentサービスのユーザー・インタフェースです。

ニーズに応じて基本操作と拡張操作を実行できます。概要ページには、管理エージェント・サービスで構成されたリソースに関する重要な情報およびリンクが表示されます。コンソールでは、構成された管理エージェント(エージェント)および管理ゲートウェイ(ゲートウェイ)へのアクセス、およびチャート内の関連データをビジュアル化するダッシュボードも提供されます。

管理エージェント・コンソールを開くには:
  • OCIにサインインし、OCIコンソールでナビゲーション・メニューを開きます。

  • 「監視および管理」で、「管理エージェント」をクリックします。

  • 左側のメニューから、「コンパートメント」ドロップダウン・リストからコンパートメントを選択します。

    管理エージェント・コンソールが表示されます。

管理エージェント・コンソールの左側に、次のオプションを含むメニューが表示されます:

概要

概要ページには、管理エージェント・サービス、およびインストールされている管理エージェントおよび管理ゲートウェイに関する有用な情報が表示されます。

コンパートメント・セレクタ・ドロップダウン付近の「サブコンパートメント」チェック・ボックスを選択すると、選択したコンパートメントおよびその子コンパートメント全体のエージェント詳細の概要を取得できます。

「概要」ページには、環境内の管理エージェントおよび管理ゲートウェイに関するサマリー情報が表示され、次のチャートで構成されます:

  • エージェント: インストールされている管理エージェントの数。

  • エージェント可用性:管理エージェントの可用性ステータス。使用可能なステータスは次のとおりです。

    • アクティブ: 管理エージェント・サービスが管理エージェントと通信しています。

    • サイレント: 管理エージェント・サービスが管理エージェントと通信していません。エージェントとの通信はエージェントのインストール後に確立されましたが、何かが発生し、管理エージェント・サービスとエージェントの間に通信の問題が存在する可能性があります。

    • 使用不可: 管理エージェントのインストール・プロセスが実行中であり、管理エージェント・サービスがエージェントとの通信をまだ確立していません。

    ノート

    2024年12月9日以降、サイレント状態に60日間残っているエージェントはシステムから削除されます。

  • アラーム: OCIモニタリング・サービスからの管理エージェントおよびゲートウェイ・アラームの詳細。

    サブコンパートメント・オプションは、現在このチャートではサポートされていません。

    アラームおよび通知の設定の詳細は、次を参照してください:
  • エージェント・オペレーティング・システム:インストールされた管理エージェントのオペレーティング・システムのバージョン。

  • エージェント・バージョン:管理エージェントのバージョン。

  • エージェント・サービス・プラグイン:管理エージェントによってデプロイされたサービス・プラグイン。

  • エージェントによって送信されるデータ:管理エージェントによってサービス・プラグインに送信されるデータの量。サブコンパートメント・オプションは、現在このチャートではサポートされていません。

  • ゲートウェイ:インストールされている管理ゲートウェイの数。
  • ゲートウェイの可用性:管理ゲートウェイの可用性ステータス。
  • ゲートウェイ別送信データ:管理ゲートウェイによってサービス・プラグインに送信されるデータの量。サブコンパートメント・オプションは、現在このチャートではサポートされていません。

次のスクリーンショットは、管理エージェントの概要ページの例です。


インストールされている管理エージェントに関する情報を表示する概要ページ。

ダッシュボード

ダッシュボードを使用して、解釈しやすいチャートでデータを表示、調査および分析できます。詳細は、ダッシュボードの操作を参照してください。

エージェント

エージェント・ページには、選択したコンパートメントにインストールされているすべての管理エージェント(エージェント)および管理ゲートウェイ(ゲートウェイ)がリストされます。

「エージェント」ページには、次のオプションが含まれます。

エージェントとゲートウェイ

コンパートメントを選択するには:
  • 左側のペインに移動します。「スコープ」で、「コンパートメント」ドロップダウン・リストから目的のコンパートメントを選択します。
    • 「サブコンパートメントを含む」チェック・ボックスを使用して、サブコンパートメント内のアクセス可能なすべてのエージェントをリストします。

      リストされるエージェントおよびゲートウェイのデフォルトの最大数は1,000です。選択をカスタマイズするには、左側のペインに移動し、「フィルタ」を使用します。

      ポリシー要件: 選択したコンパートメント・レベルでinspect management-agents権限があり、そのコンパートメントからすべてのサブコンパートメントをリストできることを確認します。たとえば: ALLOW GROUP <group_name> TO INSPECT management-agents IN TENANCY

エージェントおよびゲートウェイ・ページには、インストールされているすべての管理エージェントおよび管理ゲートウェイをリストする表が表示されます。

この表は次の列で構成されています:

  • 名前: 管理エージェントまたはゲートウェイ名が表示されます。

  • ホスト: 管理エージェントまたはゲートウェイがインストールされているホスト名が表示されます。

  • 可用性: 管理エージェントまたはゲートウェイのステータスが表示されます。

  • オペレーティング・システム: 管理エージェントまたはゲートウェイがインストールされているホストのオペレーティング・システムが表示されます。

  • バージョン: インストールされた管理エージェントまたはゲートウェイのバージョンが表示されます。

  • プラグイン: 管理エージェントによってデプロイされたサービス・プラグインの名前が表示されます。

  • 作成日: 管理エージェントまたはゲートウェイがインストールされた日付が表示されます。

  • アクション・アイテム: 特定の管理エージェントまたはゲートウェイで使用可能なその他のアクションが表示されます。

次のスクリーンショットは、エージェントおよびゲートウェイ・リストの例です。

インストールされているすべての管理エージェントおよび管理ゲートウェイを表示する「エージェントとゲートウェイ」ページ。

特定のエージェントまたはゲートウェイをクリックして詳細ページを開き、すぐに詳細情報を取得できます。

ノート

エージェントまたはゲートウェイの詳細を表示できるREAD management-agents権限があることを確認します。

エージェント詳細

「エージェント詳細」ページには、選択したエージェントに関する情報が表示されます。

  • 「プラグインのデプロイ」を使用して、選択したエージェントにプラグインをデプロイします。

  • エージェント・ログの有効化を使用して、Log Analyticsサービスが選択したエージェントの管理エージェント・ログ・ファイルを収集できるようにします。詳細は、エージェント・ログの有効化を参照してください。

  • 「DataSourcesの管理」を使用して、選択したエージェントで構成されているデータソース・タイプのプロパティおよびディメンションを表示または編集します。詳細は、データ・ソースの管理を参照してください。

  • 「他のアクション」を使用して、エージェントを「タグの追加」または「削除」します。
  • 「エージェント情報」タブには、詳細なエージェント情報が表示されます。ホスト名、コンパートメント名、エージェント・バージョン、オペレーティング・システム、それにデプロイされたサービス・プラグイン、作業リクエスト、データ・ソースなどが表示されます。
    • サービス・プラグイン: 「サービス・プラグイン」リンクを使用して、この特定の管理エージェントにデプロイされたすべてのサービス・プラグインをリストします。詳細は、「サービス・プラグインのデプロイ」を参照してください。
    • DataSources: DataSourcesリンクを使用して、この特定の管理エージェントに構成されているすべてのデータソースをリストします。詳細は、データ・ソースの管理を参照してください。

インストールされている管理エージェントに関する情報を表示するエージェントの詳細ページ。

ゲートウェイ詳細

「ゲートウェイの詳細」ページには、ゲートウェイに関する詳細情報が表示されます。

「ゲートウェイ情報」タブには、ゲートウェイの詳細情報が表示されます。ホスト名、コンパートメント名、ゲートウェイ・バージョン、オペレーティング・システム、関連エージェントなどが表示されます。

関連エージェント: 「関連エージェント」リンクを使用して、この特定の管理ゲートウェイを使用するように構成されているすべての管理エージェントをリストします。「関連付けられたエージェント」ペインには、管理エージェントのID、ホスト、可用性およびオペレーティング・システムの情報が表示されます。


インストールされている管理ゲートウェイに関する情報を示す管理ゲートウェイの詳細ページ。

DataSourceを含むエージェント

DataSourceを持つエージェント・ページには、データソースが構成されているすべてのエージェントをリストする表が表示されます。

この表は次の列で構成されています:
  • 名前:エージェントの名前。

  • DataSource型:データソースのタイプ。例: プロメテウス。

  • DataSource:エージェントに関連付けられたデータ・ソースの合計数。

  • 可用性:エージェントの可用性。

  • 作成日:エージェント作成時のタイムスタンプ。

特定のエージェントをクリックすると、詳細ページが開き、すぐに詳細情報を取得できます。

ダウンロードとキー

ダウンロードとキー・ページには、管理エージェントのダウンロード・ファイルおよび作成された管理エージェントのインストール・キーに関する情報が表示されます。

これは、上部の「エージェント・ソフトウェアのダウンロード」ペインと下部の「エージェント・インストール・キー」ペインで構成されます。

エージェント・ソフトウェアのダウンロード

「ソフトウェア・ダウンロード」ペインには、次の列で構成される表があります。

  • ダウンロード: Management Agentのダウンロード・ファイル名が表示されます。

  • パッケージ・タイプ: パッケージ・タイプ: ZIPまたはRPMが表示されます。

  • バージョン: インストールされた管理エージェント・バージョンが表示されます。

  • サイズ(MB): 管理エージェント・サイズが表示されます。

  • SHA-256チェックサム: ファイルの整合性を確認するための情報が表示されます。

次のスクリーンショットは、「ソフトウェア・ダウンロード」ペインの例です。

ソフトウェア・ダウンロード・ペイン

エージェント・インストール・キー

「エージェント・インストール・キー」ペインには、エージェント・インストール・キーを作成するための「キーの作成」ボタンがあります。また、次の列で構成される表も表示されます:

  • キー名: 管理エージェントのインストール・キー名が表示されます。

  • コンパートメント: 管理エージェントのインストール・キーが作成されたコンパートメント名が表示されます。

  • 作成者: 管理エージェントのインストール・キーを作成したユーザーに関する情報が表示されます。

  • 作成日: 管理エージェントのインストール・キーの作成日が表示されます。

  • 残り日数: 管理エージェントのインストール・キーが期限切れになるまでの残り日数が表示されます。

  • 残りのエージェント・インストール: 各管理エージェント・インストール・キーの残りのインストール数が表示されます。

  • アクション・アイテム 「Action Item(処理項目)」メニュー: 「Copy Key to Clipboard(キーをクリップボードにコピー)」、「Download Key to File(キーをファイルにダウンロード)」、「Delete Key(キーの削除)」など、エージェント・インストール・キーに使用できるその他の処理が表示されます。

管理エージェントの証明書のインポート

管理エージェントのインストール・プロセス中に、カスタムの信頼できる証明書をインポートできます。環境のオプションを選択します。

スタンドアロン管理エージェント用のカスタム信頼できる証明書のインポート

スタンドアロン管理エージェントのインストールでは、次のステップに従ってカスタムの信頼できる証明書をインポートできます。

  1. 追加の信頼できるルート認証局(CA)証明書をPEM形式で格納するディレクトリを作成します。次の例では、tmpディレクトリが例です。任意のディレクトリを使用して、エージェント・ユーザーが証明書のパス内のすべてのディレクトリへの読取りアクセス権を持っていることを確認できます。
    mkdir /tmp/crt
  2. 次に、次のコマンドを入力して、PEM形式のすべてのカスタム信頼できる証明書を、前のステップで作成した新しいディレクトリにコピーします。
    cp *.pem /tmp/crt
  3. スタンドアロン・エージェントが証明書にアクセスできるように、ディレクトリおよびそのコンテンツに対する権限を設定します。
    chmod 644 /tmp/crt
  4. インストール時または構成時にカスタムの信頼できる証明書を管理エージェントに追加するには、input.rspレスポンス・ファイルで証明書のディレクトリを指定する必要があります。
    importTrustedCertsDirectory=/tmp/crt
  5. これで、インストールを実行して証明書を管理エージェントにインポートできます。
  6. インストール後、次のコマンドを使用し、次の値を環境の値に置き換えて、信頼できる証明書がエージェントのキーストアに正常にインポートされたことを確認できます。<CUSTOM_CERTIFICATE_FILE_NAME>を環境内のカスタム証明書ファイル名に置き換えます(例: my-cert.pem)。
    keytool -list -keystore /opt/oracle/mgmt_agent/agent_inst/config/security/comm/commwallet.jks -alias <CUSTOM_CERTIFICATE_FILE_NAME>

    commwallet.pemファイルは、エージェントの信頼できる証明書ストアに追加されるカスタム証明書です。

コンピュート・インスタンスでのOracle Cloud Agent (OCA)管理エージェント・プラグインのカスタム信頼できる証明書のインポート

コンピュート・インスタンスでOracle Cloud Agent (OCA)管理エージェント・プラグインを使用している場合は、次のステップに従って、インストール・プロセス中にカスタムの信頼できる証明書をインストールできます。

  1. 次のコマンドを使用して、trustedcertsディレクトリを作成し、信頼できる証明書を/var/lib/oracle-cloud-agent/plugins/oci-managementagent/にインポートします。oracle-cloud-agentユーザーがディレクトリの所有者であることを確認します。
    cd /var/lib/oracle-cloud-agent/plugins/oci-managementagent/
    mkdir trustedcerts
    chown oracle-cloud-agent:oracle-cloud-agent trustedcerts/
  2. PEM形式のすべてのカスタム信頼できる証明書を、前のステップで作成した新しいディレクトリにコピーします。
    cp *.pem /var/lib/oracle-cloud-agent/plugins/oci-managementagent/trustedcerts
  3. これで、OCAエージェントのインストールを実行して、証明書を管理エージェントにインポートできます。
  4. インストール後、次のコマンドを使用すると、信頼できる証明書がエージェントのキーストアに正常にインポートされたことを確認できます。<CUSTOM_CERTIFICATE>を環境内のカスタム証明書ファイル名に置き換えます(例: my-cert.pem)。
    keytool -list -keystore /var/lib/oracle-cloud-agent/plugins/oci-managementagent/polaris/agent_inst/config/security/comm/commwallet.jks -alias <CUSTOM_CERTIFICATE>
    commwallet.pemファイルは、エージェントの信頼できる証明書ストアに追加されるカスタム証明書です。

管理エージェントの証明書の更新

スタンドアロン管理エージェント用のカスタム信頼できる証明書の更新

スタンドアロン管理エージェント用のカスタム信頼できる証明書で既存の証明書を更新するには、次のコマンドを使用します。

  1. カスタム証明書の新しいディレクトリを作成します。次の例では、tmpディレクトリが例です。任意のディレクトリを使用して、エージェント・ユーザーが証明書のパス内のすべてのディレクトリへの読取りアクセス権を持っていることを確認できます。
    mkdir /tmp/customcerts 
  2. PEM形式のすべてのカスタム証明書をこの新しいステージング・ディレクトリにコピーします。
     cp *.pem /tmp/customcerts
  3. スタンドアロン・エージェントが証明書にアクセスできるように、ステージング・ディレクトリおよびそのコンテンツに対する権限を設定します。
     chmod 644 /tmp/customcerts
  4. 既存の証明書をカスタム証明書で更新するには、次のコマンドを使用し、次のものを環境の値に置き換えます。
    • 最初の引数は、カスタム証明書を含むフォルダへのパスです。
    • 2番目の引数をagent_instのパスに置き換えます。
      sudo -u 
      mgmt_agent /opt/oracle/mgmt_agent/agent_inst/bin/update_trusted_certs.sh /tmp/customcerts /opt/oracle/mgmt_agent/agent_inst
  5. コマンドの実行後に更新を確認するには、次のコマンドを実行して構成を確認し、カスタム証明書で正常に更新された既存の証明書を確認します。
    keytool -list -keystore /opt/oracle/mgmt_agent/agent_inst/config/security/comm/commwallet.jks -alias <CUSTOM_CERTIFICATE_FILE_NAME>

コンピュート・インスタンス上のOracle Cloud Agent (OCA)管理エージェント・プラグインのカスタム信頼できる証明書の更新

コンピュート・インスタンスでOCA管理エージェント・プラグインを使用している場合は、次のコマンドを使用して、信頼できるカスタム証明書で既存の証明書を更新できます。

  1. カスタム証明書の新しいディレクトリを作成します。次の例では、tmpディレクトリが例です。任意のディレクトリを使用して、エージェント・ユーザーが証明書のパス内のすべてのディレクトリへの読取りアクセス権を持っていることを確認できます。
    mkdir /tmp/customcerts 
  2. PEM形式のすべてのカスタム証明書をこの新しいステージング・ディレクトリにコピーします。
     cp *.pem /tmp/customcerts
  3. スタンドアロン・エージェントが証明書にアクセスできるように、ステージング・ディレクトリおよびそのコンテンツに対する権限を設定します。
     chmod 777 /tmp/customcerts
  4. oci-managementagentコマンドライン・ツールを使用して証明書を既存のエージェントにインポートするには、次のコマンドを使用します。
     sudo -u oracle-cloud-agent /usr/libexec/oracle-cloud-agent/plugins/oci-managementagent/oci-managementagent -cli -trusted-certs-dir=/tmp/trustedcerts
    出力例:
    Import Trusted Certificates Management Agent ...
    Log file path: /var/log/oracle-cloud-agent/plugins/oci-managementagent/oci-managementagent_importcerts.log
    Trusted Certificates added

サービス・プラグインのデプロイ

管理エージェントは、様々なOracle Cloud Infrastructure (OCI)サービスのプラグインをデプロイできます。デプロイ時に、これらのサービス・プラグインはそれらのサービスのタスクを実行できます。どの管理エージェントも複数のサービス・プラグインをデプロイできます。

使用可能なサービス・プラグイン

次のサービス・プラグインを使用できます。

  • Database Management and Operations Insights Service。
  • Java Management Service。
  • Java使用状況トラッキング。
  • Log Analytics。
  • 操作インサイトのホスト・サービス。
  • スタック・モニタリング。

OCIサービスの詳細は、Oracle Cloud Infrastructure (OCI)サービスを参照してください。

ノート

OCIサービス・プラグインの更新が使用可能な場合、プラグインはエージェントを自動的に更新して再起動します。この再起動はモニタリングに大きく影響しません。

サービス・プラグインのデプロイ

サービス・プラグインは、次のいずれかの方法を使用してデプロイできます:

エージェント・ページを使用したサービス・プラグインのデプロイ

この方法は、管理エージェントのインストールの説明に従って管理エージェントがすでにインストールされている場合に使用します。

エージェント・ページを使用してプラグインをデプロイするには、次を実行します:

  1. 左側のメニューで「エージェント」をクリックし、エージェント・ページを開きます。

  2. 「エージェント」リストで、プラグインをデプロイするエージェントをクリックします。

    エージェントの詳細ページが表示されます。


    プラグインをデプロイするオプション付きのエージェント詳細ページ。

  3. 「プラグインのデプロイ」をクリックします。

    「プラグインのデプロイ」ウィンドウが表示されます。

  4. プラグインを選択し、「更新」を選択します。

    これで、選択したプラグインが目的のエージェントにデプロイされます。

管理エージェントのインストール中のサービス・プラグインのデプロイ

この方法を使用すると、管理エージェントのインストール・プロセス中にプラグインのデプロイメントが実行されます。

  1. 管理エージェント・ソフトウェアのダウンロードおよびインストール・キーの作成の説明に従って、エージェント・ソフトウェアをダウンロードし、エージェント・インストール・キーを作成します。

  2. エージェント・インストール・キーのファイルをダウンロードします。

    エージェント・インストール・キー・ページに移動し、アクション・メニューから「キーをファイルにダウンロード」オプションを選択します。

    「キーをファイルにダウンロード」オプションを使用すると、レスポンス・ファイル・テンプレートをダウンロードできます。詳細は、インストール・キーのダウンロードを参照してください。

  3. テキスト・エディタを使用してレスポンス・ファイル・テンプレートを編集し、カスタム・レスポンス・ファイルを作成します。

    オプション1: レスポンス・ファイル・テンプレートをダウンロードして、レスポンス・ファイルを作成しますで説明されている手順に従って、レスポンス・ファイルを作成します。

    レスポンス・ファイル・テンプレートには、プラグインのデプロイに必要なサービス・プラグイン・パラメータなどのエージェント・パラメータが含まれます。

    管理エージェントのインストール・プロセスの一部としてサービス・プラグインをデプロイするには、Service.plugin.<plugin_name>.downloadパラメータをカスタマイズします。

    たとえば、エージェントのインストール時にDataSafeプラグインをデプロイしようとする場合は、パラメータ値を次のように指定します: Service.plugin.datasafe.download=true

    レスポンス・ファイルでサポートされるエージェント・パラメータの詳細は、エージェント・パラメータの確認を参照してください。

  4. 管理エージェントのインストールの説明に従って管理エージェントをインストールし、インストールを完了します。

デプロイメント後のタスク

サービス・プラグインをデプロイした後、次のことを実行できます。

サービス・プラグイン・ステータスの確認

  • 「エージェント詳細」ページで、「エージェント情報」に移動して「サービス・プラグイン」リンクをクリックします。

  • 「サービス・プラグイン」ペインが表示され、「名前」、「ステータス」および「メッセージ」の情報が表示されます。

    管理エージェントに複数のサービス・プラグインがデプロイされている場合、すべてのサービス・プラグインの情報が表示されます。

デプロイメントが成功すると、「ステータス」の下にRunningが表示されます。

デプロイメントに問題がある場合は、「ステータス」の下にFailedが表示され、「メッセージ」の下にエラーの説明が表示されます。

作業リクエスト・ステータスの確認

サービス・プラグインがデプロイされると、デプロイメント・プロセスを追跡するための作業リクエストが生成されます。

作業リクエスト・ステータスを確認するには、次の手順を実行します:

  • 「エージェント詳細」ページで、「エージェント情報」に移動して「作業リクエスト」リンクをクリックします。

  • 「作業リクエスト」ペインが表示され、ID、操作タイプ、プラグイン名、ステータスおよび受理時間に関する情報が表示されます。

    過去30日間のすべての作業リクエストが表示されます。

デプロイメントが成功すると、作業リクエストは「ステータス」の下にSucceededと表示されます。

デプロイメントに問題がある場合、作業リクエストは「ステータス」の下にFailedと表示されます。「ID」情報を使用してトラブルシューティングできます。

エージェント・ログの有効化

「エージェント・ログの有効化」オプションを使用すると、Log Analyticsサービスへのエージェント・ログの継続的な収集を有効にできます。

この機能により、選択したエージェントがLog Analyticsでオンボードされ、エージェントのログ・ファイルがLog Analyticsに自動アップロードされます。Log Analytics OCIサービスの詳細は、Log Analyticsを参照してください。

前提条件

  • 選択したエージェントのステータスは「アクティブ」です。
  • テナンシをLog Analyticsサービスにオンボーディングする必要があります。
  • 選択したエージェントにLog Analyticsプラグインをデプロイする必要があります。

エージェント・ログの有効化

ログを有効にするには、次を実行します。
  • [代理店]リストページで、目的のエージェントをクリックします。

    エージェントの詳細ページが表示されます。

  • 「エージェント・ログの有効化」をクリックします。

    選択したエージェントの「ログの有効化: エージェント」ウィンドウが表示されます。

  • ドロップダウン・リストから「ログ・グループ・コンパートメント」を選択します。
  • ドロップダウン・リストから「ログ・グループ」を選択します。

    新しいログ・グループを作成する場合は、「ログ・グループの作成」をクリックします。

    「ログ・グループの作成」ウィンドウで、「ログ・グループ名」および「説明」を入力します。その後、「作成」をクリックします。

  • 「有効化」をクリックします。

トラブルシューティング:

  • エージェントごとに、Log Analyticsで作成される対応するエンティティ(リソース)があります。選択したエージェントに一致するエンティティが見つからない場合、ロギングを有効にできません。この場合、ログを有効にするには、しばらくしてから再試行するか、エージェントをLog Analyticsのエンティティとして手動で追加します。詳細は、Log Analyticsログ出力リソースを表すエンティティの作成を参照してください。

エージェント・ログのソース・アソシエーションの検証

ログを有効にすると、関連付けをLog Analyticsで表示できます。
  • 「監視および管理」に移動し、「Log Analytics」に移動します。
  • 「Log Analytics」ページで、「管理」に移動します。

    左側のメニューから「ソース」を選択します。

    中央のペインから「Oracle Management Agentログ」を選択し、エージェントが「関連付けられたエンティティ」リストの下にリストされていることを確認します。

ログは、「エージェント詳細」ページで選択したログ・グループでのみ有効です。

ログ・データのパージ・ポリシーを設定するには、「ログ・データのパージ」(Log Analytics)を参照してください。

エージェント・ログの無効化

エージェント・ログを無効にすると、選択したエージェントのログのLog Analyticsへの継続的なアップロードが停止されます。

ログを無効にするには、次を実行します。
  • 「エージェント・ログの無効化」をクリックします。

    選択したエージェントの「エージェント・ログの無効化」ウィンドウが表示されます。

  • 「無効化」をクリックします。

データ・ソースの管理

「データ・ソースの管理」では、Prometheusデータソースなど、選択したエージェントで構成されているデータソースのプロパティおよびディメンションを表示または編集できます。

Prometheusデータ・ソースの前提条件:
  • 管理エージェントは、管理エージェント・バージョン231231.0001以上を使用してデプロイされました。
  • Prometheus Exporterの場合、管理エージェントは、同じ仮想マシン(VM)上、またはエクスポータのエンドポイントにアクセスできるVM上にある必要があります。この管理エージェントは、実行中のPrometheusエクスポータからメトリックをスクレイプするように構成されています。
データ・ソースを管理するには、次を実行します:
  • [代理店]リストページで、目的のエージェントをクリックします。

    エージェントの詳細ページが表示されます。

  • 「データ・ソースの管理」をクリックします。

    「データ・ソース」ウィンドウに、次の列を含む表が表示されます:
    • 名前:データソース名
    • タイプ:データ・ソースのタイプ。例: プロメテウス。
    • 状態:データ・ソースのステータス。
    • 作成時間:データ・ソースが作成されたときのタイムスタンプ。
    • アクション・アイテム : 特定のデータ・ソースで使用可能な処理をさらに表示します。
  • 特定のデータ・ソース名をクリックすると、「データ・ソースの表示」ウィンドウが表示されます。

    「データ・ソースの表示」を使用して、データ・ソースに関するすべての情報を表示します。

    たとえば、Prometheus Exporterからメトリック・データを表示できます。

  • データ・ソースを追加するには、「データ・ソースの追加」を使用します。
    • 「データ・ソースのタイプ」をドロップダウン・リストから選択します。例: プロメテウス。
    • 「名前」を使用して、新しいデータ・ソース名を入力します。
    • ドロップダウン・リストから「メトリック・コンパートメント」を選択します。
    • メトリック・ネームスペースを入力します。
    • Prometheus Exporterがメトリックの公開に使用する「URL」を入力します。
    • メトリック・ディメンションを追加するには、カスタム・メトリック・ディメンションを使用します。
    • 必要に応じて、「オプションのプロパティ」を使用します。
  • データ・ソースの削除: アクション・メニューアクション・アイテムを使用して、データ・ソースを削除します。
  • データ・ソースの編集: アクション・メニューアクション・アイテムを使用して、データ・ソースのプロパティを編集します。

    たとえば、メトリック・データをOCIモニタリング・サービスに公開するPrometheusエクスポータURLを変更できます。

ノート

Prometheus Exporterの場合は、ポリシーを作成する必要があります。

管理エージェントの制御

管理タスクの1つは、管理エージェントの状態を制御することです。管理エージェントの起動、停止およびステータスの確認を行うことができます。

エージェントの起動

エージェント・サービスを起動するには、次を実行します:

Linuxの場合:
  1. sudo権限を持つユーザーとしてログインします。

  2. 次のコマンドを実行します:

    Oracle Linux 6の場合: sudo /sbin/initctl start mgmt_agent

    Oracle Linux 7の場合: sudo systemctl start mgmt_agent

Windowsの場合:
  1. Administratorユーザーとしてログインし、「コマンド・プロンプト」ウィンドウを開きます。

  2. 次のコマンドを実行します: net start mgmt_agent

Solarisの場合:
  1. sudo権限を持つユーザーとしてログインし、rootユーザーとしてコマンドを実行します。

  2. 次のコマンドを実行します:

    sudo /etc/init.d/mgmt_agent start

エージェントの停止

エージェント・サービスを停止するには、次を実行します:

Linuxの場合:
  1. sudo権限を持つユーザーとしてログインします。

  2. 次のコマンドを実行します:

    Oracle Linux 6の場合: sudo /sbin/initctl stop mgmt_agent

    Oracle Linux 7の場合: sudo systemctl stop mgmt_agent

Windowsの場合:
  1. 管理者ユーザーとしてログインし、「コマンド・プロンプト」ウィンドウを開きます。

  2. 次のコマンドを実行します: net stop mgmt_agent

Solarisの場合:
  1. rootユーザーとしてコマンドを実行するsudo権限を持つユーザーとしてログインします。

  2. 次のコマンドを実行します:

    sudo /etc/init.d/mgmt_agent stop

エージェントの確認

エージェントのステータスを確認するには、次を実行します:

Linuxの場合:

  1. sudo権限を持つユーザーとしてログインします。

  2. 次のコマンドを実行します:

    Oracle Linux 6の場合: sudo /sbin/initctl status mgmt_agent

    Oracle Linux 7の場合: sudo systemctl status mgmt_agent

    詳細は、ログ・ファイル/opt/oracle/mgmt_agent/agent_inst/log/mgmt_agent.logを参照してください。

Windowsの場合:
  1. 管理者ユーザーとしてログインし、「コマンド・プロンプト」ウィンドウを開きます。

  2. 次のコマンドを実行します: sc query mgmt_agent

    詳細は、ログ・ファイルC:\Oracle\mgmt_agent\agent_inst\log\mgmt_agent.logを参照してください。

Solarisの場合:
  1. rootユーザーとしてコマンドを実行するsudo権限を持つユーザーとしてログインします。

  2. 次のコマンドを実行します: sudo /etc/init.d/mgmt_agent status

    詳細は、ログ・ファイル/opt/oracle/mgmt_agent/agent_inst/log/mgmt_agent.logを参照してください。

インストール・キーの管理

インストール・キーの作成

管理エージェントをインストールする前に、インストール・キーを作成する必要があります。

インストール・キーはアイデンティティ・ドメインに対して発行され、インストールの信頼性を検証します。管理エージェントのインストールを開始する前に、必ずインストール・キーを作成してください。

インストール・キーを作成するには:

  1. 管理エージェントのホーム・ページで、左側のメニューの「ダウンロードとキー」をクリックして、「インストール・キー」ペインを表示します。

    ページの下部に「インストール・キー」ペインが表示されます。

  2. 「インストール・キー」ペインで、「キーの作成」をクリックしてキーを作成します。

  3. 「キーの作成」ウィンドウに、必要な詳細を入力します。

    1. 「キー名」フィールドに、キーを識別するための名前を指定します。

    2. 「コンパートメント」フィールドで、ドロップダウン・リストからコンパートメントを選択します。これは、エージェント・リソースが作成されるコンパートメントです。

    3. 「最大インストール」フィールドに、キーに関連付けることができるインストールの最大数を示す数値を指定します。デフォルト値は1000です。

    4. 「有効な対象」フィールドに、キーの有効期間を示す数値を指定します。デフォルト値は1週間です。

    5. 「無制限」チェック・ボックスはオプションです。

      これを選択すると、エージェントおよびゲートウェイのインストールを無制限に使用でき、キーは期限切れになりません。

      無制限キーを使用するリスク: Oracleでは、インストール・キーの存続期間を、最小限必要な時間と限られた数のエージェントに保持することをお薦めします。機密性を保護するために、ダウンロードしたキーをセキュアな場所に保持します。無制限のインストール・キーが危険にさらされた場合、攻撃者はテナンシに不正エージェントをインストールできます。テナンシのエージェントを定期的に監査することで、無制限のインストール・キーに関連する潜在的なリスクを軽減できます。無制限のインストール・キーが不要になった場合は、管理エージェント・コンソールまたはCLIを使用して必ず削除してください。

    「キーの作成」ダイアログ・ボックス。

    新しいキーが作成されました。

「インストール・キー」ペインには、キーの管理に使用できる様々なオプションが用意されています。「キーをファイルにダウンロード」オプションは、レスポンス・ファイルの構成の説明に従って、レスポンス・ファイル・テンプレートとして使用できるファイルをダウンロードするのに役立ちます。

インストール・キーの管理の詳細は、インストール・キーの管理を参照してください。

ノート

管理ゲートウェイをインストールしている場合、同じインストール・キーを使用して管理ゲートウェイと管理エージェントをインストールできます。管理ゲートウェイの詳細は、管理ゲートウェイを参照してください。

インストール・キーのコピー

「インストール・キー」ペインで、インストール・キーをクリップボードにコピーできます。

  1. 管理エージェントのホーム・ページで、左側のメニューの「ダウンロードとキー」をクリックして、「インストール・キー」ペインを表示します。

    「インストール・キー」ペインが表示されます。

  2. インストール・キーのリストから、クリップボードにコピーするキーを選択します。
  3. 選択したキーの右側で、アクション・メニューアクション・メニューをクリックし、「キーをクリップボードにコピー」を選択します。

    アクション・メニュー・リストの「キーをクリップボードにコピー」オプションを表示している「インストール・キー」リスト。

    キーがクリップボードにコピーされます。

「キーをクリップボードにコピー」オプションは、エージェントの構成プロセス中にレスポンス・ファイルを作成するときに、キーの値をコピーして貼り付けるために役立ちます。詳細は、レスポンス・ファイルの作成を参照してください。

インストール・キーのダウンロード

「インストール・キー」ペインで、インストール・キーをダウンロードできます。

  1. 管理エージェントのホーム・ページで、左側のメニューの「ダウンロードとキー」をクリックして、「インストール・キー」ペインを表示します。

    「インストール・キー」ペインが表示され、既存のすべてのキーがリスト表示されます。

  2. インストール・キーのリストから、ダウンロードするキーを選択します。
  3. 選択したキーの右側で、アクション・メニューアクション・メニューをクリックし、「キーをファイルにダウンロード」を選択します。

    アクション・メニュー・リストの「キーをファイルにダウンロード」オプションを表示している「インストール・キー」リスト。

    ファイルがダウンロードされます。

「キーをファイルにダウンロード」オプションは、エージェント・パラメータを含むファイルをダウンロードするために役立ちます。このファイルは、エージェントのインストール・プロセスでレスポンス・ファイルとして使用できます。詳細は、レスポンス・ファイルの作成を参照してください。

インストール・キーの削除

「インストール・キー」ペインで、インストール・キーを削除できます。

  1. 管理エージェントのホーム・ページで、左側のメニューの「ダウンロードとキー」をクリックして、「インストール・キー」ペインを開きます。

    「インストール・キー」ペインが表示され、既存のすべてのキーがリスト表示されます。

  2. インストール・キーのリストから、削除するキーを選択します。

  3. 選択したキーの右側で、アクション・メニューアクション・メニューをクリックし、「キーの削除」を選択します。

    アクション・メニュー・リストの「キーの削除」オプションを表示している「インストール・キー」リスト。

  4. 「キーの削除」をクリックします。
  5. 「削除」を押して操作を確定します。

「キーの削除」オプションは、認可されていないユーザーがエージェント・インストール・キーの値を入手したと思われる場合に役立ちます。

管理エージェントのアップグレード

管理エージェントのアップグレードには、次の2つの方法があります:

管理エージェントの一括アップグレードの詳細は、チュートリアル「Ansible Playbookを使用したOracle Management Agentの一括アップグレード」を参照してください。

複数の仮想マシンにわたって管理エージェントをアップグレードできます。詳細は、OCI Management Agent: 複数の仮想マシンにわたる管理エージェントのアップグレード方法のビデオを参照してください。

自動アップグレード

管理エージェント・サービスでは、自動アップグレードがサポートされています。

自動アップグレード機能の有効化は、テナンシ・レベルで行われます。ユーザーは、現在のテナンシに存在するすべての管理エージェントで自動アップグレードを有効にできます。

要件:

  • 権限: 自動アップグレード機能を有効にするには、テナンシ・ルート・コンパートメントのMGMT_AGENT_UPDATE権限が必要です。次のポリシー構文を使用します:

    ALLOW GROUP <group_name> TO USE management-agents IN TENANCY

    管理エージェント・ポリシーの詳細は、管理エージェントの詳細を参照してください。

  • 管理エージェントの最小バージョン: 210918.1427以上。

デフォルトの自動アップグレード・ステータス: 無効。

自動アップグレードの有効化

Oracle Cloudコンソールを使用して、テナンシ内のエージェントの自動アップグレードを有効にできます。エージェントがアップグレードすると、Java Development Kit (JDK)も自動的にアップグレードされます。アップグレードされたJDKはエージェントにバンドルされており、次のパスにあります。
/var/lib/oracle-cloud-agent/plugins/oci-managementagent/polaris/jdk1.8.0_XXX
  1. 管理エージェントのホームページで、「ダウンロードとキー」を選択します。自動アップグレードの有効化
  2. 「自動アップグレードの有効化」を選択します。
  3. 「OK」を選択して、現在のテナンシのすべての管理エージェントの自動アップグレードを有効にします。

自動アップグレードの無効化

自動アップグレードは、管理エージェント・コンソールを使用して無効化できます。

  • 管理エージェント のホーム・ページで、左側のメニューの「ダウンロードとキー」をクリックします。

    「エージェント自動アップグレード」ペインがページの上部に表示されます。

    自動アップグレードの無効化

  • 「エージェント自動アップグレード」ペインで、「自動アップグレードの無効化」をクリックします。

    「自動アップグレードの無効化」ウィンドウが表示されます。

  • 「自動アップグレードの無効化」ウィンドウで、「OK」をクリックして、現在のテナンシのすべての管理エージェントの自動アップグレードを無効にします

自動アップグレードの有効化または無効化に使用できるCLIコマンドのリストは、Oracle Cloud Infrastructure CLIコマンド・リファレンスを参照してください。

手動アップグレード

エージェントがアップグレードすると、Java Development Kit (JDK)も自動的にアップグレードされます。アップグレードされたJDKはエージェントにバンドルされており、次のパスにあります。
/var/lib/oracle-cloud-agent/plugins/oci-managementagent/polaris/jdk1.8.0_XXX

管理エージェントでは、次のオペレーティング・システムでの手動アップグレードがサポートされています:

Linux手動アップグレード(RPMファイル)

RPMファイルを使用してLinux上のエージェントをアップグレードするには、次を実行します:
  • エージェント・ソフトウェア・ダウンロード・ファイルを含む、最新バージョンのRPMファイルをダウンロードします。管理エージェント・ソフトウェアのダウンロードを参照してください。
  • エージェントをアップグレードするには、rpm -Uアップグレード・オプションを指定してrpmコマンドを実行します:
    sudo rpm -U <rpm_file_name.rpm>

Linux手動アップグレード(ZIPファイル)

ZIPファイルを使用してLinux上のエージェントをアップグレードするには、次を実行します:
  • エージェント・ソフトウェア・ダウンロード・ファイルを含む、最新バージョンのZIPファイルをダウンロードします。管理エージェント・ソフトウェアのダウンロードを参照してください。
  • 管理エージェント・ソフトウェアのZIPファイルをダウンロードしたディレクトリに移動し、このファイルを任意の場所に解凍します。
  • エージェントをアップグレードするには、-uオプションを指定してinstaller.shスクリプトを実行します:
    installer.sh -u
    出力は、次のようになります。
    sudo ./installer.sh -u 
    Checking pre-requisites
        Checking available disk space for agent upgrade    
        Checking agent version
    
    Executing install
        Unpacking software zip
        Copying files to destination dir (/opt/oracle/mgmt_agent)
        Updating communication wallet
        Creating 'mgmt_agent' daemon
        Starting mgmt_agent
        Agent Install Logs: /opt/oracle/mgmt_agent/installer-logs/installer.log.0
    
    Agent upgrade successful

Windowsでの手動アップグレード

Windows上のエージェントをアップグレードするには、次を実行します:
  • 管理者ユーザーとしてログインし、「コマンド・プロンプト」ウィンドウを開きます。
  • エージェント・ソフトウェア・ダウンロード・ファイルを含む、最新バージョンのZIPファイルをダウンロードします。管理エージェント・ソフトウェアのダウンロードを参照してください。
  • 管理エージェント・ソフトウェアのZIPファイルをダウンロードしたディレクトリに移動し、このファイルを任意の場所に解凍します。
  • エージェントをアップグレードするには、-uオプションを指定してinstaller.batスクリプトを実行します: installer.bat -u
    出力は、次のようになります。
    C:\Users\test_agent>installer.bat -u 
    Checking pre-requisites
    
         Checking if C:\Oracle\mgmt_agent\200821.0751 directory exists 
         Checking available disk space for agent install
         Checking Java version
                  Java version: 1.8.0_261 found at C:\Program Files\Java\jdk1.8.0_261
    
    Executing Upgrade
            Unpacking software zip
            Copying files to destination dir(C:\Oracle\mgmt_agent)
            Initializing software from template
            Creating mgmt_agent service
    
    Agent Upgrade  successful

Solarisでの手動アップグレード

Solaris上のエージェントをアップグレードするには、次を実行します:
  • エージェント・ソフトウェア・ダウンロード・ファイルを含む、最新バージョンのZIPファイルをダウンロードします。管理エージェント・ソフトウェアのダウンロードを参照してください。
  • 管理エージェント・ソフトウェアのZIPファイルをダウンロードしたディレクトリに移動し、任意の優先場所に解凍します。
  • エージェントをアップグレードするには、rootユーザーとしてログインし、-uオプションを指定してinstaller.shスクリプトを実行します:
    installer.sh -u
    出力は、次のようになります。
    sudo ./installer.sh -u 
    Checking pre-requisites
        Checking available disk space for agent upgrade    
        Checking agent version
    
    Executing install
        Unpacking software zip
        Copying files to destination dir (/opt/oracle/mgmt_agent)
        Updating communication wallet
        Creating 'mgmt_agent' daemon
        Starting mgmt_agent
        Agent Install Logs: /opt/oracle/mgmt_agent/installer-logs/installer.log.0
    
    Agent upgrade successful

AIX手動アップグレード(ZIPファイル)

ZIPファイルを使用してAIXのエージェントをアップグレードするには、次の手順を実行します。
  • エージェント・ソフトウェア・ダウンロード・ファイルを含む、最新バージョンのZIPファイルをダウンロードします。管理エージェント・ソフトウェアのダウンロードを参照してください。
  • 管理エージェント・ソフトウェアのZIPファイルをダウンロードしたディレクトリに移動し、このファイルを任意の場所に解凍します。
  • エージェントをアップグレードするには、-uオプションを指定してinstaller.shスクリプトを実行します:
    installer.sh -u
    出力は、次のようになります。
    sudo ./installer.sh -u 
    Checking pre-requisites
            Checking available disk space for agent upgrade
            Checking agent version
    
    Executing install
            Unpacking software zip
            Copying files to destination dir (/opt/oracle/mgmt_agent)
            Updating communication wallet
            Creating mgmt_agent daemon
            Starting mgmt_agent
            Agent Install Logs: /opt/oracle/mgmt_agent/installer-logs/installer.log.0
    
    Agent upgrade successful

管理エージェントの削除

ホストに関連付けられた管理エージェントを削除すると、管理エージェントは、管理エージェントCloud Serviceから登録解除されてからホストから削除されます。

次の理由で、ホストからエージェントを削除できます:
  • ターゲット・ホストにデプロイされたエージェントが必要なくなりました。
  • 特定のターゲット・ホストからデータ、パフォーマンス・メトリックまたはログを収集する必要がなくなりました。
  • デプロイメント・トポロジを変更しました。

このトピックでは、管理エージェントを削除する方法について説明します。

ユーザー・インタフェースでのエージェントの削除

ユーザー・インタフェースでエージェントを削除するには、次を実行します:
  1. 「エージェント」リストでエージェントを選択し、アクション・メニューをクリックします。

    図4-1 エージェントの削除

    アクション・メニュー・リストの「エージェントの削除」オプションを表示している「エージェント」リスト・ページ。
  2. 「エージェントの削除」をクリックします。

  3. 「削除」を押して選択を確定します。

エージェントは管理エージェント・ユーザー・インタフェースから削除されますが、エージェント・ソフトウェアはターゲット・ホストから削除されません。ユーザーがホストに接続し、ホストからエージェント・ソフトウェアを手動で削除する必要があります。Linuxの場合は、rpmコマンドを-eオプションとともに使用します。

コマンドライン・インタフェースでのエージェントの削除

エージェントをコマンドライン・インタフェースから削除すると、そのエージェントとエージェント・ソフトウェアがホストから削除されます。

次のオペレーティング・システムから管理エージェントを削除(アンインストール)します。

RPMコマンドを使用するLinux

-eオプションを指定してrpmコマンドを実行します。
sudo rpm -e <rpm_name>

アンインストーラ・スクリプトを使用するLinux

ZIPファイルを使用してエージェントをインストールした場合は、uninstaller.shスクリプトを実行します。

出力は、次のようになります。

$ sudo bash /opt/oracle/mgmt_agent/agent_inst/bin/uninstaller.sh
Executing pre-remove step from uninstall
Attempting to remove the agent from Management Agent Cloud service, please do not interrupt...
Attempting to remove the agent from Management Agent Cloud service, please do not interrupt...
Agent was removed from Management Agent Cloud service successfully.
Detected Oracle Linux Server (Red Hat family):
Stopping mgmt_agent...
Removing mgmt_agent daemon from systemd...
Removed symlink/etc/systemd/system/multi-user.target.wants/mgmt_agent.service.
Agent was removed from the host successfully.
Executing post-remove step from uninstall
Agent state directory was removed from the host successfully.
ノート

Linuxに外部ボリュームを使用して管理エージェントをインストールした場合、管理エージェント・アンインストーラ・スクリプトは/opt/oracle/mgmt_agentディレクトリの下のすべてのデータを削除し、一部のオペレーティング・システムでは、シンボリックリンクが指すターゲット・ディレクトリも削除します。

Windows

コマンド・プロンプト・ウィンドウを開き、エージェント・インストール・ベース・ディレクトリに移動して、uninstaller.batスクリプトを実行します。

出力は、次のようになります。
C:\Oracle>mgmt_agent\uninstaller.bat
Removing agent from Management Agent Cloud Service
Attempting to remove the agent from Management Agent Cloud service, please do not interrupt...
Agent was removed from Management Agent Cloud service successfully.
Removing agent service from the host
Agent service was removed from the host successfully
Removing agent directories

uninstaller.batスクリプトを実行する前に、他のすべてのコマンド・プロンプト・ウィンドウが閉じていること、またはそれらによってエージェント・ホーム・ディレクトリが指定されていないことを確認してください。

Solaris

rootユーザーとしてuninstaller.shスクリプトを実行します。

出力は次のとおりです。

sudo bash /opt/oracle/mgmt_agent/agent_inst/bin/uninstaller.sh
Executing pre-remove step from uninstall
Attempting to remove the agent from Management Agent Cloud service, please do not interrupt...
Attempting to remove the agent from Management Agent Cloud service, please do not interrupt...
Agent was removed from Management Agent Cloud service successfully.
Detected Oracle Linux Server (Red Hat family):
Stopping mgmt_agent...
Removing mgmt_agent daemon from systemd...
Removed symlink /etc/systemd/system/multi-user.target.wants/mgmt_agent.service.
Agent was removed from the host successfully.
Executing post-remove step from uninstall
Agent state directory was removed from the host successfully.

AIX

rootユーザーとしてuninstaller.shスクリプトを実行します。

出力は次のとおりです。

sudo sh /opt/oracle/mgmt_agent/agent_inst/bin/uninstaller.sh
Executing pre-remove step from uninstall
Attempting to remove the Agent from Management Agent Cloud service, please do not interrupt...
Attempting to remove the Agent from Management Agent Cloud service, please do not interrupt...
Agent was removed from Management Agent Cloud service successfully.
Detected AIX:
Stopping mgmt_agent...
Waiting for mgmt_agent to exit...
Stopped mgmt_agent.
Removing mgmt_agent daemon...
0513-083 Subsystem has been Deleted.
Agent was removed from the host successfully.
Executing post-remove step from uninstall
Agent state directory was removed from the host successfully.

デフォルト以外のOSユーザーを使用した管理エージェントのインストール

Oracleでは、デフォルトのOSユーザーmgmt_agentを使用して管理エージェントのインストールを実行することをお薦めしますが、要件によっては、別のOSユーザーを使用してインストールを実行する必要がある場合があります。

この項では、デフォルトのOSユーザーであるmgmt_agentとは異なるユーザーを使用して管理エージェントをインストールする方法について説明します。

前提条件

ノート

mgmt_agent以外のOSユーザーを選択してLinuxまたはUnixシステムで管理エージェントのインストールを実行する場合、次の考慮事項を考慮する必要があります。

  • 制限された権限を持つOSユーザーを選択します。

    デフォルトのmgmt_agent OSユーザーは、ログイン・シェルがない最小権限のOSユーザーです。かわりに別のOSユーザーを選択する場合は、選択したユーザーに制限された権限があることを確認してください。

  • 管理エージェントはマルチスレッド・アプリケーションであり、各スレッド(LWP)はOSユーザー制限にカウントされます。次をチェックして、max user processesのユーザー制限(ulimit)が適切に設定されていることを確認します:
    ulimit -u

    不十分な制限を選択すると、管理エージェントおよび選択したOSユーザーとして実行されるアプリケーションが不安定になる可能性があります。

  1. 管理エージェントのインストールを実行する有効なOSユーザーを特定し、RUN_AGENT_AS_USER変数の値として使用します。
    Oracleでは、選択したOSユーザーには最小限の権限とログイン・シェルを使用しないことをお薦めします。
    id -un <username>

    例1:

    id -un myexistinguser
    myexistinguser OSユーザーが存在します。出力は、選択したユーザーの値を返し、次のようになります。
    myexistinguser
    例2:
    id -un mytestuser2
    mytestuser2 OSユーザーが存在しないため、有効なユーザーではありません。出力ではユーザー値は返されず、次のようになります。
    id: mytestuser2: no such user
  2. AGENT_USER_GROUP変数の値として使用するユーザーのプライマリ・グループを識別します。
    AGENT_USER_GROUPの値が、選択したOSユーザーのプライマリ・ユーザー・グループであることを確認します。
    ノート

    セカンダリ・グループの使用はサポートされていないため、管理エージェントが破損する可能性があります。
    id -gn <username>
    例:
    id -gn myexistinguser
    次のように出力されます。
    staff

環境変数の設定および管理エージェントのインストール

  1. 次の環境変数を設定します。
    RUN_AGENT_AS_USER=<selected_OS_user_for_ManagementAgent_installation>
    AGENT_USER_GROUP=<OS_primary_group_of_selected_OS_user>
    例:
    RUN_AGENT_AS_USER=myexistinguser
    AGENT_USER_GROUP=staff
  2. root OSユーザーが前述の環境変数にアクセスできることを確認します。

    デフォルトでは、環境変数はrootユーザーと共有されません。

  3. 次を実行して、環境変数が正しく設定されていることを確認します。
    sudo su
    echo $RUN_AGENT_AS_USER
    echo $AGENT_USER_GROUP
    たとえば、出力は次のようになります。
    myexistinguser
    staff
    rootが環境変数にアクセスできない場合は、/etc/sudoersファイルを編集して、次を追加します。
    Defaults env_keep+=RUN_AGENT_AS_USER
    Defaults env_keep+=AGENT_USER_GROUP

    前述のとおり、RUN_AGENT_AS_USERおよびAGENT_USER_GROUP環境変数は保持され、rootユーザーがアクセスできるようになります。

    /etc/sudoersファイルを更新した後、環境変数を再度設定し、rootが環境変数にアクセスできることを確認します。

  4. 検証が完了したら、管理エージェントのインストールを開始できます: rootとしてログインし、環境変数を設定し、管理エージェントのインストールを開始します。

    希望する方法に応じて、Linuxへの管理エージェントのインストール(RPMファイル)またはLinuxへの管理エージェントのインストール(ZIPファイル)の手順に従うことができます。

    たとえば、Linuxへの管理エージェントのインストール(RPMファイル)の手順に従います。この場合、すでにrootであり、sudo権限は必要ないため、ステップ1をスキップします。ステップ2から開始: rpm -ivh <rpm_file_name.rpm>

管理エージェントでの資格証明の作成および管理

エージェントに資格証明を追加すると、エージェントは、アクションを実行するために資格証明を必要とするリソースに接続できます。

エージェントに資格証明を追加するには、次の2つの方法があります。
  • オプション1。管理エージェント・サービスでは、Oracleでは、Oracle CloudコンソールまたはAPIを使用して名前付き資格証明を追加することをお薦めします。
  • オプション2。エージェントの構成ファイルでソース資格証明を構成して、エージェントが様々なソースからデータを収集できるようにします。

オプション1。コンソールおよびAPIを使用したエージェントでの名前付き資格証明の作成および管理

ユーザー・シナリオ

名前付き資格証明では、構成ファイルに資格証明のユーザー名、パスワードまたはその他の識別子を格納せずに、セキュリティを強化するボールトおよびシークレットを使用します。OCI Vaultsに格納されたシークレットは、一元的に格納および管理され、エージェントにデプロイされたプラグインまたはサービスの複数の名前付き資格証明で再利用できます。

名前付き資格証明を作成および管理するには、次を使用します。

前提条件

名前付き資格証明の使用を開始する前に、テナンシ管理者が次のタスクを完了する必要があります。

  • 管理エージェントのバージョン: 250704.1404以上がインストールされていることを確認します。
  • ユーザーに対して次を構成します。
  • エージェント・リソースの権限およびポリシーを構成します。これを行うには:
    • 次の例を使用して、エージェント・リソースの動的グループを作成します。ocid1.compartment.oc1.agentcompartmentidをエージェントのコンパートメントOCIDに置き換えます。コンソールでの動的グループの作成方法および動的グループの管理を参照してください。

      ALL {resource.type='managementagent', resource.compartment.id='ocid1.compartment.oc1.agentcompartmentid'}
    • 次のポリシーを追加して、動的グループが特定のコンパートメント内のシークレットを読み取ることを許可し、ocid1.compartment.oc1.secretcompartmentidをシークレットのコンパートメントOCIDに置き換えます。ポリシーの文の更新を参照してください。
      allow dynamic-group X to read secret-bundles in compartment ocid1.compartment.oc1.secretcompartmentid
    • また、エージェントには、名前付き資格証明の作成に使用されるOCIリソースの権限およびポリシーも必要です。たとえば、エージェントが名前付き資格証明を使用して自律型データベースと対話する場合、エージェントの動的グループが自律型データベース・ウォレットを読み取ることを許可するポリシーを作成する必要があります。例:
      allow dynamic-group X to read autonomous-databases in compartment DB_COMPARTMENT
名前付き資格証明の権限を設定すると、異なる権限を持つユーザーを設定できます。各ユーザーは、異なるアクセス・レベルの権限を使用してタスクを実行できます。たとえば、次のものを構成できます。
  • MGMT_AGENT_NAMED_CREDENTIAL_APPLY権限を持つオペレータ・ユーザー、およびユーザーがアクセス権を持つエージェントは、名前付き資格証明を使用して、パスワードにアクセスすることなくアクションを実行できます。この権限を持つユーザーは、名前付き資格証明に含まれているボールトまたはシークレットOCIDsを表示できません。
  • 次の権限を持つ管理者ユーザーは、名前付き資格証明に対して標準のCRUD操作を実行でき、ボールトからシークレットのバンドルを読み取るアクセス権がありません。
    • MGMT_AGENT_NAMED_CREDENTIAL_CREATE

    • MGMT_AGENT_NAMED_CREDENTIAL_UPDATE

    • MGMT_AGENT_NAMED_CREDENTIAL_DELETE

  • ユーザーがMGMT_AGENT_DELETE権限を持っている場合、ユーザーはエージェント・リソースを削除でき、関連付けられた名前付き資格証明もすべて削除されます。
    ノート

    エージェントまたは名前付き資格証明を削除しても、OCIボールトに格納されているシークレットには影響しません。

Oracle Cloudコンソールを使用した名前付き資格証明の作成

Oracle Cloudコンソールでは、名前付き資格証明を追加、編集または削除できます。

名前付き資格証明を作成するには、更新するエージェントを見つけます:
  1. ナビゲーション・メニューを開き、「監視および管理」を選択します。「管理エージェント」で、「エージェント」を選択します。
  2. リストするエージェントを含むコンパートメントを選択します。子コンパートメントを含む、選択したコンパートメント全体のエージェント詳細の概要を取得するサブコンパートメントを含めるには、オプションを選択します。
  3. 「アクション」メニューから、「名前付き資格証明の管理」を選択します。
    • または、「エージェントの詳細」ページに移動し、「他のアクション」オプションを選択して、「名前付き資格証明の管理」を選択できます。
  4. 「資格証明名」を入力します。オプションで、説明を入力できます。
  5. 「資格証明タイプ」ドロップダウン・リストから、追加する資格証明のタイプを選択します。
  6. 選択した資格証明タイプのフィールドまたは属性ごとに、値を入力するか、リソース識別子を選択するか、ボールトおよびシークレット識別子を選択します。

    リソースが別のコンパートメントに存在する場合、「コンパートメントの変更」を選択してコンパートメントを変更し、リソースの値を検索できます。

  7. タグを追加するには、「拡張オプションの表示」を選択します。
    • タグを追加するには、タグ・ネームスペースを選択し、タグ・キーおよびタグ値を入力して、「タグの追加」を選択します。タグを追加することで、資格証明へのアクセスを制限できます。名前付き資格証明の作成に必要な権限がある場合、フリーフォーム・タグを追加する権限もあります。定義済タグを追加するには、タグのネームスペースに対する権限も必要です。詳細は、タグ付けの概要を参照し、リソースの作成時にタグを追加する方法を学習するには、リソース・タグの操作を参照してください。
    • タグを削除するには、「X」を選択します。
  8. 「保存」を選択して、エージェントに名前付き資格証明を追加します。名前付き資格証明を保存できない場合は、すべての必須フィールドを入力したことを確認します。

    名前付き資格証明が保存されると、作業リクエストがエージェントに送信されます。作業リクエストが完了すると、エージェントはこれらの名前付き資格証明を使用して、エージェントにデプロイされた複数のプラグインまたはサービス間で様々なタスクを実行できます。

    ノート

    作業リクエストが失敗した場合は、エージェントにSECRET_READ権限があることを確認し、ボールト・シークレットにアクセスしてGetSecret操作を実行します。Vault、キー管理およびシークレットの詳細を参照してください。

    エージェントの名前付き資格証明を編集または削除するには:

    1. 更新するエージェントを検索すると、次のことができます。
      • 「エージェント」リスト・ページに移動します。更新するエージェントの横で、「アクション」メニューを選択し、「名前付き資格証明の管理」を選択します。
      • または、「エージェントの詳細」ページに移動し、「他のアクション」オプションを選択して、「名前付き資格証明の管理」を選択できます。
    2. 「編集」または「削除」を選択します。ユーザー名およびパスワードのボールト詳細を編集できます。資格証明の名前またはタイプは編集できません。
      ノート

      アクティブに使用されている名前付き資格証明を削除すると、エージェント上のソースのモニタリングが中断される可能性があります。

APIを使用した名前付き資格証明の作成および管理

名前付き資格証明を管理するAPIのリストは、管理エージェントの名前付き資格証明APIを参照してください。

OCI CLIを使用した名前付き資格証明の作成および管理

名前付き資格証明を管理するためのCLIコマンドのリストは、管理エージェントの名前付き資格証明用のOracle Cloud Infrastructure CLIを参照してください。

ノート

管理エージェント・サービスで名前付き資格証明を作成した後、名前付き資格証明をサポートする他のOracle Cloud Infrastructure (OCI)サービスで使用できます。詳細は、特定のOCIサービスを参照してください。

たとえば、Opsインサイト・サービスを使用している場合は、Opsインサイト・ドキュメントの「Autonomous Databasesおよびフル機能サポートの有効化」で接続プロパティを確認します。

オプション2。エージェントレベルでのソース資格情報の作成と管理

管理エージェントにプラグインをデプロイした後で、場合によっては、エージェントが様々なソースからデータを収集できるようにソース資格証明を構成する必要があります。

データ・ソースごとに異なる方法で資格証明が管理されます。ソース資格証明の構成は、エージェントにデプロイされたプラグインまたはサービスのタイプに固有です。詳細は、プラグインまたはサービスのドキュメントを参照してください。

ソース資格証明タイプ

エージェントの資格証明ストアには、エージェントが把握して認識する資格証明(Oracle Database資格証明など)と、特定のサービスのみが認識する資格証明が格納されます。エージェントは、組込み資格証明タイプを検証しますが、検証なしで他の自由形式タイプも受け入れます。

自由形式の資格証明

ユーザーは、1つ以上の機密プロパティを含む任意のタイプの資格証明を定義できます。これらは自由形式であるため、分類できません。

例:

SSHKeyCreds

エージェントがSSHキー資格証明を必要とする、SSH RSAキー資格証明。

この資格証明の例を次に示します。SSHUserNameSSHPrivateKeyおよびSSHPublicKeyは、大/小文字が区別されるプロパティです。

{"source":"<DATA_SOURCE_NAME>", 
"name":"OSCreds", 
"type":"SSHKeyCreds", 
"description":"<DESCRIPTION>", 
"properties":[
{"name":"SSHUserName","value":"<USER_NAME>"},               
{"name":"SSHPrivateKey","value":"<RSA_PRIVATE_KEY>"},
{"name":"SSHPublicKey","value":"<PUBLIC KEY>"]}

例:

{"source":"host.myvm.example.com", 
"name":"OSCreds", 
"type":"SSHKeyCreds", 
"description":"SSH keys for a user", 
"properties":[
{"name":"SSHUserName","value":"username"},               
{"name":"SSHPrivateKey","value":"-----BEGIN RSA PRIVATE KEY-----<RSA_PRIVATE_KEY>-----END RSA PRIVATE KEY-----"},
{"name":"SSHPublicKey","value":"-----BEGIN PUBLIC KEY-----<PUBLIC KEY>-----END PUBLIC KEY-----"]}
組込み資格証明

エージェントには、組込み資格証明タイプがいくつかあります。すべてのサービス・プラグインは、次のいずれかの資格証明タイプを使用してエージェントに資格証明を提供できます:
管理ゲートウェイおよびプロキシの資格証明タイプ

ProxyCreds

これらの資格証明は、管理ゲートウェイまたはネットワーク・プロキシの認証に使用されます。

前提条件: 次の2つのプロパティを使用して、エージェントに管理ゲートウェイまたはプロキシを構成する必要があります:
  • GatewayServerHost。例: GatewayServerHost=myproxy.example.com
  • GatewayServerPort。例: GatewayServerPort=80
次の資格証明プロパティでは、大文字と小文字が区別されます:
  • ProxyUser: プロキシに対して認証するユーザー名。
  • ProxyPassword: ユーザーの認証に使用されるパスワード。

{"source":"<DATA_SOURCE_NAME>", 
"name":"ManagementAgent-Proxy", 
"type":"ProxyCreds", 
"description":"<DESCRIPTION>", 
"properties":[
{"name":"ProxyUser","value":"<USER_NAME>"},               
{"name":"ProxyPassword","value":"<USER_PASSWORD>"}]}

例:

{"source":"agent.ocid1.managementagent.unique-identifier", 
"name":"ManagementAgent-Proxy", 
"type":"ProxyCreds", 
"description":"Proxy Credentials", 
"properties":[
{"name":"ProxyUser","value":"user-name"},               
{"name":"ProxyPassword","value":"example-password"}]}
ノート

これらの資格証明は、エージェントによってOracle Cloud Infrastructureサービスと通信するために使用されます。形式を変更したり資格証明を削除したりすると、エージェントがOracle Cloud Infrastructureサービスに通信を行う機能に悪影響を及ぼす可能性があります。

データベース用の資格証明タイプ

DBCreds

これらの資格証明は、TCPプロトコルを使用したOracleデータベースへの認証に使用されます。

次のプロパティでは大/小文字が区別されます:
  • DBUserName: データベース・ユーザー名。
  • DBPassword: データベース・ユーザーのパスワード。
  • DBRole: データベース・ユーザーのロール。SYSDBA、SYSOPER、NORMALのいずれかです。指定しない場合、NORMALが使用されます。
{"source":"<DATA_SOURCE_NAME>", 
"name":"SQLCreds", 
"type":"DBCreds", 
"description":"<DESCRIPTION>", 
"properties":[
{"name":"DBUserName","value":"<DB_USER_NAME>"},               
{"name":"DBPassword","value":"<DB_USER_PASSWORD>"},               
{"name":"DBRole","value":"<DB_ROLE>"}]}

例:

{"source":"auditvault_db.myhost", 
"name":"SQLCreds", 
"type":"DBCreds", 
"description":"This is a credential that can be used for operations on DATASAFE databases.", 
"properties":[
{"name":"DBUserName","value":"sys"},               
{"name":"DBPassword","value":"sys"},               
{"name":"DBRole","value":"SYSDBA"}]}

DBANOCreds

これらの資格証明は、TCPプロトコルを使用したOracleデータベースへの認証に使用されます。

次のプロパティでは大/小文字が区別されます:
  • DBUserName: データベース・ユーザー名。
  • DBPassword: データベース・ユーザーのパスワード。
  • DBRole: データベース・ユーザーのロール。SYSDBA、SYSOPER、NORMALのいずれかです。指定しない場合、NORMALが使用されます。
  • DBEncryptionTypes: カッコで囲んだ、暗号化アルゴリズムのカンマ区切りリスト。
  • DBEncryptionLevel: クライアントによって指定された暗号化のレベル。REJECTED、ACCEPTED、REQUESTED、REQUIREDのいずれかです。指定しない場合、ANOサービスのデフォルトが使用されます。
  • DBChecksumTypes: カッコで囲んだ、チェックサム・アルゴリズムのカンマ区切りリスト。
  • DBChecksumLevel: クライアントによって指定された整合性のレベル(REJECTED、ACCEPTED、REQUESTED、REQUIRED)。指定しない場合、ANOサービスのデフォルトが使用されます。
{"source":"<DATA_SOURCE_NAME>", 
"name":"SQLCreds", 
"type":"DBANOCreds", 
"description":"<DESCRIPTION>", 
"properties":[
{"name":"DBUserName","value":"<DB_USER_NAME>"},               
{"name":"DBPassword","value":"<DB_USER_PASSWORD>"},               
{"name":"DBRole","value":"<DB_ROLE>"},               
{"name":"DBEncryptionTypes","value":"<DB_ENCRYPTION_TYPE>"},               
{"name":"DBEncryptionLevel","value":"<DB_ENCRYPTION_LEVEL>"},               
{"name":"DBChecksumTypes","value":"<DB_CHECKSUM_TYPE>"},               
{"name":"DBChecksumLevel","value":"<DB_CHECKSUM_LEVEL>"}]}

例:

{"source":"auditvault_db.myhost", 
"name":"SQLCreds", 
"type":"DBANOCreds", 
"description":"This is a credential that can be used for operations on DATASAFE databases.", 
"properties":[
{"name":"DBUserName","value":"sys"},               
{"name":"DBPassword","value":"sys"},               
{"name":"DBRole","value":"SYSDBA"},               
{"name":"DBEncryptionTypes","value":"(AES256,AES192,AES128,3DES168,3DES112)"},               
{"name":"DBEncryptionLevel","value":"REQUIRED"},               
{"name":"DBChecksumTypes","value":"(SHA2)"},               
{"name":"DBChecksumLevel","value":"REQUESTED"}]}

DBTCPSCreds

これらの資格証明は、TCPSを使用した認証に使用されます。

次のプロパティでは大/小文字が区別されます:
  • DBUserName: データベース・ユーザー名。
  • DBPassword: データベース・ユーザーのパスワード。
  • DBRole: データベース・ユーザーのロール。SYSDBA、SYSOPER、NORMALのいずれかです。指定しない場合、NORMALが使用されます。
  • ssl_trustStoreType: トラスト・ストアのタイプ。
  • ssl_trustStoreLocation: トラスト・ストア・ウォレットのファイル・システム上の場所。エージェント・ユーザーがアクセスできる必要があります。
  • ssl_trustStorePassword: トラスト・ストア・ウォレットのパスワード。
  • ssl_keyStoreType: キー・ストアのタイプ。
  • ssl_keyStoreLocation: キー・ストア・ウォレットのファイル・システム上の場所。エージェント・ユーザーがアクセスできる必要があります。
  • ssl_keyStorePassword: キー・ストア・ウォレットのパスワード。
  • ssl_server_cert_dn: サーバー証明書のドメイン名。
    ノート

    管理エージェントのバージョン: 230207.1529 (2023年2月)以降、ssl_server_cert_dnプロパティはオプションです。(例: {"name":"ssl_server_cert_dn","value":"<SERVER_CERT_DN>"})。

    サーバー・ウォレットに値が含まれている場合、ユーザーはそれを資格証明に指定できます。ウォレットに存在しない場合、ユーザーは資格証明でそれを指定する必要はありません。

    以前のバージョンでは、管理エージェントは資格証明にこのプロパティが含まれていることを想定しています。ただし、ssl_server_cert_dnの値がないことを示すために、ユーザーは"unknownDn"値を指定する必要があります。

{"source":"<DATA_SOURCE_NAME>", 
"name":"SQLCreds", 
"type":"DBTCPSCreds", 
"description":"<DESCRIPTION>", 
"properties":[
{"name":"DBUserName","value":"<DB_USER_NAME>"},               
{"name":"DBPassword","value":"<DB_USER_PASSWORD>"},               
{"name":"ssl_trustStoreType","value":"<STORE_TYPE>"},               
{"name":"ssl_trustStoreLocation","value":"<STORE_LOCATION>"},               
{"name":"ssl_trustStorePassword","value":"<STORE_PASSWORD>"},               
{"name":"ssl_keyStoreType","value":"<KEY_STORE_TYPE>"},               
{"name":"ssl_keyStoreLocation","value":"<KEY_STORE_LOCATION>"},               
{"name":"ssl_keyStorePassword","value":"<KEY_STORE_PASSWORD>"},               
{"name":"ssl_server_cert_dn","value":"<SERVER_CERT_DN>"}]}

例:

{"source":"auditvault_db.myhost_pdb1_regress", 
"name":"SQLCreds", 
"type":"DBTCPSCreds", 
"description":"This is a TCPS credential that can be used for operations on DATASAFE databases.", 
"properties":[
{"name":"DBUserName","value":"C#AUDIT"},               
{"name":"DBPassword","value":"example-password"},               
{"name":"ssl_trustStoreType","value":"JKS"},               
{"name":"ssl_trustStoreLocation","value":"/home/jks_wallets/ewalletT.jks"},               
{"name":"ssl_trustStorePassword","value":"example-password"},               
{"name":"ssl_keyStoreType","value":"JKS"},               
{"name":"ssl_keyStoreLocation","value":"/home/jks_wallets/ewalletK.jks"},               
{"name":"ssl_keyStorePassword","value":"example-password"},               
{"name":"ssl_server_cert_dn","value":"CN=myvm.example.com"}]}

資格証明の追加または更新

資格証明を追加するには、upsertCredentials操作とともにcredential_mgmt.shスクリプトを使用します。

credential_mgmt.shスクリプトは/opt/oracle/mgmt_agent/agent_inst/binディレクトリにあります。

構文

credential_mgmt.sh -o upsertCredentials -s [service-name]
ノート

Oracle Cloud Agentプラグインを使用してコンピュート・インスタンス上で実行している管理エージェントの場合、credential_mgmt.shスクリプトの場所は/var/lib/oracle-cloud-agent/plugins/oci-managementagent/polaris/agent_inst/binです。

  1. 資格証明情報を含むJSONファイルを作成します。

    次の例は、orcl123という名前のdatasafe_dbソース用の資格証明タイプの形式です:

    {"source":"datasafe_db.orcl123", 
    "name":"audit_cred", 
    "description":"This is the audit credential for orcl123 Oracle RDBMS system.", 
    "properties":[ 
    {"name":"username","value":"CLEAR[scott]"}, 
    {"name":"password","value":"CLEAR[tiger]"}]
    }

    たとえば、このファイルをmy_credentials.jsonとして保存できます。

  2. JSONファイルを使用して資格証明を追加します。

    credential_mgmt.sh -o upsertCredentials -s [service-name]

    たとえば、my_credentials.jsonファイルを使用して、DataSafeサービスに対して次を実行できます:

    cat my_credentials.json | sudo -u mgmt_agent /opt/oracle/mgmt_agent/agent_inst/bin/credential_mgmt.sh -o upsertCredentials -s datasafe
  3. ステップ1で作成したJSONファイルを削除します。

    資格証明のJSONファイルには機密情報が含まれます。ユーザーは、資格証明の追加または更新操作を完了した後で、資格証明のJSONファイルを削除する必要があります。

資格証明の削除

資格証明を削除するには、deleteCredentials操作とともにcredential_mgmt.shスクリプトを使用します。

credential_mgmt.shスクリプトは/opt/oracle/mgmt_agent/agent_inst/binディレクトリにあります。

構文

credential_mgmt.sh -o deleteCredentials -s [service-name]
  1. 次の形式を使用してJSONファイルを作成します:

    {"source":"datasafe_db.orcl123"
     "name":"audit_cred"} 

    たとえば、このファイルをmy_credentials.jsonとして保存できます。

  2. JSONファイルを使用して資格証明を削除します。

    credential_mgmt.sh -o deleteCredentials -s [service-name]

    たとえば、my_credentials.jsonファイルを使用して、DataSafeサービスに対して次を実行できます:

    cat my_credentials.json | sudo -u mgmt_agent /opt/oracle/mgmt_agent/agent_inst/bin/credential_mgmt.sh -o deleteCredentials -s datasafe
  3. ステップ1で作成したJSONファイルを削除します。

    資格証明のJSONファイルには機密情報が含まれます。ユーザーは、資格証明の削除操作を完了した後で、資格証明のJSONファイルを削除する必要があります。

資格証明別名の追加または更新

資格証明別名を追加したり、既存の資格証明別名を更新したりするには、aliasCredentials操作とともにcredential_mgmt.shスクリプトを使用します。

credential_mgmt.shスクリプトは/opt/oracle/mgmt_agent/agent_inst/binディレクトリにあります。

構文

credential_mgmt.sh -o aliasCredentials -s [service-name]
  1. 次の形式を使用してJSONファイルを作成します:

    {"alias":
     {"source":"datasafe_db.orcl123",
      "name":"audit_cred"},
     "credential":
      {"source":"datasafe_db.host.1521.orcl123",
       "name":"datasafe_cred"}}
    

    たとえば、このファイルをmy_credentials.jsonとして保存できます。

  2. JSONファイルを使用して資格証明別名を追加します。

    credential_mgmt.sh -o aliasCredentials -s [service-name]

    たとえば、my_credentials.jsonファイルを使用して、DataSafeサービスに対して次を実行できます:

    cat my_credentials.json | sudo -u mgmt_agent /opt/oracle/mgmt_agent/agent_inst/bin/credential_mgmt.sh -o aliasCredentials -s datasafe
  3. ステップ1で作成したJSONファイルを削除します。

    資格証明のJSONファイルには機密情報が含まれます。ユーザーは、資格証明別名の追加または更新操作を完了した後で、資格証明のJSONファイルを削除する必要があります。

資格証明別名の削除

資格証明別名を削除するには、unaliasCredentials操作とともにcredential_mgmt.shスクリプトを使用します。

credential_mgmt.shスクリプトは/opt/oracle/mgmt_agent/agent_inst/binディレクトリにあります。

構文

credential_mgmt.sh -o unaliasCredentials -s [service-name]
  1. 次の形式を使用してJSONファイルを作成します:

    {"source":"datasafe_db.orcl123",
     "name":"audit_cred"}

    たとえば、このファイルをmy_credentials.jsonとして保存できます。

  2. JSONファイルを使用して資格証明別名を削除します。

    credential_mgmt.sh -o unaliasCredentials -s [service-name]

    たとえば、my_credentials.jsonファイルを使用して、DataSafeサービスに対して次を実行できます:

    cat my_credentials.json | sudo -u mgmt_agent /opt/oracle/mgmt_agent/agent_inst/bin/credential_mgmt.sh -o unaliasCredentials -s datasafe
  3. ステップ1で作成したJSONファイルを削除します。

    資格証明のJSONファイルには機密情報が含まれます。ユーザーは、資格証明別名の削除操作を完了した後で、資格証明のJSONファイルを削除する必要があります。

管理エージェントの監査ログ

管理エージェント・サービスでは、監査サービスによるロギングがサポートされます。このサービスでは、サポートされるすべてのOracle Cloud Infrastructureパブリック・アプリケーション・プログラミング・インタフェース(API)エンドポイントへのコールをログ・イベントとして自動的に記録します。

管理エージェントの監査

管理エージェント・サービスでは、監査サービスのmanagement-agentキーワードがサポートされます。

OCIコンソールを使用して、管理エージェント・サービスのログ・イベントを表示できます。
  • ナビゲーション・メニューを開きます。「ガバナンスと管理」で、「ガバナンス」に移動し、「監査」をクリックします。

    監査サービスが表示されます。

管理エージェントのログ・イベントを検索するには、目的のコンパートメントを選択し、KEYWORDSフィールドにmanagement-agentと入力します。

監査サービスの詳細は、Oracle Cloud Infrastructureドキュメントの監査の概要を参照してください。

エージェント・パラメータの確認

エージェント設定スクリプトを実行する際には、エージェント・パラメータを含むレスポンス・ファイルが必要です。

次の項では、レスポンス・ファイルでサポートされるパラメータについて説明します:

表4-1レスポンス・ファイルのパラメータ

パラメータ名 パラメータ・タイプ 説明
ManagementAgentInstallKey 必須 ドメインのアイデンティティとインストールの信頼性を検証するために必要なインストール・キー。
CredentialWalletPassword オプション エージェント・ウォレットのパスワード(ユーザーが機密情報を格納するためにウォレットのカスタム・パスワードとして指定する場合)。
パスワードの長さは8文字以上で仕様は次のとおりです:
  • 少なくとも1つの小文字(a-z)
  • 少なくとも1つの大文字(A-Z)
  • 少なくとも1つの数字(0-9)
  • 次の特殊文字を少なくとも1つ: !、@、#、%、^、&、*'

パスワードの文字はすべて、前述の文字を使用する必要があります。たとえば、パスワードの一部に$文字が含まれる場合、そのパスワードは有効性チェックに合格しません。$は前述の特殊文字の中にないためです。

GatewayServerHost オプション 管理ゲートウェイ・サーバーまたはプロキシ・サーバーのホスト名またはアドレス。

指定する場合は、GatewayServerPortも指定する必要があります。

管理ゲートウェイが高可用性モードで構成されている場合は、ロード・バランサのホスト名をGatewayServerHost値として指定する必要があります。詳細は、管理ゲートウェイの高可用性の構成を参照してください。

GatewayServerPort オプション 管理ゲートウェイ・サーバーまたはプロキシ・サーバーのポート番号。

指定する場合は、GatewayServerHostも指定する必要があります。

管理ゲートウェイが高可用性モードで構成されている場合は、ロード・バランサのポート番号をGatewayServerPort値として指定する必要があります。詳細は、管理ゲートウェイの高可用性の構成を参照してください。

GatewayServerUser オプション ユーザー名(管理ゲートウェイ・サーバーまたはプロキシ・サーバーが認証を必要とする場合)。

指定する場合は、GatewayServerPasswordも指定する必要があります。

GatewayServerPassword オプション 管理ゲートウェイ・サーバーまたはプロキシ・サーバーで認証が必要な場合のパスワード。

指定する場合は、GatewayServerUserも指定する必要があります。

GatewayServerRealm オプション プロキシ・サーバーの認証レルム。

管理ゲートウェイを使用する場合、この値は不要です。

AgentDisplayName オプション エージェントの表示名。空にしておくと、デフォルト値がAgent (host-name)に設定されます。
Service.plugin.<plugin_name>.download=true オプション エージェントのインストール時にデプロイするプラグインの名前。<plugin_name>は、管理エージェント・サービスでサポートされるプラグインです。

たとえば、エージェントのインストール時にDataSafeプラグインをデプロイしようとする場合は、次のように指定します: Service.plugin.datasafe.download=true

FreeFormTags = [{"<key1>":"<value1>"}, {"<key2>":"<value2>"}] オプション OCIでタグを使用する場合のタグ・メタデータの関連付け。

これはキーと値で構成されます。キーは、タグを参照するために使用する任意の名前です。値は、タグを適用するユーザーがタグ・キーに追加する値です。

「関連付けられたエージェント」で、この管理エージェントが管理ゲートウェイを介して接続するように構成されている場合は、"GatewayGroup"という名前のタグを追加します。

たとえば: "GatewayGroup":"<User_Defined_ClusterName>

DefinedTags = [{"namespace1":{"<key1>":"<value1>"}}, {"namespace2":{"<key2>":"<value2>"}}] オプション OCIでタグを使用する場合のタグ・メタデータの関連付け。タグ管理者がすべてのタグを作成および管理し、ユーザーがそれらをリソースに適用します。ユーザーはタグ・ポリシーを定義しておく必要があります。

タグ・ネームスペースは、タグ・キーのコンテナです。タグ・キーはネームスペース内のキーです。ネームスペース内の定義済タグに対してタグ・キーを作成する必要があります。

定義済タグでは、タグ値のタイプが文字列または文字列リストのいずれかになります。タグ値タイプを定義する際に、定義されたタイプが文字列である場合は、任意の値を入力できます。一方、文字列リストである場合、この値はそのリストのいずれかの文字列である必要があります。

次の例では、ネームスペースadmin_namespacefinance_namespaceが2つあります。各ネームスペースでは、2つのキーと2つの値environment_type=non-prod, sensitivity=restrictedが使用されます。タグを定義するには、次を使用できます。

DefinedTags = [{"admin_namespace": {"environment_type": "non-prod",
    "sensitivity": "restricted"}, "finance_namespace": {"environment_type":
    "non-prod","sensitivity": "restricted"}}]
GatewayServerRootCACertOcid オプション このパラメータは、エージェント・バージョン221019.0021以降で使用できます。

エージェントがバージョン221019.0021.1667404647以降の管理ゲートウェイに接続すると、接続が暗号化されます。

このパラメータは、使用するルート認証局証明書のOCIDを指定します。エージェントとゲートウェイの両方が同じコンパートメントに存在する必要があります。

importTrustedCertsDirectory オプション

PEM形式の追加のルートCA証明書の場所。

このパラメータは、PEM形式でルートCA証明書を追加する場合に使用します。管理エージェントは、その場所を検索し、インストール時に証明書を追加します。

たとえば: importTrustedCertsDirectory=/tmp/crt

maxHeapInMb オプション 最大ヒープの量(MB)。

デフォルトのヒープ値は512MBです。このパラメータを使用して、ログやデータベースなど、大規模な負荷でエージェントが構成される前のインストール時間がわかっている場合に、より多くのヒープを使用するようにエージェントをチューニングします。

例: maxHeapInMb=1024

BufferingEnabled オプション Log AnalyticsやObject Storage OCIサービスなどの管理ゲートウェイを介した様々なエンドポイントのバッファリングを有効にします。

管理エージェントでのJavaの使用

管理エージェントでは、管理エージェントがデプロイされるすべての環境にJava Runtime Environment (JRE)を事前にインストールする必要があります。管理エージェントの前提条件の詳細は、管理エージェントのデプロイに関する一般的な前提条件を参照してください。

JREが管理エージェントの実行に使用されます。Oracleでは、バグ修正およびセキュリティ・パッチで新しい更新が使用可能になると、使用可能な最新のJREバージョンにアップグレードすることをお薦めします。

この項では、管理エージェント用のJREをアップグレードする方法について説明します。

LinuxでのJREのアップグレード

この手順では、Linux 64ビット・プラットフォーム(Oracle Linux、CentOS、Ubuntu、SUSE Linuxなど)上でJREをアップグレードする方法について説明します。

RPMパッケージを使用したJREのアップグレード

これは、推奨されるアップグレード方法です。これにより、最新のJREバージョンが適切な場所にインストールされます。

Javaダウンロード・ページにあるRPMパッケージ・ファイルを使用してJREをアップグレードするには、次を実行します:

  1. JREをダウンロードします。

    最新のJREバージョンをhttps://www.oracle.com/java/technologies/downloads/#java8からダウンロードします。

  2. 管理エージェントを停止します。
    sudo systemctl stop mgmt_agent
  3. JREをアップグレードします。
    sudo rpm -Uvh jre-8u<VERSION>-linux-x64.rpm
  4. Javaシンボリック・リンクを更新します。

    update-alternativesコマンドを使用して、システムのデフォルトのJavaシンボリック・リンクを変更し、新しいJREの場所を参照します。

    sudo update-alternatives --config java

    または、プラットフォームに対してupdate-alternativesコマンドを使用できない場合は、デフォルトのJavaシンボリック・リンクを手動で変更できます

    シンボリック・リンクを更新してデフォルトのJavaを手動で変更するには、次を使用します。

    sudo ln -s <path-to-java_home>/bin/java /usr/bin/java
  5. JREアップグレードを確認します。
    次を実行して、新しいJREが環境でデフォルトとして使用されていることを確認します:
    env -i java -version

    出力表示:

    java version "1.8.0_xxx"
    ...
  6. 管理エージェントを起動します。
    sudo systemctl start mgmt_agent
  7. 管理エージェントが更新されたJREを使用して実行していることを確認します。
    grep "java.runtime.version" /opt/oracle/mgmt_agent/agent_inst/log/startup.info

    出力表示:

    java.runtime.version=1.8.0_<VERSION>
圧縮アーカイブを使用したJREのアップグレード

圧縮アーカイブ(tarファイル)を使用してJREをアップグレードするには、次を実行します:

  1. 最新のJREファイルをダウンロードします

    最新バージョンをhttps://www.oracle.com/java/technologies/downloads/#java8からダウンロードします。

  2. 管理エージェントを停止します。
    sudo systemctl stop mgmt_agent
  3. JRE Java圧縮ファイルをJavaの場所に抽出します。

    次の例では、Javaの抽出先の場所は/usr/lib/jvm/ディレクトリです

    sudo tar -xvfz jre-8u<VERSION>-linux-x64.tar.gz -C /usr/lib/jvm/
  4. Javaシンボリック・リンクを更新します。

    update-alternativesコマンドを使用して、システムのデフォルトのJavaシンボリック・リンクを変更し、新しいJREの場所を参照します。

    # install/register the new java with alternatives
    sudo update-alternatives --install "/usr/bin/java" "java" "<path-to-java_home>/bin/java" 1
    
    # set executables as default using update-alternatives command
    sudo update-alternatives --set java "<path-to-java_home>/bin/java"

    また、update-alternativesコマンドがプラットフォームで使用できない場合は、デフォルトのJavaシンボリック・リンクを手動で変更できます。

    シンボリック・リンクを更新してデフォルトのJavaを手動で変更するには、次を使用します。

    sudo ln -s <path-to-java_home>/bin/java /usr/bin/java
  5. JREアップグレードを確認します。
    次を実行して、新しいJREが環境でデフォルトとして使用されていることを確認します:
    env -i java -version

    出力表示:

    java version "1.8.0_xxx"
    ...
  6. 管理エージェントを起動します。
    sudo systemctl start mgmt_agent
  7. 管理エージェントが更新されたJREを使用して実行していることを確認します。
    grep "java.runtime.version" /opt/oracle/mgmt_agent/agent_inst/log/startup.info

出力表示:

java.runtime.version=1.8.0_<VERSION>

WindowsでのJREのアップグレード

このトピックでは、管理エージェントを実行するために、サポートされているWindows 64ビット・プラットフォームでJREをアップグレードする方法について説明します。

Windows環境に管理エージェントをインストールするには、インストール前に環境変数JAVA_HOMEを設定する必要があります。詳細は、Windows環境のカスタムJAVA_HOMEの更新を参照してください。将来変更できる場所にJAVA_HOME変数を設定します。

Windows上のJREをアップグレードするには、次を実行します:

  1. JREインストーラ・ファイルをダウンロードします

    最新のJREバージョンをhttps://www.oracle.com/java/technologies/downloads/#java8からダウンロードします。

  2. 管理エージェントを停止します。
    sc stop mgmt_agent 
  3. JREをアップグレードします。
    • ステップ1でダウンロードしたインストーラ・ファイルをダブルクリックして実行し、インストーラによって指示される対話型手順に従います。
      サイレント・インストールが望ましい場合は、次のコマンドを使用します:
      # Optional Command Line Silent Install
      # Start the installer with silent (/s) switch and store output to jre8-install.log file with log (/L) switch
      jre-8u<VERSION>-windows-x64.exe /s /L C:/jre8-install.log

    代替方法: 前述のインストーラ・ファイルを使用しない場合は、圧縮されたアーカイブ・ファイルを目的の場所に抽出します。

  4. ジャンクション(Javaシンボリック・リンク)を更新します。

    既存のジャンクションを削除し、新しいジャンクションを作成し、それを新しいJREの場所に指定します。

    rd C:\Oracle\jre8-latest
    mklink /J "C:\Oracle\jre8-latest" "C:\Program Files\Java\jre1.8.0_<VERSION>
    Junction created for C:\Oracle\jre8-latest <<===>> C:\Program Files\Java\jre1.8.0_<VERSION>
  5. JREアップグレードを確認します。
    次を実行して、新しいJREが環境でデフォルトとして使用されていることを確認します:
    echo %JAVA_HOME%
    C:\Oracle\jre8-latest
    
    %JAVA_HOME%/bin/java -version
    # output example:
    java version "1.8.0_<VERSION>"
    ...
    
  6. 管理エージェントを起動します。
    sc start mgmt_agent 
  7. 管理エージェントが更新されたJREを使用して実行していることを確認します。

    java.runtime.version設定が新しくインストールされたJREと一致することを確認します。

    findstr "java.runtime.version" C:\Oracle\mgmt_agent\agent_inst\log\startup.info
    java.runtime.version=1.8.0_<VERSION>

カスタムJAVA_HOMEの更新

環境によってはシステムのデフォルトのJavaの場所がありません。このような場合、JREのアップグレード・プロセスを開始する前に、OracleではカスタムのJAVA_HOMEの場所を更新することをお薦めします。

管理エージェントのインストールにカスタムJAVA_HOMEの場所を使用しているときに、JavaバージョンがJAVA_HOMEパスに含まれている場合、JREのアップグレードによって問題が発生する可能性があります。この解決策は、JREバージョン番号を参照しないJAVA_HOMEパスのシンボリック・リンクを作成することです。

シナリオ: 環境には1つのJREバージョンがありますが、JAVA_HOMEパスには、アップグレード後に別のJREバージョンを指す場合でも、そのパスに含まれるバージョン番号があります。
  • Linuxシナリオ: 環境のJREバージョンはjre1.8.301JAVA_HOMEパスはJAVA_HOME=/custom/jre1.8.301と設定されています。新しいJREバージョン(jre1.8.311など)にアップグレードすると、新しいJREがインストールされますが、JAVA_HOME変数は場所/custom/jre1.8.301を指しています。

  • Windowsシナリオ: 環境のJREバージョンはjre1.8.301JAVA_HOMEパスはJAVA_HOME=C:\custom\jre1.8.301と設定されています。新しいJREバージョン(例: jre1.8.311)にアップグレードすると、新しいJREがインストールされますが、JAVA_HOME変数は場所C:/custom/jre1.8.301を指しています。

問題: アップグレード後の実際のJREバージョンがjre1.8.311であっても、JAVA_HOMEパスの値が'jre1.8.301'であるため、前述の設定ではJREバージョンの混乱が発生します。

解決策: バージョン番号を含まないシンボリック・リンクを作成し、それをJAVA_HOME設定として使用して管理エージェントをインストールします。

バージョン番号を参照しないシンボリック・リンクを使用することで、JREのアップグレード・プロセスが簡略化されます。アップグレードで必要となるのは、シンボリック・リンクが指す場所の変更のみです。
  • Linux解決策: JAVA_HOME=/custom/jre8-latest -> /custom/jre1.8.301

  • Windows解決策: JAVA_HOME=C:\custom\jre8-latest -> C:\custom\jre1.8.301