Request Tracing Service

The Request Tracing Service provides tracing facilities for multiple protocols and process communications done by the components of deployed applications.

The service helps users to detect application slowness and performance degradation by logging requests that exceed a given threshold. The trace data from long-running requests gives insight to solving bottlenecks and other performance issues.

The service is available in both Payara Server and Payara Micro, though the service configuration is different in Payara Micro.

The following types of requests are traced if the service is enabled:

  • REST (JAX-RS endpoints)

  • Servlets (HTTP requests)

  • SOAP Web Services

  • WebSockets

  • EJB timers execution

  • Inbound JMS messages received by an MDB

  • JBatch jobs creation

  • Tasks executed by injected Managed Executors.

In Payara Server and Micro 5.181, the Request Tracing Service was given an overhaul - traces are now in an OpenTracing-style format using Spans, instead of the original event stream format. Practically, this means that instead of having an ordered sequence of time stamped events constituting a trace (with separate entered and exited events), you now have a set of related traces (now called spans) with individual durations and attributes.

The OpenTracing specification, found here, gives a more detailed description of what Spans are and the general trace format.

The Request Tracing overhaul also brought in the concept of sample rates, affording you extra options to limit the amount of tracing done. In Payara 5.181, there are two offerings: flat probability, and an adaptive solution. The flat probability sampling simply applies a percentage chance that a trace will not be traced. The adaptive solution allows you to configure a target number of traces to sample over a given time period (e.g. sample 6 traces every 10 minutes).

We also offer an option to perform this sampling before or after the threshold checks, allowing you to either determine if a trace should be sampled at its inception, or only after determining that a trace has breached your configured thresholds respectively.