This is the second post in a series of posts alphabetically listing and defining important Observability terms. If you have just jumped in then please consider starting from the beginning to get a better understanding of my selection.
Scaling the use of Observability within a large enterprise is not just about moving data around, from one machine to another, and then being able to query and render it from within a monitoring console. Serious consideration needs to be given to how best to structure, group, link, and categorize data in order to make derived information far more relevant to a particular team within an organization and contextual to the task at hand. Don’t leave users to be driven by data. It is hugely inefficient, especially when operating under extreme stress and time constraints. Teams should be able to limit and frame their initial investigation to systems, services, groups, and hierarchies under their responsibility before branching off beyond their custom-defined boundaries of influence and control.
Alternatives: Edge, Egress, Event, Endpoint, Error, Extensibility, Entity, Engineering
Observability solutions need to be able to collect, communicate, and consume information from many different and diverse sensory (data) sources and then fuse it all to facilitate the construction of valid and useful mental representations of objects of concern within an environment. During this integration, much like how the brain functions, Observability solutions need to decide how best to integrate and segregate structural and behavioral groupings from feeds and if that was not already complicated enough address temporal inconsistencies by employing various reconciliation techniques to insulate, to some degree, the measurement gap and opaque windows of state transitioning that exist within multiple spaces and time. Now is a necessary (weak) illusion.
Alternatives: Feedback, Feeds, Functions, Fault, Failure, Fog
With increasing complexity and more rapid rates of change, there has never been a more urgent need for intelligent assistive guidance. Any Observability initiative is very likely to fail, operational speaking, if users are left alone to scan through reams of logs, events, traces, and metrics. Tooling must intelligently and contextually direct user attention to events of significance while shortcutting the shifting focus of attention, up and down stack layers, and across systems and services. Any interaction with information must reflect and optimize for the task and situation.
Alternatives: Gauge, Group, Gravity
Never lose sight of the big picture; that is keeping things healthy. Health is a state, not a signal. That said, a well-defined, limited set of higher-order signals can allow us to more easily infer the state of a system, service, component, or endpoint. Being able to assess the health at any level of aggregation, framing, or contextual bounding is paramount if complexity is to be contained and change steered (to some degree). It needs to be extremely easy to look back to the past, relate it to the present, and project it into the near future. This cannot be found in starring over traces, metrics, logs, and events. Quality over quantity. Qualitative over Quantitative.
Alternatives: Hysteresis, Histogram, Hardware, Humane