×

Did you know that your internet is out of date?

Your browser is out of date, and may not be compatible with our website.

Just click on the icons to download a compatible browser. 

Close this window

By closing this window you acknowledge that your experience on this website may be degraded. 

/content/tridium/us/en/search.html
Outage Notification: On Saturday, June 5,12:30-2:30 p.m. EDT (6:30 to 8:30 p.m. UDT), this website will undergo planned maintenance. Thank you for your patience.

Prometheus Driver

Puts Niagara data into the monitoring stack the IT department already runs. Live point values are published on a Prometheus scrape endpoint, each with an up or down status alongside the reading, so a building appears in Prometheus, Grafana, and Alertmanager the same way a server does. History travels the other way as well: metrics already held in Prometheus can be imported into Niagara histories. It suits multi-site portfolios and converged IT and OT alerting.
CONTACT SELLER

Overview

Every readable point is exposed as a metric carrying its engineering units as labels, degrees Celsius and cubic metres per second included, so a dashboard does not have to be told what a value means. Each point also reports an up or down status, which makes a dead sensor or a dropped device something Alertmanager can raise rather than something noticed later. In the other direction, metrics are discovered from the database and imported into Niagara histories, fetching only the samples that have arrived since the last run. Anything that speaks PromQL is a valid target, so Prometheus itself, VictoriaMetrics, Grafana Mimir, Thanos, and Cortex all work. The endpoint runs over HTTP or HTTPS, and access is per user, with role-based filtering deciding which points a given scrape is allowed to see, so a monitoring team can be given plant data and nothing else. Runs on a JACE or a Supervisor. Licensing is perpetual, unlimited on points and devices, and bound to the Host ID.

List of FAQs

Which way does the data flow? Both ways. Live point values are published on a scrape endpoint for Prometheus to collect, and historical metrics already sitting in Prometheus can be pulled back into Niagara histories. Most sites use the export direction, but the import is there when the analytics live outside and the results need to come home. Do I need to be running Prometheus already? Effectively yes. This connects Niagara to a monitoring stack you have or intend to build, and it pays off when Prometheus, Grafana, and Alertmanager are already part of how the organisation watches its systems. If all you want is station history in a time-series database and there is no Prometheus in the picture, look at our InfluxDB product instead, and ask us if you are not sure which fits. Does it work with VictoriaMetrics, Mimir, Thanos, or Cortex? Yes. Anything that speaks PromQL and scrapes in the Prometheus manner works, so the long-term storage layer you have chosen is not a constraint. Can I build Grafana dashboards from this? Yes, and that is the usual reason people buy it. Grafana queries the time-series database rather than the station, so dashboards keep working at whatever refresh rate you like without Niagara sitting in the path. How do point names and engineering units come across? Units travel as labels on the metric, with UTF-8 preserved, so degrees Celsius and cubic metres per second arrive intact rather than as stripped ASCII. A dashboard or an alert rule can read the unit directly instead of having it hard-coded somewhere else. Can I alert on building data with Alertmanager? Yes, and the up or down status published for each point is the part worth knowing about. It means device and sensor health is alertable in the same place as server and network health, rather than needing a separate mechanism inside Niagara. 

Software Version

Niagara-powered device with software N4.8+, including JACE and Supervisor.