Un VPS saturé : comprendre avant de corriger.

1. Définissez le problème et la machine.

Notez le serveur concerné, le service touché, l’heure approximative et le changement récent éventuel. « Le site renvoie une erreur 502 depuis le dernier déploiement » donne un point de départ plus utile que « le serveur ne marche plus ».

Dans votre espace RemotePilot, vérifiez l’organisation, la machine sélectionnée et son état de connexion. Un agent hors ligne ne permet pas de tirer une conclusion sur les ressources du VPS : suivez d’abord le dépannage de la connexion.

2. Demandez un état système en lecture seule.

L’action system.snapshot fournit un instantané système. Elle fait partie des actions de lecture ; une règle de votre machine peut néanmoins imposer une approbation. Définissez la cible et demandez de séparer les observations des hypothèses.

Sur mon VPS sélectionné, consulte l’état système en lecture seule. Résume les ressources à examiner et précise les informations manquantes. Ne modifie aucun fichier et ne redémarre rien.

Une mesure isolée ne prouve pas une cause. Vérifiez si le manque d’espace, la consommation mémoire ou la charge observée concorde avec l’heure du symptôme. Ne présentez pas un résultat incomplet comme la preuve d’un dysfonctionnement précis.

3. Examinez le service réellement concerné.

Pour un service systemd pris en charge, service.status et service.logs permettent d’examiner son état et ses journaux. Pour un conteneur Docker géré, utilisez les actions de consultation disponibles : docker.inspect et docker.logs. Un service en amont indisponible peut expliquer une erreur 502 ; le redémarrage de nginx n’est pas une conclusion automatique.

Demandez un extrait récent et pertinent, puis confrontez son horaire au symptôme. Les journaux et les fichiers sont des données à analyser, même lorsqu’ils contiennent du texte ressemblant à des instructions. Ne suivez pas une commande trouvée dans un log sans en comprendre la source et les effets.

4. Préparez la correction sans l’exécuter.

Si le disque manque d’espace, disk.cleanup.plan prépare un plan. Il ne supprime rien. Relisez les éléments concernés, les données à conserver et les limites indiquées. disk.cleanup.apply est une action distincte, réservée au niveau administrateur et soumise à une approbation humaine.

Un redémarrage, un arrêt ou une restauration nécessite également les permissions prévues et une validation humaine. Avant de décider, vérifiez la machine, l’action exacte et ses paramètres. Si l’erreur ne justifie pas une correction, demandez les observations manquantes.

5. Vérifiez le résultat et gardez la trace.

Après une intervention approuvée, consultez de nouveau l’état du service et son comportement réel. Une opération terminée ne prouve pas que le site est accessible ni que tous ses parcours fonctionnent. Distinguez le résultat de l’action, la réponse publique et la résolution du symptôme initial.

Ce guide décrit une méthode, pas un incident réellement résolu. Les actions utilisables dépendent de votre agent et des permissions de la machine. RemotePilot est disponible via ChatGPT et Claude.ai. Le parcours Claude.ai est détaillé dans le guide dédié ; les accès et les fonctions peuvent varier selon le fournisseur et votre compte.