From a5bbd85702ce6a71edb0366297408bef5ffef2f4 Mon Sep 17 00:00:00 2001 From: Severin Neumann Date: Tue, 15 Nov 2022 22:40:30 +0100 Subject: [PATCH] Text and style fixes for concept pages (#2011) Signed-off-by: svrnm Signed-off-by: svrnm --- content/en/docs/concepts/data-collection.md | 6 +++--- content/en/docs/concepts/signals/traces.md | 2 +- content/en/docs/concepts/what-is-opentelemetry.md | 12 ++++++------ 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/content/en/docs/concepts/data-collection.md b/content/en/docs/concepts/data-collection.md index 0e053d3d1d0..9ad8aa2533c 100644 --- a/content/en/docs/concepts/data-collection.md +++ b/content/en/docs/concepts/data-collection.md @@ -9,8 +9,8 @@ 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 +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. @@ -56,6 +56,6 @@ The OpenTelemetry project provides two versions of the Collector: 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, + 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. diff --git a/content/en/docs/concepts/signals/traces.md b/content/en/docs/concepts/signals/traces.md index e6d03878aab..b8c40f3c695 100644 --- a/content/en/docs/concepts/signals/traces.md +++ b/content/en/docs/concepts/signals/traces.md @@ -124,7 +124,7 @@ Providers. In some languages, a global Tracer is already initialized for you. Trace Exporters send traces to a consumer. This consumer can be standard output for debugging and development-time, the OpenTelemetry Collector, or any -open-source or vendor backend of your choice. +open source or vendor backend of your choice. ### Trace Context diff --git a/content/en/docs/concepts/what-is-opentelemetry.md b/content/en/docs/concepts/what-is-opentelemetry.md index 0db777923b0..e0396a40365 100644 --- a/content/en/docs/concepts/what-is-opentelemetry.md +++ b/content/en/docs/concepts/what-is-opentelemetry.md @@ -25,9 +25,9 @@ must emit [traces](/docs/concepts/observability-primer/#distributed-traces), [metrics](/docs/concepts/observability-primer/#reliability--metrics), and [logs](/docs/concepts/observability-primer/#logs). The instrumented data must then be sent to an Observability back-end. There are a number of Observability -back-ends out there, ranging from self-hosted open-source tools (e.g. +back-ends out there, ranging from self-hosted open source tools (e.g. [Jaeger](https://www.jaegertracing.io/) and [Zipkin](https://zipkin.io/)), to -commercial SAAS offerings. +commercial SaaS offerings. In the past, the way in which code was instrumented would vary, as each Observability back-end would have its own instrumentation libraries and agents @@ -43,7 +43,7 @@ choice. > and the burden on the user to maintain instrumentation libraries. Recognizing the need for standardization, the cloud community came together, and -two open-source projects were born: [OpenTracing](https://opentracing.io) (a +two open source projects were born: [OpenTracing](https://opentracing.io) (a [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io) project) and [OpenCensus](https://opencensus.io) (a [Google Open Source](https://opensource.google) community project). @@ -65,7 +65,7 @@ takes the best of both worlds, and then some. OTel's goal is to provide a set of standardized vendor-agnostic SDKs, APIs, and [tools](/docs/collector) for ingesting, transforming, and sending data to an -Observability back-end (i.e. open-source or commercial vendor). +Observability back-end (i.e. open source or commercial vendor). ## What can OpenTelemetry do for me? @@ -87,7 +87,7 @@ OTel has broad industry support and adoption from cloud providers, formats in parallel to assist with migrating as standards evolve. - A path forward no matter where you are on your observability journey. -With support for a variety of [open-source and commercial +With support for a variety of [open source and commercial protocols][otel-collector-contrib], format and context propagation mechanisms as well as providing shims to the OpenTracing and OpenCensus projects, it is easy to adopt OpenTelemetry. @@ -95,7 +95,7 @@ to adopt OpenTelemetry. ## What OpenTelemetry is not OpenTelemetry is not an observability back-end like Jaeger or Prometheus. -Instead, it supports exporting data to a variety of open-source and commercial +Instead, it supports exporting data to a variety of open source and commercial back-ends. It provides a pluggable architecture so additional technology protocols and formats can be easily added.