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

As organizations collect more telemetry data, their pipelines grow in complexity and scale. Telemetry pipelines are dynamic, continually adjusted to improve data quality, reduce costs, and meet evolving observability requirements. At this scale, even small configuration changes can significantly affect how much data moves through your pipeline. Without clear visibility, you rely on assumptions. Did the new filtering rule actually reduce the amount of data you’re sending to the SIEM?

Telemetry data is the stream of measurements that instrumented devices, applications, and services continuously emit to a central system so engineers can monitor behavior, diagnose problems, and make informed decisions in real time and over the long term. In this article, we’ll look at what telemetry data means in practice for modern software, networks, and cloud platforms: how it’s produced, what kinds of signals it carries (logs, metrics, traces, and more), and why it has become essential for observability, performance, and security at scale.

Most discussions about OpenTelemetry pipelines focus on getting data from point A to point B. Collect telemetry, maybe convert the format, forward it to a backend. That’s the minimum viable pipeline, and it’s where most tooling stops. But a pipeline that only moves data is a pipe, not a processing layer. The telemetry arriving at your observability platform or SIEM is only as useful as the context it carries. A raw log entry saying "connection from 198.

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.