feat(observability): Refactor content observation mechanism to support both logging and tracing #3612
Conversation
traburiss
force-pushed
the
feature/content-trace
branch
from
b212a6f to
c485721
Compare
…t both logging and tracing This commit refactors the content observation mechanism by adding support for trace recording without altering the original logging functionality. The motivation for this change is to ensure complete context availability in scenarios such as integration with Langfuse, which is essential for proper functionality. Main changes: 1. New configuration options: 1. `trace-prompt`: Enables recording prompts to trace 2. `trace-completion` : Enables recording completions to trace 3. `trace-prompt-size` : Limits the length of prompt context 4. `content-formatter` : Handles content formatting, currently supporting both 'text' and 'langfuse' modes 2. Added two handlers, ChatModelCompletionObservationTraceHandler and ChatModelPromptContentObservationTraceHandler, to support recording context to trace. 3. Introduced the MessageFormatter interface and its subclasses to support formatting for prompt and completion content. 4. Rolled back parts of the code and dependencies from commit ca843e8. Signed-off-by: tingchuan.li <[email protected]>
traburiss
force-pushed
the
feature/content-trace
branch
from
c485721 to
ef2ad4d
Compare
|
@jonatan-ivanov Could you take a look a this PR? Thanks! |
|
It would help in reviewing this if you could share a link to the relevant parts of Langfuse's documentation that specifies what they're expecting for the desired integration. How likely is it to change? This is reintroducing using the deprecated API on OTel Spans to add Event Attributes, which was removed because it's deprecated and the suggested alternative was Log Events. |
|
https://langfuse.com/docs/integrations/spring-ai Langfuse doc still uses |
| name = "chatModelPromptContentObservationTraceHandler") | ||
| @ConditionalOnProperty(prefix = ChatObservationProperties.CONFIG_PREFIX, name = "trace-prompt", | ||
| havingValue = "true") | ||
| TracingAwareLoggingObservationHandler<ChatModelObservationContext> chatModelPromptContentObservationTraceHandler( |
There was a problem hiding this comment.
Why are these wrapped into TracingAwareLoggingObservationHandler?
Please check what it does, it is used to make the tracing data available for log entries (log correlation). If I understand correctly, this is not needed in this use-case.
| @@ -61,7 +61,7 @@ | |||
|
|
|||
| <dependency> | |||
| <groupId>io.micrometer</groupId> | |||
| <artifactId>micrometer-tracing</artifactId> | |||
| <artifactId>micrometer-tracing-bridge-otel</artifactId> | |||
There was a problem hiding this comment.
spring-ai-commons should not depend on a bridge (implementation instead of the abstraction).
| } | ||
|
|
||
| @Nullable | ||
| public static Span extractOtelSpan(@Nullable TracingObservationHandler.TracingContext tracingContext) { |
There was a problem hiding this comment.
I think we should depend on the abstraction (tracing API) instead of a single implementation (OTel API/SDK).
| @@ -60,7 +60,7 @@ | |||
|
|
|||
| <dependency> | |||
| <groupId>io.micrometer</groupId> | |||
| <artifactId>micrometer-tracing</artifactId> | |||
| <artifactId>micrometer-tracing-bridge-otel</artifactId> | |||
There was a problem hiding this comment.
spring-ai-model should not depend on a bridge (implementation instead of the abstraction).
| .getRequired(TracingObservationHandler.TracingContext.class); | ||
| Span currentSpan = TracingHelper.extractOtelSpan(tracingContext); | ||
| if (currentSpan != null) { | ||
| currentSpan.addEvent(AiObservationEventNames.CONTENT_COMPLETION.value(), |
There was a problem hiding this comment.
It seems this API will be deprecated (maybe already is?), see: micrometer-metrics/micrometer#5238 (comment)
This makes me a bit confused. Why are we doing this if one is already deprecated and another is not supported? |
|
Basically my view is that our observability needs to support products like langfuse. How to achieve this goal. wrt to this PR
that change in behavior can't occur in 1.0.x - and not sure about the strategy for 1.1 on this front. Hoping to use this issue to drive a strategy. I thought there is flexibility to override behavior - we can perhaps create ready to use repos for products that customize observability in our https://github.com/orgs/spring-ai-community/repositories org @ThomasVitale suggestions on how to structure the convo and go forward - a working google doc would seem to be a good start. |
|
Also related discussion is here - #3151 (comment) |
This commit refactors the content observation mechanism by adding support for trace recording without altering the original logging functionality. The motivation for this change is to ensure complete context availability in scenarios such as integration with Langfuse, which is essential for proper functionality.
Main changes:
trace-prompt: Enables recording prompts to tracetrace-completion: Enables recording completions to tracetrace-prompt-size: Limits the length of prompt contextcontent-formatter: Handles content formatting, currently supporting both 'text' and 'langfuse' modes