Cedric Abonnel
135 lines
4.1 KiB
Markdown
135 lines
4.1 KiB
Markdown
*(Méthode basée sur l’installation via le script communautaire Proxmox : [https://community-scripts.github.io/ProxmoxVE/scripts?id=uptimekuma](https://community-scripts.github.io/ProxmoxVE/scripts?id=uptimekuma))*
|
||
|
||
Lorsque Uptime Kuma rencontre des problèmes de démarrage, des erreurs dans la base SQLite, ou des comportements anormaux après une mise à jour, il peut être nécessaire d’effectuer une série de vérifications et de corrections. Le guide ci-dessous détaille les étapes recommandées pour diagnostiquer et réparer votre instance Uptime Kuma tout en minimisant les risques de perte de données.
|
||
|
||
---
|
||
|
||
## 1. Arrêt du service Uptime Kuma
|
||
|
||
Avant toute manipulation sur les fichiers de données, il est indispensable d’arrêter correctement le service :
|
||
|
||
```bash
|
||
systemctl stop uptime-kuma
|
||
```
|
||
|
||
L’arrêt garantit que la base SQLite ne subit aucune écriture pendant la maintenance. Sans cela, on risque d’aggraver les corruptions ou de provoquer des pertes de données.
|
||
|
||
---
|
||
|
||
## 2. Accéder au dossier de l’application
|
||
|
||
Le script communautaire installe généralement Uptime Kuma dans `/opt/uptime-kuma` :
|
||
|
||
```bash
|
||
cd /opt/uptime-kuma
|
||
```
|
||
|
||
Ce répertoire contient le code de Kuma ainsi que le dossier `data`, qui renferme toutes les données utilisateur, les paramètres, les historiques de monitoring et la base de données `kuma.db`.
|
||
|
||
---
|
||
|
||
## 3. Sauvegarde des données avant intervention
|
||
|
||
Avant toute réparation, il est impératif de créer une copie de la base SQLite :
|
||
|
||
```bash
|
||
cp -r data data-backup-$(date +%Y%m%d)
|
||
```
|
||
|
||
Cette sauvegarde permet de revenir en arrière en cas de problème.
|
||
Elle inclut notamment :
|
||
|
||
* la base de données `kuma.db`
|
||
* les historiques de monitoring
|
||
* les configurations des sondes
|
||
* les paramètres de l’interface
|
||
|
||
⚠️ **Ne jamais sauter cette étape**, surtout si vous modifiez la base à la main.
|
||
|
||
---
|
||
|
||
## 4. Vérification de l’intégrité de la base SQLite
|
||
|
||
On se rend ensuite dans le dossier des données :
|
||
|
||
```bash
|
||
cd data/
|
||
```
|
||
|
||
Puis on effectue une vérification complète :
|
||
|
||
```bash
|
||
sqlite3 kuma.db "PRAGMA integrity_check;"
|
||
```
|
||
|
||
Cette commande retourne :
|
||
|
||
* **ok** → la base est saine
|
||
* un ou plusieurs messages d’erreur → corruption ou index endommagé
|
||
|
||
Selon le résultat, il faudra peut-être appliquer une des corrections suivantes.
|
||
|
||
---
|
||
|
||
## 5. Suppression d’un paramètre problématique dans la base
|
||
|
||
Certaines versions d’Uptime Kuma ont rencontré un problème lié à l’entrée `migrateAggregateTableState` dans la table `setting`.
|
||
Si cette clé est corrompue ou mal migrée, elle peut empêcher le service de démarrer.
|
||
|
||
La correction consiste à supprimer cette entrée :
|
||
|
||
```bash
|
||
sqlite3 kuma.db "DELETE FROM setting WHERE key = 'migrateAggregateTableState';"
|
||
```
|
||
|
||
Cette action force Uptime Kuma à recréer proprement l’état de migration au prochain démarrage.
|
||
|
||
---
|
||
|
||
## 6. Solution extrême : vider toute la table `heartbeat`
|
||
|
||
Si les problèmes concernent uniquement les historiques (table heartbeat corrompue), une solution radicale consiste à vider la table :
|
||
|
||
```bash
|
||
sqlite3 kuma.db "DELETE FROM heartbeat;"
|
||
```
|
||
|
||
⚠️ Cette commande supprime **tout l’historique des sondes**, mais ne touche pas aux sondes ni aux paramètres.
|
||
À utiliser uniquement en dernier recours si :
|
||
|
||
* la vérification SQLite échoue
|
||
* Uptime Kuma ne démarre plus
|
||
* l’historique est corrompu
|
||
|
||
---
|
||
|
||
## 7. Redémarrage du service
|
||
|
||
Une fois les corrections effectuées :
|
||
|
||
```bash
|
||
systemctl start uptime-kuma
|
||
```
|
||
|
||
Si la base est correcte, Uptime Kuma devrait redémarrer normalement.
|
||
|
||
---
|
||
|
||
## 8. Consultation des journaux pour valider les corrections
|
||
|
||
Pour suivre en temps réel les messages du service et détecter d’éventuelles anomalies persistantes :
|
||
|
||
```bash
|
||
journalctl -u uptime-kuma -f
|
||
```
|
||
|
||
Points à surveiller dans les logs :
|
||
|
||
* erreurs SQLite
|
||
* migrations bloquées
|
||
* permissions incorrectes
|
||
* modules Node.js manquants
|
||
* services stoppés subitement
|
||
|
||
Les journaux permettent de confirmer que la base est stable et que le service démarre correctement.
|