Below is the list of blog posts with the “telemetry data pipeline” tag.

OpenTelemetry has become the de facto standard for telemetry data. Nearly 50% of surveyed cloud-native end-user companies have adopted it, and the project ranks as the second-highest-velocity initiative in the CNCF, behind only Kubernetes. The direction is clear: if your infrastructure doesn’t speak OpenTelemetry, it will increasingly be left out of the observability conversation. But adopting OpenTelemetry across an entire infrastructure is a different problem than adopting it in a greenfield application.

Collecting, processing, and forwarding logs and metrics at scale. OpenTelemetry provides a common instrumentation model that makes it easier to collect telemetry data across distributed systems, and many modern applications are adopting it as a standard for generating logs and metrics. However, in practice, you still need to collect, process, and shape the data before it becomes useful. You cannot simply forward raw telemetry data downstream without risking that your observability platform becomes expensive storage instead of a means of maintaining visibility into your environment.

A practical approach to converting existing logs into modern observability. OpenTelemetry promises a vendor-neutral standard for observability, consistent telemetry, and the flexibility to change backends without rewriting everything. In practice, however, OpenTelemetry adoption often runs into a familiar obstacle: reality. Here’s a common scenario. You’re eager to improve observability, but your environment includes a mix of legacy applications, network devices, and third-party systems. Many of these were never designed for modern instrumentation, and changing them is risky, expensive, or simply not an option.

Today, most enterprises use a security log analytics solution or SIEM (Security Information & Event Management), but analytics are only as good as the data fed into your solution. If you’re missing data sources or are failing to extract full value from the data, you won’t see the big picture. This is an issue new customers commonly mention to NXLog. That’s why one of our key goals is to provide a solid data collection layer that ensures all relevant data is collected and properly fed into the SIEM.

With an ever-expanding choice of technologies on the market, navigating the range of open-source observability tools can be a challenge. Which is why, when it comes to managing complex multicloud environments and their services, standardization is crucial. Here’s where OpenTelemetry (OTel) can play a key role. Developed through the merger of OpenCensus and OpenTracing, OpenTelemetry has become the new standard for open-source telemetry. Discover what OTel is, the types of telemetry data it encompasses, its potential benefits, and how NXLog can support your OpenTelemetry ecosystem.

Back in the day, Gordon Moore made relatively accurate observations and projections about the exponential growth of transistors on semiconductors. It still amazes me, yet very few predicted the incredible growth of system interconnectedness and the vast amount of data it generates. It is estimated that 90% of all data was created in the last two years. Given that everything is connected, the need for telemetry is growing at an unprecedented rate, and so is the need to efficiently channel and manage telemetry data.