Manual Instrumentation
Setup¶
OpenTelemetry Swift provides limited functionality in its default configuration. For more useful functionality, some configuration is required.
The default registered TracerProvider
and MetricProvider
are not configured
with an exporter. There are several
exporters
available depending on your needs. Below we will explore configuring the OTLP
exporter, which can be used for sending data to the
collector.
A similar pattern is used for the OtlpMetricExporter:
After configuring the MeterProvider & TracerProvider all subsequently initialized instrumentation will be exporting using this OTLP exporter.
Acquiring a Tracer¶
To do tracing, you will need a tracer. A tracer is acquired through the tracer provider and is responsible for creating spans. The OpenTelemetry manages the tracer provider as we defined and registered above. A tracer requires an instrumentation name, and an optional version to be created:
Creating Spans¶
A span represents a unit of work or operation. Spans are the building blocks of Traces. To create a span use the span builder associated with the tracer:
It is required to call end()
to end the span.
Creating Nested Spans¶
Spans are used to build relationship between operations. Below is an example of how we can manually build relationship between spans.
Below we have parent()
calling child()
and how to manually link spans of
each of these methods.
The parent-child relationship will be automatically linked if activeSpan
is
used:
Getting the Current Span¶
Sometimes it's useful to do something with the current/active span. Here's how to access the current span from an arbitrary point in your code.
Span Attributes¶
Spans can also be annotated with additional attributes. All spans will be
automatically annotated with the Resource
attributes attached to the tracer
provider. The Opentelemetry-swift sdk already provides instrumentation of common
attributes in the SDKResourceExtension
instrumentation. In this example a span
for a network request capturing details about that request using existing
semantic conventions.
Creating Span Events¶
A Span Event can be thought of as a structured log message (or annotation) on a Span, typically used to denote a meaningful, singular point in time during the Span’s duration.
Setting Span Status¶
A status can be set on a span,
typically used to specify that a span has not completed successfully -
SpanStatus.Error
. In rare scenarios, you could override the Error status with
OK, but don’t set OK on successfully-completed spans.
The status can be set at any time before the span is finished:
Recording exceptions in Spans¶
Semantic conventions provide special demarcation for events that record exceptions:
SDK Configuration¶
Processors¶
Different Span processors are offered by OpenTelemetry-swift. The
SimpleSpanProcessor
immediately forwards ended spans to the exporter, while
the BatchSpanProcessor
batches them and sends them in bulk. Multiple Span
processors can be configured to be active at the same time using the
MultiSpanProcessor
. For example, you may create a SimpleSpanProcessor
that
exports to a logger, and a BatchSpanProcesssor
that exports to a OpenTelemetry
Collector:
The batch span processor allows for a variety of parameters for customization including.
Exporters¶
OpenTelemetry-Swift provides the following exporters:
InMemoryExporter
: Keeps the span data in memory. This is useful for testing and debugging.DatadogExporter
: Converts OpenTelemetry span data to Datadog traces & span Events to Datadog logs.JaegerExporter
: Converts OpenTelemetry span data to Jaeger format and exports to a Jaeger endpoint.- Persistence exporter: An exporter decorator that provides data persistence to existing metric and trace exporters.
PrometheusExporter
: Converts metric data to Prometheus format and exports to a Prometheus endpoint.StdoutExporter
: Exports span data to Stdout. Useful for debugging.ZipkinTraceExporter
: Exports span data to Zipkin format to a Zipkin endpoint.