Visit Azul.com Support

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 openTelemetryEnabled to true, for example via asadmin 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:

  • opentelemetry follows convention prescribed by OpenTelemetry semantic conventions for HTTP spans (default setting)

  • opentracing-http-path satisfies MicroProfile OpenTracing setting for Operation Name Provider http-path

  • opentracing-class-method corresponds to MicroProfile OpenTracing setting for Operation Name Provider class-method

  • microprofile-telemetry satisfies span naming as tested by the MicroProfile Telemetry TCK

Span Name Examples

Let’s assume GET request made to /app/rest/resource/method, where

  • /app is application context root

  • /rest is @ApplicationPath of Jakarta REST

  • /resource is @Path annotation of class example.Resource

  • /method is @Path annotation of method restMethod

The following span names will be created for this request for different Span Convention settings:

Span-Convention Setting Server Span Name

opentelemetry

GET /app/rest/resource/method

opentracing-class-method

GET:example.Resource.restMethod

opentracing-http-path

GET:/resource/method

microprofile-telemetry

/app/rest/resource/method

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.exporter property to none

  • To set the remote endpoint otel.exporter.otlp.endpoint to http://<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

  1. Download opentelemetry-exporter-logging.jar

  2. Run asadmin add-library opentelemetry-exporter-logging.jar

  3. 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

src/main/resources/META-INF/services/io.opentelemetry.sdk.autoconfigure.spi.traces.ConfigurableSpanExporterProvider
 
fish.payara.example.LogExporter.Provider
src/main/java/fish/payara/example/LogExporter.java
 
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.