What is OTel and why it's important

Observability should start from somewhere. And that somewhere is usually data collection. In days of distant past (give or take a decade), when systems were more simple and mostly monolithic (or at least that's the systems I worked on) you could get away with some logs, add some metrics, server performance monitoring and you were good to go. Now we live in the world of microservices, distributed systems, cloud computing, and other buzzword you can fit in. And now simple logs and metrics are not enough. We need to see more, trace requests throughout the system, see where we're bottlenecking. Logs, metrics, and debugger just doesn't cut it.

And that's where OpenTelemetry (also called OTel) comes in. It is not some concrete tool, but rather a set of specifications and libraries that define how to collect telemetry data (logs, traces, and metrics), how it should be shaped, how it can be exported. And when we have all that data (that is not vendor locked) we can then use other tools to analyse it. I always dreamed to try out honeycomb.io, but my current workplace hsa something else setup, so I'll play with that for now. And there lies the beauty of OpenTelemetry - you can use it with any backend of your choice. The difference is only in how capable your backend is.

How to take advantage of it

For the most common languages and environments there are already libraries and tools available. For some of them (like k8s) it is possible to just enable it and it will start collecting data. For others there might be some additional configuration needed. I'm mostly concerned with PHP and Python, and looking into official docs it seems that I'm covered there. How to use it in practice I'll explore in the next post. From what little I know about it, it seems that the biggest difference from previous tooling is logging, because now it has to be collected by OTel.