The OpenMetrics endpoint added in 33 already covers a lot, and it makes something practical
that wasn't before: reading an instance's state from outside, without shell access on it. Two
small additions would carry that further.
For context, I maintain an open-source monitoring dashboard for Nextcloud instances, which is
where both of these come from.
1. A shipped flag on the app inventory
Today:
# 33.0.6
nextcloud_apps_info{activity="6.0.0",dav="1.36.0",…} 1
# 34.0.1
nextcloud_app_enabled{app_id="activity",version="7.0.0"} 1
Knowing whether an app ships with the server would make this inventory directly comparable with
the app store. Bundled apps have frozen store entries and versions that track the release, so
today they all read as outdated in such a comparison; with the flag, the metric alone is enough
to tell which third-party apps are genuinely behind.
nextcloud_app_enabled{app_id="activity",version="7.0.0",shipped="1"} 1
IAppManager::isShipped() already has it, and it's one label on a metric that's already emitted.
2. Setup check results
occ setupchecks and Settings → Overview already compute a full health picture. Exposing it as
metrics would allow tracking it over time and alerting on regressions, which the CLI form
doesn't lend itself to.
nextcloud_setupcheck{check="DatabaseHasMissingIndices",category="database"} 2
Descriptions and documentation links wouldn't survive the metric model, but the per-check status
is the actionable part.
Context: I first raised the setup checks part in nextcloud/serverinfo#960, which was closed with
a pointer to OpenMetrics, on the grounds that serverinfo shouldn't depend on other apps. That
makes sense and since neither of these is app-specific, nextcloud/server seemed the right
place for them.
Happy to split this into two issues if that's easier to track.
One question that stayed open on #960: is serverinfo expected to keep evolving, or will
monitoring data progressively move to OpenMetrics? Knowing which surface to build against
would help.
The OpenMetrics endpoint added in 33 already covers a lot, and it makes something practical
that wasn't before: reading an instance's state from outside, without shell access on it. Two
small additions would carry that further.
For context, I maintain an open-source monitoring dashboard for Nextcloud instances, which is
where both of these come from.
1. A
shippedflag on the app inventoryToday:
Knowing whether an app ships with the server would make this inventory directly comparable with
the app store. Bundled apps have frozen store entries and versions that track the release, so
today they all read as outdated in such a comparison; with the flag, the metric alone is enough
to tell which third-party apps are genuinely behind.
IAppManager::isShipped()already has it, and it's one label on a metric that's already emitted.2. Setup check results
occ setupchecksand Settings → Overview already compute a full health picture. Exposing it asmetrics would allow tracking it over time and alerting on regressions, which the CLI form
doesn't lend itself to.
Descriptions and documentation links wouldn't survive the metric model, but the per-check status
is the actionable part.
Context: I first raised the setup checks part in nextcloud/serverinfo#960, which was closed with
a pointer to OpenMetrics, on the grounds that serverinfo shouldn't depend on other apps. That
makes sense and since neither of these is app-specific, nextcloud/server seemed the right
place for them.
Happy to split this into two issues if that's easier to track.
One question that stayed open on #960: is serverinfo expected to keep evolving, or will
monitoring data progressively move to OpenMetrics? Knowing which surface to build against
would help.