Observe instantaneous events

[jonatan-ivanov]

This PR makes possible to signal instantaneous events that will be sent to handlers so they can record these Events.

A few notes, questions:

• I wanted to keep it simple for now so Events don't have KeyValues but handlers have access to the Context. Is there a use-case for being able to attach KeyValues to events?
• Events can be extended so arbitrary fields can be added (adding data is also possible to the Context).
• The Events are not available from the Context and event history is not preserved (in the Context). Both should be simple to implement though.
• Because of the above, the signature of the method in the handler contains the Event and the Context too: onEvent(Observation.Event event, Observation.Context context).
• I think it would be nice to be consistent to the other methods and pass only the Context but that has a few consequences:
  • The last Event or the Event history should be available from the Context which would make it bigger and it can be problematic if concurrent events are possible.
  • Harder to use since users should know where they can get the event and when will it be available for them.
• In this PR we track the events using a Counter but adding events/annotations to the Span should be simple:

    @Override
    public void onEvent(Observation.Event event, Observation.Context context) {
        Span span = getTracingContext(context).getSpan();
        span.event(event.getContextualName());
    }

• Run ObservationHandlerSample for an example, you should see the Counter (custom.event) and a log entry simulating logging/tracing scenarios: [...] i.m.o.ObservationTextPublisher - EVENT - event.name='custom.event' [...]

fyi: TimerObservationHandler was renamed to DefaultMeterObservationHandler because it can create Counters not only Timers.

[shakuzen]

Looks good. I just left one question about the naming of the counter in the default meter handler.

[shakuzen]

Since the event is scoped to the Observation, I wonder if the Counter name should somehow include both. observation name + event name, perhaps? I'm not sure how this looks given typical use cases, though, which is probably the best gauge of what makes sense. Unless events are supposed to be standalone things that just happen to occur during an observation?

[jonatan-ivanov]

It makes a lot of sense to me. Since we are attaching an Event to an Observation, I think it is a fair assumption that they belong together.

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.