diff options
-rw-r--r-- | aclk/README.md | 18 | ||||
-rw-r--r-- | claim/README.md | 102 | ||||
-rw-r--r-- | cli/README.md | 2 | ||||
-rw-r--r-- | daemon/README.md | 2 | ||||
-rw-r--r-- | docs/agent-cloud.md | 6 | ||||
-rw-r--r-- | docs/anonymous-statistics.md | 2 | ||||
-rw-r--r-- | docs/configure/secure-nodes.md | 2 | ||||
-rw-r--r-- | docs/contributing/style-guide.md | 4 | ||||
-rw-r--r-- | docs/getting-started.md | 4 | ||||
-rw-r--r-- | docs/guides/deploy/ansible.md | 8 | ||||
-rw-r--r-- | docs/guides/monitor/anomaly-detection.md | 2 | ||||
-rw-r--r-- | docs/guides/monitor/kubernetes-k8s-netdata.md | 8 | ||||
-rw-r--r-- | docs/guides/monitor/lamp-stack.md | 2 | ||||
-rw-r--r-- | docs/guides/step-by-step/step-03.md | 4 | ||||
-rw-r--r-- | docs/guides/troubleshoot/monitor-debug-applications-ebpf.md | 4 | ||||
-rw-r--r-- | docs/monitor/enable-notifications.md | 2 | ||||
-rw-r--r-- | docs/quickstart/infrastructure.md | 4 | ||||
-rw-r--r-- | packaging/installer/methods/kickstart-64.md | 10 | ||||
-rw-r--r-- | packaging/installer/methods/kickstart.md | 10 | ||||
-rw-r--r-- | packaging/installer/methods/kubernetes.md | 10 | ||||
-rw-r--r-- | packaging/installer/methods/manual.md | 6 |
21 files changed, 106 insertions, 106 deletions
diff --git a/aclk/README.md b/aclk/README.md index 36f2c90f16..13a9be27f7 100644 --- a/aclk/README.md +++ b/aclk/README.md @@ -9,13 +9,13 @@ custom_edit_url: https://github.com/netdata/netdata/edit/master/aclk/README.md The Agent-Cloud link (ACLK) is the mechanism responsible for securely connecting a Netdata Agent to your web browser through Netdata Cloud. The ACLK establishes an outgoing secure WebSocket (WSS) connection to Netdata Cloud on port -`443`. The ACLK is encrypted, safe, and _is only established if you claim your node_. +`443`. The ACLK is encrypted, safe, and _is only established if you connect your node_. The Cloud App lives at app.netdata.cloud which currently resolves to 35.196.244.138. However, this IP or range of IPs can change without notice. Watch this page for updates. -For a guide to claiming a node using the ACLK, plus additional troubleshooting and reference information, read our [get -started with Cloud](https://learn.netdata.cloud/docs/cloud/get-started) guide or the full [claiming +For a guide to connecting a node using the ACLK, plus additional troubleshooting and reference information, read our [get +started with Cloud](https://learn.netdata.cloud/docs/cloud/get-started) guide or the full [connect to Cloud documentation](/claim/README.md). ## Data privacy @@ -31,7 +31,7 @@ We do however store a limited number of *metadata* to be able to offer the stunn The information we store in Netdata Cloud is the following (using the publicly available demo server `frankfurt.my-netdata.io` as an example): - The email address you used to sign up/or sign in -- For each node claimed to your Spaces in Netdata Cloud: +- For each node connected to your Spaces in Netdata Cloud: - Hostname (as it appears in Netdata Cloud) - Information shown in `/api/v1/info`. For example: [https://frankfurt.my-netdata.io/api/v1/info](https://frankfurt.my-netdata.io/api/v1/info). - The chart metadata shown in `/api/v1/charts`. For example: [https://frankfurt.my-netdata.io/api/v1/info](https://frankfurt.my-netdata.io/api/v1/info). @@ -46,7 +46,7 @@ How we use them: ## Enable and configure the ACLK The ACLK is enabled by default, with its settings automatically configured and stored in the Agent's memory. No file is -created at `/var/lib/netdata/cloud.d/cloud.conf` until you either claim a node or create it yourself. The default +created at `/var/lib/netdata/cloud.d/cloud.conf` until you either connect a node or create it yourself. The default configuration uses two settings: ```conf @@ -56,7 +56,7 @@ configuration uses two settings: ``` If your Agent needs to use a proxy to access the internet, you must [set up a proxy for -claiming](/claim/README.md#claim-through-a-proxy). +connecting to cloud](/claim/README.md#connect-through-a-proxy). You can configure following keys in the `netdata.conf` section `[cloud]`: ``` @@ -104,7 +104,7 @@ You can pass the `--disable-cloud` parameter to the Agent installation when usin Git](/packaging/installer/methods/manual.md). When you pass this parameter, the installer does not download or compile any extra libraries. Once running, the Agent -kills the thread responsible for the ACLK and claiming behavior, and behaves as though the ACLK, and thus Netdata Cloud, +kills the thread responsible for the ACLK and connecting behavior, and behaves as though the ACLK, and thus Netdata Cloud, does not exist. ### Disable at runtime @@ -160,7 +160,7 @@ If you first disable the ACLK and any Cloud functionality and then decide you wo If you passed `--disable-cloud` to `netdata-installer.sh` during installation, you must [reinstall](/packaging/installer/REINSTALL.md) your Agent. Use the same method as before, but pass `--require-cloud` to -the installer. When installation finishes you can [claim your node](/claim/README.md#how-to-claim-a-node). +the installer. When installation finishes you can [connect your node](/claim/README.md#how-to-connect-a-node). If you changed the runtime setting in your `var/lib/netdata/cloud.d/cloud.conf` file, edit the file again and change `enabled` to `yes`: @@ -170,6 +170,6 @@ If you changed the runtime setting in your `var/lib/netdata/cloud.d/cloud.conf` enabled = yes ``` -Restart your Agent and [claim your node](/claim/README.md#how-to-claim-a-node). +Restart your Agent and [connect your node](/claim/README.md#how-to-connect-a-node). [![analytics](https://www.google-analytics.com/collect?v=1&aip=1&t=pageview&_s=1&ds=github&dr=https%3A%2F%2Fgithub.com%2Fnetdata%2Fnetdata&dl=https%3A%2F%2Fmy-netdata.io%2Fgithub%2Faclk%2FREADME&_u=MAC~&cid=5792dfd7-8dc4-476b-af31-da2fdb9f93d2&tid=UA-64295674-3)](<>) diff --git a/claim/README.md b/claim/README.md index b3ebb82217..7e209dd9f6 100644 --- a/claim/README.md +++ b/claim/README.md @@ -1,12 +1,12 @@ <!-- -title: "Agent claiming" -description: "Agent claiming allows a Netdata Agent, running on a distributed node, to securely connect to Netdata Cloud via the encrypted Agent-Cloud link (ACLK)." +title: "Connect Agent to Cloud" +description: "Connecting a Netdata Agent, running on a distributed node, to Netdata Cloud securely via the encrypted Agent-Cloud link (ACLK)." custom_edit_url: https://github.com/netdata/netdata/edit/master/claim/README.md --> -# Agent claiming +# Connect Agent to Cloud -Agent claiming allows a Netdata Agent, running on a distributed node, to securely connect to Netdata Cloud. A Space's +You can securely connect a Netdata Agent, running on a distributed node, to securely connect to Netdata Cloud. A Space's administrator creates a **claiming token**, which is used to add an Agent to their Space via the [Agent-Cloud link (ACLK)](/aclk/README.md). @@ -14,34 +14,34 @@ Are you just starting out with Netdata Cloud? See our [get started with Cloud](https://learn.netdata.cloud/docs/cloud/get-started) guide for a walkthrough of the process and simplified instructions. -Claiming nodes is a security feature in Netdata Cloud. Through the process of claiming, you demonstrate in a few ways -that you have administrative access to that node and the configuration settings for its Agent. By logging into the node, +Connecting Agents, also referrered as **nodes**, is a security feature in Netdata Cloud. Through the connection process, you demonstrate in a few ways +that you have administrative access to that node and the configuration settings for the Netdata Agent. By logging into the node, you prove you have access, and by using the claiming script or the Netdata command line, you prove you have write access and administrative privileges. Only the administrators of a Space in Netdata Cloud can view the claiming token and accompanying script generated by Netdata Cloud. -> The claiming process ensures no third party can add your node, and then view your node's metrics, in a Cloud account, +> The connection process ensures no third party can add your node, and then view your node's metrics, in a Cloud account, > Space, or War Room that you did not authorize. -By claiming a node, you opt-in to sending data from your Agent to Netdata Cloud via the [ACLK](/aclk/README.md). This -data is encrypted by TLS while it is in transit. We use the RSA keypair created during claiming to authenticate the -identity of the Agent when it connects to the Cloud. While the data does flow through Netdata Cloud servers on its way +By connecting a node, you opt-in to sending data from your Agent to Netdata Cloud via the [ACLK](/aclk/README.md). This +data is encrypted by TLS while it is in transit. We use the RSA keypair created during the connection process to authenticate the +identity of the Netdata Agent when it connects to the Cloud. While the data does flow through Netdata Cloud servers on its way from Agents to the browser, we do not store or log it. -You can claim a node during the Netdata Cloud onboarding process, or after you created a Space by clicking on **Claim +You can connect a node during the Netdata Cloud onboarding process, or after you created a Space by clicking on **Connect Nodes** in the [Spaces management area](https://learn.netdata.cloud/docs/cloud/spaces#manage-spaces). -There are two important notes regarding claiming: +There are two important notes regarding connecting nodes: -- _You can only claim any given node in a single Space_. You can, however, add that claimed node to multiple War Rooms +- _You can only connect any given node in a single Space_. You can, however, add that connected node to multiple War Rooms within that one Space. -- You must repeat the claiming process on every node you want to add to Netdata Cloud. +- You must repeat the connection process on every node you want to add to Netdata Cloud. -## How to claim a node +## How to connect a node -To claim a node, select which War Rooms you want to add this node to with the dropdown, then copy and paste the script +To connect a node, select which War Rooms you want to add this node to with the dropdown, then copy and paste the script given by Cloud into your node's terminal. Hit **Enter**. ```bash @@ -55,7 +55,7 @@ use root privileges via `sudo` to run the claiming script, see the next section. Repeat this process with every node you want to add to Cloud during onboarding. You can also add more nodes once you've finished onboarding. -### Claim an agent without root privileges +### Connect an agent without root privileges If you don't want to run the claiming script with root privileges, you can discover which user is running the Agent, switch to that user, and run the claiming script. @@ -78,13 +78,13 @@ netdata-claim.sh -token=TOKEN -rooms=ROOM1,ROOM2 -url=https://app.netdata.cloud Hit **Enter**. The script should return `Agent was successfully claimed.`. If the claiming script returns errors, or if you don't see the node in your Space after 60 seconds, see the [troubleshooting information](#troubleshooting). -### Claim an Agent running in Docker +### Connect an Agent running in Docker -To claim an instance of the Netdata Agent running inside of a Docker container, either set claiming environment -variables in the container to have it automatically claimed on startup or restart, or use `docker exec` to manually -claim an already running container. +To connect an instance of the Netdata Agent running inside of a Docker container, either set claiming environment +variables in the container to have it automatically connected on startup or restart, or use `docker exec` to manually +connect an already running container. -For claiming to work, the contents of `/var/lib/netdata` _must_ be preserved across container +For the connection process to work, the contents of `/var/lib/netdata` _must_ be preserved across container restarts using a persistent volume. See our [recommended `docker run` and Docker Compose examples](/packaging/docker/README.md#create-a-new-netdata-agent-container) for details. @@ -97,9 +97,9 @@ The Netdata Docker container looks for the following environment variables on st - `NETDATA_CLAIM_ROOMS` - `NETDATA_CLAIM_PROXY` -If the token and URL are specified in their corresponding variables _and_ the container is not already claimed, -it will use these values to attempt to claim the container, automatically adding the node to the specified War -Rooms. If a proxy is specified, it will be used for the claiming process and for connecting to Netdata Cloud. +If the token and URL are specified in their corresponding variables _and_ the container is not already connected, +it will use these values to attempt to connect the container, automatically adding the node to the specified War +Rooms. If a proxy is specified, it will be used for the connection process and for connecting to Netdata Cloud. These variables can be specified using any mechanism supported by your container tooling for setting environment variables inside containers. For example, when creating a new Netdata continer using `docker run`, the following @@ -126,12 +126,12 @@ docker run -d --name=netdata \ Output that would be seen from the claiming script when using other methods will be present in the container logs. -Using the environment variables like this to handle claiming is the preferred method of claiming Docker containers +Using the environment variables like this to handle the connection process is the preferred method of connecting Docker containers as it works in the widest variety of situations and simplifies configuration management. #### Using docker exec -Claim a _running Netdata Agent container_ by appending the script offered by Cloud to a `docker exec ...` command, replacing +Connect a _running Netdata Agent container_ by appending the script offered by Cloud to a `docker exec ...` command, replacing `netdata` with the name of your running container: ```bash @@ -141,14 +141,14 @@ docker exec -it netdata netdata-claim.sh -token=TOKEN -rooms=ROOM1,ROOM2 -url=ht The script should return `Agent was successfully claimed.`. If the claiming script returns errors, or if you don't see the node in your Space after 60 seconds, see the [troubleshooting information](#troubleshooting). -### Claim a Kubernetes cluster's parent Netdata pod +### Connect a Kubernetes cluster's parent Netdata pod -Read our [Kubernetes installation](/packaging/installer/methods/kubernetes.md#claim-a-kubernetes-clusters-parent-pod) -for details on claiming a parent Netdata pod. +Read our [Kubernetes installation](/packaging/installer/methods/kubernetes.md#connect-a-kubernetes-clusters-parent-pod) +for details on connecting a parent Netdata pod. -### Claim through a proxy +### Connect through a proxy -A Space's administrator can claim a node through a SOCKS5 or HTTP(S) proxy. +A Space's administrator can connect a node through a SOCKS5 or HTTP(S) proxy. You should first configure the proxy in the `[cloud]` section of `netdata.conf`. The proxy settings you specify here will also be used to tunnel the ACLK. The default `proxy` setting is `none`. @@ -162,8 +162,8 @@ The `proxy` setting can take one of the following values: - `none`: Do not use a proxy, even if the system configured otherwise. - `env`: Try to read proxy settings from set environment variables `http_proxy`/`socks_proxy`. -- `socks5[h]://[user:pass@]host:ip`: The ACLK and claiming will use the specified SOCKS5 proxy. -- `http://[user:pass@]host:ip`: The ACLK and claiming will use the specified HTTP(S) proxy. +- `socks5[h]://[user:pass@]host:ip`: The ACLK and connection process will use the specified SOCKS5 proxy. +- `http://[user:pass@]host:ip`: The ACLK and connection process will use the specified HTTP(S) proxy. For example, a SOCKS5 proxy setting may look like the following: @@ -173,7 +173,7 @@ For example, a SOCKS5 proxy setting may look like the following: proxy = socks5h://proxy.example.com:1080 # With a URL ``` -You can now move on to claiming. When you claim with the `netdata-claim.sh` script, add the `-proxy=` parameter and +You can now move on to connecting. When you connect with the `netdata-claim.sh` script, add the `-proxy=` parameter and append the same proxy setting you added to `netdata.conf`. ```bash @@ -185,11 +185,11 @@ you don't see the node in your Space after 60 seconds, see the [troubleshooting ### Troubleshooting -If you're having trouble claiming a node, this may be because the [ACLK](/aclk/README.md) cannot connect to Cloud. +If you're having trouble connecting a node, this may be because the [ACLK](/aclk/README.md) cannot connect to Cloud. With the Netdata Agent running, visit `http://NODE:19999/api/v1/info` in your browser, replacing `NODE` with the IP address or hostname of your Agent. The returned JSON contains four keys that will be helpful to diagnose any issues you -might be having with the ACLK or claiming process. +might be having with the ACLK or connection process. ```json "cloud-enabled" @@ -211,7 +211,7 @@ If you are using an unsupported package, such as a third-party `.deb`/`.rpm` pac please remove that package and reinstall using our [recommended kickstart script](/docs/get-started.mdx#install-on-linux-with-one-line-installer-recommended). -#### Claiming on older distributions (Ubuntu 14.04, Debian 8, CentOS 6) +#### Connecting on older distributions (Ubuntu 14.04, Debian 8, CentOS 6) If you're running an older Linux distribution or one that has reached EOL, such as Ubuntu 14.04 LTS, Debian 8, or CentOS 6, your Agent may not be able to securely connect to Netdata Cloud due to an outdated version of OpenSSL. These old @@ -285,7 +285,7 @@ with details about your system and relevant output from `error.log`. #### agent-claimed is false -You must [claim your node](#how-to-claim-a-node). +You must [connect your node](#how-to-connect-a-node). #### aclk-available is false @@ -293,14 +293,14 @@ If `aclk-available` is `false` and all other keys are `true`, your Agent is havi through the ACLK. Please check your system's firewall. If your Agent needs to use a proxy to access the internet, you must [set up a proxy for -claiming](#claim-through-a-proxy). +connecting](#connect-through-a-proxy). If you are certain firewall and proxy settings are not the issue, you should consult the Agent's `error.log` at `/var/log/netdata/error.log` and contact us by [creating an issue on GitHub](https://github.com/netdata/netdata/issues/new?labels=bug%2C+needs+triage%2C+ACLK&template=bug_report.md&title=ACLK-available-is-false) with details about your system and relevant output from `error.log`. -### Remove and reclaim a node +### Remove and reconnect a node To remove a node from your Space in Netdata Cloud, delete the `cloud.d/` directory in your Netdata library directory. @@ -309,10 +309,10 @@ cd /var/lib/netdata # Replace with your Netdata library directory, if not /var sudo rm -rf cloud.d/ ``` -This node no longer has access to the credentials it was claimed with and cannot connect to Netdata Cloud via the ACLK. +This node no longer has access to the credentials it was used when connecting to Netdata Cloud via the ACLK. You will still be able to see this node in your War Rooms in an **unreachable** state. -If you want to reclaim this node into a different Space, you need to create a new identity by adding `-id=$(uuidgen)` to +If you want to reconnect this node into a different Space, you need to create a new identity by adding `-id=$(uuidgen)` to the claiming script parameters. Make sure that you have the `uuidgen-runtime` package installed, as it is used to run the command `uuidgen`. For example, using the default claiming script: ```bash @@ -321,9 +321,9 @@ sudo netdata-claim.sh -token=TOKEN -rooms=ROOM1,ROOM2 -url=https://app.netdata.c The agent _must be restarted_ after this change. -## Claiming reference +## Connecting reference -In the sections below, you can find reference material for the claiming script, claiming via the Agent's command line +In the sections below, you can find reference material for the claiming script, connecting via the Agent's command line tool, and details about the files found in `cloud.d`. ### The `cloud.conf` file @@ -338,7 +338,7 @@ using the [ACLK](/aclk/README.md). ### Claiming script -A Space's administrator can claim an Agent by directly calling the `netdata-claim.sh` script either with root privileges +A Space's administrator can connect an Agent by directly calling the `netdata-claim.sh` script either with root privileges using `sudo`, or as the user running the Agent (typically `netdata`), and passing the following arguments: ```sh @@ -356,7 +356,7 @@ using `sudo`, or as the user running the Agent (typically `netdata`), and passin where PROXY_URL is the endpoint of a SOCKS5 proxy. ``` -For example, the following command claims an Agent and adds it to rooms `room1` and `room2`: +For example, the following command connects an Agent and adds it to rooms `room1` and `room2`: ```sh netdata-claim.sh -token=MYTOKEN1234567 -rooms=room1,room2 @@ -368,11 +368,11 @@ You should then update the `netdata` service about the result with `netdatacli`: netdatacli reload-claiming-state ``` -This reloads the Agent claiming state from disk. +This reloads the Agent connection state from disk. ### Netdata Agent command line -If a Netdata Agent is running, the Space's administrator can claim a node using the `netdata` service binary with +If a Netdata Agent is running, the Space's administrator can connect a node using the `netdata` service binary with additional command line parameters: ```sh @@ -388,9 +388,9 @@ For example: If need be, the user can override the Agent's defaults by providing additional arguments like those described [here](#claiming-script). -### Claiming directory +### Connection directory -Netdata stores the Agent's claiming-related state in the Netdata library directory under `cloud.d`. For a default +Netdata stores the Agent's connection-related state in the Netdata library directory under `cloud.d`. For a default installation, this directory exists at `/var/lib/netdata/cloud.d`. The directory and its files should be owned by the user that runs the Agent, which is typically the `netdata` user. diff --git a/cli/README.md b/cli/README.md index 93812372ab..1962b2ede5 100644 --- a/cli/README.md +++ b/cli/README.md @@ -26,7 +26,7 @@ shutdown-agent fatal-agent Log the state and halt the netdata agent. reload-claiming-state - Reload agent claiming state from disk. + Reload agent connection state from disk. ``` Those commands are the same that can be sent to netdata via [signals](/daemon/README.md#command-line-options). diff --git a/daemon/README.md b/daemon/README.md index 359b3ea392..1ea865f899 100644 --- a/daemon/README.md +++ b/daemon/README.md @@ -184,7 +184,7 @@ The command line options of the Netdata 1.10.0 version are the following: Check if string matches pattern and exit. -W "claim -token=TOKEN -rooms=ROOM1,ROOM2 url=https://app.netdata.cloud" - Claim the agent to the workspace rooms pointed to by TOKEN and ROOM*. + Connect the agent to the workspace rooms pointed to by TOKEN and ROOM*. Signals netdata handles: diff --git a/docs/agent-cloud.md b/docs/agent-cloud.md index 061b8472db..fcec10af89 100644 --- a/docs/agent-cloud.md +++ b/docs/agent-cloud.md @@ -28,7 +28,7 @@ Cloud](https://user-images.githubusercontent.com/1153921/80828986-1ebb3b00-8b9b- [Read more about Netdata Cloud](https://learn.netdata.cloud/docs/cloud/) to better understand how it gives you real-time visibility into your entire infrastructure, and why you might consider using it. -Next, [get started in 5 minutes](https://learn.netdata.cloud/docs/cloud/get-started/), or read our [claiming +Next, [get started in 5 minutes](https://learn.netdata.cloud/docs/cloud/get-started/), or read our [connection to Cloud reference](/claim/README.md) for a complete investigation of Cloud's security and encryption features, plus instructions for Docker containers. @@ -72,8 +72,8 @@ about how you might want to use or configure Cloud, we recommend the following: - Get an overview of Cloud's features by reading [Cloud documentation](https://learn.netdata.cloud/docs/cloud/). - Follow the 5-minute [get started with Cloud](https://learn.netdata.cloud/docs/cloud/get-started/) guide to finish - onboarding and claim your first nodes. -- Better understand how agents connect securely to the Cloud with [claiming](/claim/README.md) and [Agent-Cloud + onboarding and connect your first nodes. +- Better understand how agents connect securely to the Cloud with [connect agent to Cloud](/claim/README.md) and [Agent-Cloud link](/aclk/README.md) documentation. [![analytics](https://www.google-analytics.com/collect?v=1&aip=1&t=pageview&_s=1&ds=github&dr=https%3A%2F%2Fgithub.com%2Fnetdata%2Fnetdata&dl=https%3A%2F%2Fmy-netdata.io%2Fgithub%2Fdocs%2Fagent-cloud&_u=MAC~&cid=5792dfd7-8dc4-476b-af31-da2fdb9f93d2&tid=UA-64295674-3)]() diff --git a/docs/anonymous-statistics.md b/docs/anonymous-statistics.md index 9f079e3798..75e586bd41 100644 --- a/docs/anonymous-statistics.md +++ b/docs/anonymous-statistics.md @@ -68,7 +68,7 @@ Starting with v1.21, we additionally collect information about: - Failures to build the dependencies required to use Cloud features. - Unavailability of Cloud features in an agent. -- Failures to connect to the Cloud in case the agent has been [claimed](/claim/README.md). This includes error codes +- Failures to connect to the Cloud in case the [connection process](/claim/README.md) has been completed. This includes error codes to inform the Netdata team about the reason why the connection failed. To see exactly what and how is collected, you can review the script template `daemon/anonymous-statistics.sh.in`. The diff --git a/docs/configure/secure-nodes.md b/docs/configure/secure-nodes.md index 704db35a33..180ffe357d 100644 --- a/docs/configure/secure-nodes.md +++ b/docs/configure/secure-nodes.md @@ -34,7 +34,7 @@ that align with your goals and your organization's standards. ## Disable the local dashboard -This is the _recommended method for those who have claimed their nodes to Netdata Cloud_ and prefer viewing real-time +This is the _recommended method for those who have connected their nodes to Netdata Cloud_ and prefer viewing real-time metrics using the War Room Overview, Nodes view, and Cloud dashboards. You can disable the local dashboard (and API) but retain the encrypted Agent-Cloud link ([ACLK](/aclk/README.md)) that diff --git a/docs/contributing/style-guide.md b/docs/contributing/style-guide.md index faa6fc62bb..625237bc07 100644 --- a/docs/contributing/style-guide.md +++ b/docs/contributing/style-guide.md @@ -469,7 +469,7 @@ The following tables describe the standard spelling, capitalization, and usage o | Term | Definition | |-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| **claimed node** | A node that you've proved ownership of by completing the [claiming process](/claim/README.md). The claimed node will then appear in your Space and any War Rooms you added it to. | +| **claimed node** | A node that you've proved ownership of by completing the [connecting to Cloud process](/claim/README.md). The claimed node will then appear in your Space and any War Rooms you added it to. | | **Netdata** | The company behind the open-source Netdata Agent and the Netdata Cloud web application. Never use _netdata_ or _NetData_. <br /><br />In general, focus on the user's goals, actions, and solutions rather than what the company provides. For example, write _Learn more about enabling alarm notifications on your preferred platforms_ instead of _Netdata sends alarm notifications to your preferred platforms_. | | **Netdata Agent** | The free and open source [monitoring agent](https://github.com/netdata/netdata) that you can install on all of your distributed systems, whether they're physical, virtual, containerized, ephemeral, and more. The Agent monitors systems running Linux, Docker, Kubernetes, macOS, FreeBSD, and more, and collects metrics from hundreds of popular services and applications. | | **Netdata Cloud** | The web application hosted at [https://app.netdata.cloud](https://app.netdata.cloud) that helps you monitor an entire infrastructure of distributed systems in real time. <br /><br />Never use _Cloud_ without the preceding _Netdata_ to avoid ambiguity. | @@ -477,7 +477,7 @@ The following tables describe the standard spelling, capitalization, and usage o | **Netdata community forum** | The Discourse-powered forum for feature requests, Netdata Cloud technical support, and conversations about Netdata's monitoring and troubleshooting products. | | **node** | A system on which the Netdata Agent is installed. The system can be physical, virtual, in a Docker container, and more. Depending on your infrastructure, you may have one, dozens, or hundreds of nodes. Some nodes are _ephemeral_, in that they're created/destroyed automatically by an orchestrator service. | | **Space** | The highest level container within Netdata Cloud for a user to organize their team members and nodes within their infrastructure. A Space likely represents an entire organization or a large team. <br /><br />_Space_ is always capitalized. | -| **unreachable node** | A claimed node with a disrupted [Agent-Cloud link](/aclk/README.md). Unreachable could mean the node no longer exists or is experiencing network connectivity issues with Cloud. | +| **unreachable node** | A connected node with a disrupted [Agent-Cloud link](/aclk/README.md). Unreachable could mean the node no longer exists or is experiencing network connectivity issues with Cloud. | | **visited node** | A node which has had its Agent dashboard directly visited by a user. A list of these is maintained on a per-user basis. | | **War Room** | A smaller grouping of nodes where users can view key metrics in real-time and monitor the health of many nodes with their alarm status. War Rooms can be used to organize nodes in any way that makes sense for your infrastructure, such as by a service, purpose, physical location, and more. <br /><br />_War Room_ is always capitalized. | diff --git a/docs/getting-started.md b/docs/getting-started.md index e80b80eeda..2d1f3de6d9 100644 --- a/docs/getting-started.md +++ b/docs/getting-started.md @@ -203,7 +203,7 @@ You can use these features together or separately—the decision is up to yo - Sign up for [Netdata Cloud](https://app.netdata.cloud). - Read the [infrastructure monitoring quickstart](/docs/quickstart/infrastructure.md). -- Better understand how the Netdata Agent connects securely to Netdata Cloud with [claiming](/claim/README.md) and +- Better understand how the Netdata Agent connects securely to Netdata Cloud with [connection process](/claim/README.md) and [Agent-Cloud link](/aclk/README.md) documentation. ## Start, stop, and restart Netdata @@ -221,7 +221,7 @@ details. ## What's next? Even after you've configured `netdata.conf`, tweaked alarms, learned the basics of performance troubleshooting, and -claimed all your systems in Netdata Cloud or added them to the Visited nodes menu, you've just gotten started with +connected all your systems in Netdata Cloud or added them to the Visited nodes menu, you've just gotten started with Netdata. Take a look at some more advanced features and configurations: diff --git a/docs/guides/deploy/ansible.md b/docs/guides/deploy/ansible.md index b1afdf3158..3e7c64a561 100644 --- a/docs/guides/deploy/ansible.md +++ b/docs/guides/deploy/ansible.md @@ -33,7 +33,7 @@ operate. When you deploy Netdata with Ansible, you're also deploying _monitoring In this guide, we'll walk through the process of using an [Ansible playbook](https://github.com/netdata/community/tree/main/netdata-agent-deployment/ansible-quickstart) to automatically -deploy the Netdata Agent to any number of distributed nodes, manage the configuration of each node, and claim them to +deploy the Netdata Agent to any number of distributed nodes, manage the configuration of each node, and connect them to your Netdata Cloud account. You'll go from some unmonitored nodes to a infrastructure monitoring solution in a matter of minutes. @@ -98,7 +98,7 @@ two different SSH keys supplied by AWS. ### Edit the `vars/main.yml` file -In order to claim your node(s) to your Space in Netdata Cloud, and see all their metrics in real-time in [composite +In order to connect your node(s) to your Space in Netdata Cloud, and see all their metrics in real-time in [composite charts](/docs/visualize/overview-infrastructure.md) or perform [Metric Correlations](https://learn.netdata.cloud/docs/cloud/insights/metric-correlations), you need to set the `claim_token` and `claim_room` variables. @@ -120,7 +120,7 @@ claim_rooms: XXXXX Change the `dbengine_multihost_disk_space` if you want to change the metrics retention policy by allocating more or less disk space for storing metrics. The default is 2048 Mib, or 2 GiB. -Because we're claiming this node to Netdata Cloud, and will view its dashboards there instead of via the IP address or +Because we're connecting this node to Netdata Cloud, and will view its dashboards there instead of via the IP address or hostname of the node, the playbook disables that local dashboard by setting `web_mode` to `none`. This gives a small security boost by not allowing any unwanted access to the local dashboard. @@ -147,7 +147,7 @@ Next, Ansible makes changes to each node according to the `tasks` defined in the [returns](https://docs.ansible.com/ansible/latest/reference_appendices/common_return_values.html#changed) whether each t |