diff options
Diffstat (limited to 'docs/category-overview-pages')
8 files changed, 112 insertions, 283 deletions
diff --git a/docs/category-overview-pages/accessing-netdata-dashboards.md b/docs/category-overview-pages/accessing-netdata-dashboards.md index 97df8b835..af7b0df82 100644 --- a/docs/category-overview-pages/accessing-netdata-dashboards.md +++ b/docs/category-overview-pages/accessing-netdata-dashboards.md @@ -35,4 +35,4 @@ Netdata starts a web server for its dashboard at port `19999`. Open up your web navigate to `http://NODE:19999`, replacing `NODE` with the IP address or hostname of your Agent. If installed on localhost, you can access it through `http://localhost:19999`. -Documentation for previous Agent dashboard can still be found [here](https://github.com/netdata/netdata/blob/master/web/gui/README.md).
\ No newline at end of file +Documentation for previous Agent dashboard can still be found [here](https://github.com/netdata/netdata/blob/master/src/web/gui/README.md).
\ No newline at end of file diff --git a/docs/category-overview-pages/deployment-strategies.md b/docs/category-overview-pages/deployment-strategies.md deleted file mode 100644 index 69daaf9fd..000000000 --- a/docs/category-overview-pages/deployment-strategies.md +++ /dev/null @@ -1,268 +0,0 @@ -# Deployment strategies - -Netdata can be used to monitor all kinds of infrastructure, from stand-alone tiny IoT devices to complex hybrid setups -combining on-premise and cloud infrastructure, mixing bare-metal servers, virtual machines and containers. - -There are 3 components to structure your Netdata ecosystem: - -1. **Netdata Agents** - To monitor the physical or virtual nodes of your infrastructure, including all applications and containers running on them. - - Netdata Agents are Open-Source, licensed under GPL v3+. - -2. **Netdata Parents** - To create data centralization points within your infrastructure, to offload Netdata Agents functions from your production - systems, to provide high-availability of your data, increased data retention and isolation of your nodes. - - Netdata Parents are implemented using the Netdata Agent software. Any Netdata Agent can be an Agent for a node and a Parent - for other Agents, at the same time. - - It is recommended to set up multiple Netdata Parents. They will all seamlessly be integrated by Netdata Cloud into one monitoring solution. - - -3. **Netdata Cloud** - Our SaaS, combining all your infrastructure, all your Netdata Agents and Parents, into one uniform, distributed, - scalable, monitoring database, offering advanced data slicing and dicing capabilities, custom dashboards, advanced troubleshooting - tools, user management, centralized management of alerts, and more. - - -The Netdata Agent is a highly modular software piece, providing data collection via numerous plugins, an in-house crafted time-series -database, a query engine, health monitoring and alerts, machine learning and anomaly detection, metrics exporting to third party systems. - - -## Deployment Options Overview - -This section provides a quick overview of a few common deployment options. The next sections go into configuration examples and further reading. - -### Stand-alone Deployment - -To help our users have a complete experience of Netdata when they install it for the first time, a Netdata Agent with default configuration -is a complete monitoring solution out of the box, having all these features enabled and available. - -The Agent will act as a _stand-alone_ Agent by default, and this is great to start out with for small setups and home labs. By [connecting each Agent to Cloud](https://github.com/netdata/netdata/blob/master/claim/README.md), you can see an overview of all your nodes, with aggregated charts and centralized alerting, without setting up a Parent. - - - -### Parent – Child Deployment - -An Agent connected to a Parent is called a _Child_. It will _stream_ metrics to its Parent. The Parent can then take care of storing metrics on behalf of that node (with longer retention), handle metrics queries for showing dashboards, and provide alerting. - -When using Cloud, it is recommended that just the Parent is connected to Cloud. Child Agents can then be configured to have short retention, in RAM instead of on Disk, and have alerting and other features disabled. Because they don't need to connect to Cloud themselves, those children can then be further secured by not allowing outbound traffic. - - - -This setup allows for leaner Child nodes and is good for setups with more than a handful of nodes. Metrics data remains accessible if the Child node is temporarily unavailable or decommissioned, although there is no failover in case the Parent becomes unavailable. - - -### Active–Active Parent Deployment - -For high availability, Parents can be configured to stream data for their children between them, and keep the data sets in sync. Child Agents are configured with the addresses of both Parent Agents, but will only stream to one of them at a time. When that Parent becomes unavailable, it reconnects to another. When the first Parent becomes available again, that Parent will catch up by receiving the backlog from the second. - -With both Parent Agents connected to Cloud, Cloud will route queries to either Parent transparently, depending on their availability. Alerts trigger on either Parent will stream to Cloud, and Cloud will deduplicate and debounce state changes to prevent spurious notifications. - - - - -## Configuration Details - -### Stand-alone Deployment - -The stand-alone setup is configured out of the box with reasonable defaults, but please consult our [configuration documentation](https://github.com/netdata/netdata/blob/master/docs/cloud/cheatsheet.md) for details, including the overview of [common configuration changes](https://github.com/netdata/netdata/blob/master/docs/configure/common-changes.md). - -### Parent – Child Deployment - -For setups involving Child and Parent Agents, the Agents need to be configured for [_streaming_](https://github.com/netdata/netdata/blob/master/streaming/README.md), through the configuration file `stream.conf`. This will instruct the Child to stream data to the Parent and the Parent to accept streaming connections for one or more Child Agents. To secure this connection, both need set up a shared API key (to replace the string `API_KEY` in the examples below). Additionally, the Child is configured with one or more addresses of Parent Agents (`PARENT_IP_ADDRESS`). - -An API key is a key created with `uuidgen` and is used for authentication and/or customization in the Parent side. I.e. a Child will stream using the API key, and a Parent is configured to accept connections from Child, but can also apply different options for children by using multiple different API keys. The easiest setup uses just one API key for all Child Agents. - -#### Child config - -As mentioned above, the recommendation is to not claim the Child to Cloud directly during your setup, avoiding establishing an [ACLK](https://github.com/netdata/netdata/blob/master/aclk/README.md) connection. - -To reduce the footprint of the Netdata Agent on your production system, some capabilities can be switched OFF on the Child and kept ON on the Parent. In this example, Machine Learning and Alerting are disabled in the Child, so that the Parent can take the load. We also use RAM instead of disk to store metrics with limited retention, covering temporary network issues. - -##### netdata.conf - -On the child node, edit `netdata.conf` by using the edit-config script: `/etc/netdata/edit-config netdata.conf` set the following parameters: - -```yaml -[db] - # https://learn.netdata.cloud/docs/agent/database - # none = no retention, ram = some retention in ram - mode = ram - # The retention in seconds. - # This provides some tolerance to the time the child has to find a parent in - # order to transfer the data. For IoT this can be lowered to 120. - retention = 1200 - # The granularity of metrics, in seconds. - # You may increase this to lower CPU resources. - update every = 1 -[ml] - # Disable Machine Learning - enabled = no -[health] - # Disable Health Checks (Alerting) - enabled = no -[web] - # Disable remote access to the local dashboard - bind to = lo -[plugins] - # Uncomment the following line to disable all external plugins on extreme - # IoT cases by default. - # enable running new plugins = no -``` - -##### stream.conf - -To edit `stream.conf`, again use the edit-config script: `/etc/netdata/edit-config stream.conf`. - -Set the following parameters: - -```yaml -[stream] - # Stream metrics to another Netdata - enabled = yes - # The IP and PORT of the parent - destination = PARENT_IP_ADDRESS:19999 - # The shared API key, generated by uuidgen - api key = API_KEY -``` - -#### Parent config - -For the Parent, besides setting up streaming, the example will also provide an example configuration of multiple [tiers](https://github.com/netdata/netdata/blob/master/database/engine/README.md#tiering) of metrics [storage](https://github.com/netdata/netdata/blob/master/docs/store/change-metrics-storage.md), for 10 children, with about 2k metrics each. - -- 1s granularity at tier 0 for 1 week -- 1m granularity at tier 1 for 1 month -- 1h granularity at tier 2 for 1 year - -Requiring: - -- 25GB of disk -- 3.5GB of RAM (2.5GB under pressure) - -##### netdata.conf - -On the Parent, edit `netdata.conf` with `/etc/netdata/edit-config netdata.conf` and set the following parameters: - -```yaml -[db] - mode = dbengine - storage tiers = 3 - # To allow memory pressure to offload index from ram - dbengine page descriptors in file mapped memory = yes - # storage tier 0 - update every = 1 - dbengine multihost disk space MB = 12000 - dbengine page cache size MB = 1400 - # storage tier 1 - dbengine tier 1 page cache size MB = 512 - dbengine tier 1 multihost disk space MB = 4096 - dbengine tier 1 update every iterations = 60 - dbengine tier 1 backfill = new - # storage tier 2 - dbengine tier 2 page cache size MB = 128 - dbengine tier 2 multihost disk space MB = 2048 - dbengine tier 2 update every iterations = 60 - dbengine tier 2 backfill = new -[ml] - # Enabled by default - # enabled = yes -[health] - # Enabled by default - # enabled = yes -[web] - # Enabled by default - # bind to = * -``` - -##### stream.conf - -On the Parent node, edit `stream.conf` with `/etc/netdata/edit-config stream.conf`, and then set the following parameters: - -```yaml -[API_KEY] - # Accept metrics streaming from other Agents with the specified API key - enabled = yes -``` - -### Active–Active Parent Deployment - -In order to setup active–active streaming between Parent 1 and Parent 2, Parent 1 needs to be instructed to stream data to Parent 2 and Parent 2 to stream data to Parent 1. The Child Agents need to be configured with the addresses of both Parent Agents. The Agent will only connect to one Parent at a time, falling back to the next if the previous failed. These examples use the same API key between Parent Agents as for connections from Child Agents. - -On both Netdata Parent and all Child Agents, edit `stream.conf` with `/etc/netdata/edit-config stream.conf`: - -##### stream.conf on Parent 1 - -```yaml -[stream] - # Stream metrics to another Netdata - enabled = yes - # The IP and PORT of Parent 2 - destination = PARENT_2_IP_ADDRESS:19999 - # This is the API key for the outgoing connection to Parent 2 - api key = API_KEY -[API_KEY] - # Accept metrics streams from Parent 2 and Child Agents - enabled = yes -``` - -##### stream.conf on Parent 2 - -```yaml -[stream] - # Stream metrics to another Netdata - enabled = yes - # The IP and PORT of Parent 1 - destination = PARENT_1_IP_ADDRESS:19999 - api key = API_KEY -[API_KEY] - # Accept metrics streams from Parent 1 and Child Agents - enabled = yes -``` - -##### stream.conf on Child Agents - -```yaml -[stream] - # Stream metrics to another Netdata - enabled = yes - # The IP and PORT of the parent - destination = PARENT_1_IP_ADDRESS:19999 PARENT_2_IP_ADDRESS:19999 - # The shared API key, generated by uuidgen - api key = API_KEY -``` - -## Further Reading - -We strongly recommend the following configuration changes for production deployments: - -1. Understand Netdata's [security and privacy design](https://github.com/netdata/netdata/blob/master/docs/netdata-security.md) and - [secure your nodes](https://github.com/netdata/netdata/blob/master/docs/category-overview-pages/secure-nodes.md) - - To safeguard your infrastructure and comply with your organization's security policies. - -2. Set up [streaming and replication](https://github.com/netdata/netdata/blob/master/streaming/README.md) to: - - - Offload Netdata Agents running on production systems and free system resources for the production applications running on them. - - Isolate production systems from the rest of the world and improve security. - - Increase data retention. - - Make your data highly available. - -3. [Optimize the Netdata Agents system utilization and performance](https://github.com/netdata/netdata/blob/master/docs/guides/configure/performance.md) - - To save valuable system resources, especially when running on weak IoT devices. - -We also suggest that you: - -1. [Use Netdata Cloud to access the dashboards](https://github.com/netdata/netdata/blob/master/docs/quickstart/infrastructure.md) - - For increased security, user management and access to our latest tools for advanced dashboarding and troubleshooting. - -2. [Change how long Netdata stores metrics](https://github.com/netdata/netdata/blob/master/docs/store/change-metrics-storage.md) - - To control Netdata's memory use, when you have a lot of ephemeral metrics. - -3. [Use host labels](https://github.com/netdata/netdata/blob/master/docs/guides/using-host-labels.md) - - To organize systems, metrics, and alerts. diff --git a/docs/category-overview-pages/developer-and-contributor-corner.md b/docs/category-overview-pages/developer-and-contributor-corner.md new file mode 100644 index 000000000..d4d86382a --- /dev/null +++ b/docs/category-overview-pages/developer-and-contributor-corner.md @@ -0,0 +1,3 @@ +# Developer and Contributor Corner + +In this section of our Documentation you will find more advanced information, suited for developers and contributors alike.
\ No newline at end of file diff --git a/docs/category-overview-pages/installation-overview.md b/docs/category-overview-pages/installation-overview.md index e60dd442c..703ca26b9 100644 --- a/docs/category-overview-pages/installation-overview.md +++ b/docs/category-overview-pages/installation-overview.md @@ -1,7 +1,7 @@ # Installation In this category you can find instructions on all the possible ways you can install Netdata on the -[supported platforms](https://github.com/netdata/netdata/blob/master/packaging/PLATFORM_SUPPORT.md). +[supported platforms](https://github.com/netdata/netdata/blob/master/docs/netdata-agent/versions-and-platforms.md). If this is your first time using Netdata, we recommend that you first start with the [quick installation guide](https://github.com/netdata/netdata/edit/master/packaging/installer/README.md) and then diff --git a/docs/category-overview-pages/integrations-overview.md b/docs/category-overview-pages/integrations-overview.md index 6fa2f50af..afd4cf306 100644 --- a/docs/category-overview-pages/integrations-overview.md +++ b/docs/category-overview-pages/integrations-overview.md @@ -13,19 +13,19 @@ sidebar_position: 60 Netdata's ability to monitor out of the box every potentially useful aspect of a node's operation is unparalleled. But Netdata also provides out of the box, meaningful charts and alerts for hundreds of applications, with the ability to be easily extended to monitor anything. See the full list of Netdata's capabilities and how you can extend them in the -[supported collectors list](https://github.com/netdata/netdata/blob/master/collectors/COLLECTORS.md). +[supported collectors list](https://github.com/netdata/netdata/blob/master/src/collectors/COLLECTORS.md). Our out of the box alerts were created by expert professionals and have been validated on the field, countless times. Use them to trigger [alert notifications](https://github.com/netdata/netdata/blob/master/docs/monitor/enable-notifications.md) either centrally, via the [Cloud alert notifications](https://github.com/netdata/netdata/blob/master/docs/cloud/alerts-notifications/notifications.md) , or by configuring individual -[agent notifications](https://github.com/netdata/netdata/blob/master/health/notifications/README.md). +[agent notifications](https://github.com/netdata/netdata/blob/master/src/health/notifications/README.md). We designed Netdata with interoperability in mind. The Agent collects thousands of metrics every second, and then what you do with them is up to you. You can -[store metrics in the database engine](https://github.com/netdata/netdata/blob/master/database/README.md), +[store metrics in the database engine](https://github.com/netdata/netdata/blob/master/src/database/README.md), or send them to another time series database for long-term storage or further analysis using -Netdata's [exporting engine](https://github.com/netdata/netdata/edit/master/exporting/README.md). +Netdata's [exporting engine](https://github.com/netdata/netdata/edit/master/src/exporting/README.md). diff --git a/docs/category-overview-pages/machine-learning-and-assisted-troubleshooting.md b/docs/category-overview-pages/machine-learning-and-assisted-troubleshooting.md index 074051e3e..9a0e4b381 100644 --- a/docs/category-overview-pages/machine-learning-and-assisted-troubleshooting.md +++ b/docs/category-overview-pages/machine-learning-and-assisted-troubleshooting.md @@ -1,3 +1,97 @@ -# Machine Learning and Assisted Troubleshooting Overview +# Machine Learning and Anomaly Detection -This section contains documentation regarding Netdata's troubleshooting and machine learning features.
\ No newline at end of file +Machine learning (ML) is a subfield of Artificial Intelligence (AI) that enables computers to learn and improve from experience without being explicitly programmed. + +In observability, machine learning can be used to detect patterns and anomalies in large datasets, enabling users to identify potential issues before they become critical. + +Machine Learning for observability is usually misunderstood, and frequently leads to unrealistic expectations. Check for example the [presentation Google gave at SreCON19](https://www.usenix.org/conference/srecon19emea/presentation/underwood) explaining that all ideas that Google SREs and DevOps came up with, about the use of Machine Learning in observability were bad, and as Todd notes they should feel bad about it. + +At Netdata we are approaching machine learning in a completely different way. Instead of trying to make machine learning do something it cannot achieve, we tried to understand if and what useful insights it can provide and eventually we turned it to an assistant that can improve troubleshooting, reduce mean time to resolution and in many case prevent issues from escalating. + +## Design Principles + +The following are the high level design principles of Machine Learning in Netdata: + +1. **Unsupervised** + + In other words: whatever machine learning can do, it should do it by itself, without any help or assistance from users. + +2. **Real-time** + + We understand that Machine Learning will have some impact on resource utilization, especially in CPU utilization, but it shouldn't prevent Netdata from being real-time and high-fidelity. + +3. **Integrated** + + Everything achieved with machine learning should be tightly integrated to the infrastructure exploration and troubleshooting practices we are used to. + +4. **Assist, Advice, Consult** + + If we can't be sure that a decision made by Machine Learning is 100% accurate, we should use this to assist and consult users in their journey. + + In other words, we don't want to wake up someone at 3 AM, just because a machine learning model detected something. + +## Machine Learning per Time-Series + +Given the samples recently collected for a time-series, Machine Learning is used to detect if a sample just collected is an outlier or not. + +Since the query combinations are infinite, Netdata detects anomalies at the time-series level, and then combines the anomaly rates of all time-series involved in each query, to provide the anomaly rate for the query. + +When a collected sample is an outlier, we set the Anomaly Bit of the collected sample and we store it together with the sample value in the time-series database. + +## Multiple Machine Learning Models per Time-Series to Eliminate Noise + +Unsupervised machine learning has some noise, random false positives. + +To remove this noise, Netdata trains multiple machine learning models for each time-series, covering more than the last 2 days, in total. + +Netdata uses all of the available ML models to detect anomalies. So, all machine learning models of a time-series need to agree that a collected sample is an outlier, for it to be marked as an anomaly. + +This process removes 99% of the false positives, offering reliable unsupervised anomaly detection. + +## Node Level Anomaly + +When a metric becomes anomalous, in many cases a lot other metrics get anomalous too. + +For example, an anomaly on a web server may also introduce unusual network bandwidth, cpu usage, memory consumption, disk I/O, context switches, interrupts, etc. If the web server is serving an API that has an application server and a database server we may see anomalies being propagated to them too. + +To represent the spread of an anomaly in a node, Netdata computes a **Node Level Anomaly**. This is the percentage of the metrics of a node being concurrently anomalous, vs the total number of metrics of that node. + +## Node Anomaly Events + +Netdata produces a "node anomaly event" when a the percentage of concurrently anomalous time-series is high enough and persists over time. + +This anomaly event signals that there was sufficient evidence among all the time-series that some strange behavior might have been detected in a more global sense across the node. + +## What is the Anomaly Bit? + +Each sample collected, carries an Anomaly Bit. This bit (true/false) is set when the collected sample found to be an outlier, based on the machine learning models available for it so far. + +This bit is embedded into the custom floating point number the Netdata database uses, so it does not introduce any overheads in memory or disk footprint. + +The query engine of Netdata uses this bit to compute anomaly rates while it executes normal time-series queries. This eliminates to need for additional queries for anomaly rates, as all `/api/v2` time-series query include anomaly rate information. + +## What is the Anomaly Rate (AR)? + +The Anomaly Rate of a query, is a percentage, representing the number of samples in the query found anomalous, vs the total number of samples participating in the query. + +## How it works - a more technical presentation + +For each time-series Netdata trains every 3 hours, a `k-means clustering` model, using the last 6 hours of samples collected for it. + +Rather than using raw samples of each time-series, the model works on a preprocessed "feature vector" of recent smoothed and differenced values. + +This enables the model to detect a wider range of potentially anomalous patterns as opposed to just point anomalies like big spikes or drops. + +Some of the types of anomalies Netdata detects are: + +1. **Point Anomalies** or **Strange Points**: Single points that represent very big or very small values, not seen before (in some statistical sense). +2. **Contextual Anomalies** or **Strange Patterns**: Not strange points in their own, but unexpected sequences of points, given the history of the time-series. +3. **Collective Anomalies** or **Strange Multivariate Patterns**: Neither strange points nor strange patterns, but in global sense something looks off. +4. **Concept Drifts** or **Strange Trends**: A slow and steady drift to a new state. +5. **Change Point Detection** or **Strange Step**: A shift occurred and gradually a new normal is established. + +For a visual representation, check this infographic: + + + +A more detailed explanation can be found on [this (informal) presentation](https://docs.google.com/presentation/d/18zkCvU3nKP-Bw_nQZuXTEa4PIVM6wppH3VUnAauq-RU/edit#slide=id.p). diff --git a/docs/category-overview-pages/reverse-proxies.md b/docs/category-overview-pages/reverse-proxies.md index 07c8b9bd5..1b4d935a3 100644 --- a/docs/category-overview-pages/reverse-proxies.md +++ b/docs/category-overview-pages/reverse-proxies.md @@ -3,7 +3,7 @@ If you need to access a Netdata agent's user interface or API in a production environment we recommend you put Netdata behind another web server and secure access to the dashboard via SSL, user authentication and firewall rules. -A dedicated web server also provides more robustness and capabilities than the Agent's [internal web server](https://github.com/netdata/netdata/blob/master/web/README.md). +A dedicated web server also provides more robustness and capabilities than the Agent's [internal web server](https://github.com/netdata/netdata/blob/master/src/web/README.md). We have documented running behind [nginx](https://github.com/netdata/netdata/blob/master/docs/Running-behind-nginx.md), diff --git a/docs/category-overview-pages/secure-nodes.md b/docs/category-overview-pages/secure-nodes.md index 33e205f00..99e273920 100644 --- a/docs/category-overview-pages/secure-nodes.md +++ b/docs/category-overview-pages/secure-nodes.md @@ -47,7 +47,7 @@ This is the _recommended method for those who have connected their nodes to Netd metrics using the War Room Overview, Nodes tab, and Cloud dashboards.
You can disable the local dashboard (and API) but retain the encrypted Agent-Cloud link
-([ACLK](https://github.com/netdata/netdata/blob/master/aclk/README.md)) that
+([ACLK](https://github.com/netdata/netdata/blob/master/src/aclk/README.md)) that
allows you to stream metrics on demand from your nodes via the Netdata Cloud interface. This change mitigates all
concerns about revealing metrics and system design to the internet at large, while keeping all the functionality you
need to view metrics and troubleshoot issues with Netdata Cloud.
@@ -60,7 +60,7 @@ static-threaded` setting, and change it to `none`. mode = none
```
-Save and close the editor, then [restart your Agent](https://github.com/netdata/netdata/blob/master/docs/configure/start-stop-restart.md)
+Save and close the editor, then [restart your Agent](https://github.com/netdata/netdata/blob/master/packaging/installer/README.md#maintaining-a-netdata-agent-installation)
using `sudo systemctl
restart netdata`. If you try to visit the local dashboard to `http://NODE:19999` again, the connection will fail because
that node no longer serves its local dashboard.
@@ -98,7 +98,7 @@ the internet using multiple hosting providers). ## Fine-grained access control
If you want to keep using the local dashboard, but don't want it exposed to the internet, you can restrict access with
-[access lists](https://github.com/netdata/netdata/blob/master/web/server/README.md#access-lists). This method also fully
+[access lists](https://github.com/netdata/netdata/blob/master/src/web/server/README.md#access-lists). This method also fully
retains the ability to stream metrics
on-demand through Netdata Cloud.
@@ -107,7 +107,7 @@ static IP, only `localhost`, or connections from behind a management LAN. By default, this setting is `localhost *`. This setting allows connections from `localhost` in addition to _all_
connections, using the `*` wildcard. You can change this setting using Netdata's [simple
-patterns](https://github.com/netdata/netdata/blob/master/libnetdata/simple_pattern/README.md).
+patterns](https://github.com/netdata/netdata/blob/master/src/libnetdata/simple_pattern/README.md).
```conf
[web]
@@ -134,9 +134,9 @@ The `allow connections from` setting is global and restricts access to the dashb allow management from = localhost
```
-See the [web server](https://github.com/netdata/netdata/blob/master/web/server/README.md#access-lists) docs for additional details
+See the [web server](https://github.com/netdata/netdata/blob/master/src/web/server/README.md#access-lists) docs for additional details
about access lists. You can take
-access lists one step further by [enabling SSL](https://github.com/netdata/netdata/blob/master/web/server/README.md#enabling-tls-support) to encrypt data from local
+access lists one step further by [enabling SSL](https://github.com/netdata/netdata/blob/master/src/web/server/README.md#enabling-tls-support) to encrypt data from local
dashboard in transit. The connection to Netdata Cloud is always secured with TLS.
## Use an authenticating web server in proxy mode
|