For many engineers new to observability, and application performance monitoring for that matter, domain-oriented observability looks very much like adding interceptors and callbacks into an application codebase to simplify the calling out to a generic data collector library such as distributed tracing, metrics, or even logging as a last resort. Unfortunately, the domain-oriented approach rarely reflects the needs of a useful service level management framework because it becomes lost within the business domain’s details. The pendulum seems to swing between two extremes, highly domain-specific named callbacks, or generic non-descriptive data sinks.
A highly domain-specific approach to observability ends up with hundreds of
<Task>Instrumentation interceptor like interfaces containing various lifecycle hook methods that mirror the business function, such as
completedCreateOrder – a significant step backward from what was hoped with Aspect-Oriented Programming (AOP). This approach lacks the required level of abstraction and (conceptual) model that is needed for the effective operational management of a system of services, which is pretty much what software is and has always been to some extent. The concept of a managed service is all but absent here, as are the standard set of signals one could easily imagine being captured in observing the service interactions.
At the other end of the scale, we have the yesteryear generic data-centric approaches being dragged kicking and screaming into the modern world of software microservices architecture and the observability requirements that come with it. Again common service level management concepts such as
Status, are amiss here wholly. Instead, the instrumentation library interfaces consist of calls to
LogRecord to a
OpenSignals for Services, on the other hand, strikes the perfect balance between these two extreme views of observability. Its model is specifically designed for service level management needs with the introduction of a set of fifteen
Signal values and five
Status values that can be fired by and associated with a
Service, respectively. The domain is not the business. The domain is not the data. The domain is the system of services and the interactions that take place. Here methods on the
Service interface capture what is essential to observability, including