Goutham Veeramachaneni, a product manager at Grafana Labs, and Carrie Edwards, a senior software engineer at Grafana Labs, are both contributors to the Prometheus open source project. This post, which they wrote together, was originally published on the Prometheus.io blog in March 2024. The OpenTelemetry project is an observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs.

With applications becoming increasingly distributed and complex, gaining insights into their behavior and performance is essential for maintaining reliability and delivering exceptional user experiences. OpenTelemetry has emerged as a powerful framework for instrumenting applications to collect, process, and export telemetry data.

Observability goes beyond monitoring; it's about truly understanding your system. To achieve this comprehensive view, practitioners need a unified observability solution that natively combines insights from metrics, logs, traces, and crucially, continuous profiling. While metrics, logs, and traces offer valuable insights, they can't answer the all-important "why." Continuous profiling signals act as a magnifying glass, providing granular code visibility into the system's hidden complexities.

NestJS is a popular and powerful open-source framework for building scalable and maintainable server-side applications with Node.js. It was developed by Kamil Myśliwiec and first released in 2017. NestJS is inspired by Angular, which brings familiarity and a structured approach to building back-end applications.

Your log records may be missing a key ingredient that unlocks the world of observability for your applications, infrastructure and services. If you're building a new application or enhancing an existing one, consider adopting the OpenTelemetry Logs Data Model's Log and Event Record Definition. Adopting this definition enriches your logs by adding additional data, making it easier to use them to correlate them with metrics and traces, in addition to XYZ.

The topic of continuous profiling has been an ongoing discussion in the observability world for some time. I said back in 2021 that profiling was set to be the next major telemetry signal in observability, and in fact, since then there’s been growing interest in profiles. Startups and large observability vendors have gotten into this domain. A significant recent step was when the OpenTelemetry project decided to add profiles to its core signals and formalized the open unified specification for that.

The Uptrace team is pleased to present the latest v1.7 release, which introduces dark mode, revamped navigation, dashboards list, system tracing metrics, and much more.

Every day, we hear about new vulnerabilities or exploits that underline the importance of application security in today’s connected world. Such incidents put sensitive user information at risk and threaten applications’ infrastructure. Securing applications is therefore crucial not only from a technical standpoint but also to maintain user trust and ensure service reliability. The challenge lies in identifying and mitigating potential security threats before they can be exploited.

Telemetry data is growing exponentially, but the business value isn’t increasing at a similar pace. Getting the right telemetry data is hard, so I recently had a conversation with Matt Aslett, Director of Research at Ventana Research, now a part of ISG, about five myths and realities in telemetry data handling.

Turning logs into metrics isn’t a new concept. A version of this functionality is implemented in most agents, visualization tools, and backends. It’s everywhere because converting logs to metrics has many practical applications and is one of the fundamental mechanisms for controlling log volume in a telemetry pipeline. In this post, I’ll briefly overview log-based metrics, explain why they matter, and provide examples of how to build them using OpenTelemetry and BindPlane OP.