Building a Real-Time Network Telemetry System:
gNMI Architecture and TIG Stack Implementation

As data centers, campus networks, service provider networks, and AI infrastructure continue to scale, the number of network devices, interface speeds, and service complexity continue to increase. Traditional network monitoring approaches based on SNMP polling, the CLI, and Syslog are increasingly constrained by long data collection intervals, insufficient real-time visibility, limited data granularity, and difficulties in automated processing.

Network Telemetry uses structured data models, efficient transport protocols, and subscription-based data collection mechanisms to enable network devices to continuously provide operational state and performance data to data collection systems. This provides a more real-time and granular data foundation for network monitoring, fault localization, performance analysis, and automated operations and maintenance (O&M).

This white paper introduces the fundamental concepts, technical architecture, and operating principles of Network Telemetry and compares it with traditional network management technologies such as SNMP. On this basis, it demonstrates a complete Telemetry data collection and visualization system built with gNMI and the TIG stack (Telegraf, InfluxDB, and Grafana), illustrating how Telemetry can be applied in production network environments.

Network Telemetry is a technology framework for network observability that collects measurements and other data from remote locations and transmits the data to receiving systems for monitoring. AsterNOS switches act as such remote devices and can transmit operational state, configuration information, and event information to remote data collectors. Compared with traditional management methods that rely primarily on manual queries or periodic polling, Telemetry emphasizes continuous, structured data acquisition, providing the data foundation for subsequent real-time analysis and automated processing.

With this continuous data collection capability, Telemetry is not limited to device-state monitoring. It can also support use cases such as business intelligence for network, application, and user monitoring, network planning, security analytics, billing, logging, and traffic engineering.

As networks continue to scale, continuous real-time visibility is required to improve network manageability. Traditional SNMP-based network management typically uses periodic polling, in which the Network Management System (NMS) actively queries network devices. The basic interaction is as follows:

NMS → SNMP GET → Network Device → SNMP Response

As network scale and interface speeds increase, this periodic polling model exposes several limitations. For example, if the NMS reads interface counters every 60 seconds, short-lived traffic bursts, queue congestion, or state changes occurring between two sampling points may not be observed in time. Reducing the polling interval, however, can generate massive amounts of data and impose significant processing overhead as the network grows.

Telemetry provides an alternative data acquisition mechanism that streams device data to a target receiver. Through push and subscription mechanisms, network devices can continuously provide operational data according to predefined conditions, enabling monitoring statistics to be collected at a higher frequency. The Collector no longer needs to repeatedly send query requests for each metric; instead, it establishes a subscription. Depending on the subscription criteria and data type, structured data can be published at predefined intervals or when the data changes (On-change). In this way, network monitoring evolves from periodically querying devices to continuously receiving device-state updates.

Network telemetry is not intended to completely replace SNMP, the CLI, or Syslog. Instead, it provides a mechanism better suited to high-frequency, structured, and automated data collection in modern network environments. Each technology has different strengths in terms of data acquisition method, real-time capability, data granularity, and typical use cases; therefore, they can be used in combination according to deployment requirements. The following comparison highlights the characteristics of Telemetry for continuous state monitoring and large-scale data collection.

A complete Telemetry system typically consists of the following components:

• Network Device: The monitored device. It periodically samples monitoring data and sends the sampled data to the Collector through gRPC, INT, telemetry streams, or ERSPAN.
• Collector: Receives and stores monitoring data reported by network devices.
• Analyzer: Analyzes and processes the monitoring data received by the Collector and presents the analysis results through a graphical user interface.

The Collector can use gNMI to retrieve device operational state and establish continuous data subscriptions through the Subscribe RPC. gNMI (gRPC Network Management Interface) is a gRPC-based network management interface that provides a standardized data access mechanism between network devices and management systems. gRPC is a high-performance Remote Procedure Call (RPC) framework that provides efficient structured data communication and streaming capabilities for network management applications.

From the data model to actual network transport, gNMI, gRPC, and the underlying transport protocols form a layered data communication architecture, as shown below:

Depending on the operation, gNMI defines the following four primary RPCs:

Before using gNMI for data access, the Capabilities RPC can be used to verify the gNMI version, data models, and encodings supported by the device.

Asterfusion suppored models：

Subscribe is the key RPC for Streaming Telemetry. In standard gNMI Subscribe, subscriptions can be further classified as ONCE, POLL, or STREAM according to the data retrieval mode.

• ONCE

The device returns the requested data once according to the Subscription and terminates the RPC after completion.

• POLL

The Collector first establishes a Subscription and subsequently sends Poll Requests to actively trigger the device to return current data.

• STREAM

The Collector establishes a long-lived Subscription, and the device continuously sends data according to the configured update policy. For a STREAM Subscription, the data update behavior can be further specified; common modes include SAMPLE and ON_CHANGE.

• SAMPLE: The device periodically sends data at a fixed Sample Interval. This mode is suitable for continuously changing data, such as Interface Counters and PTP Offset.

As shown below, gnmic acts as the Collector and establishes a long-lived STREAM subscription with the switch at 192.168.15.44. The device is configured to sample and send PTP_INSTANCE data from STATE_DB every 10 seconds in SAMPLE mode.

• ON_CHANGE: The device sends an Update to the Collector only when the data changes. This mode is therefore better suited to change-oriented data such as Interface Status and PTP Clock State.

In actual deployments, it is also necessary to consider which endpoint initiates the Telemetry Session. Based on the direction in which the session is established, common deployment modes can be classified as Dial-in and Dial-out.

• Dial-in

In Dial-in mode, the Collector initiates the connection to the network device. The Collector acts as the gNMI Client and the Network Device acts as the gNMI Server. The Collector can send one or more subscription requests within the same session, and the Network Device continuously streams data according to the subscribed data path. As long as the session remains established, the network device continues publishing data to the application until the session is terminated.

• Dial-out

In Dial-out mode, the user configures the target Collector through the CLI, NETCONF, or RESTCONF, after which the device initiates a session with the application. Unlike Dial-in, if a Dial-out session is disconnected, the device attempts to re-establish the session with the application. Dial-out subscriptions can also be used to stream data to multiple receivers.

The TIG Stack is an open-source technology stack commonly used for time-series data collection, storage, and visualization. It consists of three core components: Telegraf, InfluxDB, and Grafana. These components are responsible for data collection, time-series data storage, and data visualization, respectively, and together form a complete monitoring and data analytics platform.

In Network Telemetry scenarios, network devices continuously generate large volumes of time-dependent operational data, including interface traffic, CPU/Memory utilization, routing protocol state, queue statistics, optical transceiver information, and PTP data. The TIG Stack can collect, store, and visualize this Telemetry data, converting raw operational data generated by devices into time-series data that can be retained and analyzed over time and ultimately presented through dashboards to show network operational state and trends.

Before integrating AsterNOS with the TIG Stack, the Telemetry data exposed by the device can first be validated using a gNMI Client. This step verifies that the target Path can be successfully subscribed to and that the device returns data in the expected mode. It also establishes a validated data source for subsequent continuous collection by Telegraf.

After the subscription is established, AsterNOS returns the corresponding Telemetry Update. The following output shows the data source, timestamp, Target, Path, and actual field value:

After gNMI data validation is complete, the one-time command-line validation can be transitioned to a continuously running data collection workflow, with Telegraf serving as the production Telemetry Collector. Telegraf uses the gNMI Input Plugin to establish connections with network devices, converts the received Telemetry data into metrics, and forwards the metrics to the backend database. The workflow can be divided into two parts: defining the data to be collected and specifying the data output.

1. Specify the Data to Be Collected

2. Configure the Output for Database Storage

After defining the collection items, the storage destination for the Telemetry data must also be specified. InfluxDB is a database designed for time-series data and is well suited for Network Telemetry data composed of elements such as Timestamp, Metric, Tag, and Value. Through the InfluxDB Output Plugin, Telegraf can continuously write collected metrics to a specified Bucket, providing the data foundation for subsequent queries and visualization.。

After Telemetry data is stored in InfluxDB, Grafana can be used to visualize the data.

Grafana can query Telemetry data from InfluxDB for a specified time range and build Network Telemetry dashboards using panels such as Time Series, Gauge, Stat, and Table. By directly querying time-series data in InfluxDB, Grafana transforms raw metrics into intuitive trend charts, status indicators, and dashboards.

Through integration with the TIG Stack, Telemetry data provided by AsterNOS can be continuously collected using standardized data collection tools and further used for real-time state monitoring, historical trend analysis, and visualization of network operational status, providing the data foundation for building a Network Observability system.