feature: Disentangle tracing and logging

[RobGeada]

Did you check the docs?

• I have read all the NeMo-Guardrails docs

Is your feature request related to a problem? Please describe.

Currently, when tracing is enabled, all log options are overridden to true, to ensure the generated traces are sufficiently detailed:

            # enable log options
            # it is aggressive, but these are required for tracing
            if (
                not options.log.activated_rails
                or not options.log.llm_calls
                or not options.log.internal_events
            ):
                options.log.activated_rails = True
                options.log.llm_calls = True
                options.log.internal_events = True

However, this then clutters the server's response, dumping a massive log in the JSON response object. If we want to use the guardrails-server as a replacement for an OpenAI model endpoint, this restricts our options to:

1. Have tracing, and expose all system/rail internals back to the original caller regardless of their logging option
2. Have no tracing

Describe the solution you'd like

I propose disentangling the log and tracing configuration options, so that the returned object always returns the information as configured in the original configuration. This can be done by:

1. Making a copy of the original log configuration during tracing setup
2. Set all log options to true for tracing, ensuring that trace detail is not compromised
3. After tracing is computed, refer to original log configuration and strip out undesired log information from the response object.

Tracing Setting	Log Setting	Behavior
off	off	No tracing, no logs
on	off	Tracing is performed, but log information is not returned in the response object
off	on	Tracing is not performed, but log information is returned in the reponse object
on	on	Tracing is performed, and log information is returned in the response object . This is the current behavior when tracing is on, and therefore would preserve that functionality if desired

With this solution, we can use tracing on a guardrails server without exposing internal system details back to the original caller. The current behavior can also be preserved, simply by setting the corresponding log options to true in config when enabling tracing.

If the maintainers agree with this proposal, I have opened a PR that implements this flow.

Describe alternatives you've considered

• Create a shim server/gateway between the guardrails server and the original caller, that filters out log information in the response if undesired. This would solve the problem, but feels like a pretty clunky solution as compared to the above.

Additional context

No response