OMLET: (O)pen (M)etrics (L)ogs (E)vents (T)races

I've been in the Observability world for over 12 years now, witnessing the comforts (and complexities) that Cloud architecture provided. Recently, I had a random thought about the space:

If I were to start a high school course around the topic, what would it look like..?

To me, it fundamentally speaks to the importance of understanding proper "feedback from a system" to accurately answer questions like:

• Why is it deviating from a baseline?

• If I were to make X or Y change, what data points would be forecasted to change alongside that?

• What is the system's "homeostasis"?

• How can I easily gather system output data that is best reflective of internal states?

If you strip away all the vernacular that we use in the industry, it becomes simply about being able to "ask" something about the system. A stable and open standard is crucial to that succeeding. Furthermore, fostering an environment that facilitates an enticing entry for future generations is even more significant.

OpenTelemetry (OTeL)

I think everyone in the Observability space has explored OTeL from the perspective of a practitioner, vendor, architect, engineer, IT/OPs, analyst, the list goes on. Opinions have varied from it being a liberator, misguided initiative, "not ready yet", indifference, or even adversarial.

With all that said, if we consider a student's (even beginner) approach to comfortably approaching this subject, we can all agree that humans hate context shifting. So whatever the state of the standard or what it looks like, the fact that the space is relentlessly heading towards it is good.

Every individual within the space can claim the cognitive burden induced by obscure data structures, unlinked data, and arbitrary config patterns. In fact, vendors have the most to benefit. Why is this? Sales cycles, onboarding and continuous engagement.

Ask every account person and customer in Observability, the main toil is re-education and re-absorption of concepts that should be quite fluid. Very often, the engineering and product teams focus on patterns that allow them to iterate quickly and unfortunately emerge as hyper-opinionated. This comes at a direct cost to the mental bandwidth of the account teams responsible for promoting to and maintaining the users. Not only are they consistently playing catch-up to the core product/eng teams, they are hearing the brunt of the complaints from customers.

OMLET

OMLET was started because we wanted to be part of the OTeL journey, but especially because promotion and evangelism of an open standard in this space is such a need. We plan to focus on the pipeline problem that restricts observability users from kickstarting their OTeL journey, or keeping it alive. Beyond the tech, standardization is very much an organizational and cultural need.

"You can't make an omelette without breaking eggs"