Logging and Debugging Guardrails Generated Responses
This guide covers the various methods for logging, debugging, and understanding what happens during guardrails generation.
Overview
The NeMo Guardrails library provides multiple ways to inspect and debug guardrails generation:
Verbose Mode
Enable detailed console logging by setting verbose=True when creating the LLMRails instance:
This outputs detailed information about:
- LLM calls and their prompts/completions
- Rail activations and decisions
- Action executions
- Flow transitions
Verbose mode on Guardrails and LLMRails
The two entry points interpret verbose=True differently.
When Guardrails falls back to LLMRails — because an llm was passed, or the config contains flows IORails does not support — both apply, because verbose is forwarded to the LLMRails instance it creates.
Note that configure_logging also stops the nemoguardrails.guardrails logger propagating to the root logger; see OpenTelemetry logs for what that means for handlers you attach yourself.
A default Guardrails(config) construction configures no logging at all, leaving handlers, levels, and formatting to your application.
Explain Method
explain() is an LLMRails method.
It raises NotImplementedError when IORails is the active engine, because ExplainInfo is built from Colang events.
On IORails, use the log generation option described below.
Get a quick summary of the last generation using the explain() method:
The ExplainInfo object provides methods to inspect:
- LLM calls summary
- Colang history
- Generated events
Generation Options: Log
For detailed structured logging, use the log generation option. This returns comprehensive information about what happened during generation.
Enabling Log Options
Log Option Reference
internal_events and colang_history describe Colang runtime state.
IORails does not run the Colang runtime, so it raises NotImplementedError when you set either option to True instead of returning an empty value.
For the IORails log structure, refer to Generation Options: Log Options on IORails.
Response Structure
Using print_summary()
The log object has a print_summary() method for a human-readable overview:
Example output:
Accessing Detailed Data
Access specific log components programmatically:
Output Variables
Output variables are an LLMRails capability, because they read the Colang context.
IORails raises ValueError when you pass output_vars.
To find which rail stopped a request on IORails, read log.activated_rails and look for the entry with stop set to True.
The action’s return_value["failed"] value distinguishes a rail failure from a policy block.
You can also use check() and check_async(), which report the rail that stopped processing.
Return specific context variables using the output_vars option:
Return Specific Variables
Return All Context Variables
Set output_vars to True to return the complete context:
Common Output Variables
Combining Log and Output Variables
Use both options together for comprehensive debugging:
Debugging Common Issues
Input Blocked Unexpectedly
Understanding Flow Execution
Analyzing LLM Performance
Server API Logging
When using the server API, include options in the request body:
Complete Debugging Example
Related Resources
- Tracing - Production monitoring and observability with OpenTelemetry