See Everything: Visualizing Nubus Metrics with Prometheus and Grafana

The metrics endpoint in UCS 5.2 delivers the raw data, Prometheus stores it, Grafana turns it into a graph. Give it a little time and you stop reading numbers off a screen—you start seeing how your Nubus instance is changing.

How many user accounts right now? How close are we to the license limit? What patch level are we on? If you run a Nubus environment, you know these questions. Until now, the answers lived in the portal or on the command line.

Thats’s what errata level 410 for UCS 5.2-5 changed. Nubus now exposes a metrics endpoint for the UDM REST API that reports the key numbers in Prometheus format. Admins can pull them in seconds, keep them for later, and also graph them in Grafana.

So let’s do that. This article takes you from the raw endpoint to a Prometheus collector, and ends up with a Grafana dashboard actually worth watching. By the time you’re done, you’ll know exactly where your Nubus instance stands and which way it’s going.

The metrics endpoint is part of the UDM REST API, protected by HTTP basic auth (username and password go in the request header). You’ll find it at /univention/udm/-/metrics. Access goes to members of the udm-rest-metrics group, plus any account that can already reach the UDM REST API. That includes the Administrator account, which is what we’ll use here to keep things simple. In production, set up a dedicated account and add it to the udm-rest-metrics group.

A single curl call is enough to grab the current metrics:

:~# curl -k -u Administrator:<password> https://<nubus-host>/univention/udm/-/metrics
# HELP nubus_ucs_version_info UCS version information
# TYPE nubus_ucs_version_info gauge
nubus_ucs_version_info{domain="nubus.example",errata="515",license_uuid="dce67f03-e7b2-4a6b-92f7-c4777dac6ef5",patch="6",system_uuid="1847168b-4caf-418c-a741-edaec5fc8978",ucs="5.2"} 1.0
# HELP nubus_n4k_version_info Nubus for Kubernetes version information
# TYPE nubus_n4k_version_info gauge
# HELP nubus_users_user_total Total number of UDM objects of type users/user
# TYPE nubus_users_user_total gauge
nubus_users_user_total{domain="nubus.example",license_uuid="dce67f03-e7b2-4a6b-92f7-c4777dac6ef5",platform="ucs"} 949.0
# HELP nubus_settings_license_users_limit_total Number of active users permitted by the installed license
# TYPE nubus_settings_license_users_limit_total gauge
nubus_settings_license_users_limit_total{domain="nubus.example",license_uuid="dce67f03-e7b2-4a6b-92f7-c4777dac6ef5",platform="ucs"} +Inf

Replace <password> in the command with the password for the Administrator account. The response comes back in the Prometheus exposition format: plain text that Prometheus reads directly. Right now the endpoint serves three metrics:

• nubus_ucs_version_info shows the full version info for the instance. The actual values live in the labels: ucs, patch, and errata describe the software level, while domain and system_uuid identify the installation uniquely.
• nubus_users_user_total counts the active, managed user accounts in the Nubus domain. Disabled accounts and system accounts don’t count; this is the same number the license check uses.
• nubus_settings_license_users_limit_total shows the maximum number of active user accounts allowed under the installed license. With no license limit, the endpoint returns +Inf or -1, which is what you’ll see in our test setup running the Core Edition.

Which version metric the endpoint fills with values depends on the deployment type. In a UCS environment like the one here, nubus_ucs_version_info reports the version, patch level, and errata status. In a Kubernetes environment, nubus_n4k_version_info reports the Kubernetes-specific version details. Whichever metric doesn’t apply still shows up in the output—as a header line with no data.

One label stands out: domain. It appears on every metric and ties each value cleanly to a specific Nubus domain. If you monitor several instances later on, that’s the field that keeps them apart.

Prometheus actively queries the metrics from the endpoints it monitors (that’s called “scraping”) and stores them in its own time series database. To connect Nubus, add a new scrape job to your prometheus.yml:

global:
  scrape_interval: 30s

scrape_configs:
  - job_name: 'nubus'
    metrics_path: '/univention/udm/-/metrics'
    scheme: https
    tls_config:
      insecure_skip_verify: true
    basic_auth:
      username: Administrator
      password: <password>
    static_configs:
      - targets: ['<nubus-host>']

Adjust the password and target host for your environment. The insecure_skip_verify option skips the certificate check; in production, use a valid certificate and drop the option instead. After you reload Prometheus, open the web interface and go to Status → Target health to check whether the nubus job shows up as UP. That tells you Prometheus is reaching the endpoint on schedule and collecting the metrics.

A dashboard gathers several panels on one page. Each panel sends a query to the data source and visualizes the answer. For our Nubus monitoring, four panels are enough to cover the whole picture: the current user count, the license limit, the version info, and the trend over time.

Create an empty dashboard under Dashboards → New Dashboard. For the layout, pick Custom grid so you can set the size and position of each panel yourself. The + Add visualization button creates your first panel.

Panel 1: Active Users

The first panel sits in the top left corner and shows the current number of active user accounts as a large single figure. Below it, a small arrow gives the percentage change from the previous period, and a sparkline sketches the trend within the selected time window. The figure carries the panel; the two additions supply the context.

In the panel editor, pick the prometheus data source at the bottom and enter the query in code mode:

nubus_users_user_total

In the top right, switch the panel type to Stat. In the options on the right, set Panel options → Title to Active Users. Under Stat styles → Graph mode, choose Area: alongside the large number, a small sparkline now appears in the panel. The Show percent change option adds an arrow and a percentage that reflect the change from the previous period.

It’s also worth opening the Thresholds section. This is where you define which value turns the panel which color: green as the baseline, say, yellow from 1199, red from 1200. The number in the panel then switches color on its own as soon as it crosses a threshold.

Panel 2: User Limit (License)

The second panel shows the license limit; in our test setup on the Core Edition, it reads ∞. Create a new panel with this query:

nubus_settings_license_users_limit_total

Set the panel type to Stat and the title to User Limit (License). Grafana recognizes the +Inf value automatically and renders it as an infinity symbol.

Panel 3: UCS Version

The third panel shows all the labels of the version metric in a clear table. This time the query is:

nubus_ucs_version_info

Set the panel type to Table. Since the interesting information sits in the metric’s labels, you need a transformation that surfaces those labels as columns. Switch to the Transformations tab at the bottom and add the Labels to fields transformation. Set the mode to Rows so the labels stack vertically instead of side by side.

For a simplified view, add a second transformation: Organize fields by name. Use it to hide technical fields like _name_ and job, and to sort the labels that remain: domain, ucs, patch, errata, license_uuid, system_uuid.

Panel 4: User Count over Time

The fourth panel tracks the user count over time. This is what a time series database is for. Create a new panel with the same query as in Panel 1:

nubus_users_user_total

The Time series panel type is already selected. A click into the query options takes you to the Legend field. Enter this:

{{domain}}

Now the legend shows just the domain name of the Nubus instance instead of the expression with every label; in our example, that’s nubus.example. Once you’re monitoring several instances later on, Grafana tells them apart by exactly this label.

Final Layout

Drag and drop the panels into an arrangement that works. For the screenshots in this article, the three Stat and table panels sit side by side up top, with the time series panel spanning the full width beneath them. Save the finished dashboard with Save.

The real strength of a Grafana dashboard like this comes out in daily use. What matters isn’t a metric’s single reading, but its trend. Take the start of a school year. Over a few weeks, the administrators create several hundred new accounts. The time series panel renders that as a staircase, and the figure in the Active Users panel climbs. As the number nears a threshold you defined earlier, it flips from green to yellow. One look is enough: things are getting tight, and the license may need to be expanded.

At the end of the year, graduating classes leave and their accounts are deleted from the system. The time series panel registers the drop, and the percent arrow in the Stat panel goes red with a negative value. Once the number falls back below the warning band, it returns to green. Consolidation phases like these show that your data hygiene is working, and they give you a realistic basis for capacity planning.

In larger environments, the same metrics can also feed automated alerts. Prometheus evaluates alert rules and passes any triggered alerts to Alertmanager, which then notifies the admin team by email or chat, for example, when the user limit hits 90 percent. The dashboard is what you check on purpose; the alerts make sure nothing slips past.

The setup in this article monitors a single Nubus instance. In practice, single instances are rare. Educational providers, municipalities, and other organizations often run dozens or hundreds of deployments, one per school, per site, per department. This is exactly where the approach shown here scales without much effort.

Prometheus can query any number of endpoints. To bring in another Nubus instance, add it as one more entry under static_configs in prometheus.yml. Because every metric carries the domain label automatically, Grafana keeps the instances neatly separated. What starts as a handful of panels for one instance becomes an overview dashboard for many.

PromQL, Prometheus’s own query language, handles the rest. It offers aggregation operators that summarize or filter metrics across any set of labels. An expression like sum(nubus_users_user_total) returns the total user count across every instance you monitor. Others, such as topk, avg, or count, open up different views: the five largest environments, for example, or the average number of users per site. You’ll find the full list of operators in the Prometheus documentation, and examples of common queries in the Query Examples chapter.

The new metrics endpoint gives Nubus an interface to Prometheus and makes central identity management fit right in with the monitoring tools you already run. If Prometheus and Grafana are handling your other services, a few lines of configuration bring Nubus into the same setup, on the same dashboard as your servers, databases, and web applications.

A single query on the command line answers the question of where things stand right now. The time series in a Grafana panel shows how they develop, which gives you a solid basis for capacity planning, license management, and the assessment of operational processes. For small environments, that’s a useful tool. For large ones with many instances, it becomes the foundation for dependable statements about your own infrastructure.

As of July 2026, the endpoint delivers three metrics. That’s enough for a first overview, and it lays the groundwork for the metrics to come in future releases. A good moment to set up monitoring for your own Nubus.