Naming Hierarchy

Naming as the saying goes in programming is one of the more, if not the most, arduous task to get right for everyone concerned. It is so crucial for effective communication and to the efficient organization of referenced structures, which is why Name is a first-class citizen in the OpenSignals interface. The Name interface serves two needs: to define service structures and access environment values.

In OpenSignals, a name is effectively a namespace – a sequence of name parts or string-valued nodes in a tree. The string “banking.teller” when converted into a name becomes two names. The first name has a value of “banking” with an empty prefix. The second name, the actual result for the transformation, is a name with a prefix property referring to the first name and a string value of “teller”. If we add both “deposit” and “withdraw” to the teller name reference, we end up with two additional name references, both having a prefix referencing teller. As a Name is treated much like a constant the string value for a part should be viewed likewise.

It is via this hierarchical naming scheme that OpenSignals supports the modeling of aggregated services. If a service is created for both the deposit and withdraw name references, then there is an implicit grouping of these services under the service teller and in turn banking. This does not preclude other forms of grouping such as at the context level or within management tooling via boundaries.

In OpenSignals, a service is an identifiable activity of interest that can be decomposed into finer levels of activity within a service and across other service compositions. Developers writing instrumentation need only worry about the logical service names; the underlying OpenSignals provider is required to capture the environment, which itself can be nested, and expose via the context.

It is important to note that names are context-independent. The same name can be used across different contexts within the same process or across processes. The context and its named property values map capture some aspect of the environment, the more physical or deployment components of the model, and the service name the logical and far more permanent aspects.

Comparing the OpenSignals approach with popular metric systems that use both a name and a set (or bag) of labels (or tags), the context is where infrastructure metadata resides cleanly separated from the service naming and the derived service level model. The context is not entirely lost, it is just not always relevant and useful to be promoted so. It is best to see the context and the state therein as transient, and the service naming as semi-permanent and the basis for the ongoing operational management of systems.

The simplicity of the OpenSignals naming scheme and the clean separation of both context and environment from a logical service level model means that system engineers and developers do not get bogged down in the component categorization and typing that many of the observability and application performance monitoring solutions force unnecessarily on them – component types such as environment, cluster, region, domain, host, container, pod, service, entrypoint, url, port, and so on. The model is not (always) the map.