Grafana for industrial IoT dashboards and monitoring

What Grafana is

Grafana is an open-source dashboard and observability tool, published under the AGPL licence by Grafana Labs (who also offer a hosted Grafana Cloud and an enterprise edition). Its job is to query data from one or more sources, draw it as charts, gauges, tables and maps, and raise alerts when values cross a threshold. It is best known for working with time-series data — measurements stamped with a time, which is exactly what a flow meter, vibration sensor or energy meter produces all day long.

That focus is why Grafana has become a default choice for performance monitoring across IT and, increasingly, industrial environments. The same tool that watches server CPU and request latency can watch pump pressure, reservoir level or motor temperature — the shape of the problem is identical: many streams of numbers over time that someone needs to see at a glance and be warned about when they go wrong.

How Grafana fits an industrial IoT stack

The single most important thing to understand is that Grafana sits at the top of the stack. It is a presentation and alerting layer, not a data collector and not a database. A typical industrial IoT pipeline that ends in Grafana looks like this:

• Sensors and equipment — flow meters, pressure transmitters, vibration sensors, energy meters, and PLCs exposing data over Modbus, OPC-UA or MQTT.
• Edge gateway — reads the equipment, normalises the values, buffers locally when connectivity drops, and forwards readings upstream.
• Time-series database — InfluxDB, Prometheus or TimescaleDB (PostgreSQL with a time-series extension) store the readings efficiently and answer time-range queries fast.
• Grafana — connects to that database as a data source and renders dashboards, then evaluates alert rules and sends notifications.

Grafana is deliberately database-agnostic: it ships with data-source plugins for the common time-series databases plus plain SQL (PostgreSQL, MySQL), Elasticsearch, and many cloud back-ends. On a plant, that means the database and the ingest pipeline are the substance of the system; Grafana is the window onto it. If nothing is reliably collecting and storing the data, a beautiful dashboard is just an empty frame.

Monitoring, logging and observability — what they actually mean

People use "monitoring and logging" as one phrase, but they describe different kinds of signal, and Grafana touches all of them. Getting the vocabulary straight helps you scope a monitoring system properly.

Performance monitoring is mostly about metrics: is the asset running within limits, and is it trending the right way? Monitoring and logging together — metrics plus event logs — is what gives you observability: not just an alarm that something is wrong, but enough context to understand why. Grafana can display metrics from a time-series database and logs from a log store (such as Loki or Elasticsearch) side by side on one dashboard, which is the practical value of the "single pane of glass" idea.

It is worth separating all of this from condition monitoring, which is a specific engineering discipline: tracking the health of rotating and critical assets (vibration, temperature, oil analysis) to predict failure. Condition monitoring is a use of monitoring data — Grafana might visualise it, but the value comes from the sensors, the sampling and the engineering judgement behind the thresholds.

Alerting: catching threshold breaches

Dashboards are for humans who are looking. Alerting is for the times nobody is. Grafana has a built-in alerting engine: you define a rule against a query (for example, reservoir level below 20% for more than five minutes, or motor temperature above its trip point), and when the rule fires Grafana sends a notification to email, a webhook, a chat channel or an on-call tool. This is the feature that turns a dashboard from a nice-to-have into something operations actually rely on.

Two cautions for plant use. First, alert quality matters more than alert quantity — too many noisy thresholds and people stop reading them, so tune for "for X minutes" durations and sensible bands rather than instantaneous trips. Second, Grafana alerting depends on the data arriving. If your edge layer goes blind during load shedding and stops feeding the database, Grafana can only alert on the silence (a "no data" rule), not on what the sensor would have read. That is why buffering at the edge — so readings catch up when connectivity returns — matters as much as the alert rule itself.

What Grafana is good at — and what it is not

Good at: visualising time-series data beautifully and flexibly; combining many data sources on one screen; threshold alerting and notifications; building real-time dashboards quickly; sharing read-only views with management. For an operations team that wants visibility and warnings, it is hard to beat on value.

Not designed for: Grafana is not a SCADA or control system. It is read-and-alert, not read-and-act — you do not start pumps or move setpoints from a Grafana panel, and you should not try to. It is also not a historian by itself: it stores dashboard definitions and alert rules, but the actual measurement history lives in the time-series database you point it at, with that database's retention and backup. And it is not a data-acquisition layer — it will not talk Modbus or OPC-UA to your PLC; something has to collect and store the data first. If you are weighing control and visibility, our note on SCADA vs an IoT platform draws that line in more detail.

How addaNet works with Grafana

addanode builds the in-house addaNet platform, which handles the parts of the stack that sit below a dashboard: reading equipment over Modbus, OPC-UA, MQTT and direct I/O; buffering at the edge so nothing is lost through load shedding and patchy links; and storing readings in a time-series back-end hosted in-region. addaNet ships with its own dashboards and alerting, so for many sites it is the whole picture — sensors to screen — without a second tool to run.

But Grafana is widely loved, and plenty of engineering teams already have it. So rather than fight that, addaNet is built to expose its data to Grafana for teams who want it — over a REST API, plain SQL, or a time-series database connection that Grafana can treat as a data source. You point Grafana at addaNet, build the panels you like, and let addaNet keep doing the unglamorous, essential work underneath: ingest, normalisation, buffering through outages, and keeping the data in South Africa. You can read more about the stack on our technology page.

The honest summary: Grafana is an excellent visualisation and alerting tool, and a sensible choice when you already have a solid data pipeline feeding a time-series database. It is not the whole solution, and it does not pretend to be. The harder, more valuable work on a plant is getting clean data off the equipment and keeping it flowing through real-world conditions — and that is the layer addaNet is built for, whether you view the result in addaNet's own dashboards or in your own Grafana.

Frequently asked questions