艦隊の管理

セットアップ ガイドを使用して最初のフリートを作成したら、日常業務のほとんどをFleet Control UI から実行します。これらの操作はAPIを介してプログラムで実行することもできますが、このページではフリート、デプロイメント、設定を管理するためのUIワークフローに焦点を当てます。

艦隊の種類を理解する

Fleet Control 特定の管理対象エンティティ タイプ向けに設計された 3 種類のフリートをサポートします。

• Kubernetesクラスタ フリート:エージェントがHelmチャートとして活躍するKubernetesクラスタを管理します。
• Linux ホスト フリート:エージェントがホストベースのプロセスとして実行される Linux サーバーを管理します。（公開プレビュー）
• Windows ホスト フリート:エージェントが Windows サービスまたはホストベースのプロセスとして実行される Windows サーバーを管理します。（公開プレビュー）

フリートを作成するときに、管理対象のエンティティ タイプを選択します。この選択は、その艦隊をどのように操作するかに重要な影響を及ぼします。

• エンティティの割り当て:フリートのタイプに一致する管理対象エンティティのみを追加できます。 たとえば、 Windowsホスト フリートにはWindowsホストのみを含めることができ、 Kubernetesクラスタ フリートにはKubernetesクラスタのみを含めることができます。
• 設定フィルタリング:デプロイメント中、フリートのタイプに一致する設定のみが表示されます。 Windowsホスト フリートで作業している場合、設定セレクターにはWindowsホスト設定のみが表示されます。 この自動フィルタリングにより、構成ミスが防止され、デプロイメント プロセスが合理化されます。
• エージェントの可用性:デプロイに利用可能なエージェントのリストは、フリートのタイプとその環境でサポートされている内容に基づいてフィルターされます。 たとえば、特定のエージェントは、 Kubernetes環境または特定のホスト OS でのみ利用できる場合があります。

この設計により、フリート内のすべての管理対象エンティティにわたる一貫性が確保され、誤ってKubernetes Helmチャート設定をWindowsホストにデプロイしようとするなどの構成ミスが防止されます。

表内のデータの並べ替え

Fleet Control UI 全体のデータ テーブルの多くは並べ替え可能です。特定の列でテーブルを並べ替えるには、列ヘッダーにマウスを置きます。薄い灰色の上矢印または下矢印が表示された場合は、ヘッダーをクリックして、その列のデータに基づいてテーブル行を並べ替えることができます。

艦隊ページ

New Relic Control → Fleetsに移動すると、メインのFleetsページが表示され、 Fleet Control環境全体の概要が表示されます。ここから、次のことができます。

• 艦隊の検索:検索バーを使用して、名前で特定の艦隊を検索します。
• 概要数を表示:フリートの合計数と割り当てられていない管理対象エンティティの数を確認します。
• フリートの分布を参照:タイプ (Kubernetesクラスタまたはホスト) ごとにフリートの内訳を表示します。

艦隊行動

メインの艦隊ページで、艦隊の右端にある省略記号 ( ... ) をクリックすると、アクション メニューが表示されます。

• 設定の編集:艦隊の名前と説明を変更できます。

• 権限の編集:関連付けられたグループまたはロールを変更することで、フリートに対するきめ細かなアクセス制御 (FGA) を管理できます。

• 艦隊の削除:艦隊を完全に削除します。艦隊を削除する前に、次の条件を満たしている必要があります。

  • すべての管理対象エンティティをフリートから削除する必要があります。
  • フリートは現在進行中のデプロイメントを行うことはできません。

フリート権限（きめ細かなアクセス）

Fleet Control きめ細かいアクセス (FGA) を使用して、アドミニストレーターが特定のフリートの管理を特定のユーザーまたはグループに委任できるようにします。 これは、広範な組織レベルの権限を付与せずに、チームが独自のフリートを管理できるようにしたい場合に役立ちます。

アクセスを委任する主な方法は、特定のフリートのユーザー グループに定義済みのFleet Managerロールを割り当てることです。これにより、そのグループのユーザーは、デプロイメントの作成、設定の管理、管理対象エンティティの追加または削除など、そのフリートを完全に制御できるようになります。

管理者の前提条件

フリート権限を設定するには、 Organization ManagerおよびAuthDomain Manager役割が必要です。

セットアップワークフロー

このプロセスには 2 つの主な手順が含まれます。まず、アドミニストレーターがユーザー グループを作成し、次にそのグループに特定のフリートのFleet Managerロールを割り当てます。

ステップ1: ユーザーグループを作成する

1. 左側のナビゲーション メニューの下部でユーザー名をクリックし、 Administrationを選択します。
2. Administrationページで、 Access Managementを選択します。
3. groupsタブに移動して、 Create a new group [新しいグループの作成] をクリックします。
4. グループに意味のある名前を付けます (例: k8s-platform-team-fleet-managers )。
5. membersセクションで、フリート管理を委任するユーザーを追加します。
6. Add user to the groupをクリックします。ここでアカウントまたは組織レベルのロールを割り当てる必要はありません。権限は艦隊レベルで付与されます。

ステップ2: フリートにグループとロールを割り当てる

新しいフリートを作成するとき、または既存のフリートを編集するときに、権限を割り当てることができます。

既存のフリートに権限を割り当てるには:

1. メインのfleetsページから、管理する艦隊を見つけます。

2. 行末の省略記号 ( ... ) をクリックし、Edit permissions [権限の編集を]選択します。

3. fleet permissionsモーダル内:

   • Select a group: 前の手順で作成したユーザー グループを選択します。
   • 役割を選択: Fleet Manager役割を選択します。

4. Saveをクリックします。選択したグループ内のユーザーには、このフリートに対する完全な管理権限が付与されます。

フリート作成中に権限を割り当てるには:

1. セットアップ ガイドのフリート作成手順に従ってください。
2. Create Fleet [艦隊を作成] をクリックする前に、access management authorizationセクションで、ドロップダウンを使用して、希望するGroup [グループ]とFleet Manager [フリート マネージャーの]役割を選択します。
3. Create Fleet[フリートの作成]をクリックします。

特定の艦隊の管理

艦隊名をクリックすると、詳細な管理ページに移動します。

フリートヘッダー: タグとメタデータ

ページの上部のヘッダーには、フリートの名前と、クリック可能なTags [タグ]およびMetadata [メタデータ]ボタンが表示されます。これらにより、艦隊の重要な識別情報に素早くアクセスできるようになります。

• タグ:これをクリックすると、フリートに関連付けられたキーの値ペアのデータ ( accountId 、フリートのdescription 、作成または更新のタイムスタンプなど) の包括的なセットが表示されます。
• メタデータ:これをクリックすると、 Entity guid 、 Account ID 、 Managed entities typeなど、New Relic エンティティとしてのフリートの主要な識別詳細が表示されます。

詳細管理ページは、 Summary[概要] 、 Agents[エージェント] 、 Deployments[デプロイメント] の3 つのメインタブで構成されています。

概要タブ

このタブには、艦隊の現在の状態のスナップショットが 3 つのテーブルに整理されて表示されます。

• Active deployment table: 最新のデプロイメントの名前、含まれるエージェント/構成の数、および最終更新日が表示されます。
• Agents table: エージェントのタイプ、それに関連付けられた設定とバージョン、設定の作成日をリストします。
• Managed entities table: フリートに割り当てられたすべてのエンティティ、そのアカウント、タイプ、および現在の計装ステータスをリストします。 また、 New Relicプラットフォームの他の場所 (Kubernetesエクスプローラーなど) にあるエンティティのメイン ページに移動するView entity [View エンティティ]リンクも含まれています。

エージェントタブ

このタブには、フリート内の管理対象エンティティで実行されているすべてのエージェントの詳細ビューが表示されます。このタブの上部にある検索バーを使用して、特定のエージェントを名前またはタイプで検索できます。

重要な詳細として、 New Relic Agent Controlスーパーバイザもエージェント タイプとしてここにリストされています。各エージェントについて、関連する管理対象エンティティ、計装ステータス、リモート設定ステータス、および最後にハートビートを受信した時刻を確認できます。

効果的な設定を見る

agentsタブの主な機能は、あらゆるアクションの効果的な設定を確認できることです。 エージェントの名前をクリックすると、詳細ビューが開きます。ここではHelmチャートのバージョンなどのメタデータを確認できますが、最も重要なのは、ラケットのエージェントで実行されている正確な設定を表示できることです。

有効な設定は、ローカル環境変数などのソースからのオーバーライドを考慮しているため、プロイメントした設定とは異なる場合があります。 このビューは、トラブルシューティング設定関連の問題にとって非常に貴重です。

デプロイメントタブ

このタブには、フリートの完全な配備履歴が含まれています。 検索バーを使用して、特定のデプロイメントをその名前で検索できます。表には、各デプロイメントの名前、ステータス、エージェント/構成の数、最終更新日がリストされます。最新の成功したデプロイメントには、それが現在フリートに適用されているものであることを示すActiveラベルが付けられます。

デプロイメントの名前をクリックすると、その特定のデプロイメントの概要ビューが表示されます。このビューは 2 つのタブで構成されています。

詳細タブ

detailsタブには、次のようなデプロイメントの概要が表示されます。

• デプロイメント メタデータ (名前、タイプ、説明、開始/終了時刻、およびトラブルシューティングのデプロイメント ID)。
• エージェントのタイプ、実行されたアクション (インストール、更新など)、設定バージョンを示すAgentsテーブル。
• デプロイメントによって影響を受けたエンティティと、それらがカナリアとしてマークされたかどうかを正確に示すManaged Entitiesテーブル。

デプロイメントイベントタブ

deployment eventsタブでは、デプロイメント中に発生したすべてのアクションをイベントレベルで詳細に確認できます。このタブは、デプロイメントの問題のトラブルシューティングと根本原因の理解に不可欠です。あなたはできる：

• タイムスタンプ、ステータス、管理対象エンティティ名、エージェント名、エージェント タイプ、イベント タイプ、詳細、期間などの詳細を含むアトミック イベントを表示します。
• キーワードで特定のイベントを検索します。
• 管理対象エンティティごとにイベントをフィルタリングして、特定のクラスターまたはホストに焦点を当てます (大規模なフリートの障害のトラブルシューティングに役立ちます)。
• ステータス (完了、構成適用済み、適用中など) でイベントをフィルタリングします。
• イベント テーブル ヘッダーの右側にあるボタンをクリックして、高度なトラブルシューティングのための基礎となる NRQL クエリにアクセスします。

トラブルシューティングにdeployment eventsタブを使用する方法の詳細については、トラブルシューティングに関するドキュメントを参照してください。

デプロイメントの理解

デプロイメントは、フリート内の管理対象エンティティに対するエージェントとその設定をインストール、削除、または更新できる、制御された一連のアクションです。 このセクションでは、さまざまなデプロイメント ステータスの理解、 Agent Control自動アップグレード プロセス、変更を安全に管理するためのドラフトやカナリア デプロイメントなどの高度な機能の使用方法など、デプロイメント ライフサイクルの重要な側面について説明します。

デプロイメントステータスの理解

各デプロイメントのステータスは、その結果を理解するのに役立ちます。考えられるステータスとその意味は次のとおりです。

デプロイメントイベントフローの理解

deployment eventsタブを表示すると、デプロイメントのライフサイクルを表す一連のイベントが表示されます。すべてのデプロイメント イベントは、 FleetDeploymentカスタムイベント タイプに書き込まれます。 このイベント フローを理解すると、 deployment eventsタブに表示される内容を解釈し、問題をより効果的に診断できるようになります。

Fleet Control デプロイ設定は「リング」と呼ばれる段階で変化し、リスクを軽減します。 デプロイメント プロセスは次のように機能します。

• カナリア エンティティを指定した場合:デプロイメントでは最初にカナリア リング (カナリアとしてマークしたエンティティのみを含む) が使用され、その後、残りのすべてのエンティティに対してデフォルトのリングが使用されます。次のリングが始まる前に、各リングが正常に完了する必要があります。カナリア リングが失敗した場合、デフォルト リングに進む前にデプロイメントが停止し、問題が広範囲に及ぶのを防ぎます。
• カナリア エンティティを指定していない場合:デプロイメントでは、フリート内のすべてのエンティティが含まれるデフォルトのリングのみが使用されます。デプロイメントは、その単一リング内のすべてのエンティティにわたって完了するまで実行されます。

デプロイメントイベントの種類

次のイベントは、デプロイメントの進行状況を最初から最後まで追跡します。

エージェントのデプロイメントステータス

エージェントがデプロイメントの試行を完了すると (AgentDeploymentCompleted)、次のいずれかのステータスが報告されます。

イベントフローの仕組み

デプロイメントを開始すると、次の順序でイベントが生成されます。

1. FleetDeploymentStarted — フリート全体に対してデプロイメントが開始されます。
2. RingDeploymentStarted — 最初のリング (通常はカナリア) が開始され、そのリング内のすべてのエージェントが識別されます。
3. AgentDeploymentStarted — リング内のエージェントごとに、デプロイメント イベントが記録されます。これらのイベントは、リング内のすべてのエージェントに対して並行して発生します。
4. AgentDeploymentCompleted — 各エージェントはステータス (CONFIG_APPLIED 、 FAILED 、 TIMEOUT 、またはNOT_REPORTING) を報告します。
5. RingDeploymentCompleted — リング内のすべてのエージェントが完了するかタイムアウトすると、リングは完了としてマークされます。リングが成功した場合、次のリングが始まります。失敗した場合、デプロイメントは停止します。
6. FleetDeploymentCompleted — すべてのリングが完了する (またはリングが失敗する) と、デプロイメントは最終ステータスCOMPLETED 、 FAILED 、またはINTERNAL_FAILUREで終了します。

視覚的なイベントフロー

FleetDeploymentStarted
│
├─▶ RingDeploymentStarted (canary)
│   │
│   ├─▶ AgentDeploymentStarted (agent 1) ──▶ AgentDeploymentCompleted ─┐
│   ├─▶ AgentDeploymentStarted (agent 2) ──▶ AgentDeploymentCompleted ─┤ [parallel]
│   ├─▶ AgentDeploymentStarted (agent 3) ──▶ AgentDeploymentCompleted ─┘
│   │
│   └─▶ RingDeploymentCompleted (canary)
│       │
│       ├─ ✓ If SUCCESS → proceed to default ring
│       └─ ✗ If FAILED → stop deployment
│
├─▶ RingDeploymentStarted (default)
│   │
│   ├─▶ AgentDeploymentStarted (agent 4) ──▶ AgentDeploymentCompleted ─┐
│   ├─▶ AgentDeploymentStarted (agent 5) ──▶ AgentDeploymentCompleted ─┤ [parallel]
│   ├─▶ AgentDeploymentStarted (agent 6) ──▶ AgentDeploymentCompleted ─┘
│   │
│   └─▶ RingDeploymentCompleted (default)
│
└─▶ FleetDeploymentCompleted

エージェント デプロイメント ステータス オプション:

• ✅ CONFIG_APPLIED — エージェントは設定を正常に適用しました
• ❌FAILED— エージェントにエラーが発生しました
• ⏱️TIMEOUT— エージェントが時間内に応答しなかった
• 📡 NOT_REPORTING — デプロイメント開始時にエージェントがオフラインでした

キー識別子: fleetId 、 deploymentId 、 ringName

「デプロイメント イベント」タブを使用すると、これらすべてのイベントを詳細に表示できます。 トラブルシューティングのためのデプロイメント イベントへのアクセスと使用の詳細については、「デプロイメント」タブのセクションを参照してください。

自動Agent Controlアップグレード

管理対象エンティティが最新のセキュリティ パッチ、パフォーマンスの強化、機能の恩恵を確実に受けられるように、 Fleet Control Agent Controlのアップグレード プロセスを自動的に管理します。 デプロイメントを開始すると、 Fleet Control 、フリート内の管理対象エンティティに対して Agent Control の新しいバージョンが使用可能かどうかを確認します。

アップグレードが必要な場合は、デプロイメントの一部として自動的に組み込まれます。デプロイメント プロセス中にUIに、 Agent Controlがアップグレードされることを知らせる通知が表示されます。 この暗黙的なアップグレードは、実行中のデプロイメント アクション (エージェントのインストール、エージェントの削除、エージェント設定の変更など) と並行して行われ、最小限の労力で環境を最新の状態に保つことができます。

デプロイメントの下書きの作成と管理

デプロイメントを下書きとして保存し、変更をすぐにデプロイせずに、時間をかけて作業することができます。

下書きを作成して再開する

1. 特定の艦隊内のdeploymentsタブに移動します。
2. Create deploymentをクリックします。
3. Deployment [デプロイメント] ペインで、必須の名前とオプションの説明を入力します。
4. エージェントの追加や設定の更新など、必要な変更を加えます。
5. デプロイメントを開始する代わりに、 Save draftをクリックします。
6. その後、デプロイメント ペインを閉じることができます。新しいデプロイメントは、ステータスがDraftでdeploymentsタブに表示されます。

ドラフトの作業を続行するには、デプロイメント履歴テーブルでその名前をクリックするだけです。これにより、デプロイメント ペインが再度開き、変更を完了して準備ができたらStart deployment[デプロイメントの開始] をクリックできるようになります。

下書きを削除する

ドラフトデプロイメントが不要になった場合:

1. deploymentsタブから、削除したい下書きの名前をクリックします。
2. 開いたデプロイメント ペインで、画面上部のStart deploymentの横にある省略記号 (...) ボタンをクリックします。
3. メニューからDelete draftを選択します。
4. 下書きは完全に削除され、 deploymentsタブに戻ります。

デプロイメント中のエージェント バージョンの選択

デプロイメントにエージェントを追加する場合、設定を選択する前にエージェントのバージョンを選択する必要があります。

1. エージェント タイプを選択すると、 Select a versionドロップダウンが表示されます。

2. デフォルトでは最新バージョンが選択されます。

3. インストレーション用に他の利用可能なバージョンから選択することもできます。

4. 各バージョンには、次のような追加のメタデータが表示される場合があります。

   • 新機能と改善点をまとめたリリースノート
   • セキュリティ更新情報
   • その他のバージョン固有の詳細

このバージョン選択機能は、サポートされているすべてのインフラストラクチャ タイプ (Kubernetesクラスタ、Linux ホスト、およびWindowsホスト) で機能し、管理対象エンティティに対してどのエージェント バージョンをデプロイするかを正確に制御できます。

エージェントのバージョンを選択したら、 Nextをクリックして設定の選択に進みます。

デプロイメントにおけるエージェントのアクション

デプロイメントを作成または編集する場合、Agents [デプロイメント]ペインのエージェント表には、エージェントごとにいくつかのアクションが表示されます。 エージェントの行の右側にある省略記号 ( ... ) をクリックすると、次のオプションにアクセスできます。

• 設定の編集:設定エディターが開き、デプロイメントの一部としてこのエージェントの設定を変更できるようになります。
• 最新バージョンを使用する:複数のバージョンの設定を作成した場合、このオプションは、保存された最新の設定バージョンを使用するようにデプロイメントを自動的に更新します。
• 設定バージョンの変更:デプロイメントに使用する特定の古いバージョンの設定を手動で選択できます。
• デプロイメントから削除:エージェントとその設定をこのデプロイメントから完全に削除します。

艦隊内のエンティティを管理する

艦隊からエンティティを削除する

1. 現在エンティティが含まれている艦隊のsummaryタブに移動します。
2. managed entitiesテーブルで、チェックボックスを使用して、削除する 1 つ以上のエンティティを選択します。
3. 表示されるRemoveをクリックします。
4. 削除するエンティティをリストする検証モーダルが表示されます。確認するには、テキスト フィールドにremoveと入力します。
5. Remove entitiesをクリックします。エンティティは艦隊から割り当て解除されました。

割り当てられていない管理対象エンティティをフリートに追加する

新しいデプロイメントを作成して、割り当てられていない管理対象エンティティをフリートに追加します。このプロセスにより、エンティティがフリートおよびそのデプロイ設定に関連付けられます。

1. エンティティを追加するフリートに移動し、 Create a deploymentをクリックします。
2. デプロイメントにわかりやすい名前と説明を付けます。
3. デプロイメント画面の下部にあるmanaged entitiesテーブルで、 Add managed entitiesボタンをクリックします。
4. ペインが開き、割り当てられていないすべての管理対象エンティティのリストが表示されます。
5. 選択ボックスを使用して、艦隊に追加する 1 つ以上のエンティティを選択します。
6. Add to deploymentをクリックします。選択したエンティティがこのデプロイメントのmanaged entitiesテーブルに表示されます。
7. Save draftをクリックし、次にStart deploymentクリックしてプロセスを完了します。エンティティは新しい艦隊に割り当てられます。

カナリアデプロイメントを使用する

Fleet Control デプロイメント プロセス中に 1 つ以上の管理対象エンティティを「カナリア」として指定できます。これにより、変更を展開するための重要な安全メカニズムが提供されます。

新しいデプロイメントを作成するときに、リスト内の任意の管理対象エンティティの横にある省略記号 ( ... ) を使用して、それをカナリアとして指定できます。

デプロイメントが開始されると、次のようになります。

1. 変更は、カナリアとしてマークされた管理対象エンティティに対してのみデプロイされます。
2. デプロイメント プロセスは一時停止し、カナリア デプロイメントが成功するのを待ちます。
3. いずれかのカナリア デプロイメントが失敗すると、デプロイメント全体が直ちに停止し、他の管理対象エンティティは影響を受けません。
4. すべてのカナリア デプロイメントが成功すると、デプロイメントはフリート内の残りの管理対象エンティティに進みます。

設定ページ

New Relic Control → Configurationsに移動すると、すべてのエージェント設定を管理するための中心ハブであるメインの設定ページが表示されます。

メインページの概要

このページでは、アカウントで利用可能なすべての設定の概要を説明します。 ここから、次のことができます。

• 概要カウントを表示:合計設定数を表示します。
• 「設定のディストリビューション」を参照してください。エージェント タイプ別の設定の内訳を表示します (たとえば、 New Relic Infrastructure 、 Fluent Bit 、 NRDOT Collector )。
• 設定の検索:検索バーを使用して、名前または関連するエージェント タイプで特定の設定を検索します。
• リストを更新します:新しい設定を作成したばかりで、それがテーブルに表示されない場合は、 Create configurationの左側にある更新ボタンをクリックします。

このページには、次の列を含む設定の表が表示されます。

• 設定:設定の名前。
• エージェント:設定が適用されるエージェントのタイプ。
• リビジョン:設定に存在するバージョンの数。
• タイプ:管理対象エンティティのタイプ (Kubernetesクラスタ、Linux ホスト、またはWindowsホストなど)。
• 最終更新日:最終更新のタイムスタンプ。

設定アクション

メイン設定テーブルから、設定の右端にある省略記号 ( ... ) をクリックしてEdit [編集]できます。 これにより、設定ファイルを変更できるメイン編集ペインが開きます。 このビューには、構成ファイルをローカル マシンに Download [ダウンロード] したり、その内容をクリップボードに Copy [コピー] したりするためのボタンもあります。

設定を理解する

設定ファイルの構造は、選択した管理対象エンティティ タイプ(Kubernetesクラスタ、Linux ホスト、またはWindowsホスト) によって異なります。

• Kubernetesクラスタの場合、 UIで作成する設定はvalues.yamlファイルです。 デプロイメント中に、 Fleet ControlこのファイルをエージェントのHelmチャートとともにパッケージ化し、クラスタ上で構成します。 Kubernetes エージェントのテンプレートは、標準的な Helm チャートvalues.yamlファイルとして構造化されています。テンプレートの上部近くに、 New Relic Helm Charts GitHub リポジトリにあるエージェントのHelmチャートへのコメントアウト リンクがあります。 これにより、スキーマ、使用可能な値、その他のエージェント固有のドキュメントを簡単に参照できます。
• ホストの場合、設定ファイル形式はデプロイであるエージェントに固有です。

コンフィギュレーションの作成

新しいグローバル設定を最初から作成するには:

1. メインの設定ページで、 Create configurationをクリックします。

2. 表示されるモーダルで、次の操作を行う必要があります。

   • managed entity type (Kubernetesクラスタ、Linux ホスト、またはWindowsホスト) を選択します。 なお、Linux ホストと Windows ホストのサポートは現在パブリック プレビュー段階です。
   • ドロップダウン メニューからAgent type (たとえば、New Relic Infrastructure、NRDOT コレクター、Fluent Bit) を選択します。利用可能なエージェント タイプは、選択した管理対象エンティティ タイプに基づいてフィルターされます。
   • 設定に意味のある一意のName指定します。

3. Continueをクリックします。これにより、2 つのペインに分割された設定編集ビューが開きます。

   • 左ペイン (アクティブな設定):ここで設定を作成します。 このペインに直接入力したり、別のソースからコンテンツを貼り付けたりすることができます。
   • 右ペイン (テンプレート):このペインには、選択したエージェント タイプの最新のデフォルト テンプレートが含まれています。これらのテンプレートは、エージェントを実行するために必要な最小限の設定を提供しますが、コメントアウトされた追加のオプションも多数含まれています。これらの例を参考にすることも、コメントを解除してよりカスタマイズされた設定を構築することもできます。

4. 一般的なワークフローでは、テンプレート ペインでCopyクリックし、その内容を左側のアクティブな設定ペインに貼り付けて、開始点として使用します。

5. 左側のペインで設定が完了したら、Saveをクリックします。編集ビューが閉じて、新しい設定を見つけることができるメインの設定ページに戻ります。組織でこのエージェント・タイプの承認が必要な場合、保存すると、バージョンはすぐに利用可能になるのではなく、レビューのために送信されます — 設定の承認をご覧ください。

特定の設定の表示とバージョン管理

設定の詳細を表示し、そのバージョンを管理するには、メイン リストで設定の名前をクリックします。 これにより、特定の設定の詳細ペインが開きます。

このビューには次の内容が表示されます。

• 設定の名前、エージェントのタイプ、および利用可能なバージョンのリスト。
• デプロイメント ステータス。設定がいずれかのフリートにデプロイされているかどうか、またデプロイされている場合はどの艦隊にデプロイされたかを示します。
• 組織でこのエージェント・タイプの承認が必要な場合の、各バージョンの承認状態。設定の承認をご覧ください。

このペインからは、Download [ダウンロード]、Copy [コピー]、Clone [複製]などのいくつかのアクションを実行することもできます。ここでの主なアクションは、設定の新しいバージョンを作成することです。

新しいバージョンを作成するには:

1. Add new versionをクリックします。
2. これにより、設定を変更できる編集ペインが開きます。
3. 編集が完了したら、 Saveをクリックします。
4. メインの設定ページに戻り、その設定のrevisionsカウントが 1 つ増加していることがわかります。

設定に戻ってクリックすると、リストから新しいバージョンを選択して表示できるようになります。

既存のバージョンは編集できません。設定を変更するには新しいバージョンを作成します。これにより、時間の経過とともに変更された内容の記録が保持され、承認されたバージョンはレビュー時とまったく同じ状態に保たれます。

設定とそのバージョンを削除する

設定を削除するには、まずその個々のバージョンをすべて削除する必要があります。 最後のバージョンが削除されると、親設定は自動的に削除されます。

設定バージョンを削除するには:

1. 設定ページに移動します。
2. 変更したい設定の名前をクリックして、詳細ペインを開きます。
3. 左側に、すべてのバージョンのリストが表示されます。削除したいバージョンにマウスを移動し、表示される省略記号 (...) をクリックします。
4. メニューからDeleteを選択します。
5. 残りのすべてのバージョンに対してこのプロセスを繰り返します。最後のバージョンが削除されると、親設定はメイン設定ページのリストから削除されます。

設定のクローンを作成する

クローン作成は、既存の設定に基づいて新しい設定を素早く作成する方法です。

1. メイン設定ページで、メインCreate configurationの横にある省略記号 (...) ボタンをクリックします。
2. ドロップダウンから、クローンの開始点として使用する既存の設定を選択します。
3. これにより、選択した設定の内容が事前に入力された、同じ 2 つのペインの編集ビューが開きます。
4. これで、新しい設定を作成して保存できます。

設定の承認

設定の承認では、そのバージョンをデプロイメントで使用する前に、作成者以外の少なくとも1人が設定バージョンを承認する必要があります。Gitプロバイダーでプルリクエストのレビューを使用したことがある場合、このワークフローはなじみのあるものに感じられるでしょう：レビュアーは設定を読み、それを承認するか、変更をrequestsするか、拒否します。

これが重要である理由は、Fleet Controlが設定をリモートで管理するためです。ユーザーは、個々のホスト上のファイルを編集するのではなく、中央のコントロール・プレーンから設定を作成し、フリート全体の本番環境のインフラストラクチャにプッシュできます。設定の承認により、そのプロセスに第三者の目が加わるため、1人の人間が単独で設定を作成してデプロイすることはできなくなります。

承認は、インフラストラクチャとAPMの両方で、含めるように選択したすべてのエージェント・タイプの設定に適用されます。

承認ポリシーを設定する

誰かが作成するまで、組織には承認ポリシーがありません。これを設定するには、Organization Managerロール、またはポリシー機能を持つカスタム・ロールが必要です。

1. 左側のナビゲーションで、New Relic Control → Fleet Control Settings → Approvalsに移動します。
2. 組織でポリシーを設定したことがない場合は、設定変更の承認ポリシーを作成するためのプロンプトが表示されます。クリックして開始してください。
3. Governance for agent typesで、承認が必要なエージェント・タイプを選択します。承認をサポートするすべてのエージェント・タイプがデフォルトで選択されているため、リストを最初から作成するのではなく、不要なエージェント・タイプの選択を解除できます。
4. 承認の最小数を設定します。これはデフォルトで1であり、最大5まで増やすことができます。この数は作成者以外の人からの承認を指すため、最小値が1の場合、作成者と1人の承認者の2人が設定を確認したことを意味します。
5. Saveをクリックします。

保存されていない変更を破棄するには、Resetをクリックします。これにより、フォームが組織の保存済みポリシーに戻るため、ポリシーをクリアするのではなく、編集内容が元に戻ります。ポリシーをまだ保存していない場合、フォームはすべてのエージェントタイプが選択された初期状態に戻ります。

ポリシーを作成する権限がない場合、ページにその旨が表示され、アドミニストレーターに連絡するように指示されます。組織内でOrganization Managerロールを持つ担当者に、セットアップを完了するように依頼してください。

オンホストインテグレーションを管理対象外のままにすると、保存時にプロンプトが表示され、変更が有効になる前にリスクを承認するよう求められます。オンホストインテグレーションはホスト上でスクリプトを実行できるため、レビューなしのままにしておくには最も影響の大きい設定となります。NRI Flexは最も広く使用されている例です。承認は確認ステップであり、制限ではありません：承認すれば変更を保存できます。

承認から除外されるエージェントタイプ

2種類の設定は、異なる理由により永久に除外されます：

• Agent Control: エージェントではなく、スーパーバイザーです。Fleet ControlはAgent Controlを通じてすべてのライフサイクル操作を実行するため、これに承認を要求すると、承認された他のすべての変更を実行するメカニズムが制限されることになります。
• Pipeline Control Gateway (including Config Mode): Pipeline Control これらの設定を所有しています。Fleet Controlがそれらを配信しますが、作成と管理はPipeline Controlで行われます。

組織で利用可能な他のすべてのエージェントタイプは、承認を必要とするように設定できます。

承認状態について

設定のバージョンは不変です。設定を編集すると、既存のバージョンを変更するのではなく、常に新しいバージョンが作成されます。つまり、承認されたバージョンは、レビューされたときの状態のまま維持されます。各バージョンは個別に承認されます。

承認が必要なバージョンは、次の状態を遷移します：

承認されたバージョンであっても、後から拒否することができます。レビュー担当者が設定を承認した後に、含まれるべきではない機密データなどの問題に気付いた場合、それを拒否することで、誰かがそのバージョンをデプロイするのを直ちに阻止できます。これは意図的な仕様です：最初のレビュー時だけでなく、いつでも問題のある設定の使用を停止することができます。

承認が必要な設定を作成する

承認が必要なエージェントタイプの設定を作成または編集する場合、保存する前にエディターでその旨が通知され、保存すると、バージョンがすぐに利用可能になるのではなく、レビューのために送信されます。

1. 通常どおりに設定を作成してください。
2. Saveをクリックします。バージョンは1つのステップで保存され、レビューのために送信されます。個別の送信アクションはありません。
3. メインの設定ページでは、設定にロックアイコンが表示され、承認が必要であることを示します。その現在の状態が横に表示されます。

承認済みの状態になるまで、そのバージョンをデプロイすることはできません。

レビュアーのフィードバックに対応するには、新しいバージョンを追加します：

1. 設定の名前をクリックして開きます。このビューには、設定のバージョンとその承認状態が一覧表示されるため、どのバージョンが拒否されたか、または変更がリクエストされたかを確認できます。
2. Add new versionをクリックします。エディタは設定の最新バージョンのコピーで開くため、小さな変更の要求であっても最初からやり直す必要はありません。
3. View configuration historyをクリックして、レビュアーのコメントを確認してください。これにより、変更要求のコメント、拒否のコメント、およびすべてのバージョンにわたって設定に対して経時的に記録された承認アクティビティが表示されます。
4. 変更を行い、新しいバージョンを保存してください。独自のレビューを開始します。

各設定には、そのバージョンを子として持つ親レコードがあります。View configuration historyはそれらにまたがっているため、誰がいつ何をレビューしたかの監査証跡としても機能します。トラブルシューティング用の識別子を取得するには、View metadataを使用します。これには、親の設定IDと、表示している特定のバージョンの設定バージョンIDが表示されます。

設定の確認

レビューには、Organization Managerロール、または承認機能を持つカスタムロールが必要です。

設定バージョンを開き、3つのアクションのいずれかを選択します：

• Approve: 承認を記録します。コメントは任意です。バージョンが必要な承認数に達すると、すぐにデプロイメントで使用できるようになります。
• Request changes: 作成者に修正を依頼します。設定がほぼ完了しているものの、特定の編集が必要な場合に使用します。作成者は設定履歴でコメントを確認できるため、どの行をなぜ修正するのかを記載してください。
• Deny: バージョンを完全にブロックします。編集が必要というよりも、設定をまったく進めるべきではない場合にこれを使用してください。作成者は新しいバージョンを追加する必要があります。

承認および拒否が記録される前に、確認を求められます。

チームが活動するタイムゾーンをカバーするのに十分な人数のユーザーが承認権限を持っていることを確認してください。最小承認数が利用可能な承認者の数よりも多い場合、設定はレビューされないままになります。

レビュー待ちの設定を検索

設定があなたの対応を待っている場合、設定ページの上部にあるカードに、レビューが必要な数が表示されます。Show pending configurationsをクリックして承認待ちのすべての項目をリストしたドロワーを開くと、キューを一目で確認し、任意の項目に直接移動してレビューを開始できます。

承認権限の委任

設定バージョンの承認と承認ポリシーのセットアップの両方の機能は、デフォルトでOrganization Managerロールに属しています。事前定義された承認者ロールはないため、他の誰かに設定を承認させたい場合は、組織マネージャーがカスタムロールを作成し、それをグループに付与します。

どちらの権限も組織スコープです。つまり、カスタムロールは組織スコープのロールである必要があります。アカウントスコープまたはエンティティスコープのロールではこれらを保持することはできません。また、ロールの作成は作業の半分にすぎません。ロールをアクセス許可を持つグループにリンクするまで、権限は有効になりません。

ロールを作成するには：

1. 左側のナビゲーション メニューの下部でユーザー名をクリックし、 Administrationを選択します。

2. AdministrationページでAccess Managementを選択し、rolesタブに移動します。

3. Add a roleをクリックします。

4. ロールのスコープには、Organizationを選択してから、Nextをクリックします。

5. 後でメンテナンスする人が理解しやすいロール名を付けます（例：Config Approver）。

6. Fleet Controlセクションを見つけて展開します。

7. Fleets (all)行目のOtherの下で、このロールが持つべき機能を選択します：

   • Approve configurations: 保持者が、レビュー待ちの設定バージョンに対してアクションを実行できるようにします。
   • Configure organization governance: 保持者が、どのエージェントタイプに承認が必要か、および最小承認数を含む承認ポリシーを設定および変更できるようにします。

8. ロールを保存します。

各グループのニーズに基づいて、これらを個別に付与します。設定をレビューする必要があるが、どのエージェントタイプに承認が必要かを変更できないようにする必要があるユーザーには、Approve configurationsのみが必要です。

ロールを割り当てるには：

1. Access Managementで、access grantsタブに移動します。
2. Create new grantをクリックします。
3. 設定を承認する必要があるメンバーのグループを、組織を対象として作成したロールとペアにします。

ロールは個々のユーザーではなくグループに割り当てられるため、承認権限を与えるにはグループに人を追加し、権限を取り消すにはグループから人を削除してください。

承認権限は組織スコープであるため、承認者は組織内の任意の設定バージョンを承認できます。Fleet Controlの設定は、特定のフリートに属するのではなく組織レベルのオブジェクトであるため、承認されたバージョンはどのフリートのデプロイメントでも使用できます。承認者を特定のフリートにスコープすること、またはフリートごとに異なる承認ポリシーを設定することはサポートされていません。

管理対象エンティティのメインページ

New Relic Control → Managed Entitiesに移動すると、 KubernetesクラスタまたはAgent Controlがインストールされているホストなど、すべての管理対象エンティティを一元的に表示できます。 このページは、 Fleet Controlで管理できるすべてのエンティティの完全な資産インベントリとして機能し、 Fleet managedとUnassigned 2 つのタブで構成されています。

フリート管理タブ

このタブには、現在フリートに割り当てられているすべての管理対象エンティティが一覧表示されます。表には次の情報が記載されています。

• Entity name: 名前をクリックすると、 New Relicプラットフォームのエンティティのエクスプローラー エクスペリエンス (Kubernetesクラスタ エクスプローラーなど) に直接移動します。
• Entity type: 管理対象エンティティのタイプ (Kubernetesクラスタやホストなど)。
• Instrumentation status: エンティティ上の計装の現在の稼働ステータス。
• Fleet: エンティティが現在割り当てられている艦隊。フリート名をクリックすると、そのフリートの管理ページに直接移動できます。
• Account name: 管理対象エンティティに関連付けられた New Relic アカウント。

未割り当てのタブ

このタブには、 Agent Controlがインストールされているが、現在どのフリートにも割り当てられていないすべての管理対象エンティティのリストが表示されます。表には次の情報が記載されています。

• Entity name: 名前をクリックすると、New Relic プラットフォームのそのエンティティのエクスプローラー エクスペリエンスに直接移動します。
• Entity type: 管理対象エンティティのタイプ。
• Instrumentation status: 計装の現在の稼働ステータス。
• Account name: 管理対象エンティティに関連付けられた New Relic アカウント。

このビューは、 Fleet Controlによってまだ管理されていない資産を識別するのに特に役立ちます。すべての管理対象エンティティをフリートに割り当てて、それらが一貫して構成され、監視されていることを確認することがベストプラクティスです。

メインエージェントページ

New Relic Control → Agentsに移動すると、組織全体でFleet Controlによって管理されているすべてのエージェントのグローバル概要が表示されます。

ページの上部には、エージェントの健全性を簡単に確認できる次のような概要カードがあります。

• 接続されているすべてのエージェントの数。
• 切断されたエージェントの数。トラブルシューティングが必要な可能性のあるエージェントを迅速に特定するのに役立ちます。
• 上位 500 のエージェント タイプの分布。

概要カードの下には、管理対象エージェントがすべて一覧表示された包括的な表が表示されます。このテーブルはエージェント名で検索でき、エージェントの種類またはレポートのステータスでフィルタリングできます。表には次の列が含まれます。

• Type: エージェントのタイプ (例: New Relic Infrastructure)。
• Agent Name: エージェントの特定の名前。
• Managed Entity: エージェントが関連付けられている管理対象エンティティ。
• Connection Status: エージェントの現在の接続ステータス。
• Fleet: エージェントが所属する艦隊。
• Agent Version: エージェントのバージョン番号。