A live value rarely stays a single value for long. You look at the seconds or minutes before it, bring another channel into the same interval, and follow the relationship until you can see what changed and when.

Teams can now run that whole investigation beside the hardware. One local deployment of Sift Edge, available in early access, ingests custom protobuf telemetry, stores it on local disk, serves live and historical views in a native desktop GUI and in Grafana, and uploads the telemetry your team selects to your Sift tenant.

Most teams get there today by assembling a few parts: a converter that reshapes telemetry into a format some viewer will accept, a local time-series database and dashboard stack to watch the test while it runs, and a transfer step that moves the run into the platform where the rest of the company works. One Sift Edge deployment does those jobs, starting from the message types your software already defines, and your team keeps control of each handoff, including which telemetry leaves the site and when.

That leaves one record rather than a copy in the converter’s output, a copy in the local database, and a copy in the platform. What your operators watch during the test is what your analysts open afterward.

What begins beside the hardware continues into analysis, reports, rules, collaboration, and campaign history in the tenant your organization already uses, whether it runs in the cloud or on-prem.

The fields your hardware already sends become channels you can plot

A plot in the viewer matches the .proto on the bench, nesting included: fields land as channels under the names your team already uses, and nested messages show up as a tree in the channel selector. Register a descriptor with its fully qualified message type name and file descriptor set, take back the descriptor ID, and stream raw protobuf messages against it. Nested messages and map fields come through, and parsing options govern how maps and lists resolve into channels.

Schema problems surface at registration. A field the server cannot ingest comes back by name with the reason attached, which turns a schema mismatch into a fix at the desk rather than a missing channel discovered mid-test. Keeping a hand-written converter in step with every schema change becomes re-registering a descriptor.

Sequence IDs ride along with the data, and a checkpoint request returns the last sequence the server received, so a client reconciles what the server received rather than guessing at it. Teams streaming Arrow-native columnar telemetry use the Arrow Flight client API instead, and both paths land in the same storage and query model, so the client a team picks never limits what the viewer or the upload can do.

Channels then appear in the native desktop GUI, ready to select and plot. The same local server that received them holds the history, answers the queries, and later runs the upload, and it ships as a single binary, so the test-stand machine runs one process instead of a stack your team has to assemble.

The live value and the minutes behind it come from one query

Select a range that covers this second and the last ten minutes, and read it as one series. The server holds current telemetry in memory and writes Parquet files to local disk, and DataFusion merges both inside a single query, so one request returns samples still in memory next to samples already written to disk. Whoever is watching never has to know which side of that line a sample sits on.

SQLite catalogs those Parquet files and their metadata as the record grows, and a write-ahead log backs the durability of what has been written, so a hard restart mid-test comes back to the same queryable record. Local history arrives with the server rather than from a separate time-series database your team installs, tunes, and keeps running beside the test.

In the native desktop GUI, a live panel tracks current time at its right edge. Zoom or pan into the past and the panel switches to a fixed range, backfills history, and clips live data at the edge, which holds a window still while the test keeps running. Tables carry strings, enums, and current values, so a run-state enum sits beside the pressure trace it explains, and a second tab keeps another subsystem ready in its own layout.

Your existing Grafana dashboards read from the local server

Operators who run test stands from Grafana keep the panels and alerts they already trust. Connect a local Grafana instance through the Sift Grafana plugin, which ships an Edge build that reads from the server beside the hardware, and those panels show the same telemetry the native application shows. Changing where the data comes from costs your team nothing in dashboard rebuilds.

The two viewers cover different work. The native GUI handles the channel selector, tables, tabs, connection state, and upload jobs. Grafana holds the panel layouts and dashboards your team has already built for its test stands, so each person works where they are fastest.

Both read one record. Your team can catch a live value in Grafana, open the surrounding history in the native GUI, and upload the run it belongs to, all from the same machine, and the number on the dashboard and the number in the viewer come from the same file on the same disk.

The live view keeps running when the network drops

Your operators keep watching the test while the link to Sift is down, because every step of that view runs on the local machine. Current samples sit in local memory, Parquet files sit on local disk, and DataFusion reads both from there.

The connection panel shows color-coded status for the server profile in use, so an operator can tell at a glance whether the numbers on screen are still arriving. Holding source, storage, and query work on one local machine is what makes ingestion resilient to an unreliable upstream.

Size the deployment for the rate your source produces and the queries your team runs. Local hardware and workload shape what you observe, so use early access to measure the build against the rates, query patterns, and machines you plan to deploy.

Telemetry stays on local disk until someone starts an upload job. The server keeps writing Parquet the whole time, so the decision about what moves upstream can wait until after the run.

A run, a time range, or a selection you choose uploads as a job you can track

Send the telemetry your team plans to review, and leave the rest on disk. Pick a run, an asset time range, or a selection you make in Explore, then start an upload job that follows the unit your team already uses to review the test.

Quick upload handles a single run, bulk selection handles several that belong together, and Explore covers finer choices of channels and time. Each action creates a job of its own, which lets the transfer match the review: one run for a debrief, several for a campaign summary, a narrow channel and time selection when one signal is the whole question.

The Uploads view lists every job and its progress, and a job row offers cancel and retry while those actions apply, so your team can confirm what reached the tenant before anyone frees disk. Each job carries its telemetry into your Sift tenant, whether that tenant runs in the cloud or on-prem.

The work continues there: reports, rules, review across sites, and history across campaigns.

Cleanup runs as its own client-initiated action, with an optional retention threshold that decides what stays on disk after an upload. Upload and disk space stay under separate controls, so your team can reclaim space on its own schedule.

The result is store-and-forward telemetry. Capture keeps running against local disk, and transfer happens on a schedule your team sets rather than one the network sets. The local record is also not a dead end, because an uploaded run joins the same campaign history, reports, and rules as everything else in the tenant, which is the part a local database beside the test stand has never been able to offer.

One system in place of a converter, a local database, and a transfer step

Start with one source your team already runs

Its message types, expected channels, upload unit, and retention needs give the evaluation a clear scope, and one test campaign answers what a rollout depends on: whether the schema registers cleanly, whether the view holds during an outage, and whether the upload lands what your team expects.

Stand up ingestion for that source, then confirm the channels arrive in the native GUI. Move from a live value into Parquet history, and open that same telemetry in Grafana through the plugin.

Change the upstream link during a controlled run and watch how the deployment behaves at your rates on your hardware. Select a run, start the upload job, confirm the telemetry lands in your Sift tenant, then run cleanup at the retention threshold your disk requires.