diff --git a/docs/guides/contributing.md b/docs/guides/contributing.md index 44fbfbdfc..76d6c262f 100644 --- a/docs/guides/contributing.md +++ b/docs/guides/contributing.md @@ -68,7 +68,7 @@ read-only access requires a login. Therefore, consider everything in Slack as ephemeral and inaccessible for the general public. Slack content is also not retained forever. Important information, like the result of a discussion, should also be published via other channels (e.g. -on [GitHub](github) or the [mailing list](#developer-mailing-list)) to make it +on [GitHub](#github) or the [mailing list](#developer-mailing-list)) to make it accessible and durable. Avoid linking to Slack messages from other media without summarizing the content of the linked messages. diff --git a/docs/guides/multi-target-exporter.md b/docs/guides/multi-target-exporter.md index f175e1a40..5fa7724ea 100644 --- a/docs/guides/multi-target-exporter.md +++ b/docs/guides/multi-target-exporter.md @@ -98,7 +98,7 @@ process_start_time_seconds 1.54115492874e+09 process_virtual_memory_bytes 1.5609856e+07 ``` -Those are metrics in the Prometheus [format](/docs/instrumenting/exposition_formats/#text-format-example). They come from the exporter’s [instrumentation](/docs/practices/instrumentation/) and tell us about the state of the exporter itself while it is running. This is called whitebox monitoring and very useful in daily ops practice. If you are curious, try out our guide on how to [instrument your own applications](https://prometheus.io/docs/guides/go-application/). +Those are metrics in the Prometheus [format](/docs/instrumenting/exposition_formats/#example). They come from the exporter’s [instrumentation](/docs/practices/instrumentation/) and tell us about the state of the exporter itself while it is running. This is called whitebox monitoring and very useful in daily ops practice. If you are curious, try out our guide on how to [instrument your own applications](https://prometheus.io/docs/guides/go-application/). For the second type of querying we need to provide a target and module as parameters in the HTTP GET Request. The target is a URI or IP and the module must defined in the exporter’s configuration. The blackbox exporter container comes with a meaningful default configuration. We will use the target `prometheus.io` and the predefined module `http_2xx`. It tells the exporter to make a GET request like a browser would if you go to `prometheus.io` and to expect a [200 OK](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#2xx_Success) response. diff --git a/docs/guides/node-exporter.md b/docs/guides/node-exporter.md index 7eded30c4..c3d1e7f74 100644 --- a/docs/guides/node-exporter.md +++ b/docs/guides/node-exporter.md @@ -13,7 +13,7 @@ NOTE: While the Prometheus Node Exporter is for *nix systems, there is the [Wind ## Installing and running the Node Exporter -The Prometheus Node Exporter is a single static binary that you can install [via tarball](#tarball-installation). Once you've downloaded it from the Prometheus [downloads page](/download#node_exporter) extract it, and run it: +The Prometheus Node Exporter is a single static binary that you can install via tarball. Once you've downloaded it from the Prometheus [downloads page](/download#node_exporter) extract it, and run it: ```bash # NOTE: Replace the URL with one from the above mentioned "downloads" page. diff --git a/docs/instrumenting/exposition_formats.md b/docs/instrumenting/exposition_formats.md index 14f77be2a..525acb68e 100644 --- a/docs/instrumenting/exposition_formats.md +++ b/docs/instrumenting/exposition_formats.md @@ -14,7 +14,7 @@ This document outlines officially supported exposition formats. ## Prometheus Text Format In this section you can find some [basic information](#basic-info) -about this format as well as a more [detailed breakdown](#text-format-details) of the +about this format as well as a more [detailed breakdown](#details) of the format. ### Basic info diff --git a/docs/specs/native_histograms.md b/docs/specs/native_histograms.md index f420a3e2f..41f64fe93 100644 --- a/docs/specs/native_histograms.md +++ b/docs/specs/native_histograms.md @@ -641,7 +641,7 @@ classic protobuf spec as its internal data model, simplifying the initial development.) The classic Prometheus text form was not extended for native histograms, and -such an extension is not planned. (See also the [OpenMetrics](#open-metrics) +such an extension is not planned. (See also the [OpenMetrics](#openmetrics) section below.) There is a proto2 and a proto3 version of the protobuf specification, which @@ -966,7 +966,7 @@ queries involving histograms require many histograms to get merged, during which the lowest common resolution is used so that the user ends up with a lower resolution anyway. The TSDB can be protected against the churn by limiting the resolution upon ingestion (see -[below](#limit-bucket-count-and-resolution)), but if a reasonably low +[below](#limiting-bucket-count-and-resolution)), but if a reasonably low resolution will be enforced upon ingestion anyway, it is more straightforward to set this resolution during instrumentation already. However, this strategy might be worth the resource overhead within the instrumented program in @@ -1426,7 +1426,7 @@ procedure: If the two histograms are both using a standard schema, but differ in schema or in the zero bucket width, these changes could be part of a compatible resolution reduction (which happens regularly to [reduce the bucket count of a -histogram](#limit-the-bucket-count)). Both of the following is true for a +histogram](#limiting-the-bucket-count)). Both of the following is true for a compatible resolution reduction: - If the schema has changed, its number has decreased from one standard @@ -1443,7 +1443,7 @@ procedure is concluded. If both conditions are met, the first histogram has to be converted so that its schema and zero bucket width matches those of the second histogram. This -happens in the same way as [previously described](#limit-the-bucket-count): +happens in the same way as [previously described](#limiting-the-bucket-count): Neighboring buckets are merged to reduce the schema, and regular buckets are merged with the zero bucket to increase the width of the zero bucket. diff --git a/docs/specs/om/open_metrics_spec_2_0.md b/docs/specs/om/open_metrics_spec_2_0.md index b7e2c13fd..e0e9f2c67 100644 --- a/docs/specs/om/open_metrics_spec_2_0.md +++ b/docs/specs/om/open_metrics_spec_2_0.md @@ -391,7 +391,7 @@ The OpenMetrics formats are Regular Chomsky Grammars, making writing quick and s Partial or invalid expositions MUST be considered [erroneous in their entirety](#failure-modes). -> NOTE: Previous versions of [OpenMetrics](https://prometheus.io/docs/specs/om/open_metrics_spec/#protobuf-format) used to specify a [OpenMetric protobuf format](https://github.com/prometheus/OpenMetrics/blob/3bb328ab04d26b25ac548d851619f90d15090e5d/proto/openmetrics_data_model.proto). OpenMetrics 2.0 does not include the protobuf representation. For available formats, including the official [Prometheus protobuf wire format](https://prometheus.io/docs/instrumenting/exposition_formats/#protobuf-format), see [exposition formats documentation](https://prometheus.io/docs/instrumenting/exposition_formats). +> NOTE: Previous versions of [OpenMetrics](https://prometheus.io/docs/specs/om/open_metrics_spec/#protobuf-format) used to specify a [OpenMetric protobuf format](https://github.com/prometheus/OpenMetrics/blob/3bb328ab04d26b25ac548d851619f90d15090e5d/proto/openmetrics_data_model.proto). OpenMetrics 2.0 does not include the protobuf representation. For available formats, including the official [Prometheus protobuf wire format](https://prometheus.io/docs/instrumenting/exposition_formats/#prometheus-protobuf-format), see [exposition formats documentation](https://prometheus.io/docs/instrumenting/exposition_formats). ### Protocol Negotiation