Votre application s'est arrêtée. Trouvez le premier indice utile.

Définir une défaillance observable

« Arrêté » peut signifier une erreur HTTP, un délai d'attente, une tâche qui ne s'est pas terminée ou un processus qui s'est arrêté. Notez une URL ou une action, sa dernière heure de fonctionnement connue, la première heure de défaillance et votre fuseau horaire. Indiquez si tout le monde est affecté ou un seul client. Gardez la session SSH actuelle ouverte pendant l'investigation ; modifier les règles d'accès n'est pas une première réponse nécessaire à une erreur d'application.

Ce guide suppose un hôte Linux utilisant systemd, un service d'application nommé first-api.service, et un point de terminaison de santé local à 127.0.0.1:3000/healthz. Ces valeurs par défaut correspondent au premier guide de déploiement d'API. Remplacez-les par vos noms réels. L'inspection peut nécessiter des permissions d'administrateur pour voir les processus ou journaux d'autres utilisateurs. Les commandes et sorties ci-dessous sont illustratives ; aucune instance de fournisseur n'a été testée pour ce guide.

Gardez vos notes en dehors du répertoire de l'application en panne. Enregistrez les observations avant les interprétations : « connexion refusée à 09:18 UTC » est un fait ; « le VPS a besoin de plus de CPU » reste une hypothèse. Si le serveur lui-même est inaccessible, utilisez votre accès de récupération établi et collectez les détails de connexion plutôt que de supposer qu'un redémarrage de l'application est possible.

Lire l'état du processus et son historique récent

systemctl status first-api.service --no-pager --full
systemctl show first-api.service -p ActiveState -p SubState -p Result -p ExecMainStatus -p NRestarts

La vue d'état décrit l'invocation en cours ou la plus récente et inclut les messages récents du journal. Les propriétés sélectionnées vous donnent un enregistrement compact à comparer ultérieurement. Un état d'échec ou un nombre de redémarrages croissant mérite une investigation ; un processus actif nécessite encore un test de requête. Ce sont des vérifications différentes, comme décrit dans la référence systemctl upstream.

Si l'unité est manquante, vérifiez d'abord son nom et la méthode de déploiement. Une application démarrée dans un terminal interactif, un conteneur et un service systemd ont des propriétaires et des journaux différents. Créer immédiatement un nouveau service pourrait laisser deux copies se disputer le même port. Identifiez la configuration existante avant de la modifier.

Vérifier l'écouteur et faire une requête locale

sudo ss -ltnp
curl --silent --show-error --max-time 5 http://127.0.0.1:3000/healthz

Recherchez l'adresse et le port attendus, puis identifiez le processus propriétaire. Un processus à l'écoute sur un autre port peut être sain mais inaccessible via le proxy configuré. Un autre processus peut avoir revendiqué le port attendu. Le manuel ss définit les options d'écoute et de processus.

Si la requête locale fonctionne et que la requête publique HTTPS échoue, poursuivez avec les vérifications DNS, TLS et proxy. Si l'écouteur est absent, examinez l'échec de démarrage. Si la connexion réussit mais que l'application renvoie une erreur, enquêtez sur cette route et ses dépendances. Curl sans --fail peut se terminer avec succès pour une réponse d'erreur HTTP, donc lisez la réponse plutôt que de vous fier uniquement à son code de sortie. Voir les options de réponse et d'échec de curl.

Lire autour de la première défaillance, pas seulement la dernière ligne

sudo journalctl -u first-api.service --since "30 minutes ago" --no-pager -n 100
sudo journalctl -k --since "30 minutes ago" --no-pager -n 100

La première requête sélectionne le service ; la seconde sélectionne les messages du noyau. Ajustez l'intervalle pour inclure la dernière requête fonctionnelle et le changement qui a précédé la panne. L'accès et la rétention déterminent ce qui reste disponible. Le référence journalctl upstream explique les filtres d'unité, de temps et de noyau. Masquez les jetons, les données client et les chaînes de connexion avant de partager des extraits.

Extrait illustratif d'une application distincte avec une fonctionnalité de téléversement :

09:18:03 field-api: opening upload directory
09:18:03 field-api: EACCES: permission denied, open '/var/lib/field-api/uploads/index.json'
09:18:03 field-api: startup aborted

Cela pointe vers l'accès de l'utilisateur du service à un chemin spécifique. Vérifiez la propriété du fichier et du répertoire parent par rapport aux instructions de version. N'accordez pas un accès en écriture étendu à l'ensemble du système de fichiers. Un message ultérieur du proxy « upstream unavailable » serait une conséquence dans ce scénario, donc réparer le proxy d'abord manquerait la cause.

Comparer les ressources avec la version la plus récente

free -h
df -h / /opt/first-api
df -i / /opt/first-api

Ces instantanés vous aident à vous demander si une pression mémoire, un espace de système de fichiers ou un épuisement d'inodes a coïncidé avec l'échec. Leur interprétation appartient au guide de la mémoire et du disque; une seule lecture de charge ne prouve pas la cause. Un service peut également atteindre sa propre limite de ressources alors que le reste de l'hôte a de la capacité.

Comparez l'identifiant de version déployé, la commande de démarrage, les noms des variables d'environnement requises et les chemins de données avec la dernière version fonctionnelle. Ne videz pas les valeurs d'environnement secrètes dans un rapport. Recherchez un répertoire renommé, une dépendance d'exécution manquante, un changement de port ou une migration de base de données incompatible. Indiquez ce qui a changé et ce que l'erreur prédit que vous devriez trouver.

Faire une correction justifiée et vérifier la reprise

Choisissez la plus petite correction soutenue par les preuves. Pour l'échec de permission illustratif, cela signifie restaurer l'accès prévu pour le compte de service, puis effectuer une tentative de démarrage contrôlée. Si vous utilisez plutôt une version de code connue comme fonctionnelle, établissez d'abord si son schéma de base de données reste compatible. Un retour arrière de code ne peut pas inverser automatiquement une migration de données.

Après la correction, répétez les mêmes vérifications de service, de point de terminaison local et de requête publique. Confirmez qu'une action représentative de l'application fonctionne, que les nouvelles erreurs ont cessé et que le processus reste stable pendant la prochaine charge de travail normale. Les politiques de redémarrage peuvent aider à récupérer un processus, mais ne rendent pas sain un programme constamment défaillant ; consultez la référence du service systemd pour la politique réelle.

Terminez votre note d'incident avec le symptôme, le premier indice utile, le changement effectué et le résultat de la vérification. Si la cause reste incertaine, signalez cette incertitude avec des preuves masquées plutôt que d'étiqueter un redémarrage temporaire comme une correction permanente. Améliorez la liste de contrôle de version avec la vérification qui aurait permis de détecter cet échec plus tôt.