1. Introduction

A coherent transponder on a modern line system reports its own health continuously. A single 400G or 800G line card exposes received optical power, launch power, chromatic dispersion, differential group delay, laser bias current, polarization-dependent loss, optical signal-to-noise ratio, and pre-forward-error-correction bit error rate, and it can produce well over a hundred distinct readings per second when asked. The question a network operations center faces is not whether the data exists. It is how to get that data off the device at the rate the physics changes, land it in a store that can hold months of per-channel history without collapsing, and put it in front of an engineer as a trend they can act on before a wavelength drops.

The legacy answer was the Simple Network Management Protocol. An SNMP manager polls each agent on a timer, walks an OID tree, and pulls a snapshot. That model was built for interface counters that change slowly, and it breaks on two fronts for optical assurance. Polling introduces a fixed floor on how often you can observe a value, so a fast pre-FEC BER excursion between polls is simply invisible. And the manager, not the device, decides the schedule, which means the moment a signal starts to degrade is exactly the moment the manager has no way to know it should look sooner. The industry response is streaming telemetry: the device pushes values on a subscription, either at a fixed sample interval or on change, over a modern transport, using a vendor-neutral data model. In practice that means OpenConfig YANG models carried by the gRPC Network Management Interface (gNMI).

This article builds the receiving end. The target is a working optical NOC dashboard on the open-source TIG stack, named for its three components: Telegraf as the collector, InfluxDB as the time-series database, and Grafana as the visualization and alerting layer. The path runs device to gNMI subscription to Telegraf to InfluxDB to Grafana panel, and the article covers each hop at the level of detail you need to reproduce it: the exact OpenConfig paths for OSNR, power, and BER; the Telegraf subscription configuration and how it maps a gNMI update into a database row; the InfluxDB schema decisions that keep cardinality bounded; and the Grafana panel and threshold design that turns three numbers into an operational signal. It closes with the physics those thresholds encode, the scaling limits that decide your sample interval, and the failure modes that bite in production.

The intended reader spans the range from an engineer standing up their first telemetry collector to an architect sizing a fleet-wide assurance platform. Foundations are explained where they appear, and the depth is set for someone who already knows what a dB is and wants the specific paths, the specific config, and the specific numbers.

Takeaway: Streaming telemetry moves the observation schedule from the manager to the device. That single change is what lets an OSNR or pre-FEC BER trend be captured at the rate it actually moves, which is the precondition for acting before a channel fails rather than after.

2. The OpenConfig optical data model

Before any transport or dashboard, there has to be an agreed structure for the data. OpenConfig provides it. The models are vendor-neutral YANG trees that carry configuration and operational state in one structure, so a controller or collector addresses the same path on a Cisco, Ciena, Nokia, Juniper, or Infinera device and gets the same leaf back. For the optical layer the relevant modules are openconfig-platform and its transceiver submodule, openconfig-terminal-device for the client and line side of a transponder, openconfig-optical-amplifier for line-system gain stages, and openconfig-transport-types for the shared identities. As reference points on maturity: openconfig-terminal-device sits at version 1.9.2, openconfig-transport-types at 1.1.0, and openconfig-platform-transceiver at 0.17.0 — all standard-specified model versions published by the OpenConfig operator group. The point of the version numbers is not the numbers; it is that these models are stable enough that major vendors ship them in production rather than as previews.

The optical channel component

A wavelength in OpenConfig is a component. The device inventory under /components/component holds an entry whose state/type is OPTICAL_CHANNEL, and openconfig-terminal-device augments that component with an optical-channel subtree. That subtree is where the physical-layer performance monitors live. The leaves you build a dashboard on are, by their model paths:

  • OSNR — /components/component/optical-channel/state/osnr, a container reporting instant, average, minimum, and maximum values in dB. Standard-specified as a decimal value with two fraction digits.
  • Received (input) optical power — /components/component/optical-channel/state/input-power, in dBm with two fraction digits, again as instant/avg/min/max.
  • Launched (output) optical power — /components/component/optical-channel/state/output-power, in dBm.
  • Chromatic dispersion — /components/component/optical-channel/state/chromatic-dispersion, in ps/nm, useful for spotting a path change.
  • Laser bias current — /components/component/optical-channel/state/laser-bias-current, in mA, a leading indicator of transmitter aging.

One modelling detail matters for correctness downstream: OpenConfig reports several optical power values in hundredths of a dBm. The openconfig-platform definitions for line-system port power state the value in units of 0.01 dBm, so a raw reading of -1187 is -11.87 dBm, not -1187 dBm. Whether a given leaf is already scaled or reported in hundredths depends on which container it sits in, and getting the scale wrong is the most common reason a freshly built power panel reads nonsense. Confirm the units against the model for the exact leaf, then apply the scale once, in the collector, so every consumer downstream sees dBm.

Where pre-FEC BER actually lives

Pre-FEC BER is not a leaf of the optical-channel component. In openconfig-terminal-device, the coherent line signal is carried by a logical channel, and the OTN-layer statistics for that logical channel hold the error-rate metrics. The path is /terminal-device/logical-channels/channel/otn/state/pre-fec-ber, a dimensionless ratio reported as instant/avg/min/max. The same OTN state container carries related quality metrics that belong on the same dashboard: q-value, esnr (electrical SNR estimated by the receiver DSP), and counters such as fec-uncorrectable-blocks. Keeping pre-FEC BER, Q-value, and OSNR on adjacent panels is deliberate — they are three views of the same margin, and reading them together is how you tell an optical-layer problem from a receiver problem.

OpenConfig optical telemetry data tree A tree of OpenConfig paths. The device root splits into a components branch, whose optical-channel state holds OSNR, input power, output power, chromatic dispersion, and laser bias current, and a terminal-device branch, whose logical-channel OTN state holds pre-FEC BER, Q-value, ESNR, and FEC uncorrectable blocks. Every performance leaf is a statistics container with instant, average, minimum, and maximum values. gNMI target (device) root paths /components/component type = OPTICAL_CHANNEL optical-channel/state osnr dB input-power dBm output-power dBm chromatic- dispersion (ps/nm) laser-bias- current (mA) /terminal-device /logical-channels/channel otn/state pre-fec-ber ratio q-value dB esnr dB fec-uncorrect- able-blocks Every performance leaf is a statistics container Each OSNR, power, or BER leaf reports four sub-values plus the window over which they were computed: instant avg min max Subscribe to instant for trend fidelity; keep min and max to catch excursions a sample interval would otherwise miss. The interval leaf reports the averaging window, so the collector can tag a value as a snapshot or a 15-second mean.
Figure 1: The OpenConfig optical performance tree. Power, OSNR, dispersion, and laser bias sit under the optical-channel component; pre-FEC BER, Q-value, and ESNR sit under the terminal-device logical-channel OTN state. Every performance leaf is a statistics container with instant, average, minimum, and maximum values.

The two-branch shape in Figure 1 explains a routine confusion. Engineers new to the model look for BER under the optical channel, find only power and OSNR, and assume the device does not report it. It does — the error-rate metrics are one level over, under the logical channel that rides the wavelength, because in the model a wavelength carries a signal and the error rate is a property of the signal, not the carrier. For a broader map of how these southbound models relate to controllers and northbound APIs, the NETCONF and YANG walkthrough and the northbound and southbound interface protocols reference give the surrounding architecture.

Takeaway: Power, OSNR, dispersion, and laser bias are optical-channel component leaves; pre-FEC BER, Q-value, and ESNR are logical-channel OTN-state leaves. Confirm units per leaf — some optical power values are reported in hundredths of a dBm and must be scaled once in the collector.

3. gNMI: the transport that makes streaming work

OpenConfig defines the data; gNMI moves it. gNMI is a gRPC-based management interface with four remote procedure calls: Capabilities to discover which models and encodings a device supports, Get for a one-shot read, Set for configuration, and Subscribe for continuous telemetry. For a NOC dashboard, Subscribe is the entire game. It runs over gRPC on HTTP/2, which gives one persistent, multiplexed TCP connection carrying many concurrent subscription streams, and it serializes with Protocol Buffers, a compact binary format. Transport Layer Security is part of the interface, so the management channel is authenticated and encrypted rather than bolted on.

The Subscribe RPC has three modes. ONCE returns a single snapshot and closes, useful for an inventory sweep. POLL lets the client pull on demand over an open stream. STREAM is the one that matters here — the device sends updates continuously — and it has three sub-modes that decide when an update is sent:

Premium Article — Free 20% Preview

Read the Full Analysis with Premium

The remaining 80% of this article — the design numbers, trade-offs and field guidance — is part of MapYourTech Premium, along with the full premium library, courses and professional tools.

Instant access · Cancel anytime · 48-hour trial available
Sanjay Yadav

Optical Communications & Network Automation Expert | Author of 3 Books for Optical Engineers | Founder, MapYourTech

Optical networking engineer with nearly two decades of experience across DWDM, OTN, coherent optics, submarine systems, and cloud infrastructure. Founder of MapYourTech.

Follow on LinkedIn

Related Articles on MapYourTech