diff options
Diffstat (limited to 'docs/guides/monitor')
| -rw-r--r-- | docs/guides/monitor/anomaly-detection.md | 76 | ||||
| -rw-r--r-- | docs/guides/monitor/kubernetes-k8s-netdata.md | 237 | ||||
| -rw-r--r-- | docs/guides/monitor/lamp-stack.md | 238 | ||||
| -rw-r--r-- | docs/guides/monitor/pi-hole-raspberry-pi.md | 142 | ||||
| -rw-r--r-- | docs/guides/monitor/process.md | 270 | ||||
| -rw-r--r-- | docs/guides/monitor/raspberry-pi-anomaly-detection.md | 96 |
6 files changed, 0 insertions, 1059 deletions
diff --git a/docs/guides/monitor/anomaly-detection.md b/docs/guides/monitor/anomaly-detection.md deleted file mode 100644 index edd88896a6..0000000000 --- a/docs/guides/monitor/anomaly-detection.md +++ /dev/null @@ -1,76 +0,0 @@ -<!-- -title: "Machine learning (ML) powered anomaly detection" -sidebar_label: "Machine learning (ML) powered anomaly detection" -description: "Detect anomalies in any system, container, or application in your infrastructure with machine learning and the open-source Netdata Agent." -image: /img/seo/guides/monitor/anomaly-detection.png -custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/guides/monitor/anomaly-detection.md -learn_status: "Published" -learn_rel_path: "Operations" ---> - -# Machine learning (ML) powered anomaly detection - - -## Overview - -As of [`v1.32.0`](https://github.com/netdata/netdata/releases/tag/v1.32.0), Netdata comes with some ML powered [anomaly detection](https://en.wikipedia.org/wiki/Anomaly_detection) capabilities built into it and available to use out of the box, with zero configuration required (ML was enabled by default in `v1.35.0-29-nightly` in [this PR](https://github.com/netdata/netdata/pull/13158), previously it required a one line config change). - -This means that in addition to collecting raw value metrics, the Netdata agent will also produce an [`anomaly-bit`](https://github.com/netdata/netdata/blob/master/src/ml/README.md#anomaly-bit---100--anomalous-0--normal) every second which will be `100` when recent raw metric values are considered anomalous by Netdata and `0` when they look normal. Once we aggregate beyond one second intervals this aggregated `anomaly-bit` becomes an ["anomaly rate"](https://github.com/netdata/netdata/blob/master/src/ml/README.md#anomaly-rate---averageanomaly-bit). - -To be as concrete as possible, the below api call shows how to access the raw anomaly bit of the `system.cpu` chart from the [london.my-netdata.io](https://london.my-netdata.io) Netdata demo server. Passing `options=anomaly-bit` returns the anomaly bit instead of the raw metric value. - -``` -https://london.my-netdata.io/api/v1/data?chart=system.cpu&options=anomaly-bit -``` - -If we aggregate the above to just 1 point by adding `points=1` we get an "[Anomaly Rate](https://github.com/netdata/netdata/blob/master/src/ml/README.md#anomaly-rate---averageanomaly-bit)": - -``` -https://london.my-netdata.io/api/v1/data?chart=system.cpu&options=anomaly-bit&points=1 -``` - -The fundamentals of Netdata's anomaly detection approach and implementation are covered in lots more detail in the [agent ML documentation](https://github.com/netdata/netdata/blob/master/src/ml/README.md). - -This guide will explain how to get started using these ML based anomaly detection capabilities within Netdata. - -## Anomaly Advisor - -The [Anomaly Advisor](https://github.com/netdata/netdata/blob/master/docs/cloud/insights/anomaly-advisor.md) is the flagship anomaly detection feature within Netdata. In the "Anomalies" tab of Netdata you will see an overall "Anomaly Rate" chart that aggregates node level anomaly rate for all nodes in a space. The aim of this chart is to make it easy to quickly spot periods of time where the overall "[node anomaly rate](https://github.com/netdata/netdata/blob/master/src/ml/README.md#node-anomaly-rate)" is elevated in some unusual way and for what node or nodes this relates to. - - - -Once an area on the Anomaly Rate chart is highlighted netdata will append a "heatmap" to the bottom of the screen that shows which metrics were more anomalous in the highlighted timeframe. Each row in the heatmap consists of an anomaly rate sparkline graph that can be expanded to reveal the raw underlying metric chart for that dimension. - - - -## Embedded Anomaly Rate Charts - -Charts in both the [Metrics tab](https://github.com/netdata/netdata/blob/master/docs/dashboard/metrics-tab-and-single-node-tabs.md) and [single node tabs](https://github.com/netdata/netdata/blob/master/docs/dashboard/metrics-tab-and-single-node-tabs.md) also expose the underlying anomaly rates for each dimension so users can easily see if the raw metrics are considered anomalous or not by Netdata. - -Pressing the anomalies icon (next to the information icon in the chart header) will expand the anomaly rate chart to make it easy to see how the anomaly rate for any individual dimension corresponds to the raw underlying data. In the example below we can see that the spike in `system.pgpgio|in` corresponded in the anomaly rate for that dimension jumping to 100% for a small period of time until the spike passed. - - - -## Anomaly Rate Based Alerts - -It is possible to use the `anomaly-bit` when defining traditional Alerts within netdata. The `anomaly-bit` is just another `options` parameter that can be passed as part of an alert line lookup. - -You can see some example ML based alert configurations below: - -- [Anomaly rate based CPU dimensions alert](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#example-8---anomaly-rate-based-cpu-dimensions-alert) -- [Anomaly rate based CPU chart alert](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#example-9---anomaly-rate-based-cpu-chart-alert) -- [Anomaly rate based node level alert](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md#example-10---anomaly-rate-based-node-level-alert) -- More examples in the [`/health/health.d/ml.conf`](https://github.com/netdata/netdata/blob/master/src/health/health.d/ml.conf) file that ships with the agent. - -## Learn More - -Check out the resources below to learn more about how Netdata is approaching ML: - -- [Agent ML documentation](https://github.com/netdata/netdata/blob/master/src/ml/README.md). -- [Anomaly Advisor documentation](https://github.com/netdata/netdata/blob/master/docs/cloud/insights/anomaly-advisor.md). -- [Metric Correlations documentation](https://github.com/netdata/netdata/blob/master/docs/cloud/insights/metric-correlations.md). -- Anomaly Advisor [launch blog post](https://www.netdata.cloud/blog/introducing-anomaly-advisor-unsupervised-anomaly-detection-in-netdata/). -- Netdata Approach to ML [blog post](https://www.netdata.cloud/blog/our-approach-to-machine-learning/). -- `areal/ml` related [GitHub Discussions](https://github.com/netdata/netdata/discussions?discussions_q=label%3Aarea%2Fml). -- Netdata Machine Learning Meetup [deck](https://docs.google.com/presentation/d/1rfSxktg2av2k-eMwMbjN0tXeo76KC33iBaxerYinovs/edit?usp=sharing) and [YouTube recording](https://www.youtube.com/watch?v=eJGWZHVQdNU). -- Netdata Anomaly Advisor [YouTube Playlist](https://youtube.com/playlist?list=PL-P-gAHfL2KPeUcCKmNHXC-LX-FfdO43j). diff --git a/docs/guides/monitor/kubernetes-k8s-netdata.md b/docs/guides/monitor/kubernetes-k8s-netdata.md deleted file mode 100644 index 19fe740729..0000000000 --- a/docs/guides/monitor/kubernetes-k8s-netdata.md +++ /dev/null @@ -1,237 +0,0 @@ -# Kubernetes monitoring with Netdata - -This document gives an overview of what visualizations Netdata provides on Kubernetes deployments. - -At Netdata, we've built Kubernetes monitoring tools that add visibility without complexity while also helping you -actively troubleshoot anomalies or outages. This guide walks you through each of the visualizations and offers best -practices on how to use them to start Kubernetes monitoring in a matter of minutes, not hours or days. - -Netdata's Kubernetes monitoring solution uses a handful of [complementary tools and -collectors](#related-reference-documentation) for peeling back the many complex layers of a Kubernetes cluster, -_entirely for free_. These methods work together to give you every metric you need to troubleshoot performance or -availability issues across your Kubernetes infrastructure. - -## Challenge - -While Kubernetes (k8s) might simplify the way you deploy, scale, and load-balance your applications, not all clusters -come with "batteries included" when it comes to monitoring. Doubly so for a monitoring stack that helps you actively -troubleshoot issues with your cluster. - -Some k8s providers, like GKE (Google Kubernetes Engine), do deploy clusters bundled with monitoring capabilities, such -as Google Stackdriver Monitoring. However, these pre-configured solutions might not offer the depth of metrics, -customization, or integration with your preferred alerting methods. - -Without this visibility, it's like you built an entire house and _then_ smashed your way through the finished walls to -add windows. - -## Solution - -In this tutorial, you'll learn how to navigate Netdata's Kubernetes monitoring features, using -[robot-shop](https://github.com/instana/robot-shop) as an example deployment. Deploying robot-shop is purely optional. -You can also follow along with your own Kubernetes deployment if you choose. While the metrics might be different, the -navigation and best practices are the same for every cluster. - -## What you need to get started - -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 connected parent/child nodes. See - our [Kubernetes deployment process](https://github.com/netdata/netdata/blob/master/packaging/installer/methods/kubernetes.md) for details on deployment and - 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. -- The [Helm package manager](https://helm.sh/) v3.0.0 or newer on the same administrative system. - -### Install the `robot-shop` demo (optional) - -Begin by downloading the robot-shop code and using `helm` to create a new deployment. - -```bash -git clone git@github.com:instana/robot-shop.git -cd robot-shop/K8s/helm -kubectl create ns robot-shop -helm install robot-shop --namespace robot-shop . -``` - -Running `kubectl get pods` shows both the Netdata and robot-shop deployments. - -```bash -kubectl get pods --all-namespaces -NAMESPACE NAME READY STATUS RESTARTS AGE -default netdata-child-29f9c 2/2 Running 0 10m -default netdata-child-8xphf 2/2 Running 0 10m -default netdata-child-jdvds 2/2 Running 0 11m -default netdata-parent-554c755b7d-qzrx4 1/1 Running 0 11m -kube-system aws-node-jnjv8 1/1 Running 0 17m -kube-system aws-node-svzdb 1/1 Running 0 17m -kube-system aws-node-ts6n2 1/1 Running 0 17m -kube-system coredns-559b5db75d-f58hp 1/1 Running 0 22h -kube-system coredns-559b5db75d-tkzj2 1/1 Running 0 22h -kube-system kube-proxy-9p9cd 1/1 Running 0 17m -kube-system kube-proxy-lt9ss 1/1 Running 0 17m -kube-system kube-proxy-n75t9 1/1 Running 0 17m -robot-shop cart-b4bbc8fff-t57js 1/1 Running 0 14m -robot-shop catalogue-8b5f66c98-mr85z 1/1 Running 0 14m -robot-shop dispatch-67d955c7d8-lnr44 1/1 Running 0 14m -robot-shop mongodb-7f65d86c-dsslc 1/1 Running 0 14m -robot-shop mysql-764c4c5fc7-kkbnf 1/1 Running 0 14m -robot-shop payment-67c87cb7d-5krxv 1/1 Running 0 14m -robot-shop rabbitmq-5bb66bb6c9-6xr5b 1/1 Running 0 14m -robot-shop ratings-94fd9c75b-42wvh 1/1 Running 0 14m -robot-shop redis-0 0/1 Pending 0 14m -robot-shop shipping-7d69cb88b-w7hpj 1/1 Running 0 14m -robot-shop user-79c445b44b-hwnm9 1/1 Running 0 14m -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 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 connected your cluster to, if not **General**. - -Let's walk through monitoring each layer of a Kubernetes cluster using the Overview as our framework. - -## Cluster and node metrics - -The gauges and time-series charts you see right away in the Overview show aggregated metrics from every node in your -cluster. - -For example, the `apps.cpu` chart (in the **Applications** menu item), visualizes the CPU utilization of various -applications/services running on each of the nodes in your cluster. The **X Nodes** dropdown shows which nodes -contribute to the chart and links to jump a single-node dashboard for further investigation. - - - -For example, the chart above shows a spike in the CPU utilization from `rabbitmq` every minute or so, along with a -baseline CPU utilization of 10-15% across the cluster. - - -## Pod and container metrics - -Click on the **Kubernetes xxxxxxx...** section to jump down to Netdata Cloud's unique Kubernetes visualizations for view -real-time resource utilization metrics from your Kubernetes pods and containers. - - - -### Health map - -The first visualization is the [health map](https://github.com/netdata/netdata/blob/master/docs/cloud/visualize/kubernetes.md#health-map), -which places each container into its own box, then varies the intensity of their color to visualize the resource -utilization. By default, the health map shows the **average CPU utilization as a percentage of the configured limit** -for every container in your cluster. - - - -Let's explore the most colorful box by hovering over it. - - - -The **Context** tab shows `rabbitmq-5bb66bb6c9-6xr5b` as the container's image name, which means this container is -running a [RabbitMQ](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/rabbitmq/README.md) workload. - -Click the **Metrics** tab to see real-time metrics from that container. Unsurprisingly, it shows a spike in CPU -utilization at regular intervals. - - - -### Time-series charts - -Beneath the health map is a variety of time-series charts that help you visualize resource utilization over time, which -is useful for targeted troubleshooting. - -The default is to display metrics grouped by the `k8s_namespace` label, which shows resource utilization based on your -different namespaces. - - - -Each composite chart has a [definition bar](https://github.com/netdata/netdata/blob/master/docs/cloud/visualize/interact-new-charts.md#definition-bar) -for complete customization. For example, grouping the top chart by `k8s_container_name` reveals new information. - - - -## Service metrics - -Netdata has a [service discovery plugin](https://github.com/netdata/agent-service-discovery), which discovers and -creates configuration files for [compatible -services](https://github.com/netdata/helmchart#service-discovery-and-supported-services) and any endpoints covered by -our [generic Prometheus collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/prometheus/README.md). -Netdata uses these files to collect metrics from any compatible application as they run _inside_ of a pod. Service -discovery happens without manual intervention as pods are created, destroyed, or moved between nodes. - -Service metrics show up on the Overview as well, beneath the **Kubernetes** section, and are labeled according to the -service in question. For example, the **RabbitMQ** section has numerous charts from the [`rabbitmq` -collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/rabbitmq/README.md): - - - -> The robot-shop cluster has more supported services, such as MySQL, which are not visible with zero configuration. This -> is usually because of services running on non-default ports, using non-default names, or required passwords. Read up -> on [configuring service discovery](https://github.com/netdata/netdata/blob/master/packaging/installer/methods/kubernetes.md#configure-service-discovery) to collect -> more service metrics. - -Service metrics are essential to infrastructure monitoring, as they're the best indicator of the end-user experience, -and key signals for troubleshooting anomalies or issues. - -## Kubernetes components - -Netdata also automatically collects metrics from two essential Kubernetes processes. - -### kubelet - -The **k8s kubelet** section visualizes metrics from the Kubernetes agent responsible for managing every pod on a given -node. This also happens without any configuration thanks to the [kubelet -collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/k8s_kubelet/README.md). - -Monitoring each node's kubelet can be invaluable when diagnosing issues with your Kubernetes cluster. For example, you -can see if the number of running containers/pods has dropped, which could signal a fault or crash in a particular -Kubernetes service or deployment (see `kubectl get services` or `kubectl get deployments` for more details). If the -number of pods increases, it may be because of something more benign, like another team member scaling up a -service with `kubectl scale`. - -You can also view charts for the Kubelet API server, the volume of runtime/Docker operations by type, -configuration-related errors, and the actual vs. desired numbers of volumes, plus a lot more. - -### kube-proxy - -The **k8s kube-proxy** section displays metrics about the network proxy that runs on each node in your Kubernetes -cluster. kube-proxy lets pods communicate with each other and accept sessions from outside your cluster. Its metrics are -collected by the [kube-proxy -collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/k8s_kubeproxy/README.md). - -With Netdata, you can monitor how often your k8s proxies are syncing proxy rules between nodes. Dramatic changes in -these figures could indicate an anomaly in your cluster that's worthy of further investigation. - -## What's next? - -After reading this guide, you should now be able to monitor any Kubernetes cluster with Netdata, including nodes, pods, -containers, services, and more. - -With the health map, time-series charts, and the ability to drill down into individual nodes, you can see hundreds of -per-second metrics with zero configuration and less time remembering all the `kubectl` options. Netdata moves with your -cluster, automatically picking up new nodes or services as your infrastructure scales. And it's entirely free for -clusters of all sizes. - -### Related reference documentation - -- [Netdata Helm chart](https://github.com/netdata/helmchart) -- [Netdata service discovery](https://github.com/netdata/agent-service-discovery) -- [Netdata Agent 路 `kubelet` - collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/k8s_kubelet/README.md) -- [Netdata Agent 路 `kube-proxy` - collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/k8s_kubeproxy/README.md) -- [Netdata Agent 路 `cgroups.plugin`](https://github.com/netdata/netdata/blob/master/src/collectors/cgroups.plugin/README.md) - - diff --git a/docs/guides/monitor/lamp-stack.md b/docs/guides/monitor/lamp-stack.md deleted file mode 100644 index cc649dba9e..0000000000 --- a/docs/guides/monitor/lamp-stack.md +++ /dev/null @@ -1,238 +0,0 @@ -import { OneLineInstallWget } from '@site/src/components/OneLineInstall/' - -# LAMP stack monitoring with Netdata - -Set up robust LAMP stack monitoring (Linux, Apache, MySQL, PHP) in a few minutes using Netdata. - -The LAMP stack is the "hello world" for deploying dynamic web applications. It's fast, flexible, and reliable, which -means a developer or sysadmin won't go far in their career without interacting with the stack and its services. - -_LAMP_ is an acronym of the core services that make up the web application: **L**inux, **A**pache, **M**ySQL, and -**P**HP. - -- [Linux](https://en.wikipedia.org/wiki/Linux) is the operating system running the whole stack. -- [Apache](https://httpd.apache.org/) is a web server that responds to HTTP requests from users and returns web pages. -- [MySQL](https://www.mysql.com/) is a database that stores and returns information based on queries from the web - application. -- [PHP](https://www.php.net/) is a scripting language used to query the MySQL database and build new pages. - -LAMP stacks are the foundation for tons of end-user applications, with [Wordpress](https://wordpress.org/) being the -most popular. - -## Challenge - -You've already deployed a LAMP stack, either in testing or production. You want to monitor every service's performance -and availability to ensure the best possible experience for your end-users. You might also be particularly interested in -using a free, open-source monitoring tool. - -Depending on your monitoring experience, you may not even know what metrics you're looking for, much less how to build -dashboards using a query language. You need a robust monitoring experience that has the metrics you need without a ton -of required setup. - -## Solution - -In this tutorial, you'll set up robust LAMP stack monitoring with Netdata in just a few minutes. When you're done, -you'll have one dashboard to monitor every part of your web application, including each essential LAMP stack service. - -This dashboard updates every second with new metrics, and pairs those metrics up with preconfigured alerts to keep you -informed of any errors or odd behavior. - -## What you need to get started - -To follow this tutorial, you need: - -- A physical or virtual Linux system, which we'll call a _node_. -- A functional LAMP stack. There's plenty of tutorials for installing a LAMP stack, like [this - one](https://www.digitalocean.com/community/tutorials/how-to-install-linux-apache-mysql-php-lamp-stack-ubuntu-18-04) - from Digital Ocean. -- Optionally, a [Netdata Cloud](https://app.netdata.cloud/sign-up?cloudRoute=/spaces) account, which you can use to view - metrics from multiple nodes in one dashboard, and a whole lot more, for free. - -## Install the Netdata Agent - -If you don't have the free, open-source Netdata monitoring agent installed on your node yet, get started with a [single -kickstart command](https://github.com/netdata/netdata/blob/master/packaging/installer/README.md): - -<OneLineInstallWget/> - -The Netdata Agent is now collecting metrics from your node every second. You don't need to jump into the dashboard yet, -but if you're curious, open your favorite browser and navigate to `http://localhost:19999` or `http://NODE:19999`, -replacing `NODE` with the hostname or IP address of your system. - -## Enable hardware and Linux system monitoring - -There's nothing you need to do to enable [system monitoring](https://github.com/netdata/netdata/blob/master/docs/collect/system-metrics.md) and Linux monitoring with -the Netdata Agent, which autodetects metrics from CPUs, memory, disks, networking devices, and Linux processes like -systemd without any configuration. If you're using containers, Netdata automatically collects resource utilization -metrics from each using the [cgroups data collector](https://github.com/netdata/netdata/blob/master/src/collectors/cgroups.plugin/README.md). - -## Enable Apache monitoring - -Let's begin by configuring Apache to work with Netdata's [Apache data -collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/apache/README.md). - -Actually, there's nothing for you to do to enable Apache monitoring with Netdata. - -Apache comes with `mod_status` enabled by default these days, and Netdata is smart enough to look for metrics at that -endpoint without you configuring it. Netdata is already collecting [`mod_status` -metrics](https://httpd.apache.org/docs/2.4/mod/mod_status.html), which is just _part_ of your web server monitoring. - -## Enable web log monitoring - -The Netdata Agent also comes with a [web log -collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/weblog/README.md), which reads Apache's access -log file, processes each line, and converts them into per-second metrics. On Debian systems, it reads the file at -`/var/log/apache2/access.log`. - -At installation, the Netdata Agent adds itself to the [`adm` -group](https://wiki.debian.org/SystemGroups#Groups_without_an_associated_user), which gives the `netdata` process the -right privileges to read Apache's log files. In other words, you don't need to do anything to enable Apache web log -monitoring. - -## Enable MySQL monitoring - -Because your MySQL database is password-protected, you do need to tell MySQL to allow the `netdata` user to connect to -without a password. Netdata's [MySQL data -collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/mysql/README.md) collects metrics in _read-only_ -mode, without being able to alter or affect operations in any way. - -First, log into the MySQL shell. Then, run the following three commands, one at a time: - -```mysql -CREATE USER 'netdata'@'localhost'; -GRANT USAGE, REPLICATION CLIENT, PROCESS ON *.* TO 'netdata'@'localhost'; -FLUSH PRIVILEGES; -``` - -Run `sudo systemctl restart netdata`, or the [appropriate alternative for your -system](https://github.com/netdata/netdata/blob/master/packaging/installer/README.md#maintaining-a-netdata-agent-installation), to collect dozens of metrics every second for robust MySQL monitoring. - -## Enable PHP monitoring - -Unlike Apache or MySQL, PHP isn't a service that you can monitor directly, unless you instrument a PHP-based application -with [StatsD](https://github.com/netdata/netdata/blob/master/src/collectors/statsd.plugin/README.md). - -However, if you use [PHP-FPM](https://php-fpm.org/) in your LAMP stack, you can monitor that process with our [PHP-FPM -data collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/phpfpm/README.md). - -Open your PHP-FPM configuration for editing, replacing `7.4` with your version of PHP: - -```bash -sudo nano /etc/php/7.4/fpm/pool.d/www.conf -``` - -> Not sure what version of PHP you're using? Run `php -v`. - -Find the line that reads `;pm.status_path = /status` and remove the `;` so it looks like this: - -```conf -pm.status_path = /status -``` - -Next, add a new `/status` endpoint to Apache. Open the Apache configuration file you're using for your LAMP stack. - -```bash -sudo nano /etc/apache2/sites-available/your_lamp_stack.conf -``` - -Add the following to the end of the file, again replacing `7.4` with your version of PHP: - -```apache -ProxyPass "/status" "unix:/run/php/php7.4-fpm.sock|fcgi://localhost" -``` - -Save and close the file. Finally, restart the PHP-FPM, Apache, and Netdata processes. - -```bash -sudo systemctl restart php7.4-fpm.service -sudo systemctl restart apache2 -sudo systemctl restart netdata -``` - -As the Netdata Agent starts up again, it automatically connects to the new `127.0.0.1/status` page and collects -per-second PHP-FPM metrics to get you started with PHP monitoring. - -## View LAMP stack metrics - -If the Netdata Agent isn't already open in your browser, open a new tab and navigate to `http://localhost:19999` or -`http://NODE:19999`, replacing `NODE` with the hostname or IP address of your system. - -> 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 -> [connecting your node](https://github.com/netdata/netdata/blob/master/src/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 -forth through different time intervals, or hold `SHIFT` and use the scrollwheel (or two-finger scroll) to zoom in and -out. Check out our doc on [interacting with charts](https://github.com/netdata/netdata/blob/master/docs/cloud/visualize/interact-new-charts.md) for all the details. - - - -The **System Overview** section, which you can also see in the right-hand menu, contains key hardware monitoring charts, -including CPU utilization, memory page faults, network monitoring, and much more. The **Applications** section shows you -exactly which Linux processes are using the most system resources. - -Next, let's check out LAMP-specific metrics. You should see four relevant sections: **Apache local**, **MySQL local**, -**PHP-FPM local**, and **web log apache**. Click on any of these to see metrics from each service in your LAMP stack. - - - -### Key LAMP stack monitoring charts - -Here's a quick reference for what charts you might want to focus on after setting up Netdata. - -| Chart name / context | Type | Why? | -|-------------------------------------------------------|---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| System Load Average (`system.load`) | Hardware monitoring | A good baseline load average is `0.7`, while `1` (on a 1-core system, `2` on a 2-core system, and so on) means resources are "perfectly" utilized. Higher load indicates a bottleneck somewhere in your system. | -| System RAM (`system.ram`) | Hardware monitoring | Look at the `free` dimension. If that drops to `0`, your system will use swap memory and slow down. | -| Uptime (`apache_local.uptime`) | Apache monitoring | This chart should always be "climbing," indicating a continuous uptime. Investigate any drops back to `0`. | -| Requests By Type (`web_log_apache.requests_by_type`) | Apache monitoring | Check for increases in the `error` or `bad` dimensions, which could indicate users arriving at broken pages or PHP returning errors. | -| Queries (`mysql_local.queries`) | MySQL monitoring | Queries is the total number of queries (queries per second, QPS). Check this chart for sudden spikes or drops, which indicate either increases in traffic/demand or bottlenecks in hardware performance. | -| Active Connections (`mysql_local.connections_active`) | MySQL monitoring | If the `active` dimension nears the `limit`, your MySQL database will bottleneck responses. | -| Performance (phpfpm_local.performance) | PHP monitoring | The `slow requests` dimension lets you know if any requests exceed the configured `request_slowlog_timeout`. If so, users might be having a less-than-ideal experience. | - -## Get alerts for LAMP stack errors - -The Netdata Agent comes with hundreds of pre-configured alerts to help you keep tabs on your system, including 19 alerts -designed for smarter LAMP stack monitoring. - -Click the 馃敂 icon in the top navigation to [see active alerts](https://github.com/netdata/netdata/blob/master/docs/monitor/view-active-alerts.md). The **Active** tabs -shows any alerts currently triggered, while the **All** tab displays a list of _every_ pre-configured alert. The - - - -[Tweak alerts](https://github.com/netdata/netdata/blob/master/src/health/REFERENCE.md) based on your infrastructure monitoring needs, and to see these alerts -in other places, like your inbox or a Slack channel, [enable a notification -method](https://github.com/netdata/netdata/blob/master/docs/monitor/enable-notifications.md). - -## What's next? - -You've now set up robust monitoring for your entire LAMP stack: Linux, Apache, MySQL, and PHP (-FPM, to be exact). These -metrics will help you keep tabs on the performance and availability of your web application and all its essential -services. The per-second metrics granularity means you have the most accurate information possible for troubleshooting -any LAMP-related issues. - -Another powerful way to monitor the availability of a LAMP stack is the [`httpcheck` -collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/httpcheck/README.md), which pings a web server at -a regular interval and tells you whether if and how quickly it's responding. The `response_match` option also lets you -monitor when the web server's response isn't what you expect it to be, which might happen if PHP-FPM crashes, for -example. - -The best way to use the `httpcheck` collector is from a separate node from the one running your LAMP stack, which is why -we're not covering it here, but it _does_ work in a single-node setup. Just don't expect it to tell you if your whole -node crashed. - -If you're planning on managing more than one node, or want to take advantage of advanced features, like finding the -source of issues faster with [Metric Correlations](https://github.com/netdata/netdata/blob/master/docs/cloud/insights/metric-correlations.md), -[sign up](https://app.netdata.cloud/sign-up?cloudRoute=/spaces) for a free Netdata Cloud account. - -### Related reference documentation - -- [Netdata Agent 路 Get started](https://github.com/netdata/netdata/blob/master/packaging/installer/README.md) -- [Netdata Agent 路 Apache data collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/apache/README.md) -- [Netdata Agent 路 Web log collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/weblog/README.md) -- [Netdata Agent 路 MySQL data collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/mysql/README.md) -- [Netdata Agent 路 PHP-FPM data collector](https://github.com/netdata/netdata/blob/master/src/go/collectors/go.d.plugin/modules/phpfpm/README.md) - diff --git a/docs/guides/monitor/pi-hole-raspberry-pi.md b/docs/guides/monitor/pi-hole-raspberry-pi.md deleted file mode 100644 index 1e76cc096d..0000000000 --- a/docs/guides/monitor/pi-hole-raspberry-pi.md +++ /dev/null @@ -1,142 +0,0 @@ -<!-- -title: "Monitor Pi-hole (and a Raspberry Pi) with Netdata" -sidebar_label: "Monitor Pi-hole (and a Raspberry Pi) with Netdata" -description: "Monitor Pi-hole metrics, plus Raspberry Pi system metrics, in minutes and completely for free with Netdata's open-source monitoring agent." -image: /img/seo/guides/monitor/netdata-pi-hole-raspberry-pi.png -custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/guides/monitor/pi-hole-raspberry-pi.md -learn_status: "Published" -learn_rel_path: "Miscellaneous" ---> - -# Monitor Pi-hole (and a Raspberry Pi) with Netdata - -import { OneLineInstallWget } from '@site/src/components/OneLineInstall/' - -Between intrusive ads, invasive trackers, and vicious malware, many techies and homelab enthusiasts are advancing their -networks' security and speed with a tiny computer and a powerful piece of software: [Pi-hole](https://pi-hole.net/). - -Pi-hole is a DNS sinkhole that prevents unwanted content from even reaching devices on your home network. It blocks ads -and malware at the network, instead of using extensions/add-ons for individual browsers, so you'll stop seeing ads in -some of the most intrusive places, like your smart TV. Pi-hole can even [improve your network's speed and reduce -bandwidth](https://discourse.pi-hole.net/t/will-pi-hole-slow-down-my-network/2048). - -Most Pi-hole users run it on a [Raspberry Pi](https://www.raspberrypi.org/products/raspberry-pi-4-model-b/) (hence the -name), a credit card-sized, super-capable computer that costs about $35. - -And to keep tabs on how both Pi-hole and the Raspberry Pi are working to protect your network, you can use the -open-source [Netdata monitoring agent](https://github.com/netdata/netdata). - -To get started, all you need is a [Raspberry Pi](https://www.raspberrypi.org/products/raspberry-pi-4-model-b/) with -Raspbian installed. This guide uses a Raspberry Pi 4 Model B and Raspbian GNU/Linux 10 (buster). This guide assumes -you're connecting to a Raspberry Pi remotely over SSH, but you could also complete all these steps on the system -directly using a keyboard, mouse, and monitor. - -## Why monitor Pi-hole and a Raspberry Pi with Netdata? - -Netdata helps you monitor and troubleshoot all kinds of devices and the applications they run, including IoT devices -like the Raspberry Pi and applications like Pi-hole. - -After a two-minute installation and with zero configuration, you'll be able to see all of Pi-hole's metrics, including -the volume of queries, connected clients, DNS queries per type, top clients, top blocked domains, and more. - -With Netdata installed, you can also monitor system metrics and any other applications you might be running. By default, -Netdata collects metrics on CPU usage, disk IO, bandwidth, per-application resource usage, and a ton more. With the -Raspberry Pi used for this guide, Netdata automatically collects about 1,500 metrics every second! - - - -## Install Netdata - -Let's start by installing Netdata first so that it can start collecting system metrics as soon as possible for the most -possible historic data. - -> 鈿狅笍 Don't install Netdata using `apt` and the default package available in Raspbian. The Netdata team does not maintain -> this package, and can't guarantee it works properly. - -On Raspberry Pis running Raspbian, the best way to install Netdata is our one-line kickstart script. This script asks -you to install dependencies, then compiles Netdata from source via [GitHub](https://github.com/netdata/netdata). - -<OneLineInstallWget/> - -Once installed on a Rasp |