Prometheus is an incredibly flexible, open source 3rd party toolkit offering a wide range of system monitoring possibilities. With it, system administrators are able to pull metrics on existing systems, but most importantly empowered to easily define what, how and when these metrics are pulled. These metrics can then be interpreted as data or deliver alerts, based on definable rules, via Prometheus Alertmanager.
In essence, Prometheus provides a non-taxing approach to pulling metrics, defining how these are collected and making them readily available for data interpretation. Prometheus makes this all feasible by supporting the following key features:

  • The Prometheus data model is multi-dimensional and that supports time series data which can be categorized by both the metric name and key/value pairs.
  • PromQL, Prometheus' query language, allows one to manipulate the data model's dimensionality
  • The Prometheus single server nodes are standalone and do not rely on distributed storage or remote services.
  • The collection of time series collection occurs based on a pull model over HTTP.
  • If the duration of jobs is too short lived for Prometheus to pull directly, the time series can then be pushed to an intermediary gateway to build a metrics cache.
  • The targets for metric monitoring can be discovered either via service discovery or static configuration
  • Prometheus supports various ways in which data can be visually represented in graphs and dashboards.


Based on the configurable Alert Rules, Prometheus server is able communicate metrics to its Alertmanager, which then in turn handles the management, grouping, routing of alerts to users via configured methods (email, SMS, etc.)
It is important to note that Prometheus comes with its own guidelines and limitations, both of which should be fully understood before drafting a monitoring concept. For users interested in learning more about Prometheus and its capabilities, as well as documentation on how to implement and configure Prometheus, please refer to the official site provided below.

VidiFlow Specifics for Prometheus
The following aspects must be considered when drafting a monitoring concept using Prometheus.

  • All exporter types must be assigned to a dedicated port.
  • Windows nodes require an exporter. These are available with each Prometheus release in the form of an MSI installer WMI Exporter.
  • When pulling metrics from Azure Service Fabric, it is important to note that Prometheus requires a read component in order to pull metrics directly from the Service Fabric Monitor.