docs: update inputs/http through inputs/ipvs

plugins/inputs/http/README.md

@@ -1,6 +1,10 @@
 # HTTP Input Plugin
 
-The HTTP input plugin collects metrics from one or more HTTP(S) endpoints.  The endpoint should have metrics formatted in one of the supported [input data formats](../../../docs/DATA_FORMATS_INPUT.md).  Each data format has its own unique set of configuration options which can be added to the input configuration.
+The HTTP input plugin collects metrics from one or more HTTP(S) endpoints.  The
+endpoint should have metrics formatted in one of the supported [input data
+formats](../../../docs/DATA_FORMATS_INPUT.md).  Each data format has its own
+unique set of configuration options which can be added to the input
+configuration.
 
 ## Configuration
 
@@ -75,7 +79,8 @@ The HTTP input plugin collects metrics from one or more HTTP(S) endpoints.  The
 
 ## Metrics
 
-The metrics collected by this input plugin will depend on the configured `data_format` and the payload returned by the HTTP endpoint(s).
+The metrics collected by this input plugin will depend on the configured
+`data_format` and the payload returned by the HTTP endpoint(s).
 
 The default values below are added if the input format does not specify a value:
 
@@ -85,4 +90,11 @@ The default values below are added if the input format does not specify a value:
 
 ## Optional Cookie Authentication Settings
 
-The optional Cookie Authentication Settings will retrieve a cookie from the given authorization endpoint, and use it in subsequent API requests.  This is useful for services that do not provide OAuth or Basic Auth authentication, e.g. the [Tesla Powerwall API](https://www.tesla.com/support/energy/powerwall/own/monitoring-from-home-network), which uses a Cookie Auth Body to retrieve an authorization cookie.  The Cookie Auth Renewal interval will renew the authorization by retrieving a new cookie at the given interval.
+The optional Cookie Authentication Settings will retrieve a cookie from the
+given authorization endpoint, and use it in subsequent API requests.  This is
+useful for services that do not provide OAuth or Basic Auth authentication,
+e.g. the [Tesla Powerwall API][tesla], which uses a Cookie Auth Body to retrieve
+an authorization cookie.  The Cookie Auth Renewal interval will renew the
+authorization by retrieving a new cookie at the given interval.
+
+[tesla]: https://www.tesla.com/support/energy/powerwall/own/monitoring-from-home-network

plugins/inputs/http_listener_v2/README.md

@@ -1,18 +1,18 @@
 # HTTP Listener v2 Input Plugin
 
 HTTP Listener v2 is a service input plugin that listens for metrics sent via
-HTTP. Metrics may be sent in any supported [data format][data_format]. For metrics in
-[InfluxDB Line Protocol][line_protocol] it's recommended to use the [`influxdb_listener`][influxdb_listener]
-or [`influxdb_v2_listener`][influxdb_v2_listener] instead.
+HTTP. Metrics may be sent in any supported [data format][data_format]. For
+metrics in [InfluxDB Line Protocol][line_protocol] it's recommended to use the
+[`influxdb_listener`][influxdb_listener] or
+[`influxdb_v2_listener`][influxdb_v2_listener] instead.
 
 **Note:** The plugin previously known as `http_listener` has been renamed
 `influxdb_listener`.  If you would like Telegraf to act as a proxy/relay for
-InfluxDB it is recommended to use [`influxdb_listener`][influxdb_listener] or [`influxdb_v2_listener`][influxdb_v2_listener].
+InfluxDB it is recommended to use [`influxdb_listener`][influxdb_listener] or
+[`influxdb_v2_listener`][influxdb_v2_listener].
 
 ## Configuration
 
-This is a sample configuration for the plugin.
-
 ```toml @sample.conf
 # Generic HTTP write listener
 [[inputs.http_listener_v2]]
@@ -68,7 +68,8 @@ This is a sample configuration for the plugin.
 
 ## Metrics
 
-Metrics are collected from the part of the request specified by the `data_source` param and are parsed depending on the value of `data_format`.
+Metrics are collected from the part of the request specified by the
+`data_source` param and are parsed depending on the value of `data_format`.
 
 ## Troubleshooting
 

plugins/inputs/http_response/README.md

@@ -96,9 +96,12 @@ This input plugin checks HTTP/HTTPS connections.
 
 ### `result` / `result_code`
 
-Upon finishing polling the target server, the plugin registers the result of the operation in the `result` tag, and adds a numeric field called `result_code` corresponding with that tag value.
+Upon finishing polling the target server, the plugin registers the result of the
+operation in the `result` tag, and adds a numeric field called `result_code`
+corresponding with that tag value.
 
-This tag is used to expose network and plugin errors. HTTP errors are considered a successful connection.
+This tag is used to expose network and plugin errors. HTTP errors are considered
+a successful connection.
 
 |Tag value                     |Corresponding field value|Description|
 -------------------------------|-------------------------|-----------|

plugins/inputs/httpjson/README.md

@@ -97,7 +97,9 @@ Given the following response body:
 
 The following metric is produced:
 
-`httpjson,server=http://localhost:9999/stats/ b_d=0.1,a=0.5,b_e=5,response_time=0.001`
+```
+httpjson,server=http://localhost:9999/stats/ b_d=0.1,a=0.5,b_e=5,response_time=0.001
+```
 
 Note that only numerical values are extracted and the type is float.
 
@@ -110,7 +112,9 @@ If `tag_keys` is included in the configuration:
 
 Then the `service` tag will also be added:
 
-`httpjson,server=http://localhost:9999/stats/,service=service01 b_d=0.1,a=0.5,b_e=5,response_time=0.001`
+```
+httpjson,server=http://localhost:9999/stats/,service=service01 b_d=0.1,a=0.5,b_e=5,response_time=0.001
+```
 
 **Array Output:**
 
@@ -140,7 +144,9 @@ object:
 ]
 ```
 
-`httpjson,server=http://localhost:9999/stats/,service=service01 a=0.5,b_d=0.1,b_e=5,response_time=0.003`
-`httpjson,server=http://localhost:9999/stats/,service=service02 a=0.6,b_d=0.2,b_e=6,response_time=0.003`
+```
+httpjson,server=http://localhost:9999/stats/,service=service01 a=0.5,b_d=0.1,b_e=5,response_time=0.003
+httpjson,server=http://localhost:9999/stats/,service=service02 a=0.6,b_d=0.2,b_e=6,response_time=0.003
+```
 
 [HTTP input plugin]: ../http/README.md

plugins/inputs/hugepages/README.md

@@ -1,10 +1,11 @@
 # Hugepages Input Plugin
 
-Transparent Huge Pages (THP) is a Linux memory management system that reduces the overhead of
-Translation Lookaside Buffer (TLB) lookups on machines with large amounts of memory by using larger
-memory pages.
+Transparent Huge Pages (THP) is a Linux memory management system that reduces
+the overhead of Translation Lookaside Buffer (TLB) lookups on machines with
+large amounts of memory by using larger memory pages.
 
-Consult <https://www.kernel.org/doc/html/latest/admin-guide/mm/hugetlbpage.html> for more details.
+Consult <https://www.kernel.org/doc/html/latest/admin-guide/mm/hugetlbpage.html>
+for more details.
 
 ## Configuration
 

plugins/inputs/icinga2/README.md

@@ -4,7 +4,9 @@ This plugin gather services & hosts status using Icinga2 Remote API.
 
 The icinga2 plugin uses the icinga2 remote API to gather status on running
 services and hosts. You can read Icinga2's documentation for their remote API
-[here](https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/icinga2-api)
+[here][1].
+
+[1]: https://docs.icinga.com/icinga2/latest/doc/module/icinga2/chapter/icinga2-api
 
 ## Configuration
 

plugins/inputs/influxdb/README.md

@@ -1,12 +1,13 @@
 # InfluxDB Input Plugin
 
 The InfluxDB plugin will collect metrics on the given InfluxDB servers. Read our
-[documentation](https://docs.influxdata.com/platform/monitoring/influxdata-platform/tools/measurements-internal/)
-for detailed information about `influxdb` metrics.
+[documentation][1] for detailed information about `influxdb` metrics.
 
 This plugin can also gather metrics from endpoints that expose
 InfluxDB-formatted endpoints. See below for more information.
 
+[1]: https://docs.influxdata.com/platform/monitoring/influxdata-platform/tools/measurements-internal/
+
 ## Configuration
 
 ```toml @sample.conf
@@ -39,7 +40,8 @@ InfluxDB-formatted endpoints. See below for more information.
 
 ## Measurements & Fields
 
-**Note:** The measurements and fields included in this plugin are dynamically built from the InfluxDB source, and may vary between versions:
+**Note:** The measurements and fields included in this plugin are dynamically
+built from the InfluxDB source, and may vary between versions:
 
 - **influxdb_ae** _(Enterprise Only)_ : Statistics related to the Anti-Entropy (AE) engine in InfluxDB Enterprise clusters.
   - **bytesRx**: Number of bytes received by the data node.

plugins/inputs/influxdb_v2_listener/README.md

@@ -5,9 +5,9 @@ according to the [InfluxDB HTTP API][influxdb_http_api].  The intent of the
 plugin is to allow Telegraf to serve as a proxy/router for the `/api/v2/write`
 endpoint of the InfluxDB HTTP API.
 
-The `/api/v2/write` endpoint supports the `precision` query parameter and can be set
-to one of `ns`, `us`, `ms`, `s`.  All other parameters are ignored and
-defer to the output plugins configuration.
+The `/api/v2/write` endpoint supports the `precision` query parameter and can be
+set to one of `ns`, `us`, `ms`, `s`.  All other parameters are ignored and defer
+to the output plugins configuration.
 
 Telegraf minimum version: Telegraf 1.16.0
 

plugins/inputs/intel_pmu/README.md

@@ -1,13 +1,18 @@
 # Intel Performance Monitoring Unit Plugin
 
-This input plugin exposes Intel PMU (Performance Monitoring Unit) metrics available through [Linux Perf](https://perf.wiki.kernel.org/index.php/Main_Page) subsystem.
+This input plugin exposes Intel PMU (Performance Monitoring Unit) metrics
+available through [Linux Perf](https://perf.wiki.kernel.org/index.php/Main_Page)
+subsystem.
 
-PMU metrics gives insight into performance and health of IA processor's internal components,
-including core and uncore units. With the number of cores increasing and processor topology getting more complex
-the insight into those metrics is vital to assure the best CPU performance and utilization.
+PMU metrics gives insight into performance and health of IA processor's internal
+components, including core and uncore units. With the number of cores increasing
+and processor topology getting more complex the insight into those metrics is
+vital to assure the best CPU performance and utilization.
 
-Performance counters are CPU hardware registers that count hardware events such as instructions executed, cache-misses suffered, or branches mispredicted.
-They form a basis for profiling applications to trace dynamic control flow and identify hotspots.
+Performance counters are CPU hardware registers that count hardware events such
+as instructions executed, cache-misses suffered, or branches mispredicted. They
+form a basis for profiling applications to trace dynamic control flow and
+identify hotspots.
 
 ## Configuration
 
@@ -63,8 +68,10 @@ They form a basis for profiling applications to trace dynamic control flow and i
 
 ### Modifiers
 
-Perf modifiers adjust event-specific perf attribute to fulfill particular requirements.
-Details about perf attribute structure could be found in [perf_event_open](https://man7.org/linux/man-pages/man2/perf_event_open.2.html) syscall manual.
+Perf modifiers adjust event-specific perf attribute to fulfill particular
+requirements.  Details about perf attribute structure could be found in
+[perf_event_open][man]
+syscall manual.
 
 General schema of configuration's `events` list element:
 
@@ -89,48 +96,65 @@ where:
 
 ## Requirements
 
-The plugin is using [iaevents](https://github.com/intel/iaevents) library which is a golang package that makes accessing the Linux kernel's perf interface easier.
+The plugin is using [iaevents](https://github.com/intel/iaevents) library which
+is a golang package that makes accessing the Linux kernel's perf interface
+easier.
 
 Intel PMU plugin, is only intended for use on **linux 64-bit** systems.
 
-Event definition JSON files for specific architectures can be found at [01.org](https://download.01.org/perfmon/).
-A script to download the event definitions that are appropriate for your system (event_download.py) is available at [pmu-tools](https://github.com/andikleen/pmu-tools).
-Please keep these files in a safe place on your system.
+Event definition JSON files for specific architectures can be found at
+[01.org](https://download.01.org/perfmon/).  A script to download the event
+definitions that are appropriate for your system (event_download.py) is
+available at [pmu-tools](https://github.com/andikleen/pmu-tools).  Please keep
+these files in a safe place on your system.
 
 ## Measuring
 
-Plugin allows measuring both core and uncore events. During plugin initialization the event names provided by user are compared
-with event definitions included in JSON files and translated to perf attributes. Next, those events are activated to start counting.
-During every telegraf interval, the plugin reads proper measurement for each previously activated event.
-
-Each single core event may be counted severally on every available CPU's core. In contrast, uncore events could be placed in
-many PMUs within specified CPU package. The plugin allows choosing core ids (core events) or socket ids (uncore events) on which the counting should be executed.
-Uncore events are separately activated on all socket's PMUs, and can be exposed as separate
+Plugin allows measuring both core and uncore events. During plugin
+initialization the event names provided by user are compared with event
+definitions included in JSON files and translated to perf attributes. Next,
+those events are activated to start counting.  During every telegraf interval,
+the plugin reads proper measurement for each previously activated event.
+
+Each single core event may be counted severally on every available CPU's
+core. In contrast, uncore events could be placed in many PMUs within specified
+CPU package. The plugin allows choosing core ids (core events) or socket ids
+(uncore events) on which the counting should be executed.  Uncore events are
+separately activated on all socket's PMUs, and can be exposed as separate
 measurement or to be summed up as one measurement.
 
-Obtained measurements are stored as three values: **Raw**, **Enabled** and **Running**. Raw is a total count of event. Enabled and running are total time the event was enabled and running.
-Normally these are the same. If more events are started than available counter slots on the PMU, then multiplexing
-occurs and events only run part of the time. Therefore, the plugin provides a 4-th value called **scaled** which is calculated using following formula:
-`raw * enabled / running`.
+Obtained measurements are stored as three values: **Raw**, **Enabled** and
+**Running**. Raw is a total count of event. Enabled and running are total time
+the event was enabled and running.  Normally these are the same. If more events
+are started than available counter slots on the PMU, then multiplexing occurs
+and events only run part of the time. Therefore, the plugin provides a 4-th
+value called **scaled** which is calculated using following formula: `raw *
+enabled / running`.
 
 Events are measured for all running processes.
 
 ### Core event groups
 
-Perf allows assembling events as a group. A perf event group is scheduled onto the CPU as a unit: it will be put onto the CPU only if all of the events in the group can be put onto the CPU.
-This means that the values of the member events can be meaningfully compared — added, divided (to get ratios), and so on — with each other,
-since they have counted events for the same set of executed instructions [(source)](https://man7.org/linux/man-pages/man2/perf_event_open.2.html).
+Perf allows assembling events as a group. A perf event group is scheduled onto
+the CPU as a unit: it will be put onto the CPU only if all of the events in the
+group can be put onto the CPU.  This means that the values of the member events
+can be meaningfully compared — added, divided (to get ratios), and so on — with
+each other, since they have counted events for the same set of executed
+instructions [(source)][man].
 
-> **NOTE:**
-> Be aware that the plugin will throw an error when trying to create core event group of size that exceeds available core PMU counters.
-> The error message from perf syscall will be shown as "invalid argument". If you want to check how many PMUs are supported by your Intel CPU, you can use the [cpuid](https://linux.die.net/man/1/cpuid) command.
+> **NOTE:** Be aware that the plugin will throw an error when trying to create
+> core event group of size that exceeds available core PMU counters.  The error
+> message from perf syscall will be shown as "invalid argument". If you want to
+> check how many PMUs are supported by your Intel CPU, you can use the
+> [cpuid](https://linux.die.net/man/1/cpuid) command.
 
 ### Note about file descriptors
 
-The plugin opens a number of file descriptors dependent on number of monitored CPUs and number of monitored
-counters. It can easily exceed the default per process limit of allowed file descriptors. Depending on
-configuration, it might be required to increase the limit of opened file descriptors allowed.
-This can be done for example by using `ulimit -n command`.
+The plugin opens a number of file descriptors dependent on number of monitored
+CPUs and number of monitored counters. It can easily exceed the default per
+process limit of allowed file descriptors. Depending on configuration, it might
+be required to increase the limit of opened file descriptors allowed.  This can
+be done for example by using `ulimit -n command`.
 
 ## Metrics
 
@@ -208,3 +232,5 @@ pmu_metric,cpu=0,event=CPU_CLK_UNHALTED.REF_XCLK_ANY,host=xyz enabled=2200963921
 pmu_metric,cpu=0,event=L1D_PEND_MISS.PENDING_CYCLES_ANY,host=xyz enabled=2200933946i,running=1470322480i,raw=23631950i,scaled=35374798i 1621254412000000000
 pmu_metric,cpu=0,event=L1D_PEND_MISS.PENDING_CYCLES,host=xyz raw=18767833i,scaled=28169827i,enabled=2200888514i,running=1466317384i 1621254412000000000
 ```
+
+[man]: https://man7.org/linux/man-pages/man2/perf_event_open.2.html