diff options
| author | Joel Hans <joel@netdata.cloud> | 2020-04-14 10:26:13 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-04-14 10:26:13 -0700 |
| commit | e99692f145f710930723081d2e5bbf8868be2080 (patch) | |
| tree | 468157463f0f133d927019e6826a9559dd989b9b /collectors | |
| parent | 59916b01b83026d6e6caf59f4efb67b7d428b70d (diff) | |
Docs: Standardize links between documentation (#8638)
* Trying out some absolute-ish links
* Try one out on installer
* Testing logic
* Trying out some more links
* Fixing links
* Fix links in python collectors
* Changed a bunch more links
* Fix build errors
* Another push of links
* Fix build error and add more links
* Complete first pass
* Fix final broken links
* Fix links to files
* Fix for Netlify
* Two more fixes
Diffstat (limited to 'collectors')
86 files changed, 168 insertions, 168 deletions
diff --git a/collectors/COLLECTORS.md b/collectors/COLLECTORS.md index e62d9f9d00..510286c573 100644 --- a/collectors/COLLECTORS.md +++ b/collectors/COLLECTORS.md @@ -12,9 +12,9 @@ Netdata uses collectors to help you gather metrics from your favorite applicatio real-time, interactive charts. The following list includes collectors for both internal system metrics, and external apps/services metrics. -Read more about collectors and how to enable them in our [collectors documentation](README.md), or use the [collector -quickstart](QUICKSTART.md) to figure out how to collect metrics from your favorite app/service with auto-detection and -minimal configuration. +Read more about collectors and how to enable them in our [collectors documentation](/collectors/README.md), or use the +[collector quickstart](/collectors/QUICKSTART.md) to figure out how to collect metrics from your favorite app/service +with auto-detection and minimal configuration. If you don't see the app/service you'd like to monitor here, check out our [GitHub issues](https://github.com/netdata/netdata/issues). Use the search bar to look for previous discussions about that diff --git a/collectors/QUICKSTART.md b/collectors/QUICKSTART.md index 2935eed240..6a13023296 100644 --- a/collectors/QUICKSTART.md +++ b/collectors/QUICKSTART.md @@ -115,8 +115,9 @@ entry in the menu and new interactive charts! Collector not working? Learn about collector troubleshooting in our [collector reference](REFERENCE.md#troubleshoot-a-collector). -View our [collectors tutorials](README.md#tutorials) to get specific instructions on enabling new and popular -collectors. +View our [collectors tutorials](/collectors/README.md#tutorials) to get specific instructions on enabling new and +popular collectors. Finally, learn more advanced collector features, such as disabling plugins or developing a custom collector, in our -[internal plugin API](REFERENCE.md#internal-plugins-api) or our [external plugin docs](plugins.d/README.md). +[internal plugin API](/collectors/REFERENCE.md#internal-plugins-api) or our [external plugin +docs](/collectors/plugins.d/README.md). diff --git a/collectors/README.md b/collectors/README.md index df8b8ed349..d1079b25d4 100644 --- a/collectors/README.md +++ b/collectors/README.md @@ -9,45 +9,46 @@ custom_edit_url: https://github.com/netdata/netdata/edit/master/collectors/READM Netdata can collect metrics from hundreds of different sources, be they internal data created by the system itself, or external data created by services or applications. To see _all_ of the sources Netdata collects from, view our [list of -supported collectors](COLLECTORS.md), and then view our [quickstart guide](QUICKSTART.md) to get up-and-running. +supported collectors](/collectors/COLLECTORS.md), and then view our [quickstart guide](/collectors/QUICKSTART.md) to get +up-and-running. There are two essential points to understand about how collecting metrics works in Netdata: - All collectors are **installed by default** with every installation of Netdata. You do not need to install collectors manually to collect metrics from new sources. -- Upon startup, Netdata will **auto-detect** any application or service that has a [collector](COLLECTORS.md), as long - as both the collector and the app/service are configured correctly. +- Upon startup, Netdata will **auto-detect** any application or service that has a + [collector](/collectors/COLLECTORS.md), as long as both the collector and the app/service are configured correctly. Most users will want to enable a new Netdata collector for their app/service. For those details, see our [quickstart -guide](QUICKSTART.md). +guide](/collectors/QUICKSTART.md). ## Take your next steps with collectors -[Collectors quickstart](QUICKSTART.md) +[Collectors quickstart](/collectors/QUICKSTART.md) -[Supported collectors list](COLLECTORS.md) +[Supported collectors list](/collectors/COLLECTORS.md) -[Collectors configuration reference](REFERENCE.md) +[Collectors configuration reference](/collectors/REFERENCE.md) ## Tutorials -[Monitor Nginx or Apache web server log files with Netdata](../docs/tutorials/collect-apache-nginx-web-logs.md) +[Monitor Nginx or Apache web server log files with Netdata](/docs/tutorials/collect-apache-nginx-web-logs.md) -[Monitor CockroadchDB metrics with Netdata](../docs/tutorials/monitor-cockroachdb.md) +[Monitor CockroadchDB metrics with Netdata](/docs/tutorials/monitor-cockroachdb.md) -[Monitor Unbound DNS servers with Netdata](../docs/tutorials/collect-unbound-metrics.md) +[Monitor Unbound DNS servers with Netdata](/docs/tutorials/collect-unbound-metrics.md) -[Monitor a Hadoop cluster with Netdata](../docs/tutorials/monitor-hadoop-cluster.md) +[Monitor a Hadoop cluster with Netdata](/docs/tutorials/monitor-hadoop-cluster.md) ## Related features -**[Dashboards](../web/README.md)**: Vizualize your newly-collect metrics in real-time using Netdata's [built-in -dashboard](../web/gui/README.md). +**[Dashboards](/web/README.md)**: Vizualize your newly-collect metrics in real-time using Netdata's [built-in +dashboard](/web/gui/README.md). -**[Backends](../backends/README.md)**: Extend our built-in [database engine](), which supports long-term metrics -storage, by archiving metrics to like Graphite, Prometheus, MongoDB, TimescaleDB, and more. +**[Backends](/backends/README.md)**: Extend our built-in [database engine](/database/engine/README.md), which supports +long-term metrics storage, by archiving metrics to like Graphite, Prometheus, MongoDB, TimescaleDB, and more. -**[Exporting](../exporting/README.md)**: An experimental refactoring of our backends system with a modular system and +**[Exporting](/exporting/README.md)**: An experimental refactoring of our backends system with a modular system and support for exporting metrics to multiple systems simultaneously. [](<>) diff --git a/collectors/REFERENCE.md b/collectors/REFERENCE.md index 3cd52736e9..9498a0d2b5 100644 --- a/collectors/REFERENCE.md +++ b/collectors/REFERENCE.md @@ -35,8 +35,8 @@ independent processes in a variety of programming languages based on their purpo MySQL database, among many others. For most users, enabling individual collectors for the application/service you're interested in is far more important -than knowing which plugin it uses. See our [collectors list](COLLECTORS.md) to see whether your favorite app/service has -a collector, and then read the [collectors quickstart](QUICKSTART.md) and the documentation for that specific collector +than knowing which plugin it uses. See our [collectors list](/collectors/COLLECTORS.md) to see whether your favorite app/service has +a collector, and then read the [collectors quickstart](/collectors/QUICKSTART.md) and the documentation for that specific collector to figure out how to enable it. There are three types of plugins: @@ -48,7 +48,7 @@ There are three types of plugins: independent processes. They communicate with the daemon via pipes. - **Plugin orchestrators**, which are external plugins that instead support a number of **modules**. Modules are a type of collector. We have a few plugin orchestrators available for those who want to develop their own collectors, - but focus most of our efforts on the [Go plugin](go.d.plugin/README.md). + but focus most of our efforts on the [Go plugin](/collectors/go.d.plugin/README.md). ## Enable, configure, and disable modules @@ -59,7 +59,7 @@ However, there are cases that auto-detection fails. Usually, the reason is that allow Netdata to connect. In most of the cases, allowing the user `netdata` from `localhost` to connect and collect metrics, will automatically enable data collection for the application in question (it will require a Netdata restart). -View our [collectors quickstart](QUICKSTART.md) for explict details on enabling and configuring collector modules. +View our [collectors quickstart](/collectors/QUICKSTART.md) for explict details on enabling and configuring collector modules. ## Troubleshoot a collector diff --git a/collectors/apps.plugin/README.md b/collectors/apps.plugin/README.md index d9daf84148..b85a6da766 100644 --- a/collectors/apps.plugin/README.md +++ b/collectors/apps.plugin/README.md @@ -14,7 +14,7 @@ for every process found running. Since Netdata needs to present this information in charts and track them through time, instead of presenting a `top` like list, `apps.plugin` uses a pre-defined list of **process groups** -to which it assigns all running processes. This list is [customizable](apps_groups.conf) and Netdata +to which it assigns all running processes. This list is customizable via `apps_groups.conf`, and Netdata ships with a good default for most cases (to edit it on your system run `/etc/netdata/edit-config apps_groups.conf`). So, `apps.plugin` builds a process tree (much like `ps fax` does in Linux), and groups @@ -22,7 +22,7 @@ processes together (evaluating both child and parent processes) so that the resu a predefined set of members (of course, only process groups found running are reported). > If you find that `apps.plugin` categorizes standard applications as `other`, we would be -> glad to accept pull requests improving the [defaults](apps_groups.conf) shipped with Netdata. +> glad to accept pull requests improving the defaults shipped with Netdata in `apps_groups.conf`. Unlike traditional process monitoring tools (like `top`), `apps.plugin` is able to account the resource utilization of exit processes. Their utilization is accounted at their currently running parents. @@ -67,7 +67,7 @@ Each of these sections provides the same number of charts: The above are reported: -- For **Applications** per [target configured](apps_groups.conf). +- For **Applications** per target configured. - For **Users** per username or UID (when the username is not available). - For **User Groups** per groupname or GID (when groupname is not available). @@ -97,8 +97,7 @@ its CPU resources will be cut in half, and data collection will be once every 2 ## Configuration -The configuration file is `/etc/netdata/apps_groups.conf` (the default is [here](apps_groups.conf)). -To edit it on your system run `/etc/netdata/edit-config apps_groups.conf`. +The configuration file is `/etc/netdata/apps_groups.conf`. To edit it on your system, run `/etc/netdata/edit-config apps_groups.conf`. The configuration file works accepts multiple lines, each having this format: @@ -224,7 +223,7 @@ Examples below for process group `sql`: - Open Pipes  - Open Sockets  -For more information about badges check [Generating Badges](../../web/api/badges) +For more information about badges check [Generating Badges](/web/api/badges/README.md) ## Comparison with console tools @@ -358,9 +357,7 @@ So, the `ssh` session is using 95% CPU time. Why `ssh`? -`apps.plugin` groups all processes based on its configuration file -[`/etc/netdata/apps_groups.conf`](apps_groups.conf) -(to edit it on your system run `/etc/netdata/edit-config apps_groups.conf`). +`apps.plugin` groups all processes based on its configuration file. The default configuration has nothing for `bash`, but it has for `sshd`, so Netdata accumulates |