Pendulumn of Instrumentation
For many engineers new to observability and application performance monitoring, 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.
Domain-Oriented: Verbose • Specific
A highly domain-oriented approach to observability involves hundreds of Task::Instrumentation interceptor-like interfaces containing various lifecycle hook methods that mirror the business function, such as startCreateOrder, failedCreateOrder, and 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 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.
Data Centric: Voluminous • Valueless
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 Service, Signal, and Status, are amiss here wholly. Instead, the instrumentation library interfaces consist of calls to start and stop a Trace or Span, increment and decrement a Counter, or log a LogRecord to a Logger.
OpenSignals: Simplicity • Significance
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 by introducing 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 start, stop, call, fail, succeed, recourse, retry, reject, elapse, drop, delay, etc.