opentelemetry
OpenTelemetry Support
Azul Payara natively supports OpenTelemetry APIs as well as export of telemetry signals over the OTLP protocol. Natively in this context means that deployment of an OpenTelemetry Agent is not necessary and may lead to duplicate traces.
Azul Payara satisfies the requirements of MicroProfile Telemetry 2.1 provided appropriate Span Convention Settings are applied.
|
Important
|
In addition to traces, Azul Payara emits JVM runtime metrics and an HTTP server request-duration metric. Metrics and logs signal exporters are fully supported but default to none unless explicitly configured. See Server-Emitted Telemetry Signals for details on server-emitted signals.
|
Enabling OpenTelemetry
Azul Payara runs two OpenTelemetry SDK instances: a runtime (server-wide) SDK and a per-application SDK. They are not fully independent — when the runtime SDK is enabled it processes all telemetry, including signals from deployed applications. See Enabling OpenTelemetry support in the MicroProfile Telemetry specification for the underlying behaviour.
Runtime (Server-Wide) OpenTelemetry
The runtime SDK is managed by the Monitoring Service and emits server-level signals such as JVM runtime metrics and the HTTP request-duration histogram. When the runtime SDK is enabled it also processes application telemetry — spans and metrics emitted by deployed applications are handled by the same SDK instance. Using the runtime SDK is therefore generally advised.
Enable it by either:
-
Running
asadmin enable-monitoring --otel, or -
Setting the Monitoring Service attribute
openTelemetryEnabledtotrue, for example viaasadmin set-monitoring-service-configuration --otelenabled=true.
|
Note
|
Enabling the Request Tracing Service does not enable the runtime OpenTelemetry SDK. Toggling the runtime SDK setting requires a server restart. |
Per-Application OpenTelemetry
A per-application SDK can be activated independently of the runtime SDK by setting the MicroProfile Config property otel.sdk.disabled=false for the application (or the equivalent system property / environment variable OTEL_SDK_DISABLED=false).
Note that the per-application SDK is more limited than the runtime SDK — for example, JVM runtime metrics are only published by the runtime SDK and are not available from a per-application SDK.
Configuring OpenTelemetry
There is no Admin Console UI for OpenTelemetry configuration.
Enablement is via asadmin or the Monitoring Service (runtime SDK) or via the MicroProfile Config property otel.sdk.disabled=false (per-application SDK), as described in Enabling OpenTelemetry.
All other OpenTelemetry configuration — exporters, sampling, propagators, resource attributes, and more — is done exclusively via MicroProfile Config properties. See MicroProfile Telemetry configuration properties for the full list of supported properties.
When OpenTelemetry is enabled it proceeds to configure OpenTelemetry components by means of autoconfiguration, using the application’s MicroProfile Config properties prefixed with otel. first, but also falling back to system properties and environment variables as described in the linked documentation.
If the configured component does not ship with Payara distribution, it can be added as a server or application library as described in Using Additional Components.
Default Settings
The per-application SDK uses OpenTelemetry autoconfiguration. With no other configuration properties specified, the per-application OpenTelemetry components will:
-
Accept and propagate trace headers and baggage according to W3C recommendations Trace Context and Baggage
-
Export traces via OTLP protocol to
http://localhost:4317 -
Respect parent trace’s sampling decision and always sample local root traces (sampler setting
parentbased_always_on) -
Not export metrics or logs unless explicitly configured.
The runtime (server-wide) SDK uses explicit configuration. Unless configured, all exporters — traces, metrics, and logs — default to none and no signals are exported automatically.
To easily receive traces in default configuration run the following Jaeger container and then access its UI at port 16686:
docker run --name jaeger \
-e COLLECTOR_OTLP_ENABLED=true \
-p 16686:16686 \
-p 4317:4317 \
-p 4318:4318 \
jaegertracing/all-in-one:latest
Span Convention Settings
In order to improve consistency among products our implementation offers several strategies of naming and tagging spans of Jakarta REST client and server calls.
These are configured by specifying the MicroProfile Config property payara.telemetry.span-convention for your application.
The following values are accepted:
-
opentelemetryfollows convention prescribed by OpenTelemetry semantic conventions for HTTP spans (default setting) -
opentracing-http-pathsatisfies MicroProfile OpenTracing setting for Operation Name Providerhttp-path -
opentracing-class-methodcorresponds to MicroProfile OpenTracing setting for Operation Name Providerclass-method -
microprofile-telemetrysatisfies span naming as tested by the MicroProfile Telemetry TCK
Span Name Examples
Let’s assume GET request made to /app/rest/resource/method, where
-
/appis application context root -
/restis@ApplicationPathof Jakarta REST -
/resourceis@Pathannotation of classexample.Resource -
/methodis@Pathannotation of methodrestMethod
The following span names will be created for this request for different Span Convention settings:
| Span-Convention Setting | Server Span Name |
|---|---|
|
|
|
|
|
|
|
|
Suppressing Export Warning Message
When the export endpoint is not available in default setting the following error message is logged by logger io.opentelemetry.exported.internal.grpc.OkHttpGrpcExporter:
Failed to export spans. The request could not be executed. Full error message: Failed to connect to `localhost/127.0.0.1:4317`
If you don’t intend to run an OTEL endpoint on localhost or at all you need to configure the exporter by means of MP Config Properties, system properties, or environment variables:
-
To turn off exports, set the
otel.traces.exporterproperty tonone -
To set the remote endpoint
otel.exporter.otlp.endpointtohttp://<collector-host>:<port>
Manual Tracing
To fine-tune spans and have better control over their boundaries you can use the OpenTelemetry API directly.
Dependencies
The appropriate versions of APIs are provided by Payara BOM artifact matching the version of the Azul Payara distribution you are using.
Azul Payara provides the following APIs, and it is advised to mark them as provided dependencies in your application and don’t package them with it:
-
io.opentelemetry:opentelemetry-sdk-extension-autoconfigure -
io.opentelemetry:opentelemetry-sdk -
io.opentelemetry:opentelemetry-sdk-common -
io.opentelemetry:opentelemetry-sdk-metrics -
io.opentelemetry:opentelemetry-sdk-logs -
io.opentelemetry:opentelemetry-api-logs -
io.opentelemetry:opentelemetry-sdk-extension-autoconfigure-spi -
io.opentelemetry:opentelemetry-semconv -
io.opentelemetry:opentelemetry-api -
io.opentelemetry:opentelemetry-context -
io.opentelemetry:opentelemetry-exporter-otlp -
io.opentelemetry:opentelemetry-sdk-trace -
io.opentelemetry:opentelemetry-exporter-otlp-common -
io.opentelemetry:opentelemetry-exporter-common
Using Opentelemetry Manually
import io.opentelemetry.api.trace.Tracer;
@RequestScoped
public class TracedComponent {
@Inject
Tracer tracer;
public void tracedMethod() {
var span = tracer.spanBuilder("tracedTask").startSpan();
try (var scope = span.makeCurrent()) {
// do work, add information to span
if (span.isRecording()) {
// compute expensive events or tags
// only if the span is being sampled
}
} finally {
span.setStatus(StatusCode.OK);
span.end();
}
}
}
Using Additional Components
If your application requires OpenTelemetry components that are not shipped with Azul Payara, it is possible to either put them in common libraries, or ship them with an application. Extension components can even be coded directly in the application code.
Provider Components in Library Directory
|
Note
|
Applies to Payara Server only. |
Autoconfiguration can pick up components, which are placed in directory domain_dir/lib for example by means of the asadmin add-library command.
Example: Adding Export to Log
-
Download opentelemetry-exporter-logging.jar
-
Run
asadmin add-library opentelemetry-exporter-logging.jar -
Use the component by defining
otel.traces.exporter=logging
Provider Components in Application Code
Applications can declare and use their own OpenTelemetry components such as exporters or samplers by writing against autoconfiguration SPI and placing appropriate Service Loader resource in the application
Example: Minimal Logging Exporter
fish.payara.example.LogExporter.Provider
public class LogExporter implements SpanExporter {
private static final Logger LOGGER = Logger.getLogger(LogExporter.class.getName());
@Override
public CompletableResultCode export(Collection<SpanData> spans) {
spans.forEach(s -> LOGGER.info(s.toString()));
return CompletableResultCode.ofSuccess();
}
@Override
public CompletableResultCode flush() {
return CompletableResultCode.ofSuccess();
}
@Override
public CompletableResultCode shutdown() {
return CompletableResultCode.ofSuccess();
}
// This is registered as SPI and creates configured exporter
public static class Provider implements ConfigurableSpanExporterProvider {
@Override
public SpanExporter createExporter(ConfigProperties configProperties) {
return new LogExporter();
}
@Override
public String getName() {
return "logs";
}
}
}
Relation to Request Tracing Service
OpenTelemetry spans also appear in the Request Tracing Service in an OpenTelemetry-compatible structure. However, only traces that are sampled by the Request Tracing Service reach its configured notifiers. This means a trace may be exported via OTLP but not forwarded to Request Tracing notifiers if the service decided not to sample it.
|
Note
|
Enabling the Request Tracing Service does not enable the runtime OpenTelemetry SDK. See Runtime (Server-Wide) OpenTelemetry for how to enable server-wide OpenTelemetry. |