Operations | Monitoring | ITSM | DevOps | Cloud

You have nested JSON in your logs. When you query body.event.type = "user_action", it fails. Here's why and how to fix it.

NestJS applications require comprehensive monitoring to ensure optimal performance and rapid issue resolution. As your application grows—spanning multiple services, databases, and external APIs—understanding what's happening under the hood becomes critical. That's where OpenTelemetry comes in. OpenTelemetry provides vendor-agnostic observability for your NestJS applications through distributed tracing, metrics, and logs.

We optimized log processing pipeline by moving from sequential to concurrent processing at the entry level, achieving 30% higher throughput and better resource utilization without increasing infrastructure costs. When customers start sending millions of logs per minute, you quickly discover whether your processing pipeline can actually scale with vertical scaling.

Recently, I read a blog titled “It’s The End Of Observability As We Know It (And I Feel Fine)”, which discussed MCP servers in observability and how these systems would potentially be the “end of observability”. As someone who has spun up an MCP server for an observability backend and as someone who has been in the space for a while, I certainly do not think so.

Choosing the right observability platform is a critical decision. But how you deploy it is just as important. The right deployment strategy can accelerate your team, simplify operations, and ensure you meet compliance and security requirements. The wrong one can lead to operational headaches and slow you down. At SigNoz, we believe in flexibility. There is no single "best" way to deploy an observability platform; there's only the way that's best for you.

Kubernetes provides a wealth of telemetry data from container metrics and application traces to cluster events and logs. OpenTelemetry offers a vendor-neutral, end-to-end solution for collecting and exporting this telemetry in a standardised format.

Datadog and Jaeger are both leading tools in the observability space, but they represent two fundamentally different philosophies. Datadog is a commercial, all-in-one SaaS platform that unifies metrics, traces, and logs. Jaeger is a popular, open-source project focused specifically on distributed tracing. Choosing between them isn't just a technical decision; it's about balancing the convenience of a fully managed, integrated platform against the power and control of a self-hosted, specialized tool.

We cut log-query scanning from ~100% of data blocks to < 1% by reorganizing how logs are stored in ClickHouse. Instead of relying on bloom-filter skip indexes, they generate a deterministic “resource fingerprint” (hash of cluster + namespace + pod, etc.) for every log source and sort the table by this fingerprint in the primary-key ORDER BY clause. This packs logs from the same pod/service contiguously, letting ClickHouse’s sparse primary-key index skip irrelevant blocks.

The OpenTelemetry Collector is a stand-alone service that acts as a powerful, vendor-neutral pipeline for your telemetry data. It can receive, process, and export logs, metrics, and traces, giving you full control over your observability data before it reaches a backend. This guide will provide a comprehensive overview of the OpenTelemetry Collector, its architecture, deployment patterns, and how to configure it for production use.

The rising costs and complexities of monitoring cloud infrastructure are pushing many organizations to explore alternatives to Datadog. With monthly bills sometimes reaching thousands of dollars and feature sets that can be overwhelming, teams are looking for practical, cost-effective solutions that better fit their needs.