@@ -13,8 +13,8 @@ cSpell:ignore: Logback logback
13
13
14
14
<!-- markdownlint-disable no-duplicate-heading -->
15
15
16
- Instrumentation records telemetry using the [ API] ( ../api-components / ) . The
17
- [ SDK ] ( ../sdk/ ) is the built-in reference implementation of the API, and is
16
+ Instrumentation records telemetry using the [ API] ( ../api/ ) . The [ SDK ] ( ../sdk/ )
17
+ is the built-in reference implementation of the API, and is
18
18
[ configured] ( ../configuration/ ) to process and export the telemetry produced by
19
19
instrumentation API calls. This page discusses the OpenTelemetry ecosystem in
20
20
OpenTelemetry Java, including resources for end users and cross-cutting
@@ -100,8 +100,8 @@ Instrumentation" column on
100
100
101
101
[ Native instrumentation] ( /docs/specs/otel/glossary/#natively-instrumented ) is
102
102
built directly into libraries or frameworks. OpenTelemetry encourages library
103
- authors to add native instrumentation using the [ API] ( ../api-components / ) . In
104
- the long term, we hope the native instrumentation becomes the norm, and view the
103
+ authors to add native instrumentation using the [ API] ( ../api/ ) . In the long
104
+ term, we hope the native instrumentation becomes the norm, and view the
105
105
instrumentation maintained by OpenTelemetry in
106
106
[ opentelemetry-java-instrumentation] ( https://github.com/open-telemetry/opentelemetry-java-instrumentation )
107
107
as a temporary means of filling the gap.
@@ -152,20 +152,17 @@ context:
152
152
153
153
For this correlation to work, trace context must be propagated throughout an
154
154
application (across function calls and threads), and across application
155
- boundaries. The [ context API] ( ../api-components /#context-api ) facilitates this.
155
+ boundaries. The [ context API] ( ../api/#context-api ) facilitates this.
156
156
Instrumentation needs to be written in a manner which is context aware:
157
157
158
158
- Libraries that represent the entry point to an application (i.e. HTTP servers,
159
- message consumers, etc.) should
160
- [ extract context] ( ../api-components/#contextpropagators ) from incoming
161
- messages.
159
+ message consumers, etc.) should [ extract context] ( ../api/#contextpropagators )
160
+ from incoming messages.
162
161
- Libraries that represent an exit point from an application (i.e. HTTP clients,
163
- message producers, etc.) should
164
- [ inject context] ( ../api-components/#contextpropagators ) into outgoing
165
- messages.
166
- - Libraries should implicitly or explicitly pass
167
- [ Context] ( ../api-components/#context ) through the callstack and across any
168
- threads.
162
+ message producers, etc.) should [ inject context] ( ../api/#contextpropagators )
163
+ into outgoing messages.
164
+ - Libraries should implicitly or explicitly pass [ Context] ( ../api/#context )
165
+ through the callstack and across any threads.
169
166
170
167
## Semantic conventions
171
168
@@ -177,21 +174,20 @@ attribute key, value, and requirement levels.
177
174
When writing instrumentation, consult the semantic conventions and conform to
178
175
any which are applicable to the domain.
179
176
180
- OpenTelemetry Java [ publishes artifacts] ( ../api-components /#semantic-attributes )
181
- to assist in conforming to the semantic conventions, including generated
182
- constants for attribute keys and values.
177
+ OpenTelemetry Java [ publishes artifacts] ( ../api/#semantic-attributes ) to assist
178
+ in conforming to the semantic conventions, including generated constants for
179
+ attribute keys and values.
183
180
184
181
TODO: discuss instrumentation API and how it helps conform to semantic
185
182
conventions
186
183
187
184
## Log instrumentation
188
185
189
- While the [ LoggerProvider] ( ../api-components/#loggerprovider ) /
190
- [ Logger] ( ../api-components/#logger ) APIs are structurally similar to the
191
- equivalent [ trace] ( ../api-components/#tracerprovider ) and
192
- [ metric] ( ../api-components/#meterprovider ) APIs, they serve a different use
193
- case. As of now, ` LoggerProvider ` / ` Logger ` and associated classes represent
194
- the [ Log Bridge API] ( /docs/specs/otel/logs/api/ ) , which exists to write log
186
+ While the [ LoggerProvider] ( ../api/#loggerprovider ) / [ Logger] ( ../api/#logger )
187
+ APIs are structurally similar to the equivalent [ trace] ( ../api/#tracerprovider )
188
+ and [ metric] ( ../api/#meterprovider ) APIs, they serve a different use case. As of
189
+ now, ` LoggerProvider ` / ` Logger ` and associated classes represent the
190
+ [ Log Bridge API] ( /docs/specs/otel/logs/api/ ) , which exists to write log
195
191
appenders to bridge logs recorded through other log APIs / frameworks into
196
192
OpenTelemetry. They are not intended for end user use as a replacement for Log4j
197
193
/ SLF4J / Logback / etc.
0 commit comments