What is telemetry?

Telemetry plays a key role in various industries, including healthcare, aerospace, automotive and information technology (IT), giving organizations valuable insights into system performance, user behavior, security and operational efficiency. In industries that rely on physical assets, such as agriculture, utilities and transportation, organizations use telemetry to capture measurements such as temperature, air pressure, motion and light. In healthcare, telemetry systems can track heart rate, blood pressure and oxygen levels.

In both cases, physical instruments and sensors collect real-world data and send it to a central repository. The data is often transmitted using a specialized communication protocol such as Modbus, PROFINET, OPC Unified Architecture or EtherNet/IP for further analysis.

However, physical sensors aren’t designed to capture digital performance indicators such as error rates, memory usage, response times, uptime and latency. Instead, IT teams rely on the instrumentation of devices, often through software-based agents—digital sensors that are programmed to autonomously monitor and collect relevant system data. This data is often structured as metrics, events, logs and traces (MELT), with each capturing a different view into system behavior, operational workflows and performance timelines.

The lines between physical and digital telemetry systems are beginning to blur, especially as enterprises increasingly adopt digital transformation strategies, which aim to infuse digital technology into all areas of a business.

For example, a traditionally physical industry like manufacturing might use sensors to capture energy consumption, quality control and environmental conditions. At the same time, it might rely on software agents for advanced asset tracking, preventive maintenance and production flow monitoring. For that reason, this article focuses primarily on IT telemetry and its expanding role in modern enterprise environments.

At its core, IT telemetry involves five key steps:

1. Collecting metrics, events, logs and traces from disparate remote sources with sensors or software agents
   
   
2. Transmitting that data to a central repository or router through wifi, satellite, radio or another communication medium
   
   
3. Processing and organizing the incoming data so that it can be easily queried
   
   
4. Maintaining the data with a storage solution such as a time-series database, a data warehouse or a data lake
   
   
5. Analyzing, interpreting and visualizing the data to make better-informed business decisions, often with the help of an observability platform

Effective telemetry strategies help organizations achieve full-stack observability, or the ability to understand the internal state of a technology stack from end-to-end based on its external outputs.

Telemetry is also a major component of Internet of Things (IoT), a framework that equips devices with advanced sensors, software and network connectivity, enabling them to communicate and exchange data across the system.

Telemetry systems vary by industry and system complexity. Traditional platforms use recording devices, historically called telemeters, to collect data at or near a piece of equipment. This information is processed, modified and sometimes converted from analog to digital, in a process called signal conditioning.

Next, a multiplexer combines multiple data streams into a composite signal, which helps the data travel more efficiently. This combined signal is then transmitted to a remote receiving station through radio, satellite or another form of communication. Finally, a demultiplexer parses the signals and breaks them into disparate strands to prepare them for analysis.

Telemetry works differently in modern IT environments. Instead of relying on physical sensors, IT-focused systems use software agents—lightweight programs that run alongside services and applications to capture relevant metrics. In Kubernetes environments, these agents often operate in a separate container within the same cluster as the services they monitor. Other configurations might use software development kits (SDKs) to embed agents within applications themselves—or use custom APIs to facilitate data transfers.

After collection, the data is carried through a telemetry pipeline, which can standardize data, filter out noise, add metadata (such as environment and geolocation tags) and mask sensitive information to maintain compliance. This refined data is then standardized with a format such as JSON or OpenTelemetry Protocol (OTLP).

Next, it’s intelligently routed to one or more backends (the server-side components of a software system—servers, databases and application logic, for example) through gRPC, HTTP or another transport protocol. The backend is responsible for storing this data, analyzing and interpreting it and presenting it in the form of dashboards, alerts, recommendations and more.

A single telemetry system might be used to manage the entire workflow, from collection through analysis. Sometimes though, especially in modern multicloud and hybrid environments, organizations might use multiple specialized telemetry systems to manage different parts of the observability pipeline.

In IT, the most common types of telemetry are metrics, events, logs and traces, often referred to collectively as “MELT” data. Organizations can use observability platforms to combine and analyze these metrics, forming a complete picture of platform security, user behavior, system efficiency and more.

Metrics are numerical measurements that are indicative of system health or performance. Examples include request rates, network throughput, application response times, user conversion rates and CPU usage.

Events are distinct occurrences that take place within the system. They often include timestamps that show when an event began and when it ended. Examples include alert notifications, user login attempts, service interruptions, payment failures and configuration changes.

Logs provide a continuous record and chronology of system behavior, unlike events, which flag only particular incidents. Examples include restarts, database queries, file access histories and code execution steps. Logs are often used to troubleshoot and debug errors, helping IT teams pinpoint the precise moment a failure occurred.

Traces reflect the end-to-end flow of a specific user request or transaction through a distributed or microservice environment, with timestamps for each step. Examples include API and HTTP calls, database queries and e-commerce checkouts. Traces can identify bottlenecks and provide insights into the overall user experience.

While MELT showcases the breadth of telemetry data available to enterprises, there are additional data types that fall outside of this framework but still play a critical role in observability. The boundaries between telemetry types are not always clear-cut, and there can be crossover. For example, latency can be considered both a metric and a network telemetry datapoint. Other types of telemetry data include: 

• Location telemetry uses sensors or GPS receivers to track the geographical location of a person or object. Applications include transportation fleet management, emergency services, wildlife tracking and worker safety.
  
  
• Network telemtry provides real-time insights into network traffic, security and performance by tracking bandwidth usage, packet loss rates, API performance and simple network managment protocol (SNMP) data (information related to modems, routers, servers and other connected devices).
  
  
• Security telemetry identifies suspicious behaviors and vulnerabilities by examining authentication logs, firewall logs, DNS queries, intrusion detection alerts and endpoint detection and response (EDR) data.
  
  
• User telemetry tracks application usage patterns, error logs, session durations, search queries and other types of user behavior. This data is used to optimize applications and services, understand client trends and maintain a secure network.
  
  
• Profiling telemetry shows how software and applications use CPU, memory and other computer resources over time. It offers fine-grained performance data that can help developers understand the source of a slowdown as well as which parts of the codebase are most heavily used.
  
  
• Cloud telemetry collects performance, cost tracking and usage data of cloud services. This data might include storage activity, configuration changes, identity and access events and routing decisions.
  
  
• AI telemetry can track model performance during both training and production. Key metrics include model drift (tracking how a machine learning model loses coherence and accuracy over time), confidence scores (determining how confident the model is in its predictions) and inference latency (the time it takes for the model to respond to a query). These metrics can help developers improve model reliability, fairness and performance.

Telemetry is the process of gathering and transmitting multiple types of data from distributed systems and components. It’s the foundation of an organization’s visibility capabilities, offering insight into how each component behaves and performs. Enterprises ultimately rely on telemetry to power their monitoring and observability systems.

Monitoring refers to how organizations make use of telemetry data they’ve collected. For example, a telemetry monitoring system might use dashboards to help DevOps teams visualize system performance. Alert automations, meanwhile, can deliver notifications each time a notable event, such as a network outage or a data breach, takes place.

Observability involves interpreting operational data and understanding how different data streams correlate with system health and performance. Observability not only analyzes current data but also spots larger trends, using them to inform and optimize enterprise decision-making and resource usage. Modern observability platforms often include built-in telemetry and monitoring functions. Observability also plays a key role in supporting emerging technologies, including agentic AI and generative AI platforms.

An open source framework called OpenTelemetry (OTel) is among the most popular telemetry platforms, valued for its flexibility (its modular design fosters customization), affordability (its core components are available at no cost) and compatibility (it’s compatible with multiple vendors and programming languages). OTel does not handle telemetry storage or visualization. Instead, it provides a standardized set of SDKs, APIs and other tools geared toward data collection and transmission.

Nearly half of IT organizations use OTel, while an additional 25% plan to implement the framework in the future, according to a 2025 report from AI firm Elastic. Organizations with mature observability systems are more likely to use OTel, compared to companies with less developed observability workflows. IBM Instana, Datadog, Grafana, New Relic, Dynatrace and Splunk each feature robust OTel support.

An alternative open source framework called Prometheus shares some similarities with OTel. The Cloud Native Computing Foundation (CNCF), itself a subsidiary of the nonprofit Linux Foundation, hosts both solutions. Unlike OTel, Prometheus has some data storage and data visualization capabilities. But it is slightly narrower in scope: While OTel can collect different kinds of telemetry data, Prometheus works exclusively with metrics.

Telemetry normalization is the process of converting metrics into a standardized format so analytics tools can store, read and interpret them. There are two major approaches:

In this data processing approach, all data must match a pre-defined format before it can be stored and retrieved. While schema-on-write is highly reliable, it can be difficult to implement in modern IT architectures, which involve multiple systems, each with distinct formats and filing processes.

Schema-on-write is commonly used in centralized data repositories called data warehouses. These storage solutions can maintain vast amounts of telemetry data, but only if that data is structured and organized in a pre-defined format. Data warehouses can be expensive to scale and maintain but are ideal for business intelligence, data analytics and other workflows where consistency and reliability are top priorities.

This approach collects data in its original format and converts it only when a user retrieves it. While more operationally complex, schema-on-read can handle data across multiple formats, making it more flexible than schema-on-write.

Schema-on-read is common in data lakes, which are like data warehouses, but can store and manage both semi-structured and raw, unstructured data alongside structured data. Data lakes are valued for their cost-efficiency and agility, making them especially ideal for machine learning-powered analytics tools. But without solid governance, they can be difficult to manage, leading to unverified or inconsistent data.

An emerging alternative called data lakehouse aims to combine the best elements of data lakes and data warehouses. The framework supports schema-on-read for unstructured data, while at the same time enabling schema-on-write for structured data. This hybrid approach helps organizations maintain consistency and accuracy while benefiting from the flexibility and agility of data lakes.

Telemetry data can be difficult to gather, maintain and store, especially in modern hybrid and multicloud settings. Common challenges include:

Telemetry empowers organizations to transform data into actionable insights that can be used to improve performance, workflow efficiency, budgeting, customer experience and more.