The inevitable acceptance of this relabel for all things monitoring.

There is a new kind of monitoring solution in town, and it goes by the name Observability. Goodbye, Monitoring! Hello, Monitoring and Observability!

The Alter Ego Differentiates

At this point, there is very little chance in trying to stop Observability from becoming something it is apparently not — a useful measurement scale of various monitoring techniques. There are just far too many egos, both individual and corporate, already involved in pushing along this movement that we even have egos writing posts that in effect claim they were the first ego to type the word Observability alongside their other meandering writings on Monitoring. Observability has already penetrated the tech conference circuit where no one in their right mind is going to bravely omit this new word from the title of the next Monitoring talk — a rehash of last years one? Everyone loves being part of change when it entails nothing beyond words.

The software industry is well known for having problems with naming things.

I spent many years trying to convince the others that there was indeed a clear distinction between application monitoring and application management. One mostly perception-oriented and the other action-oriented. Many of those who only offered or performed monitoring added management because it was related and supportive to this function and because others did not make such distinctions. With Observability it’s impossible. How will Controllability fair?

Much Ado About Nothing

In control theory,  observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs — Wikipedia.

Observability, as it has been redefined, offers practically no value. You can’t say existing products and services providing monitoring capabilities are not already offering observability capabilities. We’ve strayed far from the source.

Observability was a measure, now it is a brand, or badge, for those wishing to stand apart in the crowd while selling a sameness — we’re being blindsided.

It is open to so much misinterpretation and misunderstanding that if you say Observability enough times, you instantly become an Observability Engineer. I don’t think anyone knows what that means or would entail. Is it an engineer who instruments systems or one who passively observes the data collected from the measurements performed by such instrumentation? It does not seem to matter that in all likelihood there is no Control whatsoever involved.

Call out some old post with the word “Observability” included, and you’re a thought leader for something of very little substance outside echo chambers.

Observability is not the new Monitoring. No, this is the new word that will be juxtaposed with “monitoring” in every new monitoring vendor press release.

The State Of Play

We now have a measurement scale of some inferred state as a new class of monitoring product. No one knows precisely what state that might be. It could be something as wildly amiss from the original definition such as a service request queue size or some other “health” labeled metric. The state can be anything and everything, and yet be of no value to systems control.

Even when used as a scale how does one say this is high observability and this low. Observability makes little sense outside of the context of Controllability.

Previously I considered “understanding” as the single most important goal in monitoring. And maybe I still do to some degree, but with the increasing system complexity and acceleration of change, this seems ever more fruitless. Probably the best we can hope for going forward is in steering systems that manage other systems and then for these steered systems to see and sense other systems and self-regulate themselves accordingly. See less, Steer more.

Many champions of Observability equate it with log (event) monitoring which primarily captures the transient state of in-flight requests, not the system state per se. Log events are the results of code execution they are not the execution itself. For many applications and systems, the code lines that log gets the least amount of care and attention — usually added in real haste.

Others see Observability as targeting the needs of developers but yet it is not profiling, code debugging or diagnostic state capture — no it is debugging of data of logged events. Oh, the other big problem the software industry has is with nonessential layers of indirection that mask rather than expose reality.

The representations of execution grouped under the Observability banner are far removed from the nature of internal state and code behavior. The ultimate Observability tooling would be one that mirrors and simulates the very nature of software execution behavior. Like Simz and Stenos. That makes me the King of Observability but yet I still consider both as Monitoring — online and offline. It doesn’t make sense to see these entirely separate. Which is which?

Cognizant Machines

A while back I created a set of slide detailing how I expected application performance monitoring and management, and to some extent software development, to evolve and embed cognitive capabilities in coming years.

https://speakerdeck.com/autoletics

The above was not a vision statement per se, as I had already built the technology between 2010 and 2013. It was more so a chart depicting the most likely adoption progression. At the time I never imagined that Observability, a supportive aspect of self-adaptation would get so much exposure and attention — leaving aside the misconstrued version we have today.

At times it seems for many in the software industry, the next small incremental step is all that is seen, understood, and adopted, without much thought given to the cost of each transition step. Why not instead leapfrog?