Multiple data sources in Grafana: When do the numbers belong together?

At the end of a shift, the production lead opens two screens. Machine data suggests output increased. The quality system shows more rejected parts over roughly the same period. Before anyone attributes the rejects to the faster pace, there is a simpler question to answer: do these records describe the same jobs?

Grafana can connect to several data sources, making that question visible in one place. Work orders might live in a SQL database, machine events in a time series store, and inspection results in a quality application. The ability to display them together is useful, but it does not establish that their identifiers, clocks and definitions agree. This article focuses on the practical boundaries of Grafana’s multiple data source capability on a shop floor.

A shared dashboard is not a shared data model

A Grafana data source is a connection to a backend that stores information. Grafana queries that backend and displays the results in dashboards. It has built-in support for several SQL databases and time series systems, with other integrations available through plugins. Panels on one dashboard can use different data sources. The Mixed option can also run queries from different sources within a single panel. Neither approach automatically reconciles what the sources mean by a completed part or an active job.

Imagine that a press reports completed cycles, the ERP reports planned quantity per work order, and the quality application records failed inspections per batch. One cycle may not equal one accepted part. Trial strokes and rework can change the count. A batch may include parts from more than one run. Putting these values on adjacent graphs gives an impression of alignment, but labels alone cannot make the definitions match.

A better starting point is one decision question. Did first-pass acceptance change during the faster run on this particular press? That question defines the relevant jobs, time window and numerator and denominator. It also tells us what to leave out. A dashboard containing every available metric can obscure precisely the distinction the team needs.

A shop-floor example

Consider a hypothetical sheet metal shop. Press events are stored as time series, work orders in the ERP database, and dimensional inspection results in a quality tool. The shift lead wants to see hourly press activity alongside the number of parts accepted at first inspection. The first dashboard plots both lines against time. At around 2 p.m., activity rises and acceptance falls.

It would be premature to infer causation. An inspection recorded at 2 p.m. may concern parts pressed an hour earlier. The press may have switched jobs within that hour. A trial run could be included in the cycle total. Showing the curves on the same chart doesn’t resolve these differences; it can hide them behind a clean visual comparison.

For a second version, the team checks how each event gets its work order identifier. If a machine event has no job identifier, its assignment might be inferred from operator sign-in or job start and stop times. An inferred match should be marked as uncertain, not silently treated as a direct record. The batch identifier in the inspection tool must then be traced to the relevant work order. Finally, distinguish event time from entry time. Was the failed measurement plotted when the part was produced, when it was inspected, or when someone typed it into the system? Each answer supports a different interpretation.

Match keys before matching curves

Jobs, machines and batches need stable identities across systems. A machine called “Press 2” in one database may appear as “PR02” in another. A maintained mapping can make those identities comparable, but the mapping itself needs an owner. If one team changes a machine code, the dashboard should not continue joining records under the old assumption without a review.

Time grain matters just as much. A second-by-second machine signal and one end-of-shift inspection summary cannot sensibly be compared point by point. They may need to be grouped by job or summarized over a defined interval. Define the denominator before calculating a rate: the number of rejects is not the same as rejects divided by the number inspected. An hour with no inspections should appear as missing inspection data, not as an hour with zero defects.

Grafana provides ways to transform query results and relate fields in a panel. That can be convenient for modest, clearly defined comparisons. It is not always the right place to maintain complex joins across high-volume or rapidly changing systems. If several dashboards need the same business definition, preparing that definition in a data layer may be easier to maintain. Otherwise two screens can show two different versions of a supposedly shared production metric.

Freshness and access belong in the design

Connecting multiple sources also means accepting different update schedules. Machine events may arrive every few seconds, ERP status every few minutes, and quality results after inspection. A dashboard refresh redraws what the sources return; it does not guarantee that all sources have fresh records. Where the difference matters, show the last event time for each source. If one source stops updating, a stale value should not masquerade as today’s status.

Permissions require the same care. A work order number may be appropriate for a shared workshop display, while customer details, pricing or raw inspection notes may not be. A Grafana connection that can query a database does not mean every field belongs on a screen visible to the whole shift. Review both source access and the information actually returned by the panels.

The first useful experiment can be small: one station, two sources and one question. Do a machine stoppage and the ERP’s waiting job refer to the same event? Manually compare sample records, document how the job and timestamps correspond, then build the panel. During actual shifts, check several exceptions against the underlying records. If the match is wrong, fix the definition before adding a third graph. This may look slower than assembling a large dashboard, but it prevents a polished display from becoming an authoritative-looking error.

The earlier article on Grafana above the data layer explains where dashboards fit. The piece on screens the team actually uses looks at daily use. Multiple data sources connect these concerns. The measure of success is not how many systems fit on a page. It is whether the records describe the same production event, with their uncertainty still visible.

Sources: Luke van Enkhuizen’s overview of open-source manufacturing tools and Grafana’s data source documentation. The workshop scenario is illustrative.