Rasa Pro License
You'll need a license to get started with Rasa Pro. Talk with Sales
Distributed tracing tracks requests as they flow through a distributed system (in this case: a Rasa assistant), sending data about the requests to a tracing backend which collects all trace data and enables inspecting it. Trace data helps you understand the flow of requests through both the components of a single service (Rasa itself), and across different distributed services, for example, your action server.
Supported Tracing Backends/Collectors
To trace requests in Rasa Pro, you can either use Jaeger as a backend, or use the OTEL Collector (OpenTelemetry Collector). to collect traces and then send them to the backend of your choice. See Configuring a Tracing Backend or Collector for instructions.
Enabling / Disabling
Tracing is automatically enabled in Rasa Pro by configuring a supported tracing backend. No further action is required to enable tracing.
You can disable tracing by leaving the
tracing: configuration key empty
in your endpoints file.
The trace context is sent along with requests to the custom action server using the W3C Trace Context Specification. You can use this trace context to continue tracing the request through your custom action code. See traced events for details on what attributes are made available as part of the trace context.
Configuring a Tracing Backend or Collector
To configure a tracing backend or collector, add a
tracing entry to your endpoints
i.e. in your
endpoints.yml file, or in the relevant section of your Helm values in a deployment.
To configure a Jaeger tracing backend, specify the
Collectors are components that collect traces in a vendor-agnostic way and then forward them to various backends. For example, the OpenTelemetry Collector (OTEL) can collect traces from multiple different components and instrumentation libraries, and then export them to multiple different backends e.g. jaeger.
To configure an OTEL Collector, specify the
The Rasa service areas that are traceable cover the actions required to:
- train a model (i.e., the training of each graph component)
- handle a message
The following attributes can be inspected during training of
training_typeof model configuration:
languageof model configuration
recipe_nameused in the
output_filename: the location where the packaged model is saved
is_finetuning: boolean argument, if
Trueenables incremental training
The following attributes are captured during the training (as well as prediction during message handling) of every graph node:
fn_name: method of component class that gets called
The following Rasa classes are instrumented to enable tracing during message handling:
Namely, these operations are now traceable:
- receiving a message
- parsing the message
- predicting the next action
- running the action
- retrieving and saving the tracker
- locking the conversation
- publishing to the event broker
- passing the trace context to the action server
Agent instance handling a message captures the following attributes:
input_channel: the name of the channel connector
sender_id: the conversation id
model_id: a unique identifier for the model
model_name: the model name
MessageProcessor attributes are extracted during the tracing:
number_of_events: number of events in tracker
action_name: the name of the predicted and executed action
sender_id: the conversation id of the
message_id: the unique message id
The latter three attributes are also injected in the trace context that gets passed to the requests made to the custom action server.
LockStore attributes include:
number_of_streamed_events: number of new events to stream
EventBrokeron which the new events are published
lock_store_class: Name of lock store used to lock conversations while messages are actively processed