When we look at an application through the lens of observability, we’re looking for signs—signals that help us reconstruct what happened, where it happened, and why it matters. The Serventis Probes API is designed around that insight, grounding its entire model in semiotics, the study of signs and meaning-making. The Probes API offers a refreshingly different approach to observability—one that’s built not on measurement, but on meaning.
At the heart of the Probes API is the Observation interface, which combines these three dimensions into a complete record of a communication event. By collecting and analyzing Observations, systems can build detailed pictures of communication patterns and quickly identify anomalies. The API uses the concept of a Probe as its primary reporting mechanism. A Probe is an instrument that emits Observations about communication operations.
Outcome
What Happened?
SUCCESS
FAILURE
Origin
Where Did It Happen?
CLIENT
SERVER
Operation
What Was Happening?
CONNECT
SEND
RECEIVE
PROCESS
CLOSE
Each Observation holds a triple of structured information, and yet together they tell a story—a Probe-based trace that doesn’t rely on span correlation or central coordination. Each Probe reports what it directly observes, but collectively, they reveal the system’s behavior. By shifting from raw telemetry to semantic judgments, the Probes API enables:
Communication Narratives
Probe observations can be assembled into coherent narratives about what happened during a system interaction, not just what was measured, but what it meant.
Multi-Perspective Understanding
By recording judgments from different vantage points, probes acknowledge the distributed nature of truth in complex systems. What looks like success from one perspective might be failure from another.
Lightweight Semantic Tracing
Without the overhead of traditional distributed tracing, probes provide a lightweight way to understand the flow and outcome of communication across system boundaries.
Common Language of Operation
Probes offer a universal vocabulary for expressing operational meaning, independent of specific technologies, protocols, or implementations.
The Probes API doesn’t try to replace your metrics, logs, or traces. Instead, it adds a critical layer of meaning that’s often missing from traditional observability approaches. In complex distributed systems, understanding often gets lost in the noise of telemetry. The Probes API cuts through that noise by focusing on the essence: structured semantic statements about what happened, where it happened, and whether it worked. That’s not a metric. It’s a meaningful observation.
1 2 3 4 5 6 7 |
Observation = Origin × Operation × Outcome Origin → Who observed it? (CLIENT | SERVER) Operation → What was done? (CONNECT | SEND | RECEIVE | PROCESS | CLOSE) Outcome → What happened? (SUCCESS | FAILURE) |
In an increasingly complex world, such observations of meaning are what we need to regain our understanding.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 |
var cortex = cortex (); var circuit = cortex.circuit (); var probes = circuit.conduit ( new Probes () ); var probe = probes.get ( cortex.name ( "com.acme.endpoint" ) ); probes.source ().subscribe ( subject -> observation -> out.printf ( "%s: %s-%s-%s%n", subject.name (), observation.origin (), observation.operation (), observation.outcome () ) ); probe.connect ( CLIENT, SUCCESS ); probe.send ( CLIENT, SUCCESS ); probe.receive ( CLIENT, FAILURE ); probe.close ( CLIENT, SUCCESS ); // alternatively we can fix the origin and // instead, specify the operation and outcome probe.client ( CONNECT, SUCCESS ); probe.client ( SEND, SUCCESS ); probe.client ( RECEIVE, FAILURE ); probe.client ( CLOSE, SUCCESS ); circuit .queue () .await (); |
The above code, when executed, will print the following to the console:
1 2 3 4 5 6 7 8 9 10 |
com.acme.endpoint: CLIENT-CONNECT-SUCCESS com.acme.endpoint: CLIENT-SEND-SUCCESS com.acme.endpoint: CLIENT-RECEIVE-FAILURE com.acme.endpoint: CLIENT-CLOSE-SUCCESS com.acme.endpoint: CLIENT-CONNECT-SUCCESS com.acme.endpoint: CLIENT-SEND-SUCCESS com.acme.endpoint: CLIENT-RECEIVE-FAILURE com.acme.endpoint: CLIENT-CLOSE-SUCCESS |