Normalize concepts/*.md and drop some relref (#1362)

content/en/docs/concepts/_index.md

@@ -1,6 +1,7 @@
 ---
 title: Concepts
-description: What is OpenTelemetry, what does it provide and what does it support?
+description: >-
+  What is OpenTelemetry, what does it provide and what does it support?
 spelling: cSpell:ignore otel
 aliases: [/about, /docs/concepts/overview, /otel]
 weight: 1

content/en/docs/concepts/components.md

@@ -5,13 +5,13 @@ weight: 20
 
 OpenTelemetry is currently made up of several main components:
 
-* Cross-language specification
-* Tools to collect, transform, and export telemetry data
-* Per-language SDKs
-* Automatic instrumentation and contrib packages
+- Cross-language specification
+- Tools to collect, transform, and export telemetry data
+- Per-language SDKs
+- Automatic instrumentation and contrib packages
 
-OpenTelemetry lets you replace the need for vendor-specific SDKs and tools for generating
-and exporting telemetry data.
+OpenTelemetry lets you replace the need for vendor-specific SDKs and tools for
+generating and exporting telemetry data.
 
 ## Specification
 
@@ -21,48 +21,53 @@ following:
 
 - **API:** Defines data types and operations for generating and correlating
   tracing, metrics, and logging data.
-- **SDK:** Defines requirements for a language-specific implementation of the API.
-  Configuration, data processing, and exporting concepts are also defined here.
+- **SDK:** Defines requirements for a language-specific implementation of the
+  API. Configuration, data processing, and exporting concepts are also defined
+  here.
 - **Data:** Defines the OpenTelemetry Protocol (OTLP) and vendor-agnostic
   semantic conventions that a telemetry backend can provide support for.
 
 For more information, see the [Specification](/docs/reference/specification/).
 
 Additionally, extensively-commented protobuf interface files for API concepts
-can be found in the [proto repository](https://github.com/open-telemetry/opentelemetry-proto).
+can be found in the
+[proto repository](https://github.com/open-telemetry/opentelemetry-proto).
 
 ## Collector
 
-The OpenTelemetry Collector is a vendor-agnostic proxy that can receive, process,
-and export telemetry data. It supports receiving telemetry data in multiple formats
-(e.g., OTLP, Jaeger, Prometheus, as well as many commercial/proprietary tools)
-and sending data to one or more backends. It also supports processing and filtering
-telemetry data before it gets exported. Collector contrib packages bring support for
-more data formats and vendor backends.
+The OpenTelemetry Collector is a vendor-agnostic proxy that can receive,
+process, and export telemetry data. It supports receiving telemetry data in
+multiple formats (e.g., OTLP, Jaeger, Prometheus, as well as many
+commercial/proprietary tools) and sending data to one or more backends. It also
+supports processing and filtering telemetry data before it gets exported.
+Collector contrib packages bring support for more data formats and vendor
+backends.
 
 For more information, see [Data Collection](/docs/concepts/data-collection/).
 
 ## Language SDKs
 
-OpenTelemetry also has language SDKs that let you use the OpenTelemetry API to generate
-telemetry data with your language of choice and export that data to a preferred backend.
-These SDKs also let you incorporate automatic instrumentation for common libraries and
-frameworks that you can use to connect to manual instrumentation in your application.
-Vendors often make distributions of language SDKs to make exporting to their backends
-simpler.
+OpenTelemetry also has language SDKs that let you use the OpenTelemetry API to
+generate telemetry data with your language of choice and export that data to a
+preferred backend. These SDKs also let you incorporate automatic instrumentation
+for common libraries and frameworks that you can use to connect to manual
+instrumentation in your application. Vendors often make distributions of
+language SDKs to make exporting to their backends simpler.
 
 For more information, see [Instrumenting](/docs/concepts/instrumenting).
 
 ## Automatic Instrumentation
 
-OpenTelemetry supports a broad number of components that generate relevant telemetry data
-from popular libraries and frameworks for supported languages. For example, inbound and
-outbound HTTP requests from an HTTP library will generate data about those requests.
-Using automatic instrumentation may differ from language to language, where one might
-prefer or require the use of a component that you load alongside your application, and
-another might prefer that you pull in a package explicitly in your codebase.
+OpenTelemetry supports a broad number of components that generate relevant
+telemetry data from popular libraries and frameworks for supported languages.
+For example, inbound and outbound HTTP requests from an HTTP library will
+generate data about those requests. Using automatic instrumentation may differ
+from language to language, where one might prefer or require the use of a
+component that you load alongside your application, and another might prefer
+that you pull in a package explicitly in your codebase.
 
-It is a long-term goal that popular libraries are authored to be observable out of the box,
-such that pulling in a separate component is not required.
+It is a long-term goal that popular libraries are authored to be observable out
+of the box, such that pulling in a separate component is not required.
 
-For more information, see [Instrumenting Libraries](/docs/concepts/instrumenting-library/).
+For more information, see
+[Instrumenting Libraries](/docs/concepts/instrumenting-library/).

content/en/docs/concepts/data-collection.md

@@ -5,15 +5,15 @@ weight: 50
 
 The OpenTelemetry project facilitates the collection of telemetry data via the
 OpenTelemetry Collector. The OpenTelemetry Collector offers a vendor-agnostic
-implementation on how to receive, process, and export telemetry data. It
-removes the need to run, operate, and maintain multiple agents/collectors in
-order to support open-source observability data formats (e.g. Jaeger,
-Prometheus, etc.) sending to one or more open-source or commercial back-ends.
-In addition, the Collector gives end-users control of their data. The Collector
-is the default location instrumentation libraries export their telemetry
-data.
+implementation on how to receive, process, and export telemetry data. It removes
+the need to run, operate, and maintain multiple agents/collectors in order to
+support open-source observability data formats (e.g. Jaeger, Prometheus, etc.)
+sending to one or more open-source or commercial back-ends. In addition, the
+Collector gives end-users control of their data. The Collector is the default
+location instrumentation libraries export their telemetry data.
 
-> The Collector may be offered as a distribution, see [here](../distributions) for more information.
+> The Collector may be offered as a distribution, see [here](../distributions)
+> for more information.
 
 ## Deployment
 
@@ -24,25 +24,26 @@ The OpenTelemetry Collector provides a single binary and two deployment methods:
 - **Gateway:** One or more Collector instances running as a standalone service
   (e.g. container or deployment) typically per cluster, datacenter or region.
 
-For information on how to use the Collector see the [getting started
-documentation](/docs/collector/getting-started).
+For information on how to use the Collector see the
+[getting started documentation](/docs/collector/getting-started).
 
 ## Components
 
 The Collector is made up of the following components:
 
 - <img width="32" src="https://raw.github.com/open-telemetry/opentelemetry.io/main/iconography/32x32/Receivers.svg"></img>
-`receivers`: How to get data into the Collector; these can be push or pull based
+  `receivers`: How to get data into the Collector; these can be push or pull
+  based
 - <img width="32" src="https://raw.github.com/open-telemetry/opentelemetry.io/main/iconography/32x32/Processors.svg"></img>
-`processors`: What to do with received data
+  `processors`: What to do with received data
 - <img width="32" src="https://raw.github.com/open-telemetry/opentelemetry.io/main/iconography/32x32/Exporters.svg"></img>
-`exporters`: Where to send received data; these can be push or pull based
+  `exporters`: Where to send received data; these can be push or pull based
 
 These components are enabled through `pipelines`. Multiple instances of
 components as well as pipelines can be defined via YAML configuration.
 
-For more information about these components see the [configuration
-documentation](/docs/collector/configuration).
+For more information about these components see the
+[configuration documentation](/docs/collector/configuration).
 
 ## Repositories
 
@@ -52,7 +53,7 @@ The OpenTelemetry project provides two versions of the Collector:
   Foundational components such as configuration and generally applicable
   receivers, processors, exporters, and extensions.
 - **[Contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/releases):**
-  All the components of core plus optional or possibly experimental components. Offers support for popular
-  open-source projects including Jaeger, Prometheus, and Fluent Bit.
-  Also contains more specialized or vendor-specific receivers, processors,
-  exporters, and extensions.
+  All the components of core plus optional or possibly experimental components.
+  Offers support for popular open-source projects including Jaeger, Prometheus,
+  and Fluent Bit. Also contains more specialized or vendor-specific receivers,
+  processors, exporters, and extensions.