Skip to content

Commit bacce67

Browse files
authored
Rework of What-is-OTel and Instrumentation pages (open-telemetry#6487)
1 parent b2b9b1a commit bacce67

File tree

2 files changed

+73
-64
lines changed

2 files changed

+73
-64
lines changed

content/en/docs/concepts/instrumentation/_index.md

+20-17
Original file line numberDiff line numberDiff line change
@@ -5,16 +5,15 @@ aliases: [instrumenting]
55
weight: 15
66
---
77

8-
In order to make a system observable, it must be **instrumented**: That is, code
9-
from the system's components must emit [traces](/docs/concepts/signals/traces/),
10-
[metrics](/docs/concepts/signals/metrics/), and
11-
[logs](/docs/concepts/signals/logs/).
8+
For a system to be [observable], it must be **instrumented**: that is, code from
9+
the system's components must emit [signals], such as [traces], [metrics], and
10+
[logs].
1211

1312
Using OpenTelemetry, you can instrument your code in two primary ways:
1413

15-
1. [Code-based solutions](/docs/concepts/instrumentation/code-based) via
16-
official [APIs and SDKs for most languages](/docs/languages/)
17-
2. [Zero-code solutions](/docs/concepts/instrumentation/zero-code/)
14+
1. [Code-based solutions](code-based/) via official
15+
[APIs and SDKs for most languages](/docs/languages/)
16+
2. [Zero-code solutions](zero-code/)
1817

1918
**Code-based** solutions allow you to get deeper insight and rich telemetry from
2019
your application itself. They let you use the OpenTelemetry API to generate
@@ -37,20 +36,24 @@ solutions. The following things are also a part of OpenTelemetry:
3736
- Libraries can leverage the OpenTelemetry API as a dependency, which will have
3837
no impact on applications using that library, unless the OpenTelemetry SDK is
3938
imported.
40-
- For each [signal](/docs/concepts/signals) (traces, metrics, logs) you have
41-
several methods at your disposals to create, process, and export them.
42-
- With [context propagation](/docs/concepts/context-propagation) built into the
39+
- For each of the [signals] you have several methods at your disposal to create,
40+
process, and export them.
41+
- With [context propagation](../context-propagation/) built into the
4342
implementations, you can correlate signals regardless of where they are
4443
generated.
45-
- [Resources](/docs/concepts/resources) and
46-
[Instrumentation Scopes](/docs/concepts/instrumentation-scope) allow grouping
47-
of signals, by different entities, like, the
48-
[host](/docs/specs/semconv/resource/host/),
44+
- [Resources](../resources/) and
45+
[Instrumentation Scopes](../instrumentation-scope/) allow grouping of signals,
46+
by different entities, like, the [host](/docs/specs/semconv/resource/host/),
4947
[operating system](/docs/specs/semconv/resource/os/) or
5048
[K8s cluster](/docs/specs/semconv/resource/k8s/#cluster)
5149
- Each language-specific implementation of the API and SDK follows the
5250
requirements and expectations of the
5351
[OpenTelemetry specification](/docs/specs/otel/).
54-
- [Semantic Conventions](/docs/concepts/semantic-conventions) provide a common
55-
naming schema that can be used for standardization across code bases and
56-
platforms.
52+
- [Semantic Conventions](../semantic-conventions/) provide a common naming
53+
schema that can be used for standardization across code bases and platforms.
54+
55+
[logs]: ../signals/traces/
56+
[metrics]: ../signals/traces/
57+
[observable]: ../observability-primer/#what-is-observability
58+
[signals]: ../signals/
59+
[traces]: ../signals/traces/
+53-47
Original file line numberDiff line numberDiff line change
@@ -1,50 +1,48 @@
11
---
22
title: What is OpenTelemetry?
3-
description: A short explanation of what OpenTelemetry is and isn't.
3+
description: A brief explanation of what OpenTelemetry is and isn't.
44
aliases: [/about, /docs/concepts/what-is-opentelemetry, /otel]
55
weight: 150
66
---
77

88
OpenTelemetry is:
99

10-
- An [Observability](/docs/concepts/observability-primer/#what-is-observability)
11-
framework and toolkit designed to create and manage telemetry data such as
12-
[traces](/docs/concepts/signals/traces/),
13-
[metrics](/docs/concepts/signals/metrics/), and
14-
[logs](/docs/concepts/signals/logs/).
15-
- Vendor- and tool-agnostic, meaning that it can be used with a broad variety of
16-
Observability backends, including open source tools like
17-
[Jaeger](https://www.jaegertracing.io/) and
18-
[Prometheus](https://prometheus.io/), as well as commercial offerings.
19-
- Not an observability backend like Jaeger, Prometheus, or other commercial
20-
vendors.
21-
- Focused on the generation, collection, management, and export of telemetry. A
22-
major goal of OpenTelemetry is that you can easily instrument your
23-
applications or systems, no matter their language, infrastructure, or runtime
24-
environment. The storage and visualization of telemetry is intentionally left
25-
to other tools.
10+
- An **[observability] framework and toolkit** designed to facilitate the
11+
12+
- [Generation][instr]
13+
- Export
14+
- [Collection](../concepts/components/#collector)
15+
16+
of [telemetry data][] such as [traces], [metrics], and [logs].
17+
18+
- **Open source**, as well as **vendor- and tool-agnostic**, meaning that it can
19+
be used with a broad variety of observability backends, including open source
20+
tools like [Jaeger] and [Prometheus], as well as commercial offerings.
21+
OpenTelemetry is **not** an observability backend itself.
22+
23+
A major goal of OpenTelemetry is to enable easy instrumentation of your
24+
applications and systems, regardless of the programming language,
25+
infrastructure, and runtime environments used.
26+
27+
The backend (storage) and the frontend (visualization) of telemetry data are
28+
intentionally left to other tools.
2629

2730
## What is observability?
2831

29-
[Observability](/docs/concepts/observability-primer/#what-is-observability) is
30-
the ability to understand the internal state of a system by examining its
31-
outputs. In the context of software, this means being able to understand the
32-
internal state of a system by examining its telemetry data, which includes
33-
traces, metrics, and logs.
32+
[Observability] is the ability to understand the internal state of a system by
33+
examining its outputs. In the context of software, this means being able to
34+
understand the internal state of a system by examining its telemetry data, which
35+
includes traces, metrics, and logs.
3436

35-
To make a system observable, it must be
36-
[instrumented](/docs/concepts/instrumentation). That is, the code must emit
37-
[traces](/docs/concepts/signals/traces/),
38-
[metrics](/docs/concepts/signals/metrics/), or
39-
[logs](/docs/concepts/signals/logs/). The instrumented data must then be sent to
40-
an observability backend.
37+
To make a system observable, it must be [instrumented][instr]. That is, the code
38+
must emit [traces], [metrics], or [logs]. The instrumented data must then be
39+
sent to an observability backend.
4140

4241
## Why OpenTelemetry?
4342

4443
With the rise of cloud computing, microservices architectures, and increasingly
4544
complex business requirements, the need for software and infrastructure
46-
[observability](/docs/concepts/observability-primer/#what-is-observability) is
47-
greater than ever.
45+
[observability] is greater than ever.
4846

4947
OpenTelemetry satisfies the need for observability while following two key
5048
principles:
@@ -62,24 +60,23 @@ If you want to learn more, take a look at OpenTelemetry's
6260

6361
OpenTelemetry consists of the following major components:
6462

65-
- A [specification](/docs/specs/otel) for all components
66-
- A standard [protocol](/docs/specs/otlp/) that defines the shape of telemetry
67-
data
68-
- [Semantic conventions](/docs/specs/semconv/) that define a standard naming
69-
scheme for common telemetry data types
63+
- A [specification](../specs/otel) for all components
64+
- A standard [protocol](../specs/otlp/) that defines the shape of telemetry data
65+
- [Semantic conventions](../specs/semconv/) that define a standard naming scheme
66+
for common telemetry data types
7067
- APIs that define how to generate telemetry data
71-
- [Language SDKs](/docs/languages) that implement the specification, APIs, and
68+
- [Language SDKs](../languages) that implement the specification, APIs, and
7269
export of telemetry data
7370
- A [library ecosystem](/ecosystem/registry) that implements instrumentation for
7471
common libraries and frameworks
7572
- Automatic instrumentation components that generate telemetry data without
7673
requiring code changes
77-
- The [OpenTelemetry Collector](/docs/collector), a proxy that receives,
78-
processes, and exports telemetry data
74+
- The [OpenTelemetry Collector](../collector), a proxy that receives, processes,
75+
and exports telemetry data
7976
- Various other tools, such as the
80-
[OpenTelemetry Operator for Kubernetes](/docs/platforms/kubernetes/operator/),
81-
[OpenTelemetry Helm Charts](/docs/platforms/kubernetes/helm/), and
82-
[community assets for FaaS](/docs/platforms/faas/)
77+
[OpenTelemetry Operator for Kubernetes](../platforms/kubernetes/operator/),
78+
[OpenTelemetry Helm Charts](../platforms/kubernetes/helm/), and
79+
[community assets for FaaS](../platforms/faas/)
8380

8481
OpenTelemetry is used by a wide variety of
8582
[libraries, services and apps](/ecosystem/integrations/) that have OpenTelemetry
@@ -97,7 +94,7 @@ extended include:
9794
- Adding a receiver to the OpenTelemetry Collector to support telemetry data
9895
from a custom source
9996
- Loading custom instrumentation libraries into an SDK
100-
- Creating a [distribution](/docs/concepts/distributions/) of an SDK or the
97+
- Creating a [distribution](../concepts/distributions/) of an SDK or the
10198
Collector tailored to a specific use case
10299
- Creating a new exporter for a custom backend that doesn't yet support the
103100
OpenTelemetry protocol (OTLP)
@@ -108,8 +105,7 @@ designed to make it possible at nearly every level.
108105

109106
## History
110107

111-
OpenTelemetry is a
112-
[Cloud Native Computing Foundation (CNCF)](https://www.cncf.io) project that is
108+
OpenTelemetry is a [Cloud Native Computing Foundation][] (CNCF) project that is
113109
the result of a [merger] between two prior projects,
114110
[OpenTracing](https://opentracing.io) and [OpenCensus](https://opencensus.io).
115111
Both of these projects were created to solve the same problem: the lack of a
@@ -119,12 +115,22 @@ they merged to form OpenTelemetry and combine their strengths while offering a
119115
single solution.
120116

121117
If you are currently using OpenTracing or OpenCensus, you can learn how to
122-
migrate to OpenTelemetry in the [Migration guide](/docs/migration/).
118+
migrate to OpenTelemetry in the [Migration guide](../migration/).
123119

124120
[merger]:
125121
https://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/
126122

127123
## What next?
128124

129-
- [Getting started](/docs/getting-started/) — jump right in!
130-
- Learn about [OpenTelemetry concepts](/docs/concepts/).
125+
- [Getting started](../getting-started/) — jump right in!
126+
- Learn about [OpenTelemetry concepts](../concepts/).
127+
128+
[Cloud Native Computing Foundation]: https://www.cncf.io
129+
[instr]: ../concepts/instrumentation
130+
[Jaeger]: https://www.jaegertracing.io/
131+
[logs]: ../concepts/signals/logs/
132+
[metrics]: ../concepts/signals/metrics/
133+
[observability]: ../concepts/observability-primer/#what-is-observability
134+
[Prometheus]: https://prometheus.io/
135+
[telemetry data]: ../concepts/signals/
136+
[traces]: ../concepts/signals/traces/

0 commit comments

Comments
 (0)