Merge branch 'main' into MetricReader-env-vars

.lycheeignore

@@ -2,3 +2,5 @@ http://localhost
 http://jaeger-collector
 https:/open-telemetry/opentelemetry-go/milestone/
 https:/open-telemetry/opentelemetry-go/projects
+file:///home/runner/work/opentelemetry-go/opentelemetry-go/libraries
+file:///home/runner/work/opentelemetry-go/opentelemetry-go/manual

website_docs/_index.md

@@ -1,8 +1,8 @@
 ---
 title: Go
 description: >-
- <img width="35" src="/img/logos/32x32/Golang_SDK.svg" alt="Go"></img> A
- language-specific implementation of OpenTelemetry in Go.
+ <img width="35" class="img-initial" src="/img/logos/32x32/Golang_SDK.svg"
+ alt="Go"></img> A language-specific implementation of OpenTelemetry in Go.
 aliases: [/golang, /golang/metrics, /golang/tracing]
 cascade:
  github_repo: &repo https:/open-telemetry/opentelemetry-go

website_docs/exporters.md

@@ -5,8 +5,8 @@ weight: 4
 ---
 
 In order to visualize and analyze your
-[traces](/docs/concepts/signals/traces/#tracing-in-opentelemetry) and metrics, you
-will need to export them to a backend.
+[traces](/docs/concepts/signals/traces/#tracing-in-opentelemetry) and metrics,
+you will need to export them to a backend.
 
 ## OTLP Exporter
 

website_docs/libraries.md

@@ -1,29 +1,39 @@
 ---
 title: Using instrumentation libraries
-weight: 3
 linkTitle: Libraries
-aliases: [/docs/instrumentation/go/using_instrumentation_libraries, /docs/instrumentation/go/automatic_instrumentation]
+aliases:
+ - /docs/instrumentation/go/using_instrumentation_libraries
+ - /docs/instrumentation/go/automatic_instrumentation
+weight: 3
 ---
 
-Go does not support truly automatic instrumentation like other languages today. Instead, you'll need to depend on [instrumentation libraries](/docs/reference/specification/glossary/#instrumentation-library) that generate telemetry data for a particular instrumented library. For example, the instrumentation library for `net/http` will automatically create spans that track inbound and outbound requests once you configure it in your code.
+Go does not support truly automatic instrumentation like other languages today.
+Instead, you'll need to depend on
+[instrumentation libraries](/docs/reference/specification/glossary/#instrumentation-library)
+that generate telemetry data for a particular instrumented library. For example,
+the instrumentation library for `net/http` will automatically create spans that
+track inbound and outbound requests once you configure it in your code.
 
 ## Setup
 
-Each instrumentation library is a package. In general, this means you need to `go get` the appropriate package:
+Each instrumentation library is a package. In general, this means you need to
+`go get` the appropriate package:
 
-```console
+```sh
 go get go.opentelemetry.io/contrib/instrumentation/{import-path}/otel{package-name}
 ```
 
-And then configure it in your code based on what the library requires to be activated.
+And then configure it in your code based on what the library requires to be
+activated.
 
 ## Example with `net/http`
 
-As an example, here's how you can set up automatic instrumentation for inbound HTTP requests for `net/http`:
+As an example, here's how you can set up automatic instrumentation for inbound
+HTTP requests for `net/http`:
 
 First, get the `net/http` instrumentation library:
 
-```console
+```sh
 go get go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp
 ```
 
@@ -76,13 +86,18 @@ func main() {
 }
 ```
 
-Assuming that you have a `Tracer` and [exporter]({{< relref "exporters" >}}) configured, this code will:
+Assuming that you have a `Tracer` and [exporter](../exporters/) configured, this
+code will:
 
-* Start an HTTP server on port `3030`
-* Automatically generate a span for each inbound HTTP request to `/hello-instrumented`
-* Create a child span of the automatically-generated one that tracks the work done in `sleepy`
+- Start an HTTP server on port `3030`
+- Automatically generate a span for each inbound HTTP request to
+ `/hello-instrumented`
+- Create a child span of the automatically-generated one that tracks the work
+ done in `sleepy`
 
-Connecting manual instrumentation you write in your app with instrumentation generated from a library is essential to get good observability into your apps and services.
+Connecting manual instrumentation you write in your app with instrumentation
+generated from a library is essential to get good observability into your apps
+and services.
 
 ## Available packages
 
@@ -91,6 +106,9 @@ A full list of instrumentation libraries available can be found in the
 
 ## Next steps
 
-Instrumentation libraries can do things like generate telemetry data for inbound and outbound HTTP requests, but they don't instrument your actual application.
+Instrumentation libraries can do things like generate telemetry data for inbound
+and outbound HTTP requests, but they don't instrument your actual application.
 
-To get richer telemetry data, use [manual instrumentation]({{< relref "manual" >}}) to enrich your telemetry data from instrumentation libraries with instrumentation from your running application.
+To get richer telemetry data, use [manual instrumentation](../manual/) to enrich
+your telemetry data from instrumentation libraries with instrumentation from
+your running application.

website_docs/manual.md

@@ -1,11 +1,15 @@
 ---
 title: Manual Instrumentation
-weight: 3
 linkTitle: Manual
-aliases: [/docs/instrumentation/go/instrumentation, /docs/instrumentation/go/manual_instrumentation]
+aliases:
+ - /docs/instrumentation/go/instrumentation
+ - /docs/instrumentation/go/manual_instrumentation
+weight: 3
 ---
 
-Instrumentation is the process of adding observability code to your application. There are two general types of instrumentation - automatic, and manual - and you should be familiar with both in order to effectively instrument your software.
+Instrumentation is the process of adding observability code to your application.
+There are two general types of instrumentation - automatic, and manual - and you
+should be familiar with both in order to effectively instrument your software.
 
 ## Getting a Tracer
 
@@ -15,7 +19,7 @@ To create spans, you'll need to acquire or initialize a tracer first.
 
 Ensure you have the right packages installed:
 
-```
+```sh
 go get go.opentelemetry.io/otel \
  go.opentelemetry.io/otel/trace \
  go.opentelemetry.io/otel/sdk \
@@ -54,7 +58,7 @@ func newTraceProvider(exp sdktrace.SpanExporter) *sdktrace.TracerProvider {
  semconv.ServiceName("ExampleService"),
  ),
  )
- 
+
  if err != nil {
  panic(err)
  }
@@ -90,9 +94,12 @@ You can now access `tracer` to manually instrument your code.
 
 ## Creating Spans
 
-Spans are created by tracers. If you don't have one initialized, you'll need to do that.
+Spans are created by tracers. If you don't have one initialized, you'll need to
+do that.
 
-To create a span with a tracer, you'll also need a handle on a `context.Context` instance. These will typically come from things like a request object and may already contain a parent span from an [instrumentation library][].
+To create a span with a tracer, you'll also need a handle on a `context.Context`
+instance. These will typically come from things like a request object and may
+already contain a parent span from an [instrumentation library][].
 
 ```go
 func httpHandler(w http.ResponseWriter, r *http.Request) {
@@ -103,13 +110,16 @@ func httpHandler(w http.ResponseWriter, r *http.Request) {
 }
 ```
 
-In Go, the `context` package is used to store the active span. When you start a span, you'll get a handle on not only the span that's created, but the modified context that contains it.
+In Go, the `context` package is used to store the active span. When you start a
+span, you'll get a handle on not only the span that's created, but the modified
+context that contains it.
 
 Once a span has completed, it is immutable and can no longer be modified.
 
 ### Get the current span
 
-To get the current span, you'll need to pull it out of a `context.Context` you have a handle on:
+To get the current span, you'll need to pull it out of a `context.Context` you
+have a handle on:
 
 ```go
 // This context needs contain the active span you plan to extract.
@@ -119,13 +129,15 @@ span := trace.SpanFromContext(ctx)
 // Do something with the current span, optionally calling `span.End()` if you want it to end
 ```
 
-This can be helpful if you'd like to add information to the current span at a point in time.
+This can be helpful if you'd like to add information to the current span at a
+point in time.
 
 ### Create nested spans
 
 You can create a nested span to track work in a nested operation.
 
-If the current `context.Context` you have a handle on already contains a span inside of it, creating a new span makes it a nested span. For example:
+If the current `context.Context` you have a handle on already contains a span
+inside of it, creating a new span makes it a nested span. For example:
 
 ```go
 func parentFunction(ctx context.Context) {
@@ -151,7 +163,10 @@ Once a span has completed, it is immutable and can no longer be modified.
 
 ### Span Attributes
 
-Attributes are keys and values that are applied as metadata to your spans and are useful for aggregating, filtering, and grouping traces. Attributes can be added at span creation, or at any other time during the lifecycle of a span before it has completed.
+Attributes are keys and values that are applied as metadata to your spans and
+are useful for aggregating, filtering, and grouping traces. Attributes can be
+added at span creation, or at any other time during the lifecycle of a span
+before it has completed.
 
 ```go
 // setting attributes at creation...
@@ -169,13 +184,21 @@ span.SetAttributes(myKey.String("a value"))
 
 #### Semantic Attributes
 
-Semantic Attributes are attributes that are defined by the [OpenTelemetry Specification][] in order to provide a shared set of attribute keys across multiple languages, frameworks, and runtimes for common concepts like HTTP methods, status codes, user agents, and more. These attributes are available in the `go.opentelemetry.io/otel/semconv/v1.12.0` package.
+Semantic Attributes are attributes that are defined by the [OpenTelemetry
+Specification][] in order to provide a shared set of attribute keys across
+multiple languages, frameworks, and runtimes for common concepts like HTTP
+methods, status codes, user agents, and more. These attributes are available in
+the `go.opentelemetry.io/otel/semconv/v1.12.0` package.
 
 For details, see [Trace semantic conventions][].
 
 ### Events
 
-An event is a human-readable message on a span that represents "something happening" during it's lifetime. For example, imagine a function that requires exclusive access to a resource that is under a mutex. An event could be created at two points - once, when we try to gain access to the resource, and another when we acquire the mutex.
+An event is a human-readable message on a span that represents "something
+happening" during it's lifetime. For example, imagine a function that requires
+exclusive access to a resource that is under a mutex. An event could be created
+at two points - once, when we try to gain access to the resource, and another
+when we acquire the mutex.
 
 ```go
 span.AddEvent("Acquiring lock")
@@ -186,7 +209,9 @@ span.AddEvent("Unlocking")
 mutex.Unlock()
 ```
 
-A useful characteristic of events is that their timestamps are displayed as offsets from the beginning of the span, allowing you to easily see how much time elapsed between them.
+A useful characteristic of events is that their timestamps are displayed as
+offsets from the beginning of the span, allowing you to easily see how much time
+elapsed between them.
 
 Events can also have attributes of their own -
 
@@ -196,7 +221,8 @@ span.AddEvent("Cancelled wait due to external signal", trace.WithAttributes(attr
 
 ### Set span status
 
-A status can be set on a span, typically used to specify that there was an error in the operation a span is tracking - .`Error`.
+A status can be set on a span, typically used to specify that there was an error
+in the operation a span is tracking - .`Error`.
 
 ```go
 import (
@@ -213,11 +239,13 @@ if err != nil {
 }
 ```
 
-By default, the status for all spans is `Unset`. In rare cases, you may also wish to set the status to `Ok`. This should generally not be necessary, though.
+By default, the status for all spans is `Unset`. In rare cases, you may also
+wish to set the status to `Ok`. This should generally not be necessary, though.
 
 ### Record errors
 
-If you have an operation that failed and you wish to capture the error it produced, you can record that error.
+If you have an operation that failed and you wish to capture the error it
+produced, you can record that error.
 
 ```go
 import (
@@ -235,18 +263,22 @@ if err != nil {
 }
 ```
 
-It is highly recommended that you also set a span's status to `Error` when using `RecordError`, unless you do not wish to consider the span tracking a failed operation as an error span.
-The `RecordError` function does **not** automatically set a span status when called.
+It is highly recommended that you also set a span's status to `Error` when using
+`RecordError`, unless you do not wish to consider the span tracking a failed
+operation as an error span. The `RecordError` function does **not**
+automatically set a span status when called.
 
 ## Creating Metrics
 
 The metrics API is currently unstable, documentation TBA.
 
 ## Propagators and Context
 
-Traces can extend beyond a single process. This requires _context propagation_, a mechanism where identifiers for a trace are sent to remote processes.
+Traces can extend beyond a single process. This requires _context propagation_,
+a mechanism where identifiers for a trace are sent to remote processes.
 
-In order to propagate trace context over the wire, a propagator must be registered with the OpenTelemetry API.
+In order to propagate trace context over the wire, a propagator must be
+registered with the OpenTelemetry API.
 
 ```go
 import (
@@ -257,10 +289,15 @@ import (
 otel.SetTextMapPropagator(propagation.TraceContext{})
 ```
 
-> OpenTelemetry also supports the B3 header format, for compatibility with existing tracing systems (`go.opentelemetry.io/contrib/propagators/b3`) that do not support the W3C TraceContext standard.
+> OpenTelemetry also supports the B3 header format, for compatibility with
+> existing tracing systems (`go.opentelemetry.io/contrib/propagators/b3`) that
+> do not support the W3C TraceContext standard.
 
-After configuring context propagation, you'll most likely want to use automatic instrumentation to handle the behind-the-scenes work of actually managing serializing the context.
+After configuring context propagation, you'll most likely want to use automatic
+instrumentation to handle the behind-the-scenes work of actually managing
+serializing the context.
 
-[OpenTelemetry Specification]: {{< relref "/docs/reference/specification" >}}
-[Trace semantic conventions]: {{< relref "/docs/reference/specification/trace/semantic_conventions" >}}
-[instrumentation library]: {{< relref "libraries" >}}
+[opentelemetry specification]: /docs/reference/specification/
+[trace semantic conventions]:
+ /docs/reference/specification/trace/semantic_conventions/
+[instrumentation library]: ../libraries/

website_docs/resources.md

@@ -5,8 +5,8 @@ weight: 6
 
 Resources are a special type of attribute that apply to all spans generated by a
 process. These should be used to represent underlying metadata about a process
-that's non-ephemeral - for example, the hostname of a process, or its instance
-ID.
+that's non-ephemeral — for example, the hostname of a process, or its
+instance ID.
 
 Resources should be assigned to a tracer provider at its initialization, and are
 created much like attributes: