Operations | Monitoring | ITSM | DevOps | Cloud

Everything comes at a cost — and observability is no exception. When we add metrics, logging, or distributed tracing to our applications, it helps us understand what’s going on with performance and key UX metrics like success rate and latency. But what’s the cost? I’m not talking about the price of observability tools here, I mean the instrumentation overhead.

Nextjs is a production-ready React framework for building single-page web applications. It enables you to build fast and user-friendly static websites, as well as web applications using Reactjs. Using OpenTelemetry Nextjs libraries, you can set up end-to-end tracing for your Nextjs applications. Nextjs has its own monitoring feature, but it is only limited to measuring the metrics like core web vitals and real-time analytics of the application.

Sentry’s auto-instrumentation, using BrowserTracing, is convenient. You can get interesting insights about your frontend application out-of-the-box, such as whether slow and failing API calls are hurting your user experience (summarized in Network Requests), or how your website stacks up against industry standards for performance (summarized in Web Vitals).

OpenTelemetry is emerging as the common framework for collecting observability data, and for good reason. It’s vendor-neutral, open source, and designed to collect traces, metrics, and logs in a consistent way. But while most of the buzz is around tracing and metrics, let’s not forget: logs are still the backbone of investigation and response. That’s why Graylog now supports native collection of OpenTelemetry data over gRPC.

In the fast-paced world of CI/CD, understanding the performance and behaviour of your pipelines is crucial. GitHub Actions has become a popular choice for automating builds and deployments, but anyone who's debugged a flaky workflow or long-running job knows how challenging it can be to get visibility into what's happening under the hood. We usually rely on build logs, timing data, or guesswork when something goes wrong.

Pulling observability data together is rarely clean. Metrics come from everywhere, formats vary, and making sense of it takes some work. OpenTelemetry Collector and Prometheus fit perfectly here. The Collector handles ingestion and processing from different sources, while Prometheus stores and queries the data. Simple, effective, and no vendor lock-in. In this blog, we cover how to integrate the Collector with Prometheus, common pitfalls, and ways to control costs.

In one of our previous blogs, we discussed distributed tracing in depth. We examined why distributed tracing is critical and its components - spans and trace context. You can check the complete guide here: What is Distributed Tracing and How to Implement it with Open Source? Here, we'll look at some of the best distributed tracing tools. We'll see what each of them offers so that you can choose the right tool for your monitoring and observability requirements.

Observability is essential for maintaining and scaling modern applications. With.NET 8, Microsoft has enhanced support for observability using OpenTelemetry. In this post, we explore how to monitor.NET 8 applications logs with SigNoz, an open-source observability platform, using the OpenTelemetry Protocol (OTLP) exporter.

Databases are a crucial part of modern systems, which means database observability is incredibly important, too. However, gathering information on them can be complex, variable, and tricky to instrument in a consistent way. OpenTelemetry is helping to change that, and one of the most important aspects in making it work is a set of shared rules called semantic conventions.

Join the live stream at 11 am ET, here. Platform teams tend to start with just one, or in some cases a handful of OpenTelemetry (OTel) Collectors usually running in gateway mode. They then embrace the benefit of a vendor-neutral, standardized, telemetry collector for unified logs, metrics, and traces.