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.

Grafana Beyla, an open source eBPF auto-instrumentation tool, has been able to produce OpenTelemetry trace spans since we introduced the project. However, the traces produced by the initial versions of Grafana Beyla were single span OpenTelemetry traces, which means the trace context information was limited to a single service view. Beyla was able to ingest TraceID information passed to the instrumented service, but was unable to propagate it upstream to other services.

The.NET framework is a powerful platform for creating various applications, from web-based services to comprehensive enterprise solutions. Its extensive libraries, support for multiple programming languages, and powerful development tools enable the creation of high-performance, scalable applications that can be customized to suit various needs. This framework continuously evolves to meet the demands of modern software development with a complete ecosystem of add-ons created by an enthusiastic community.

Continuing our series on tracing with OpenTelemetry in AWS Kinesis, we now explore a refined approach to overcome the challenges faced in our initial attempt with the PartitionKey parameter.

In the first article of our series, we explored the importance of trace headers and the complexities involved in their propagation. Now, we shift from theory to practice. This second installment will take you through a hands-on baseline scenario and our initial strategy of propagating the OpenTelemetry trace context in AWS Kinesis by using the PartitionKey parameter.

Welcome to our series on navigating the complexities of trace header propagation with OpenTelemetry in AWS Kinesis. In this 3-part exploration, we'll dive into the critical role of trace headers in distributed systems, discuss the unique challenges presented by AWS Kinesis, and explore innovative solutions that keep your data tracking robust and consistent.