Category: Observability X

Observability X – Containers

In this post, we introduce the concept of Container in the Substrates API. A Container is a collection of Conduits of the same emittance data type. With the concept of Container, we introduce a new element in the Subject hierarchy. So instead of a Conduit being parented by a Circuit, it can now also be parented by a Container which is then parented by a Circuit.

More...

Observability X – Substrates 101

We’re almost done with this series, and we’ve covered some rather profound concepts. Let’s take a quick look at what we’ve learned so far. We’ll break it down into two parts: form and function.

More...

Observability X – Composers

The Substrates API enables the direct utilization of Pipes and Channels, while simultaneously offering a mechanism to construct percepts that adorn these fundamental elements of any sensing and synthesis pipeline. To construct a Conduit that facilitates the on-demand creation of percepts upon receiving a name, we must provide a Composer to the conduit method within the Circuit interface.

More...

Observability X – Queues, Scripts, and Currents

The Substrates API separates the concerns of task definition, scheduling, and execution, while simultaneously enabling robust patterns for composing asynchronous workflows. The capability to post scripts, coupled with control over execution order facilitates adaptable and maintainable event-driven systems.

More...

Observability X – Resources, Scopes, and Closures

Resource management is crucial for scaling digital twin representations in service architectures. Proper resource cleanup ensures system stability during scaling up and down. Rigorous resource management prevents resource exhaustion and orphaned resources consuming capacity. The Substrates API’s approach to resource management ensures resources are acquired and released during scaling operations

More...

Observability X – States and Slots

The State and Slot interfaces provide a type-safe approach to managing and transmitting state. The State interface offers an immutable way to collect and chain Slots, each with a name, type, and value. It enforces type safety through method overloading, supporting primitives, strings, names, and states. These interfaces create a foundation for constructing states and communicating changes type-safely and performantly for small sets.

More...

Observability X – Subjects

How we model observables in our systems shapes how we understand, monitor, and reason about their behavior. In the proposed subject-based model, all changes are simply emissions from a subject, eliminating the artificial distinction between states and signals that plague many current observability systems.

More...

Observability X – Circuits

A significant challenge with siloed-oriented telemetry toolkits, such as OpenTelemetry, is that each instrument employs a distinct data collection and transmission process. Each pillar, including tracing, metrics, and logging, possesses numerous configuration parameters to manage underlying resource usage, such as buffers and execution threads. There is no inherent mechanism to synchronize or share context among these systems, resulting in fragmented and potentially conflicting telemetry data.

More...

Observability X – Channels

In observability, channels underpin streaming architectures for real-time monitoring and alerting, enabling dynamic system reactions and scalability. Understanding and leveraging channels creates resilient, scalable, and maintainable systems, which is essential in today’s interconnected world. Instruments provide a high-level, domain-specific interface on top of channels. Beneath the surface, they are essentially specialized wrappers around channel operations.

More...

Observability X – Pipes & Pathways

Traditionally, observability data pipelining operates like a single assembly line, where workers halt, examine items, and consult manuals before proceeding. This approach is functional but slow due to inspections. Instead of thinking of observability as one long pipeline, think of it as a graph with many possible routes. Once we know where something needs to go, we can create a specific route for it, like how a GPS creates a particular path for your destination instead of having to check a map at every intersection.

More...