From ffd4c9219493a392c5c0992ce1e6d00bc62585d0 Mon Sep 17 00:00:00 2001 From: Hugo Valente <82235632+hugovalente-pm@users.noreply.github.com> Date: Mon, 9 Aug 2021 12:49:40 +0100 Subject: changed the term claim to connect (to Cloud) on docs (#11378) --- aclk/README.md | 18 ++-- claim/README.md | 102 ++++++++++----------- cli/README.md | 2 +- daemon/README.md | 2 +- docs/agent-cloud.md | 6 +- docs/anonymous-statistics.md | 2 +- docs/configure/secure-nodes.md | 2 +- docs/contributing/style-guide.md | 4 +- docs/getting-started.md | 4 +- docs/guides/deploy/ansible.md | 8 +- docs/guides/monitor/anomaly-detection.md | 2 +- docs/guides/monitor/kubernetes-k8s-netdata.md | 8 +- docs/guides/monitor/lamp-stack.md | 2 +- docs/guides/step-by-step/step-03.md | 4 +- .../monitor-debug-applications-ebpf.md | 4 +- docs/monitor/enable-notifications.md | 2 +- docs/quickstart/infrastructure.md | 4 +- packaging/installer/methods/kickstart-64.md | 10 +- packaging/installer/methods/kickstart.md | 10 +- packaging/installer/methods/kubernetes.md | 10 +- 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 @@ -# 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_.

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.

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.

_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.

_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 task results in a changed, failure, or was skipped entirely. -The task to install Netdata will take a few minutes per node, so be patient! Once the playbook reaches the claiming +The task to install Netdata will take a few minutes per node, so be patient! Once the playbook reaches the connect to Cloud task, your nodes start populating your Space in Netdata Cloud. ## What's next? diff --git a/docs/guides/monitor/anomaly-detection.md b/docs/guides/monitor/anomaly-detection.md index f680f5f2ef..1b224b9705 100644 --- a/docs/guides/monitor/anomaly-detection.md +++ b/docs/guides/monitor/anomaly-detection.md @@ -23,7 +23,7 @@ library](https://github.com/yzhao062/pyod/tree/master), which periodically runs quantify how anomalous certain charts are. All these metrics and alarms are available for centralized monitoring in [Netdata Cloud](https://app.netdata.cloud). If -you choose to sign up for Netdata Cloud and [claim your nodes](/claim/README.md), you will have the ability to run +you choose to sign up for Netdata Cloud and [coonect your nodes](/claim/README.md), you will have the ability to run tailored anomaly detection on every node in your infrastructure, regardless of its purpose or workload. In this guide, you'll learn how to set up the anomalies collector to instantly detect anomalies in an Nginx web server diff --git a/docs/guides/monitor/kubernetes-k8s-netdata.md b/docs/guides/monitor/kubernetes-k8s-netdata.md index c5cb2c1bc9..5d4886e682 100644 --- a/docs/guides/monitor/kubernetes-k8s-netdata.md +++ b/docs/guides/monitor/kubernetes-k8s-netdata.md @@ -45,9 +45,9 @@ To follow this tutorial, you need: - A free Netdata Cloud account. [Sign up](https://app.netdata.cloud/sign-up?cloudRoute=/spaces) if you don't have one already. -- A working cluster running Kubernetes v1.9 or newer, with a Netdata deployment and claimed parent/child nodes. See +- A working cluster running Kubernetes v1.9 or newer, with a Netdata deployment and connected parent/child nodes. See our [Kubernetes deployment process](/packaging/installer/methods/kubernetes.md) for details on deployment and - claiming. + conneting to Cloud. - The [`kubectl`](https://kubernetes.io/docs/reference/kubectl/overview/) command line tool, within [one minor version difference](https://kubernetes.io/docs/tasks/tools/install-kubectl/#before-you-begin) of your cluster, on an administrative system. @@ -98,10 +98,10 @@ robot-shop web-8bb887476-lkcjx 1/1 Running 0 14m ## Explore Netdata's Kubernetes monitoring charts The Netdata Helm chart deploys and enables everything you need for monitoring Kubernetes on every layer. Once you deploy -Netdata and claim your cluster's nodes, you're ready to check out the visualizations **with zero configuration**. +Netdata and connect your cluster's nodes, you're ready to check out the visualizations **with zero configuration**. To get started, [sign in](https://app.netdata.cloud/sign-in?cloudRoute=/spaces) to your Netdata Cloud account. Head over -to the War Room you claimed your cluster to, if not **General**. +to the War Room you connected your cluster to, if not **General**. Netdata Cloud is already visualizing your Kubernetes metrics, streamed in real-time from each node, in the [Overview](https://learn.netdata.cloud/docs/cloud/visualize/overview): diff --git a/docs/guides/monitor/lamp-stack.md b/docs/guides/monitor/lamp-stack.md index 95aa03f0bb..38b9d0bef3 100644 --- a/docs/guides/monitor/lamp-stack.md +++ b/docs/guides/monitor/lamp-stack.md @@ -167,7 +167,7 @@ If the Netdata Agent isn't already open in your browser, open a new tab and navi > If you [signed up](https://app.netdata.cloud/sign-up?cloudRoute=/spaces) for Netdata Cloud earlier, you can also view > the exact same LAMP stack metrics there, plus additional features, like drag-and-drop custom dashboards. Be sure to -> [claim your node](/claim/README.md) to start streaming metrics to your browser through Netdata Cloud. +> [connecting your node](/claim/README.md) to start streaming metrics to your browser through Netdata Cloud. Netdata automatically organizes all metrics and charts onto a single page for easy navigation. Peek at gauges to see overall system performance, then scroll down to see more. Click-and-drag with your mouse to pan _all_ charts back and diff --git a/docs/guides/step-by-step/step-03.md b/docs/guides/step-by-step/step-03.md index 2319adb449..a2f37beebf 100644 --- a/docs/guides/step-by-step/step-03.md +++ b/docs/guides/step-by-step/step-03.md @@ -43,7 +43,7 @@ features, new collectors for more applications, and improved UI, so will Cloud. ## Get started with Netdata Cloud -Signing in, onboarding, and claiming your first nodes only takes a few minutes, and we have a [Get started with +Signing in, onboarding, and connecting your first nodes only takes a few minutes, and we have a [Get started with Cloud](https://learn.netdata.cloud/docs/cloud/get-started) guide to help you walk through every step. Or, if you're feeling confident, dive right in. @@ -82,7 +82,7 @@ nodes](https://user-images.githubusercontent.com/1153921/80831018-e158ac80-8b9e- ## What's next? -Now that you have a Netdata Cloud account with a claimed node (or a few!) and can navigate between your dashboards with +Now that you have a Netdata Cloud account with a connected node (or a few!) and can navigate between your dashboards with Visited nodes, it's time to learn more about how you can configure Netdata to your liking. From there, you'll be able to customize your Netdata experience to your exact infrastructure and the information you need. diff --git a/docs/guides/troubleshoot/monitor-debug-applications-ebpf.md b/docs/guides/troubleshoot/monitor-debug-applications-ebpf.md index d6c4b06976..688e7d296b 100644 --- a/docs/guides/troubleshoot/monitor-debug-applications-ebpf.md +++ b/docs/guides/troubleshoot/monitor-debug-applications-ebpf.md @@ -236,8 +236,8 @@ same application on multiple systems and want to correlate how it performs on ea findings with someone else on your team. If you don't already have a Netdata Cloud account, go [sign in](https://app.netdata.cloud) and get started for free. -Read the [get started with Cloud guide](https://learn.netdata.cloud/docs/cloud/get-started) for a walkthrough of node -claiming and other fundamentals. +Read the [get started with Cloud guide](https://learn.netdata.cloud/docs/cloud/get-started) for a walkthrough of +connecting nodes to and other fundamentals. Once you've added one or more nodes to a Space in Netdata Cloud, you can see aggregated eBPF metrics in the [Overview dashboard](/docs/visualize/overview-infrastructure.md) under the same **Applications** or **eBPF** sections that you diff --git a/docs/monitor/enable-notifications.md b/docs/monitor/enable-notifications.md index 961684b71b..e5b5a6f265 100644 --- a/docs/monitor/enable-notifications.md +++ b/docs/monitor/enable-notifications.md @@ -14,7 +14,7 @@ alarms](/docs/monitor/configure-alarms.md) to change the preconfigured threshold infrastructure. Netdata Cloud offers [centralized alarm notifications](#netdata-cloud) via email, which leverages the health status -information already streamed to Netdata Cloud from claimed nodes to send notifications to those who have enabled them. +information already streamed to Netdata Cloud from connected nodes to send notifications to those who have enabled them. The Netdata Agent has a [notification system](#netdata-agent) that supports more than a dozen services, such as email, Slack, PagerDuty, Twilio, Amazon SNS, Discord, and much more. diff --git a/docs/quickstart/infrastructure.md b/docs/quickstart/infrastructure.md index 71e70b94bc..ed136fe12f 100644 --- a/docs/quickstart/infrastructure.md +++ b/docs/quickstart/infrastructure.md @@ -25,10 +25,10 @@ In this quickstart guide, you'll learn the basics of using Netdata Cloud to moni composite charts, and alarm viewing. You'll then learn about the most critical ways to configure the Agent on each of your nodes to maximize the value you get from Netdata. -This quickstart assumes you've installed the Netdata Agent on more than one node in your infrastructure, and claimed +This quickstart assumes you've installed the Netdata Agent on more than one node in your infrastructure, and connected those nodes to your Space in Netdata Cloud. If you haven't yet, see the [Netdata Cloud](https://learn.netdata.cloud/docs/cloud) docs for details on signing up for Netdata Cloud, installation, and -claiming. +connection process. > If you want to monitor a Kubernetes cluster with Netdata, see our [k8s installation > doc](/packaging/installer/methods/kubernetes.md) for setup details, and then read our guide, [_Monitor a Kubernetes diff --git a/packaging/installer/methods/kickstart-64.md b/packaging/installer/methods/kickstart-64.md index 3418ad141e..93141740fd 100644 --- a/packaging/installer/methods/kickstart-64.md +++ b/packaging/installer/methods/kickstart-64.md @@ -71,18 +71,18 @@ your installation. Here are a few important parameters: kickstart run the process using those files. This option conflicts with the `--stable-channel` option. If you set this _and_ `--stable-channel`, Netdata will use the local files. -### Claim node to Netdata Cloud during installation +### Connect node to Netdata Cloud during installation -The `kickstart.sh` script accepts additional parameters to automatically [claim](/claim/README.md) your node to Netdata +The `kickstart.sh` script accepts additional parameters to automatically [connect](/claim/README.md) your node to Netdata Cloud immediately after installation. Find the `token` and `rooms` strings by [signing in to Netdata -Cloud](https://app.netdata.cloud/sign-in?cloudRoute=/spaces), then clicking on **Claim Nodes** in the [Spaces management +Cloud](https://app.netdata.cloud/sign-in?cloudRoute=/spaces), then clicking on **Connect Nodes** in the [Spaces management area](https://learn.netdata.cloud/docs/cloud/spaces#manage-spaces). - `--claim-token`: The unique token associated with your Space in Netdata Cloud. - `--claim-rooms`: A comma-separated list of tokens for each War Room this node should appear in. - `--claim-proxy`: Should take the form of `socks5[h]://[user:pass@]host:ip` for a SOCKS5 proxy, or - `http://[user:pass@]host:ip` for an HTTP(S) proxy.See [claiming through a - proxy](/claim/README.md#claim-through-a-proxy) for details. + `http://[user:pass@]host:ip` for an HTTP(S) proxy.See [connecting through a + proxy](/claim/README.md#connect-through-a-proxy) for details. - `--claim-url`: Defaults to `https://app.netdata.cloud`. For example: diff --git a/packaging/installer/methods/kickstart.md b/packaging/installer/methods/kickstart.md index 18fde292c8..5b5a8f8f5b 100644 --- a/packaging/installer/methods/kickstart.md +++ b/packaging/installer/methods/kickstart.md @@ -54,18 +54,18 @@ installation. Here are a few important parameters: process using those files. This option conflicts with the `--stable-channel` option. If you set this _and_ `--stable-channel`, Netdata will use the local files. -### Claim node to Netdata Cloud during installation +### Connect node to Netdata Cloud during installation -The `kickstart.sh` script accepts additional parameters to automatically [claim](/claim/README.md) your node to Netdata +The `kickstart.sh` script accepts additional parameters to automatically [connect](/claim/README.md) your node to Netdata Cloud immediately after installation. Find the `token` and `rooms` strings by [signing in to Netdata -Cloud](https://app.netdata.cloud/sign-in?cloudRoute=/spaces), then clicking on **Claim Nodes** in the [Spaces management +Cloud](https://app.netdata.cloud/sign-in?cloudRoute=/spaces), then clicking on **Connect Nodes** in the [Spaces management area](https://learn.netdata.cloud/docs/cloud/spaces#manage-spaces). - `--claim-token`: The unique token associated with your Space in Netdata Cloud. - `--claim-rooms`: A comma-separated list of tokens for each War Room this node should appear in. - `--claim-proxy`: Should take the form of `socks5[h]://[user:pass@]host:ip` for a SOCKS5 proxy, or - `http://[user:pass@]host:ip` for an HTTP(S) proxy.See [claiming through a - proxy](/claim/README.md#claim-through-a-proxy) for details. + `http://[user:pass@]host:ip` for an HTTP(S) proxy.See [connecting through a + proxy](/claim/README.md#connect-through-a-proxy) for details. - `--claim-url`: Defaults to `https://app.netdata.cloud`. For example: diff --git a/packaging/installer/methods/kubernetes.md b/packaging/installer/methods/kubernetes.md index f593765fc3..f92855b47f 100644 --- a/packaging/installer/methods/kubernetes.md +++ b/packaging/installer/methods/kubernetes.md @@ -39,10 +39,10 @@ parent pod, and multiple child pods. You've now installed Netdata on your Kubernetes cluster. Next, it's time to opt-in and enable the powerful Kubernetes dashboards available in Netdata Cloud. -## Claim your Kubernetes cluster to Netdata Cloud +## Connect your Kubernetes cluster to Netdata Cloud To start [Kubernetes monitoring](https://learn.netdata.cloud/docs/cloud/visualize/kubernetes/), you must first -[claim](/claim/README.md) your Kubernetes cluster to [Netdata Cloud](https://app.netdata.cloud). Claiming securely +[connect](/claim/README.md) your Kubernetes cluster to [Netdata Cloud](https://app.netdata.cloud). The connection process securely connects your Kubernetes cluster to stream metrics data to Netdata Cloud, enabling Kubernetes-specific visualizations like the health map and time-series composite charts. @@ -57,7 +57,7 @@ touch override.yml ``` Paste the following into your `override.yml` file, replacing instances of `ROOM` and `TOKEN` with those from the -claiming script from Netdata Cloud. These settings claim your `parent`/`child` nodes to Netdata Cloud and store more +claiming script from Netdata Cloud. These settings connect your `parent`/`child` nodes to Netdata Cloud and store more metrics in the nodes' time-series databases. ```yaml @@ -92,7 +92,7 @@ Apply these new settings: helm upgrade -f override.yml netdata netdata/netdata ``` -The cluster terminates the old pods and creates new ones with the proper persistence and claiming configuration. You'll +The cluster terminates the old pods and creates new ones with the proper persistence and connection configuration. You'll see your nodes, containers, and pods appear in Netdata Cloud in a few seconds. ![Netdata's Kubernetes monitoring @@ -107,7 +107,7 @@ Read up on the various configuration options in the [Helm chart documentation](https://github.com/netdata/helmchart#configuration) if you need to tweak your Kubernetes monitoring. Your first option is to create an `override.yml` file, if you haven't created one already for -[claiming](#claim-your-kubernetes-cluster-to-netdata-cloud), then apply the new configuration to your cluster with `helm +[connect](#connect-your-kubernetes-cluster-to-netdata-cloud), then apply the new configuration to your cluster with `helm upgrade`. ```bash diff --git a/packaging/installer/methods/manual.md b/packaging/installer/methods/manual.md index aa49c81ac8..ae96dd9541 100644 --- a/packaging/installer/methods/manual.md +++ b/packaging/installer/methods/manual.md @@ -217,13 +217,13 @@ cd netdata process using those files. This option conflicts with the `--stable-channel` option. If you set this _and_ `--stable-channel`, Netdata will use the local files. -### Claim node to Netdata Cloud during installation +### Connect node to Netdata Cloud during installation Unlike the [`kickstart.sh`](/packaging/installer/methods/kickstart.md) or [`kickstart-static64.sh`](/packaging/installer/methods/kickstart-64.md) methods, the `netdata-installer.sh` script does -not allow you to automatically [claim](/claim/README.md) your node to Netdata Cloud immediately after installation. +not allow you to automatically [connect](/claim/README.md) your node to Netdata Cloud immediately after installation. -See the [claiming](/claim/README.md) doc for details on claiming a node with a manual installation of Netdata. +See the [connect to cloud](/claim/README.md) doc for details on connecting a node with a manual installation of Netdata. ### 'nonrepresentable section on output' errors -- cgit v1.2.3