In the classic definition, Observability is something one step beyond monitoring; it’s how easy our system is to understand with the architecture and monitoring we have. The problem is a familiar one: we have monitoring tools but they’re not answering our question. This article shows how a Python developer can go from having traces but not answers, to fully understanding the root cause of a latency issue.

OpenTelemetry is a Cloud Native Computing Foundation(CNCF) project aimed at standardizing the way we instrument applications for generating telemetry data(logs, metrics, and traces). However, OpenTelemetry does not provide storage and visualization for the collected telemetry data. For visualizing OpenTelemetry data, you need an OpenTelemetry UI. The data collected by OpenTelemetry can be sent to a backend of your choice, which can then be visualized.

If you're looking for an open-source alternative to Dynatrace, then you're at the right place. SigNoz is a perfect open-source alternative to Dynatrace. SigNoz provides a unified UI for metrics, traces and logs with advanced tagging and filtering capabilities.

On a recent thread on the CNCF Slack’s OTel Collector channel, a user asked a question that shone a light on a topic I don't think has been effectively discussed elsewhere.

OpenTelemetry can be used for generating and collecting telemetry signals like logs, metrics, and traces. The advantage of using OpenTelemetry for observability is that it is open-source and frees you from vendor lock-in. You can use OpenTelemetry for multiple use cases

In a recent reddit thread, I got into a conversation about justifying the cost of observability. It got to a really basic question about running a tech company: how do you know that any cost is justified? While a small number of expenses have clear and direct business values, a bunch of other costs, I would even say most costs, just aren’t that clear cut.

I’d like to write a bit about how Observability costs are significant, how these costs tend to be justified, and how precise amount a company spends on anything tends to be more subjective than you’d think. This article is not about how to reduce or control these costs, but rather how the costs are justified.

OpenTelemetry can be used to trace Rust applications for performance issues and bugs. OpenTelemetry is an open-source project under the Cloud Native Computing Foundation (CNCF) that aims to standardize the generation and collection of telemetry data. Telemetry data includes logs, metrics, and traces.

Are you looking for an OpenTelemetry alternative? Then you've come to the right place. There are no good alternatives to OpenTelemetry if your use case involves generating different types of telemetry signals like logs, metrics, and traces and their collection. In certain use cases, like monitoring only metrics or time-series data, you can use a tool like Prometheus.

OpenTelemetry is a Cloud Native Computing Foundation(CNCF) incubating project aimed at standardizing the way we instrument applications for generating telemetry data(logs, metrics, and traces). However, OpenTelemetry does not provide storage and visualization for the collected telemetry data. And that’s where an OpenTelemetry backend is needed.

Single pane of glass monitoring is a term used to denote monitoring applications with a single tool that provides a comprehensive set of dashboards for the entire software system of an organization. Managing multiple monitoring tools for different aspects of the IT system becomes too cumbersome. And that’s how the concept of a single pane of glass monitoring evolved.