Nextcloud

Si Nextcloud sert bien ou est bloqué : mode maintenance laissé actif, une mise à jour de base de données en attente après une mise à jour, mises à jour de Nextcloud et des applications, utilisateurs actifs, espace libre pour le répertoire de données, taille de la base de données, et l’OPcache de PHP.

Ports réseau à ouvrir

Du serveur DumbMonit (ou de son agent relais) vers l’équipement :

Port	Protocole	Usage
443	TCP	API (HTTPS, par défaut)
80	TCP	Seulement avec l’option de schéma http

DumbMonit lit le status.php public et les statistiques de l’application serverinfo, fournie avec Nextcloud, avec un jeton de surveillance (NC-Token). Le jeton ouvre ces statistiques et rien d’autre : il ne peut pas se connecter, lister les utilisateurs, ouvrir un fichier ni changer un réglage.

La panne à surveiller : une mise à jour qui ne s’est pas terminée. Après une mise à jour, Nextcloud peut rester en mode maintenance, ou attendre occ upgrade ; la page web montre alors un avis que personne ne voit jusqu’à ce que quelqu’un essaie de synchroniser. Les deux sont lus depuis status.php, qui répond même alors.

Ce qu’il surveille

Toutes les métriques sont préfixées dumbmonit_nextcloud_.

Métrique	Quoi	Labels
`maintenance`	1 tant que le mode maintenance est actif
`needs_db_upgrade`	1 tant que Nextcloud attend `occ upgrade`
`version_info`	valeur 1	`version`
`update_available`	1 quand la propre vérification de mise à jour de Nextcloud a trouvé une release plus récente	`available_version`
`apps_installed`, `app_updates_available`	applications installées, et combien ont une version plus récente dans la boutique d’applications
`app_update_available`	valeur 1 par application avec une mise à jour (32 au plus)	`app`, `available_version`
`active_users`	utilisateurs vus dans les 5 dernières minutes, l’heure, le jour, la semaine et le mois	`window` (`5m`, `1h`, `24h`, `7d`, `30d`)
`users`, `files`, `shares`	comptes, fichiers et partages sur l’instance
`free_space_bytes`	espace libre où Nextcloud garde ses données
`database_size_bytes`	taille de la base de données
`platform_info`	valeur 1	`database`, `database_version`, `php_version`
`php_memory_limit_bytes`	`memory_limit` de PHP
`extended_support`	1 quand cette version est sortie du support standard (correctifs Enterprise seulement)
`disabled_users`	comptes désactivés
`storages`	stockages par type	`kind` (`local`, `home`, `other`)
`shares_by_type`	partages par type	`type` (`user`, `group`, `link`, `mail`, `room`, `federated_sent`, `federated_received`)
`shares_link_without_password`	liens publics sans mot de passe
`cpu_count`, `cpu_load`	cœurs et charge moyenne de l’hôte Nextcloud	`window` (`1m`, `5m`, `15m`) pour `cpu_load`
`memory_total_bytes`, `memory_free_bytes`, `memory_used_percent`	mémoire de l’hôte
`swap_total_bytes`, `swap_free_bytes`, `swap_used_percent`	swap de l’hôte
`php_max_execution_time_seconds`, `php_upload_max_filesize_bytes`	limites PHP qui bornent les longues tâches et les envois
`debug_mode`	1 quand `debug` est actif dans `config.php`
`file_locking_enabled`, `memcache_local_enabled`, `memcache_distributed_enabled`, `memcache_locking_enabled`	verrouillage des fichiers, et quels caches sont configurés
`update_check_age_seconds`	ancienneté de la dernière vérification de mise à jour de Nextcloud, tâche de fond quotidienne : elle reste basse en bonne santé et ne cesse de croître quand le cron ne tourne pas (écrite seulement une fois la vérification passée au moins une fois)
`apcu_hit_rate_percent`, `apcu_memory_used_percent`, `apcu_expunges`	APCu, le cache mémoire local
`opcache_cached_keys_used_percent`, `opcache_wasted_percent`	emplacements de scripts d’OPcache utilisés (ils se remplissent avant la mémoire) et mémoire gaspillée
`opcache_enabled`, `opcache_full`	OPcache activé ; OPcache sans place
`opcache_memory_used_percent`, `opcache_interned_strings_used_percent`, `opcache_hit_rate_percent`, `opcache_oom_restarts`	à quel point OPcache est plein et comme il sert bien
`fpm_active_processes`, `fpm_total_processes`, `fpm_listen_queue`, `fpm_max_children_reached`, `fpm_slow_requests`	pool PHP-FPM, quand Nextcloud tourne derrière PHP-FPM (les images `-fpm`, AIO)

Pendant que Nextcloud est en maintenance ou attend une mise à niveau, son API répond 503 : seuls maintenance, needs_db_upgrade et version_info sont alors écrits, et la surveillance n’est pas rapportée inaccessible.

Les règles intégrées qui s’appliquent :

Règle	Se déclenche quand
Nextcloud stuck in maintenance	mode maintenance actif depuis 30 minutes
Nextcloud database upgrade pending	`occ upgrade` en attente depuis 10 minutes (critique)
Nextcloud update available	une release plus récente existe (info)
Nextcloud OPcache full	OPcache sans mémoire depuis 30 minutes
Nextcloud free space low	moins de 5 Gio libres depuis 30 minutes
Nextcloud in debug mode	`debug` actif depuis une heure
Nextcloud OPcache script slots almost full	95 % des emplacements utilisés depuis une heure
Nextcloud OPcache restarting	OPcache redémarré faute de mémoire dans la dernière heure
Nextcloud background jobs seem stopped	aucune vérification de mise à jour depuis 14 jours
Nextcloud PHP memory limit low	`memory_limit` sous 512 Mio (info, illimité accepté)
Nextcloud PHP-FPM out of workers	`pm.max_children` atteint dans les 30 dernières minutes
Nextcloud PHP-FPM queue building up	plus de 10 requêtes en attente depuis dix minutes
Nextcloud app updates waiting	mises à jour d’applications en attente depuis trois jours (info)
Nextcloud version out of standard support	`extended_support` vaut 1

plus Surveillance inaccessible.

Tâches de fond (cron)

Nextcloud ne dit pas au jeton de surveillance quand les tâches de fond ont tourné pour la dernière fois : seul un compte avec tous les droits sur l’instance peut le lire, et DumbMonit n’en demande pas un. Deux choses le remplacent. La règle Nextcloud background jobs seem stopped surveille l’ancienneté de la vérification quotidienne des mises à jour, elle-même une tâche de fond (si vous avez coupé le vérificateur dans config.php, désactivez cette règle). Pour une réponse précise, surveillez le cron avec un battement de cœur : créez-en un dans DumbMonit, puis appelez son URL à la fin de la ligne cron qui lance les tâches de fond de Nextcloud, pour qu’il n’appelle que lorsque cron.php a réussi :

*/5 * * * * php -f /var/www/html/cron.php && curl -fsS -m 10 --retry 3 https://monit.example.com/api/push/<token> > /dev/null

Avec un intervalle attendu de 5 minutes, le battement de cœur alerte dès que le cron s’arrête, quelle qu’en soit la raison (un conteneur redémarré sans son cron, une erreur PHP, les tâches de fond laissées sur AJAX).

Appareils clients

Nextcloud n’expose aucune liste à l’échelle administrateur des clients de synchro ou des appareils mobiles via une API. La page personnelle « Devices & sessions » (Settings → Security) ne liste que le compte actuellement connecté, portée par une session de navigateur plutôt qu’un jeton d’API, et le seul équivalent à l’échelle administrateur est la ligne de commande (occ user:auth-tokens:list <user>, un compte à la fois) — pas quelque chose que le jeton de surveillance peut atteindre, et pas quelque chose que DumbMonit demande à un administrateur de scripter dans une sonde. L’API serverinfo que DumbMonit lit n’a pas non plus de liste d’appareils : elle donne des compteurs d’utilisateurs actifs (active_users, ci-dessus), jamais qui ou quoi ils sont.

C’est une limite délibérée, pas une fonctionnalité manquante : donner à DumbMonit une liste d’appareils signifierait élargir le jeton de surveillance en un compte d’administration complet, ce que le reste de cette page évite soigneusement. Si Nextcloud expose un jour cela via OCS, DumbMonit suivra le même schéma appareils clients déjà utilisé pour Immich, Proxmox Backup Server et Veeam.

La page de la surveillance

Le panneau au-dessus des graphiques lit ce que la sonde a stocké ; ouvrir la page n’appelle jamais Nextcloud. Il dit d’abord ce qui ne va pas (maintenance, mise à niveau en attente, OPcache plein ou désactivé), puis les mises à jour, puis les utilisateurs actifs, l’espace libre, la taille de la base de données, les utilisateurs, fichiers et chiffres OPcache, puis les applications à mettre à jour par nom et la plateforme (base de données, PHP).

Donner à Nextcloud un jeton de surveillance

Sur le serveur Nextcloud, posez un jeton aléatoire avec occ en tant qu’utilisateur du serveur web (sous Docker : docker exec -u www-data, puis le nom du conteneur).
```
php occ config:app:set serverinfo token --value "$(openssl rand -hex 32)"
php occ config:app:get serverinfo token
```
Si occ dit que serverinfo est désactivée, activez l’application Monitoring : menu du profil → Applications → Monitoring → Activer.
Dans DumbMonit, saisissez l’adresse avec laquelle vous ouvrez Nextcloud et collez le jeton.

Documentation de l’éditeur : https://github.com/nextcloud/serverinfo#api

Pourquoi un jeton, et pourquoi occ

L’application serverinfo de Nextcloud répond à un jeton de surveillance qui ouvre ses statistiques et rien d’autre : aucun fichier, aucun utilisateur, aucun partage, et le jeton ne permet de se connecter nulle part. L’application Monitoring ne documente aucun écran pour définir ce jeton : occ est donc le moyen de le poser. DumbMonit lit seulement status.php et les statistiques de serverinfo : il n’ouvre jamais un fichier, ne liste jamais les utilisateurs et ne change aucun réglage.

Juste après la pose du jeton, Nextcloud peut refuser la toute première lecture (401) avant qu’il ne soit pris en compte : DumbMonit réessaie une fois après deux secondes, si bien qu’une cible toute neuve n’affiche pas d’erreur « jeton refusé » parasite. Pour activer l’application en ligne de commande, php occ app:enable serverinfo fait la même chose que la page Applications.

L’adresse doit faire partie des domaines de confiance de Nextcloud (trusted_domains dans config.php).

Avec Nextcloud AIO, lancez occ dans le conteneur nextcloud-aio-nextcloud : docker exec -u www-data nextcloud-aio-nextcloud php occ …. Pourquoi pas un groupe d’administration délégué : Nextcloud n’ouvre l’API serverinfo qu’au jeton ou aux membres du groupe admin complet, et la délégation ne change pas ça.

Vérifier le jeton à la main, depuis l’hôte DumbMonit :

curl -H 'NC-Token: YOUR-TOKEN' 'https://cloud.example.com/ocs/v2.php/apps/serverinfo/api/v1/info?format=json'

Dépannage

401 à la première lecture. Le jeton vient d’être posé et Nextcloud ne l’a pas encore pris en compte : DumbMonit réessaie une fois après deux secondes. Un jeton qui reste refusé est faux, ou l’application serverinfo est désactivée.
« Untrusted domain » ou une page HTML. L’adresse n’est pas dans trusted_domains (config.php).
Peu de métriques, et maintenance vaut 1. Normal tant que Nextcloud est en maintenance ou attend occ upgrade : son API répond 503 et la surveillance n’est pas rapportée inaccessible.
Pas de update_check_age_seconds. Le vérificateur de mises à jour est coupé ou n’a jamais tourné.
Pas de séries fpm_* ou apcu_*. Nextcloud tourne sous Apache avec mod_php (pas de PHP-FPM), ou APCu n’est pas installé.
Pas de contrôle d’intégrité ni de dates des tâches de fond. Le jeton de surveillance ne peut pas les lire, par conception : voir « Tâches de fond (cron) » ci-dessus.

Identifiants

Identifiant	Champs
Jeton de surveillance (NC-Token)	Le jeton serverinfo. DumbMonit l’envoie dans l’en-tête `NC-Token`, avec `OCS-APIRequest: true`.

Adresse : un nom d’hôte (cloud.example.com), host:port, ou une URL complète avec un préfixe de chemin (https://example.com/nextcloud) ; un /index.php ou /login final est accepté. Options : protocole (HTTPS par défaut), port (443), vérification du certificat et délai de requête (15 s).

Le compteur de mises à jour d’applications demande le cache de la boutique d’applications de Nextcloud ; sur une instance qui ne peut pas atteindre la boutique, ce compteur reste à 0.

Validé avec Nextcloud 35.0.1 (image officielle).