Agent Control and New Relic Control are now **generally available** for Kubernetes! Support for Linux hosts is also in **public preview** program, pursuant to our [pre-release policies](/docs/licenses/license-information/referenced-policies/new-relic-pre-release-policy).
-Agent Control is a lightweight agent supervisor that simplifies large-scale monitoring management of New Relic and OpenTelemetry agents. It integrates with Fleet Control to remotely configure, update, and monitor the health of instrumentation agents in Kubernetes and host environments
+Agent Control is a lightweight agent supervisor that runs on Kubernetes clusters and hosts to manage the lifecycle of New Relic and open-source instrumentation agents. Communicating with Fleet Control, it remotely configures, updates, and monitors agent health across fleets.
## Overview
-Managing observability infrastructure across a large, diverse environment is challenging. Manually deploying and configuring multiple agents is time-consuming, prone to errors, and difficult to keep consistent. This manual toil makes it hard to quickly add new instrumentation, optimize configurations, and keep agents updated.
+Managing instrumentation at scale is labor intensive and error prone. Multiple agents, version sprawl, and configuration drift can create telemetry blind spots, compliance risk, and weeks of coordination for even small changes.
-Agent Control provides a single, unified solution for managing all your New Relic and OpenTelemetry agents. It communicates with the New Relic platform to receive remote configurations and deployment instructions. This eliminates the need for manual intervention on each host, allowing you to manage your entire fleet from a single, centralized location.
+Agent Control provides a single, extensible supervisor you install once per host or cluster. It keeps all your New Relic and open source agents healthy and up to date, applies remote configuration, and enforces consistent settings without individually touching each agent.
-Agent Control can be installed on any supported enviroment and doesn't require any paid entitlement. The supervisor itself doesn't push any new telemetry to New Relic. Ingest cost will depend on the instrumentation enabled in the managed agents (Infrastructure, APM, Logs).
+Agent Control can be installed on any supported environment and doesn't require any paid entitlement. The supervisor itself doesn't push any new telemetry to New Relic. Ingest cost will depend on the instrumentation enabled in the managed agents (Infrastructure, APM, Logs).
## Architecture
-Agent Control's power comes from its use of a declarative, GitOps-like approach to agent management. It treats the desired state of your instrumentation as a single source of truth, ensuring that what you configure in New Relic Control is what's running on your clusters.
+Agent Control uses a declarative, GitOps-like approach to agent management. It treats the remote configuration received from Fleet Control as the desired state of your instrumentation, ensuring that what you deploy to the fleet is what's running on your clusters.
### The declarative engine: Flux on Kubernetes
-On Kubernetes, Agent Control leverages **[Flux](https://fluxcd.io/)**, a powerful and widely adopted CNCF project, as its declarative engine. Flux's controllers automatically deploy and update agents based on the configuration provided by Agent Control.
+On Kubernetes, Agent Control leverages **[Flux](https://fluxcd.io/)**, a CNCF-graduated continuous delivery tool, as its declarative engine. Flux controllers automatically deploy and update agents based on the configuration provided by Agent Control.
The diagram below shows how Agent Control connects to New Relic Control (the backend and UI) and Flux (the on-cluster engine) to manage your agents:
@@ -34,47 +34,47 @@ The diagram below shows how Agent Control connects to New Relic Control (the bac
src="/images/agent-control-architecture.webp"
/>
-Agent Control can use local or remote configurations. While local configurations are defined in the initial installation file, remote configurations are fetched from New Relic Control and rendered directly to your agents. This allows you to manage everything from a central point (and UI), including:
+Agent Control can use local or remote configurations. While local configurations are defined in the initial installation file, remote configurations are received from New Relic Control and rendered directly to your agents. This allows you to manage everything centrally, including:
-- **Credentials:** Agent Control can pull sensitive credentials from external secret providers like Vault, rendering them into the agent's configuration at runtime. This enhances security by keeping credentials out of the configuration itself.
-- **Agent Configuration:** It automatically converts remote configurations into a format that is compatible with the underlying agent. This means you can manage different types of agents (e.g., Infrastructure Agent, OpenTelemetry Collector) with a single, unified process.
+- **Credentials:** Agent Control can pull sensitive credentials from external secrets providers like Vault, injecting them into the agent's configuration at runtime. This enhances security by keeping credentials out of the configuration itself.
+- **Agent Configuration:** Agent Control automatically converts remote configurations into a format that is compatible with the underlying agent. This means you can manage different types of agents, such as the New Relic infrastructure agent and OpenTelemetry collector, with a single, unified process.
-This is how Agent Control can be used to enhance your observability experience:
-- **Fleet-wide commands:** The ability to send commands and perform actions on your entire fleet of agents.
-- **Advanced communication:** Direct, real-time communication with agents for on-demand troubleshooting and data collection.
-- **Enhanced security:** Further integration with security providers and automated credential management.
+With Agent Control installed on each cluster and host, your observability practice can scale:
+- **Fleet-wide actions:** Receive configurations and perform lifecycle operations across your entire fleet of agents.
+- **Bi-directional communications:** Authenticated and encrypted communication with agents for real-time troubleshooting and diagnostics.
+- **Security posture:** Standardize how credentials are sourced from secrets providers to centralize handling, automate rotations, and reduce exposure.
To enable this level of control and communication, Agent Control requires specific permissions. It needs to be configured with the necessary access to pull configurations and to interact with local systems to manage the agent lifecycle. When deploying Agent Control, ensure you understand and grant the required permissions to maintain a secure and functional environment.
- Refer to the following section on Agent Control permissions.
+ Refer to the following section on Agent Control permissions.
-Agent Control is designed to be a supervisor able to manage your instrumentation, which requires it to perform powerful actions within your environment. It's critical to understand and grant the required permissions.
+Agent Control is designed to be a supervisor for managing instrumentation which requires the ability to perform powerful actions within your environment. It's critical to understand and grant the needed permissions.
## Agent Control permissions
Deploying and managing agents in a Kubernetes cluster requires a clear understanding of the necessary permissions. Here, we'll explain the roles of both Agent Control and Flux and how they interact to securely install, update, and remove agents while ensuring that each agent only has the permissions it needs.
### Kubernetes
-In a Kubernetes environment, Agent Control uses Flux as its declarative engine to install, update, and uninstall agents. As such, Agent Control needs permissions to manage Flux resources, and Flux itself needs elevated permissions to manage the agent workloads.
+In a Kubernetes environment, Agent Control uses Flux as its continuous delivery engine to install, update, and uninstall agents. Agent Control needs permission to create and manage Flux resources, and Flux needs elevated permission to create and update the Kubernetes resources that run the agents.
-- **Permissions for Agent Control:** Agent Control requires permissions to create, read, update, and delete Flux-specific Custom Resources, such as `HelmRelease` and `HelmRepository`. This allows Agent Control to tell Flux what to do without needing direct cluster-admin access itself.
-- **Permissions for Flux:** Flux requires high-level permissions, typically with a `cluster-admin` role, to manage the lifecycle of any Helm chart it's instructed to deploy. This includes creating `Deployments`, `DaemonSets`, `Services`, and other core Kubernetes resources on behalf of the user. For security, it's a best practice to ensure that only trusted and verified configurations are used with Agent Control.
+- **Permissions for Agent Control:** Agent Control requires permissions to create, read, update, and delete Flux-specific Custom Resources, such as `HelmRelease` and `HelmRepository`. This allows Agent Control to instruct Flux what to do without giving Agent Control cluster-wide admin rights itself.
+- **Permissions for Flux:** Flux requires elevated permissions, typically with a `cluster-admin` role, to manage the lifecycle of Helm charts for the agents it deploys. This includes creating `Deployments`, `DaemonSets`, `Services`, `ConfigMaps`, `Secrets`, and other Kubernetes resources on behalf of the user. For security, it's a best practice to ensure that only trusted and verified configurations are used with Agent Control.
### Linux hosts
-For host-based systems (currently in public preview), Agent Control also requires elevated access. The supervisor needs to run with root or equivalent privileges to perform tasks such as:
+For host-based systems (currently in public preview), Agent Control requires elevated permissions. The supervisor needs to run with root, administrator, or equivalent privileges to perform agent lifecycle tasks such as:
-- **Installing new agents:** Placing agent binaries and configuration files in system-level directories.
-- **Managing agent processes:** Starting, stopping, and restarting services (e.g., using systemd).
-- **Reading system data:** Accessing system-level logs and performance metrics.
+- **Installing new agents:** Copying agent binaries and configuration files in system directories.
+- **Managing agent processes:** Starting, stopping, and restarting services, for example using systemd.
+- **Reading system data:** Accessing system information needed for health, inventory, and diagnostics such as logs and performance metrics.
-Similar to Kubernetes, the host-based supervisor's power is balanced by the declarative model: it only takes actions that are defined in its configuration. This is designed with a goal to limit the actions the supervisor can take. Elevated privileges are used to maintain the desired state of the agents, not to perform arbitrary, unapproved actions.
+Similar to Kubernetes, Agent Control follows a declarative model on hosts: it reads the desired state in its configuration and only takes actions that are needed to reach that state. This is designed to limit the actions the supervisor can take. Elevated privileges are used to configure, install, update, and uninstall agents, not to perform arbitrary, unapproved actions.
### Agent-specific permissions
Different agent types and their configurations require different permissions. For example, an agent that collects metrics from the Kubernetes API needs more permissions than an agent that only reads logs from files.
-Agent Control is designed to manage these permissions flexibly. While Flux requires a high level of access to function, our goal is to ensure that Agent Control only requests the **minimum required permissions** for the specific combination of agents you are deploying.
+Agent Control is designed to manage these permissions flexibly. While Flux requires a high degree of access to function, our goal is to ensure that Agent Control only requests the **minimum required permissions** for the specific combination of agents you are managing.
-For detailed information on the specific permissions required by each agent, refer to [Supported agent types](/docs/new-relic-control/agent-control/agent-types).
+For detailed information on the specific permissions required by each agent, refer to [Supported agent types](/docs/new-relic-control/agent-control/agent-types).
## Requirements and compatibility
@@ -92,7 +92,7 @@ Before you begin deploying Agent Control to your Kubernetes clusters, ensure tha
- Multiple installations of Agent Control on the same cluster are not supported.
+ Installing multiple instances of Agent Control on the same cluster is not supported.
Agent Control is compatible with:
@@ -115,7 +115,7 @@ We support these operating systems up to their manufacturer's end-of-life.
**Processor architectures**
|
- The agent supports these processor architectures:
+ Agent Control supports these processor architectures:
* 64-bit for x86 processor architectures
* arm64 architecture
@@ -126,17 +126,18 @@ We support these operating systems up to their manufacturer's end-of-life.
**Operating systems**
|
- The agent supports these operating systems up to their manufacturer's end-of-life.
+ Agent Control supports these operating systems up to their manufacturer's end-of-life.
* Amazon Linux version 2 and 2023
* CentOS 8 or higher
- * Debian 11 ("bullseye") or higher
+ * Debian 11 ("Bullseye") or higher
* Red Hat Enterprise Linux (RHEL) 7 or higher
* Oracle Linux 8 or higher
* SUSE Linux Enterprise Server (SLES) version 12.5, 15.2, 15.3, 15.4, 15.5
* Ubuntu 16.04 or higher (major long-term releases only)
The following operating systems are not yet supported:
- * Windows & MacOS
+ * Windows
+ * MacOS
* Docker (containerized)
|
@@ -150,4 +151,4 @@ cat /etc/os-release
```
## Next step
-After you've confirmed compatibility and met all the prerequisites, you're ready to [install Agent Control](/docs/new-relic-control/agent-control/setup).
\ No newline at end of file
+After you've confirmed compatibility and met all the prerequisites, you're ready to [install Agent Control](/docs/new-relic-control/agent-control/setup).
diff --git a/src/content/docs/new-relic-control/agent-control/reinstrumentation.mdx b/src/content/docs/new-relic-control/agent-control/reinstrumentation.mdx
index 0fdf0303ee0..d38b6ea1c45 100644
--- a/src/content/docs/new-relic-control/agent-control/reinstrumentation.mdx
+++ b/src/content/docs/new-relic-control/agent-control/reinstrumentation.mdx
@@ -9,48 +9,53 @@ freshnessValidatedDate: never
## Kubernetes migration
-If your Kubernetes cluster is already instrumented with New Relic, you must migrate your agents to be managed by Agent Control to use its features. This process involves a "rip-and-replace" approach where you uninstall your existing agents and then install them through Agent Control.
+If your Kubernetes cluster is already instrumented with New Relic, you can transition your agents to be managed by Agent Control to use its management features. The migration process is a guided replacement of existing agent installs with Agent Control managed installs, done in a controlled sequence to maintain continuity.
-Agent Control supports a unified configuration method for all agents, ensuring you can retain all features and settings from your original Helm chart installation.
+Agent Control uses a unified configuration model for supported agents, ensuring you can retain the features and settings from your current Helm chart installation.
-To ensure data continuity, use the same cluster name and point to the same New Relic account during your Agent Control installation. You can continue to keep any agents or components that are not yet supported by Agent Control on the cluster.
+To ensure data continuity, use the same cluster name and the same New Relic account during Agent Control installation. You can keep any agents or components that are not yet supported by Agent Control on the cluster until support is available.
### Step 1. Match and Retrieve Your Existing Configuration
First, identify which of your existing agents can be managed by Agent Control.
-Agent Control can deploy and manage the following agents, supported by the Helm charts included in the `nri-bundle` chart:
+Agent Control can deploy and manage the following agents from the `nri-bundle` Helm chart, mapped to Agent Control agent types:
-- `newrelic-infrastructure`, `nri-kube-events`, `kube-state-metrics`, and `nri-kube-events` (now managed through the New Relic Infrastructure agent type)
-- `newrelic-prometheus-configurator` (now managed through the New Relic Prometheus agent type)
-- `newrelic-logging` (now managed through the Fluent Bit agent type)
-- The `nr-k8s-otel-collector` chart (now managed through the New Relic OpenTelemetry Collector agent type)
+- `newrelic-infrastructure`, `nri-kube-events`, `kube-state-metrics`, and `nri-kube-events`: Managed as the New Relic Infrastructure agent type
+- `newrelic-prometheus-configurator`: Managed as the New Relic Prometheus agent type
+- `newrelic-logging`: Managed as the Fluent Bit agent type
+- `nr-k8s-otel-collector`: Managed as the New Relic OpenTelemetry Collector agent type
If you installed agents using Helm, retrieve your installation config from the cluster by running the following command:
```sh
+# Find releases in a namespace (adjust as needed)
+helm list --namespace
+
+# Get the values for a specific release
$ helm get values --namespace
```
If you have the original configuration file saved from the installation, you can use that directly.
-On the other hand, if you have instrumented the cluster via manifest, find the corresponding options in each agent chart.
+On the other hand, if you have instrumented the cluster via Kubernetes manifests (kubectl or Kustomize), map the corresponding options in each agent chart.
- You can continue to keep any agents or components within the cluster, especially those that are not yet supported by Agent Control. To ensure the best experience, make sure to maintain the same cluster name and point to the same account.
+ You can keep any agents or components that are not yet supported by Agent Control on the cluster until support is available. To ensure data continuity, use the same cluster name and the same New Relic account during Agent Control installation.
### Step 2. Create a New Agent Control Configuration
-Now, create a new Agent Control values.yaml file based on your existing configuration. This will tell Agent Control how to deploy and configure your agents after the migration.
+Create a new `values.yaml` file for Agent Control based on your existing configuration. This file tells Agent Control what to deploy and how to configure your agents after the migration.
-1. Start the [Agent Control Installation](/docs/new-relic-control/agent-control/setup/) via guided install and select all the agents you are interested in.
-2. Copy the `values.yaml` file to your local machine.
+1. Start the [Agent Control](/docs/new-relic-control/agent-control/setup/) guided installation and select the agents you need (Infrastructure, Prometheus, Logging, OpenTelemetry Collector).
+2. Download the `values.yaml` file to your local machine.
3. Update the downloaded file to correspond with the configurations of your old agents.
+4. Keep this file handy - you'll use it to deploy with Agent Control.
#### Example: Migrating an nri-bundle Installation
@@ -163,7 +168,7 @@ For a Helm installation, you can use the helm uninstall command.
$ helm uninstall -n
```
-For the example above, you would run:
+For example, to uninstall the `nri-bundle`, you would run:
```shell
$ helm uninstall nri-bundle -n newrelic
@@ -171,7 +176,7 @@ $ helm uninstall nri-bundle -n newrelic
### Step 4. Install Agent Control
-Once your old instrumentation is uninstalled, you are ready to install Agent Control with your new configuration. Follow the remaining installation steps included in the guided install.
+Once your old instrumentation is uninstalled, you are ready to install Agent Control with your new configuration. Follow the remaining installation steps included in the guided installation.
For a Helm installation, you would typically run:
@@ -185,13 +190,13 @@ When the `newrelic-agent-control` package is installed on the same host as the i
To upgrade your infrastructure agent to Agent Control:
-1. Complete the install steps to deploy the new agent. The agent will automatically replace the existing infrastructure agent package in your host.
+1. Complete the install steps to deploy the Agent Control package. The Agent Control package will automatically replace the existing infrastructure agent on your host.
2. Determine the data source for host monitoring. You have two options: keep New Relic agents, or migrate to OpenTelemetry as the main data source for host metrics and logs.
* Infrastructure agent: If you'd like to keep the infrastructure agent as the data source for host monitoring (CPU, Memory, Disk and Network telemetry), no change is required.
- * OpenTelemetry collector: To change to the OpenTelemetry collector as the data source, you'll need to set the following configurations to `hostreceiver`:
+ * OpenTelemetry collector: To change to the OpenTelemetry collector as the data source, you'll need to set the following configurations to `hostreceiver`:
1. Set the `is_integrations_only: true` value in the infrastructure agent configuration file to disable host monitoring metrics.
2. Remove active logging configurations (*.yml files) from the `/etc/newrelic-infra/logging.d` folder.
3. Ensure `hostreceiver` and `filelogreceiver` are properly configured in the OpenTelemetry collector configuration and included in the metrics `pipeline`.
4. Restart the `newrelic-agent-control` service to load the new configurations.
-No further changes are needed in order to keep backward compatibility with existing integrations configured in the host, and custom dashboards and alerts should not be impacted. All default paths remain unchanged for the infrastructure agent.
\ No newline at end of file
+No further changes are needed in order to keep backward compatibility with existing integrations configured in the host, and custom dashboards and alerts should not be impacted. All default paths remain unchanged for the infrastructure agent.
diff --git a/src/content/docs/new-relic-control/agent-control/setup.mdx b/src/content/docs/new-relic-control/agent-control/setup.mdx
index a88417c222b..39641166455 100644
--- a/src/content/docs/new-relic-control/agent-control/setup.mdx
+++ b/src/content/docs/new-relic-control/agent-control/setup.mdx
@@ -1,6 +1,6 @@
---
title: "Setup and Install Agent Control"
-metaDescription: "Learn how to install and configure Agent Control on a Kubernetes cluster."
+metaDescription: "Learn how to install and configure Agent Control on a Kubernetes cluster or Linux host."
freshnessValidatedDate: never
---
@@ -10,7 +10,7 @@ freshnessValidatedDate: never
## Overview
-Agent Control simplifies the management of your instrumentation agents. This guide will walk you through the process of installing and uninstalling Agent Control on your Kubernetes cluster or Linux hosts using different methods.
+Agent Control simplifies the management of your instrumentation agents. This guide will walk you through the process of installing and uninstalling Agent Control on your Kubernetes clusters or Linux hosts using different methods.
## Install Agent Control
@@ -22,17 +22,17 @@ For automating Agent Control setup across large-scale infrastructure, see [Set u
1. Log in to New Relic.
2. Ensure the correct account is selected.
3. In Integrations & Agents, click **Install Agent Control** or search for **Agent Control**.
-
+
-4. Follow the steps to complete the entire installation and configuration process.
+4. Follow the steps to complete the installation and configuration process.
- To install Agent Control, it is mandatory to have a fleet. If you haven't yet created a fleet for this managed entity, you can create a fleet during the instalaltion in the Guided Install or complete the fleet creation process in **New Relic Control**, and then return to this guided installation step.
+ To install Agent Control, it is mandatory to have a fleet. If you haven't yet created a fleet for this managed entity, you can create a fleet during the installation in the Guided Install or complete the fleet creation process in **Fleet Control**, and then return to this guided installation step.
5. Download the generated configuration to your computer and run the provided command in your terminal to install Agent Control. After installation, click **Continue**.
@@ -46,7 +46,7 @@ System identities have two different ways to authenticate. The two supported aut
* Private key-signed JSON Web Token (JWT)
* Client credentials
-During the Agent Control guided installation process, the first system identity is created using client credentials, which are included in the Helm chart's values. **The credentials for this system identity expire after 12 hours.**
+During the Agent Control guided installation process, the first system identity is created using client credentials, which are included in the Helm chart's values. **The credentials for this system identity expire after 12 hours.**
When they expire, the Agent Control Helm chart deployment will fail to authenticate with the Fleet Control service, resulting in the following error:
```
@@ -78,12 +78,12 @@ Now that Agent Control is installed and running, you're ready to [configure and
1. Run the following commands to check the status of your pods:
- Agent Control installs sub-agents in a different namespace for security reasons. To verify that everything is working, check that the Agent Control pods are running in the `newrelic-agent-control` namespace and the sub-agent pods are running in a different one (e.g., `newrelic`).
+ Agent Control installs subagents in a different namespace for security reasons. To verify that everything is working, check that the Agent Control pods are running in the `newrelic-agent-control` namespace and the subagent pods are running in a different namespace, such as `newrelic`.
```shell
kubectl get pods -n newrelic-agent-control # Check Agent Control pods
- kubectl get pods -n newrelic # Check sub-agents pods
+ kubectl get pods -n newrelic # Check subagent pods
```
2. Log in to New Relic, and go to **Fleet Control**.
@@ -93,23 +93,23 @@ Now that Agent Control is installed and running, you're ready to [configure and
### Linux
-* Check the status of the `newrelic-agent-control` service:
-
+* Check the status of the `newrelic-agent-control` service:
+
```bash
sudo systemctl status newrelic-agent-control
```
- If the service appears in `failed` or `stopped` state, this means the agent got installed but there's an issue preventing its normal operation.
- Check the agent services logs using `journaltctl` (or any similar Linux tool):
+ If the service appears in `Failed` or `Stopped` state, this means the agent got installed but there's an issue preventing its normal operation.
+ Check the agent services logs using `journalctl` (or any similar Linux tool):
- ```bash
+ ```bash
journalctl -u newrelic-agent-control
```
-
- If no insights are available, check how to [run the agent in debug mode](/docs/new-relic-agent-control#debug) to access detailed logs explaining why the service cannot be started.
+
+ If no insights are available, check how to [run the agent in debug mode](/docs/new-relic-agent-control#debug) to access detailed logs to get more insight into why the service cannot be started.
* If the service is not installed, try appending `--debug` at the end of the [install command](#cli) and run it again. This will enable verbose logging for the installation script. See if the verbose output has additional context explaining the error.
* Optionally, answer `yes` when asked to send logs to New Relic to help troubleshooting the installation. Once submitted, logs can be accessed with the following NRQL query:
-
+
```sql
SELECT * FROM Log WHERE hostname = `your-host-name`
```
@@ -126,9 +126,9 @@ See the following sections on how to:
### Start, stop, and restart Agent Control [#start-stop-restart]
-Our agent starts automatically after you run the installation script.
+Our agent starts automatically after you run the installation script.
-For Linux, ensure you use the correct command for your init system. Select `start`, `stop`, `restart`, or `status` as appropriate.
+For Linux, ensure you use the correct command for your init system. Select `start`, `stop`, `restart`, or `status` as appropriate.
Here's an example for Systemd:
@@ -174,8 +174,8 @@ To uninstall Agent Control from your Kubernetes cluster, run the following comma
The uninstall process typically leaves configuration and other miscellaneous files. Stopping the service beforehand is unnecessary. The uninstall process may take several minutes.
- Example of assets that might not be deleted as part of uninstall:
- * Local and/or remote configuration files: review and remove `/etc/newrelic-agent-control` and `/var/lib/newrelic-agent-control` folders.
+ Example of assets that might not be deleted as part of the uninstallation:
+ * Local or remote configuration files: review and remove `/etc/newrelic-agent-control` and `/var/lib/newrelic-agent-control` folders.
* New Relic CLI: review and remove `/usr/bin/newrelic-cli` binary.
@@ -211,4 +211,4 @@ To uninstall Agent Control from your Kubernetes cluster, run the following comma
```
-
\ No newline at end of file
+
diff --git a/src/content/docs/new-relic-control/agent-control/troubleshooting.mdx b/src/content/docs/new-relic-control/agent-control/troubleshooting.mdx
index 32e1de4581f..898ad8c98a5 100644
--- a/src/content/docs/new-relic-control/agent-control/troubleshooting.mdx
+++ b/src/content/docs/new-relic-control/agent-control/troubleshooting.mdx
@@ -196,7 +196,7 @@ This document covers the steps to troubleshoot common issues when installing or
./nrdiag -suites K8s-agent-control --k8s-namespace=newrelic
```
- - Specify a different namespace for sub-agents using the `ac-agents-namespace` flag:
+ - Specify a different namespace for subagents using the `ac-agents-namespace` flag:
```bash
./nrdiag -suites K8s-agent-control --k8s-namespace=newrelic-agent-control --ac-agents-namespace=newrelic
```
@@ -222,7 +222,7 @@ This document covers the steps to troubleshoot common issues when installing or
[output] See nrdiag-output.json for full results.
```
- 4. All the logs and resources related to the agent-control are saved in the `nrdiag_output.zip` file in the current directory. You can analyze the contents of the zip file or open a support ticket with [New Relic support](https://support.newrelic.com) for further assistance.
+ 4. All the logs and resources related to Agent Control are saved in the `nrdiag_output.zip` file in the current directory. You can analyze the contents of the zip file or open a support ticket with [New Relic support](https://support.newrelic.com) for further assistance.