Ask Reuben – January 21, 2026

Prometheus

What is Prometheus?

The highlight feature of Genero Enterprise version 6 which was released at the end of 2025 was the Monitoring and Observability based on Prometheus.

When first looking at it, I think there are some key points to learn.

First is recognising that Prometheus is a free open-source metrics and monitoring tool for your systems and services.  So, find and read the Prometheus documentation and the Prometheus wiki page.

On the Wiki page there is an architecture section that at time of writing says …

A typical monitoring platform with Prometheus is composed of multiple tools:

  • Multiple exporters typically run on the monitored host to export local metrics.
  • Prometheus to centralize and store the metrics.
  • Alertmanager to trigger alerts based on those metrics.
  • Grafana to produce dashboards.

PromQL is the query language used to create dashboards and alerts.

Within this context, the Genero tools are “exporters” that export local metrics.  They make the metrics available, Prometheus comes along and periodically reads these metrics and then you might use tools such as Alert Manager to raise alerts or you might use a tool such as Grafana to produce GUI dashboards.

You need to recognise that the role of Genero and its various tools is to produce local metrics that are then made available to Prometheus and allows other tools in the Prometheus ecosystem such as Alertmanager or Grafana to do their thing.  This is not a case of Genero encapsulating Prometheus within it, you will need Prometheus/Grafana knowledge.

There is more than one Genero product that can be used to produce metrics.  It is therefore important to be aware that you may need to refer to more than one piece of Genero documentation as well as any Prometheus, Alert Manager, Grafana documentation.  When starting out, you can just read the Genero Application Server (GAS) documentation, but there is also other documentation links on other Genero products:

One important point to note as a result of the architecture where the Genero tools collect the metrics and periodically Prometheus polls these tools; there needs to be something running and listening for Prometheus to talk to.  This is fine for GAS, the Genero Application Server (i.e the dispatcher) is running and listening for requests.  For Genero Report Writer when running in distributed mode there is something running and listening.  Where it has an impact is where there is not something and listening, so in the following scenarios, it is not possible to make metrics available to Prometheus

A minor point to be aware of too is Prometheus is polling the exporter at regular intervals.  So when it comes to testing, don’t do something in your Genero application and expect to see something immediately occurring in Prometheus/AlertManager/Grafana.  Make sure you wait the configured polling period before thinking something is not working as intended.  It might be 15, 30 seconds after you do something before you see a change in a graph in a Grafana page.

Also be aware that Prometheus is dictating the terminology.  When I was first evaluating our implementation, I was thinking why are we using counter, gauge, histogram, but you get into it and see that that is what Prometheus has as the available metric types, and this flows through to our code with the different class and method names.

First Steps

In the GAS documentation, there is a page Quick Start.   The first two steps are

  1. Download and Install Prometheus
  2. Enable Prometheus in GAS by setting res.prometheus.enabled = TRUE in your GAS configuration

At this point, GAS is ready to expose metrics for Prometheus to collect at the /metrics end point.  If at this point you start GAS, run the demo program, and then enter http://localhost:6394/metrics into your browser (replacing address and port as appropriate) you will see the metrics that GAS has collected for Prometheus to collect.

After that, it is a case of configuring Prometheus to tell it where to look i.e where is the GAS running, so that it can “centralize and store the metrics”.  Hence the step 3 in that Quick Start where you are telling Prometheus the URL it needs to use to get the data that GAS has collected.  Prometheus is calling the equivalent of http://localhost:6394/metrics every X seconds.

Available Metrics

Within the various Genero products, we have made a number of metrics available.

To see metrics we make available, you should look for the word metrics in our documentation.  You should find pages such as

You will need to be aware of these pages, and the fact you can search on the term “metrics” to find what information we collect for Prometheus.

Making Your Own Metrics

From within a Genero application, you can create your own metrics.  I had a bit of fun with this during the Early Access Program.  Make sure that you remember …

  • only available if Genero application is running via GAS, not available if running by Direct Connection
  • to wait for Prometheus to poll GAS

The code to collect metrics is very simple and is composed of 4 key points …

  1. Import the prometheus package
  2. Define a variable for each counter, gauge, histogram metric for each Prometheus metrics you want to collect
  3. Use the applicable create method for each Prometheus metrics you want to collect
  4. Use the applicable method (inc, dec add, sub, set, observe) to determine the values.

If you look at the example in the documentation you will see the …

  1. Import the Prometheus package

IMPORT prometheus

  1. Define a variable for each counter, gauge, histogram variable for each Prometheus metrics you want to collect

DEFINE counter prometheus.Counter
DEFINE gauge prometheus.Gauge
DEFINE histogram prometheus.Histogram

  1. Use the applicable create method for each Prometheus metric you want to collect …

LET counter = prometheus.Counter.create("counter_hello", "a counter",["labela", "labelb"])
...
LET gauge = prometheus.Gauge.create("gauge_hello", "a gauge",["labela", "labelb"])
...
LET histogram = prometheus.Histogram.create("histogram_hello", "a histogram",[0.25,0.75,0.9], ["labela", "labelb"])

  1. Use the applicable method (inc, dec add, sub, set, observe)

CALL counter.inc(["valuea", "valueb"])
CALL counter.add(2.6, ["valuea", "valueb"])
...
CALL gauge.set(4.2, ["valuea", "valueb"])
CALL gauge.inc(["valuea", "valueb"])
CALL gauge.add(2.6, ["valuea", "valueb"])
CALL gauge.dec(["valuea", "valueb"])
CALL gauge.sub(2.3, ["valuea", "valueb"])
...
CALL histogram.observe(5.2, ["valuea", "valueb"])

For a good exercise to begin with, I would explore adding some counter metrics that can be used to observe how often an individual program is run and how long it takes.  Hopefully you have some library functions that are called at the beginning and end of programs where it will be very easy to add the required counter.inc and counter.add methods.

Potential Language Extensions

Using methods such as ui.Form.setDefaultInitializerFunction it is very easy to define some code that is executed every time a form is opened.

What I thought might have been raised during the EAP, but no one took my hint in the Feature of the Day, is are there any other places where it would be good to have a function called whenever a certain event occurs?  For instance every time a Dialog is instantiated,  or every time an Action is clicked, or every time an SQL statement is executed … so that you can collect a Prometheus metric when that event occurs.

Make sure you get your need recorded with your support contact if there is something in this area you think Genero would benefit by.

Grafana

The wow factor of Prometheus is in the ability to use tools such as Grafana to give pictorial views of the metrics that have been completed.

If I was to give some links in Grafana to read, I would point you at this page which relates Grafana and Prometheus https://grafana.com/docs/grafana/latest/fundamentals/intro-to-prometheus/

and these two pages which have samples of Dashboards

https://grafana.com/grafana/?plcmt=products-nav

https://grafana.com/grafana/dashboards/

Hopefully the images in those links wet your appetite as to what is possible using Prometheus and Grafana.

I am still learning the intricacies of Grafana, and the PromQL query language and will hope to publish another article once I am more adept.  If I was to make one comment, it is that you are not limited to just the metrics you can see, but can combine them in expressions.  For instance, a PromQL query such as …

count(fourjs_gas_url_count_total{status!="200"}) / count(fourjs_gas_url_count_total) * 100

… gives a percentage of requests that are ending in error.

You are not limited to the simple values of what you see in the /metrics output.  You can use and combine these primitives in expressions.

So once you have GAS and Prometheus collecting metrics, start looking at tools like Grafana to visually represent and make use of the data you have gathered.  But first you have to start collecting the metrics.