Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow create events outside of an observation scope #5487

Closed
JordiMartinezVicent opened this issue Sep 23, 2024 · 6 comments
Closed

Allow create events outside of an observation scope #5487

JordiMartinezVicent opened this issue Sep 23, 2024 · 6 comments
Labels
closed-as-inactive feedback-reminder waiting for feedback We need additional information before we can continue

Comments

@JordiMartinezVicent
Copy link

Please describe the feature request.
Currently the observation api only allows to create events when an observation has been started. If you try to create it without starting it, the following error appears:

java.lang.IllegalStateException: Span wasn't started - an observation must be started (not only created)

It would be nice to have the feature to create an event which is not coupled to an observation (or at least an observation started).

Rationale

I understand the motivation of having an event (let's say) "attached" to an observation. It is a good approach to notice "events" which happen somewhere inside of what you are "observing". For example, the GrpcServerEvents happen inside of a Grpc communication. However, in my opinion, there are other kind of events which could have sense to be isolated from an observation scope.

For example, a real world scenario would be to instrument circuit breaker's state change.

@marcingrzejszczak
Copy link
Contributor

For example, a real world scenario would be to instrument circuit breaker's state change.

How would you like that instrumented? Is it a counter? If that's the case you can create the counter without using the Observation API.

@marcingrzejszczak marcingrzejszczak added waiting for feedback We need additional information before we can continue and removed waiting-for-triage labels Sep 24, 2024
@JordiMartinezVicent
Copy link
Author

How would you like that instrumented? Is it a counter? If that's the case you can create the counter without using the Observation API.

Correct, I already have counters for that. I was wondering if I could use the micrometer-observation abstraction api instead of using metrics directly.

Searching at your repo I saw the following @jonatan-ivanov comment #3247 (comment) :

I can imagine a use-case where Events are just happening standalone, not connected to an Observation but to cover that use-case, I would use a different component (if we want to cover that at all).

A real-life example I can think of is applying the same business logic for two different endpoints or sources: let's say we are accepting messages over HTTP and AMQP but the workflow/business logic is the same for both.

I do no know if you have had a second thought about it and if you think it would be valuable.

@jonatan-ivanov
Copy link
Member

jonatan-ivanov commented Sep 24, 2024

Currently the observation api only allows to create events when an observation has been started. If you try to create it without starting it, the following error appears:

java.lang.IllegalStateException: Span wasn't started - an observation must be started (not only created)

The Observation API alone sort of allows this but this was never an intended usage that's why the tracing handler blows up. Also, if you use the TestObservationRegistry, it will validate this and throw an exception.

It would be nice to have the feature to create an event which is not coupled to an observation (or at least an observation started).

Right now events are tied to Observations. I'm not sure how to untie them since actions that react to these events are in ObservationHandler. I guess an Observation-less event would be just using any framework/library with eventing capabilities and creating counters when an event is fired. I think "fixing" the tracing handler so that it won't fail should be possible. That will let you emit events without starting Observations. At this point though, I'm not sure if we should or not.

[...] there are other kind of events which could have sense to be isolated from an observation scope.
For example, a real world scenario would be to instrument circuit breaker's state change.

Please give us real-world scenarios like this, it helps us to understand the problem better and come-up with solutions. The state changes of circuit breakers happen when you execute something through the circuit breaker, right? If so, they should be part of an Observation already (a started one). If this is not the case and you have a circuit breaker that changes its state let's say after some time even if it was not used, to me that's more like a "gauge" scenario.
Resilience4J has Micrometer support that registers a gauge for states, isn't that what you would need?

@jonatan-ivanov
Copy link
Member

jonatan-ivanov commented Sep 24, 2024

It was two years ago but I think "A real-life example I can think of" part of what I wrote was about Counter names and tags not about the Observation-less events. For those, I think what I wrote back then:

I can imagine a use-case where Events are just happening standalone, not connected to an Observation but to cover that use-case, I would use a different component (if we want to cover that at all).

is somewhat similar to what I wrote above:

I guess an Observation-less event would be just using any framework/library with eventing capabilities and creating counters when an event is fired.

In my mind, it would look like something like this:

eventPublisher.publish(CustomEvent.of("test"));

[...]

class CustomEventListener implements EventListener<CustomEvent> {
    @Override
    public void onEvent(CustomEvent event) {
        // counter.increment();
    }
}

But this is already possible with a bunch of libraries/frameworks, including Spring, Reactor, etc. (see: https://www.baeldung.com/spring-events)

Summary: fixing the tracing handler should be possible but in order to reimplement a pub-sub library we need justification.

Copy link

github-actions bot commented Oct 2, 2024

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Copy link

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-as-inactive feedback-reminder waiting for feedback We need additional information before we can continue
Projects
None yet
Development

No branches or pull requests

3 participants