You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/observability/logging/index.mdx
+15Lines changed: 15 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,6 +39,21 @@ This outputs detailed information about:
39
39
- Action executions
40
40
- Flow transitions
41
41
42
+
### Verbose mode on `Guardrails` and `LLMRails`
43
+
44
+
The two entry points interpret `verbose=True` differently.
45
+
46
+
| Entry point | Effect of `verbose=True`|
47
+
|-------------|--------------------------|
48
+
|`LLMRails(config, verbose=True)`| Adds a verbose console handler at `INFO` to the root logger and logs LLM prompts and completions. |
49
+
|`Guardrails(config, verbose=True)`| Calls `configure_logging(logging.DEBUG)`, attaching a stderr handler to the `nemoguardrails.guardrails` logger and setting it to `DEBUG`. |
50
+
51
+
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.
52
+
53
+
Note that `configure_logging` also stops the `nemoguardrails.guardrails` logger propagating to the root logger; see [OpenTelemetry logs](/observability/tracing/opentelemetry-logs) for what that means for handlers you attach yourself.
54
+
55
+
A default `Guardrails(config)` construction configures no logging at all, leaving handlers, levels, and formatting to your application.
56
+
42
57
## Explain Method
43
58
44
59
Get a quick summary of the last generation using the `explain()` method:
Copy file name to clipboardExpand all lines: docs/observability/tracing/opentelemetry-logs.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -150,7 +150,7 @@ Log records emitted outside any guardrails request, such as startup, engine regi
150
150
- Performance
151
151
: At high log volumes or DEBUG level, log export can add measurable overhead. Use `BatchLogRecordProcessor` (as shown) rather than the synchronous `SimpleLogRecordProcessor` in production, and consider filtering at the logger level (`logging.getLogger("nemoguardrails").setLevel(logging.INFO)`) to limit what crosses the bridge.
152
152
- Interaction with `propagate=False`
153
-
: If your application calls `nemoguardrails.guardrails.configure_logging()`on a freshly initialized logger, that helper sets `propagate=False` on the `nemoguardrails.guardrails` logger to prevent duplicate console output. The flag is only set on the first call, when no handlers exist yet. Records from submodules under `nemoguardrails.guardrails.*` will then not reach the handler attached to `nemoguardrails`. To capture them, attach the handler to `nemoguardrails.guardrails` instead of (or in addition to) `nemoguardrails`.
153
+
: `nemoguardrails.guardrails.configure_logging()` sets `propagate=False` on the `nemoguardrails.guardrails` logger to prevent duplicate console output. It runs when your application calls it directly, and when you construct `Guardrails(..., verbose=True)`. The flag is only set on the first call, when no handlers exist yet. Records from submodules under `nemoguardrails.guardrails.*` will then not reach the handler attached to `nemoguardrails`. To capture them, attach the handler to `nemoguardrails.guardrails` instead of (or in addition to) `nemoguardrails`. A default `Guardrails(...)` construction does not configure logging, so its records propagate normally.
0 commit comments