mirror of
https://github.com/netdata/netdata.git
synced 2025-04-16 18:37:50 +00:00
Installation section Improvements (#19981)
* Doc Ansible installation improved wording * Ansible Improved Wording * Kickstart reorganized footerless * AWS, AZURE, K8S, Improved wording
This commit is contained in:
kanelatechnical
GitHub
parent
e62322fe7a
commit
50f4686133
5 changed files with 27 additions and 69 deletions
packaging/installer/methods
|
|
@ -1,34 +1,15 @@
|
|||
# Deploy Netdata with Ansible
|
||||
|
||||
Netdata's [one-line kickstart](/packaging/installer/README.md) is zero-configuration, highly adaptable, and compatible with tons
|
||||
of different operating systems and Linux distributions. You can use it on bare metal, VMs, containers, and everything
|
||||
in-between.
|
||||
How do you quickly set up infrastructure monitoring? How can you efficiently deploy Netdata across multiple nodes? How do you make sure the deployment is **reliable, repeatable, and idempotent**? And how can you manage monitoring as **code**?
|
||||
|
||||
But what if you're trying to bootstrap an infrastructure monitoring solution as quickly as possible? What if you need to
|
||||
deploy Netdata across an entire infrastructure with many nodes? What if you want to make this deployment reliable,
|
||||
repeatable, and idempotent? What if you want to write and deploy your infrastructure or cloud monitoring system like
|
||||
code?
|
||||
Meet [Ansible](https://ansible.com), a popular tool for provisioning, configuration management, and infrastructure as code (IaC). It uses **playbooks** to streamline operations with simple syntax, running them securely over SSH—no agent required. That means less setup and more focus on your application and monitoring.
|
||||
|
||||
Enter [Ansible](https://ansible.com), a popular system provisioning, configuration management, and infrastructure as
|
||||
code (IaC) tool. Ansible uses **playbooks** to glue many standardized operations together with a simple syntax, then run
|
||||
those operations over standard and secure SSH connections. There's no Agent to install on the remote system, so all you
|
||||
have to worry about is your application and your monitoring software.
|
||||
What does **idempotent** mean?
|
||||
From the [Ansible glossary](https://docs.ansible.com/ansible/latest/reference_appendices/glossary.html)
|
||||
|
||||
Ansible has some competition from the likes of [Puppet](https://puppet.com/) or [Chef](https://www.chef.io/), but the
|
||||
most valuable feature about Ansible is **idempotent**. From the [Ansible
|
||||
glossary](https://docs.ansible.com/ansible/latest/reference_appendices/glossary.html)
|
||||
> An operation is **idempotent** if running it once produces the same result as running it multiple times, without unintended changes. With Ansible, you can deploy Netdata repeatedly without disrupting your infrastructure—ensuring monitoring as code.
|
||||
|
||||
> An operation is idempotent if the result of performing it once is exactly the same as the result of performing it
|
||||
> repeatedly without any intervening actions.
|
||||
|
||||
Idempotency means you can run an Ansible playbook against your nodes any number of times without affecting how they
|
||||
operate. When you deploy Netdata with Ansible, you're also deploying _monitoring as code_.
|
||||
|
||||
In this guide, we'll walk through the process of using an [Ansible
|
||||
playbook](https://github.com/netdata/community/tree/main/configuration-management/ansible-quickstart/) to automatically
|
||||
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.
|
||||
This guide walks you through deploying the **Netdata Agent** across multiple nodes using an [Ansible playbook](https://github.com/netdata/community/tree/main/configuration-management/ansible-quickstart/), managing configurations, and connecting to **Netdata Cloud**—all in minutes.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
|
@ -115,9 +96,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 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.
|
||||
Since this node connects to Netdata Cloud, we’ll view its dashboards there instead of using its IP or hostname. The playbook disables the local dashboard by setting `web_mode` to `none`, adding a small security boost by preventing unwanted access.
|
||||
|
||||
You can read more about this decision, or other ways you might lock down the local dashboard, in our [node security
|
||||
doc](/docs/security-and-privacy-design/README.md).
|
||||
|
|
@ -135,8 +114,7 @@ ansible-playbook -i hosts tasks/main.yml
|
|||
|
||||
Ansible first connects to your node(s) via SSH, then [collects
|
||||
facts](https://docs.ansible.com/ansible/latest/user_guide/playbooks_vars_facts.html#ansible-facts) about the system.
|
||||
This playbook doesn't use these facts, but you could expand it to provision specific types of systems based on the
|
||||
makeup of your infrastructure.
|
||||
This playbook doesn’t use these facts yet, but you can expand it to set up systems based on your infrastructure.
|
||||
|
||||
Next, Ansible makes changes to each node according to the `tasks` defined in the playbook, and
|
||||
[returns](https://docs.ansible.com/ansible/latest/reference_appendices/common_return_values.html#changed) whether each
|
||||
|
|
|
|||
|
|
@ -1,29 +1,22 @@
|
|||
# Install Netdata on AWS
|
||||
|
||||
Netdata is fully compatible with Amazon Web Services (AWS).
|
||||
You can install Netdata on cloud instances to monitor the apps/services running there, or use
|
||||
multiple instances in a [parent-child streaming](/src/streaming/README.md) configuration.
|
||||
You can install Netdata on cloud instances to monitor the apps/services running there, or use multiple instances in a [parent-child streaming](/src/streaming/README.md) configuration.
|
||||
|
||||
## Recommended installation method
|
||||
|
||||
The best installation method depends on the instance's operating system, distribution, and version. For Linux instances,
|
||||
we recommend the [`kickstart.sh` automatic installation script](/packaging/installer/methods/kickstart.md).
|
||||
The best installation method depends on the instance's operating system, distribution, and version. For Linux instances, we recommend the [`kickstart.sh` automatic installation script](/packaging/installer/methods/kickstart.md).
|
||||
|
||||
If you have issues with Netdata after installation, look to the sections below to find the issue you're experiencing,
|
||||
followed by the solution for your provider.
|
||||
If you have issues with Netdata after installation, look to the sections below to find the issue you're experiencing, followed by the solution for your provider.
|
||||
|
||||
## Post-installation configuration
|
||||
|
||||
### Add a firewall rule to access Netdata's dashboard
|
||||
|
||||
If you cannot access Netdata's dashboard on your cloud instance via `http://HOST:19999`, and instead get an error page
|
||||
from your browser that says, "This site can't be reached" (Chrome) or "Unable to connect" (Firefox), you may need to
|
||||
configure your cloud provider's firewall.
|
||||
from your browser that says, "This site can't be reached" (Chrome) or "Unable to connect" (Firefox), you may need to configure your cloud provider's firewall.
|
||||
|
||||
Cloud providers often create network-level firewalls that run separately from the instance itself. Both AWS and Google
|
||||
Cloud Platform calls them Virtual Private Cloud (VPC) networks. These firewalls can apply even if you've disabled
|
||||
firewalls on the instance itself. Because you can modify these firewalls only via the cloud provider's web interface,
|
||||
it's easy to overlook them when trying to configure and access Netdata's dashboard.
|
||||
Cloud providers often use network-level firewalls, called Virtual Private Cloud (VPC) networks (e.g., AWS and Google Cloud), separate from the instance. These firewalls can still apply even if the instance's firewall is disabled. Since they can only be modified via the cloud provider's web interface, they are easy to overlook when configuring or accessing Netdata’s dashboard.
|
||||
|
||||
You can often confirm a firewall issue by querying the dashboard while connected to the instance via SSH: `curl
|
||||
http://localhost:19999/api/v1/info`. If you see JSON output, Netdata is running properly. If you try the same `curl`
|
||||
|
|
@ -55,4 +48,4 @@ Description: Netdata
|
|||
|
||||
You can also choose **My IP** as the source if you prefer.
|
||||
|
||||
Click **Save** to apply your new inbound firewall rule.
|
||||
Click **Save** to apply your new inbound firewall rule.
|
||||
|
|
@ -1,29 +1,22 @@
|
|||
# Install Netdata on Azure
|
||||
|
||||
Netdata is fully compatible with Azure.
|
||||
You can install Netdata on cloud instances to monitor the apps/services running there, or use
|
||||
multiple instances in a [parent-child streaming](/src/streaming/README.md) configuration.
|
||||
You can install Netdata on cloud instances to monitor the apps/services running there, or use multiple instances in a [parent-child streaming](/src/streaming/README.md) configuration.
|
||||
|
||||
## Recommended installation method
|
||||
|
||||
The best installation method depends on the instance's operating system, distribution, and version. For Linux instances,
|
||||
we recommend the [`kickstart.sh` automatic installation script](/packaging/installer/methods/kickstart.md).
|
||||
The best installation method depends on the instance's operating system, distribution, and version. For Linux instances, we recommend the [`kickstart.sh` automatic installation script](/packaging/installer/methods/kickstart.md).
|
||||
|
||||
If you have issues with Netdata after installation, look to the sections below to find the issue you're experiencing,
|
||||
followed by the solution for your provider.
|
||||
If you have issues with Netdata after installation, look to the sections below to find the issue you're experiencing, followed by the solution for your provider.
|
||||
|
||||
## Post-installation configuration
|
||||
|
||||
### Add a firewall rule to access Netdata's dashboard
|
||||
|
||||
If you cannot access Netdata's dashboard on your cloud instance via `http://HOST:19999`, and instead get an error page
|
||||
from your browser that says, "This site can't be reached" (Chrome) or "Unable to connect" (Firefox), you may need to
|
||||
configure your cloud provider's firewall.
|
||||
from your browser that says, "This site can't be reached" (Chrome) or "Unable to connect" (Firefox), you may need to configure your cloud provider's firewall.
|
||||
|
||||
Cloud providers often create network-level firewalls that run separately from the instance itself. Both AWS and Google
|
||||
Cloud Platform calls them Virtual Private Cloud (VPC) networks. These firewalls can apply even if you've disabled
|
||||
firewalls on the instance itself. Because you can modify these firewalls only via the cloud provider's web interface,
|
||||
it's easy to overlook them when trying to configure and access Netdata's dashboard.
|
||||
Cloud providers like AWS and Google Cloud use network-level firewalls called Virtual Private Cloud (VPC) networks, which apply even if the instance's firewall is disabled. Since these firewalls can only be modified through the cloud provider's web interface, they can be easily overlooked when configuring or accessing Netdata's dashboard.
|
||||
|
||||
You can often confirm a firewall issue by querying the dashboard while connected to the instance via SSH: `curl
|
||||
http://localhost:19999/api/v1/info`. If you see JSON output, Netdata is running properly. If you try the same `curl`
|
||||
|
|
@ -54,4 +47,4 @@ Priority: 310
|
|||
Name: Netdata
|
||||
```
|
||||
|
||||
Click **Add** to apply your new inbound security rule.
|
||||
Click **Add** to apply your new inbound security rule.
|
||||
|
|
@ -183,7 +183,3 @@ The `kickstart.sh` script does the following after being downloaded and run usin
|
|||
- If no static build is available, installs required dependencies and then attempts to install by building Netdata locally (by downloading the sources and building them directly).
|
||||
- Installs `netdata-updater.sh` to `cron.daily`, so your Netdata installation will be updated with new nightly versions, unless you override that with an [optional parameter](#optional-parameters-to-alter-your-installation).
|
||||
- Prints a message whether installation succeeded or failed for QA purposes.
|
||||
<!--stackedit_data:
|
||||
eyJoaXN0b3J5IjpbLTExMTgwOTg4NzMsLTE1ODk2MzM4MTRdfQ
|
||||
==
|
||||
-->
|
||||
|
|
@ -3,16 +3,15 @@ import TabItem from '@theme/TabItem';
|
|||
|
||||
# Install Netdata on Kubernetes
|
||||
|
||||
This document details how to install Netdata on an existing Kubernetes (k8s) cluster, and connect it to Netdata Cloud. Read our [Kubernetes visualizations](/docs/dashboards-and-charts/kubernetes-tab.md) documentation, to see what you will get.
|
||||
This document details how to install Netdata on an existing Kubernetes (k8s) cluster, and connect it to Netdata Cloud.
|
||||
|
||||
The [Netdata Helm chart](https://github.com/netdata/helmchart/blob/master/charts/netdata/README.md) installs one `parent` pod for storing metrics and managing alert notifications, plus an additional
|
||||
`child` pod for every node in the cluster, responsible for collecting metrics from the node, Kubernetes control planes,
|
||||
pods/containers, and [supported application-specific
|
||||
metrics](https://github.com/netdata/helmchart#service-discovery-and-supported-services).
|
||||
Read our [Kubernetes visualizations](/docs/dashboards-and-charts/kubernetes-tab.md) documentation, to see what you will get.
|
||||
|
||||
The [Netdata Helm chart](https://github.com/netdata/helmchart/blob/master/charts/netdata/README.md) installs one `parent` pod for storing metrics and managing alert notifications, plus an additional `child` pod for every node in the cluster, responsible for collecting metrics from the node, Kubernetes control planes, pods/containers, and [supported application-specific metrics](https://github.com/netdata/helmchart#service-discovery-and-supported-services).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To deploy Kubernetes monitoring with Netdata, you need:
|
||||
To deploy Kubernetes monitoring with Netdata, you'll need:
|
||||
|
||||
- A working cluster running Kubernetes v1.9 or newer.
|
||||
- The [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/) command line tool, within [one minor version
|
||||
|
|
@ -121,8 +120,7 @@ The cluster terminates the old pods and creates new ones with the proper persist
|
|||
|
||||
|
||||
If you don't need to configure your Netdata deployment, [skip down](#whats-next) to see how Kubernetes monitoring works
|
||||
in Netdata, in addition to more guides and resources.
|
||||
If you don't need to configure your Netdata deployment, [skip down](#whats-next) to see how Kubernetes monitoring works in Netdata, in addition to more guides and resources.
|
||||
|
||||
## Configure your Netdata monitoring deployment
|
||||
|
||||
|
|
@ -187,4 +185,4 @@ To update Netdata's Helm chart to the latest version, run `helm repo update`, th
|
|||
```bash
|
||||
helm repo update
|
||||
helm upgrade netdata netdata/netdata
|
||||
```
|
||||
```
|
||||
Loading…
Add table
Reference in a new issue