Identifier un problème par tâche

Des symptômes aux étapes concrètes de dépannage

Cette page couvre la première connexion, les clés SSH, VNC, les services d’inférence MLX, l’intégration continue et les problèmes de commande sur les nœuds Mac physiques dédiés VMMini dans le cloud. Commencez par les vérifications de base, puis envoyez un ticket avec les journaux et la période concernée.

La page ne vous demandera jamais votre mot de passe, votre clé privée ou vos informations de récupération. Pour une commande existante, connectez-vous au portail pour envoyer un ticket et associer automatiquement la commande et le nœud.

Envoyer un ticket via le portail Lire le guide de démarrage
Procédure d’exécution Identifier, collecter, envoyer
Parcours clair
03 Étapes du dépannage
Symptôme Connexion, build, stockage, service ou commande
Preuves Heure, commandes, code de sortie et journaux anonymisés
Action Récupération autonome ou ticket associé à la commande
Nœuds disponibles Singapour · Japon (Tokyo) · Corée du Sud (Séoul) · Hong Kong
Recherche rapide

Saisissez un message d’erreur, un outil ou l’objectif de la tâche

La recherche porte sur les guides, les procédures de dépannage et le glossaire de cette page. Si le message contient un numéro de commande, un nom d’hôte ou une adresse, anonymisez-le avant de lancer la recherche.

Connexion et accès

Vérifiez d’abord les informations de livraison, puis choisissez le mode de connexion

Les problèmes de connexion proviennent souvent de l’adresse, du port, des droits de la clé, du cache client ou du chemin réseau local. Ne sautez pas la vérification avant d’avoir confirmé l’empreinte de l’hôte.

SSH : commencez par l’empreinte de l’hôte

Préparez l’adresse de l’hôte, le port SSH, le nom d’utilisateur et le fichier de clé privée correspondant à la clé publique. Conservez la clé privée sur un appareil contrôlé ou dans un gestionnaire de clés ; ne la collez pas dans un ticket.

  1. Première connexion :Comparez segment par segment l’empreinte affichée dans le portail avec l’invite du client.
  2. Vérification des droits :Vérifiez que seul l’utilisateur actuel peut lire le fichier de clé privée et que la clé publique n’a pas été altérée par des retours à la ligne.
  3. Dépannage des déconnexions :Vérifiez successivement le réseau local, le DNS ou l’adresse, l’accessibilité du port, ainsi que la correspondance entre utilisateur et clé.
  4. Collecte des preuves :Conservez la sortie détaillée avec son horodatage, en supprimant les éléments sensibles des adresses, noms d’utilisateur et chemins de clés.
ssh -vvv -p <port> <user>@<host>

VNC : vérifiez d’abord la session et l’affichage

Préparez l’adresse du nœud, le port, les identifiants de connexion et une session graphique disponible. Conservez les identifiants dans un gestionnaire de mots de passe ; ne les inscrivez ni dans un dépôt de scripts ni dans les journaux de build.

  1. Première connexion :Vérifiez la version du système, l’espace disque, le fuseau horaire, la disposition du clavier et l’état actuel du réseau.
  2. Écran noir :Vérifiez d’abord que la session graphique fonctionne toujours, puis contrôlez la profondeur de couleur et le réglage du zoom du client.
  3. Déconnexions fréquentes :Notez l’heure, la durée, le type de réseau local et la possibilité d’accéder simultanément au nœud via SSH.
  4. Affichage saccadé :Réduisez la qualité d’affichage pour effectuer un test comparatif ; ne concluez pas à une panne du nœud sur la base d’un seul ralentissement du client.

Bureau à distance : vérifiez séparément le client et le nœud

Vérifiez d’abord que le client utilisé prend en charge le mode de connexion fourni, puis contrôlez l’adresse, le port et les identifiants de session. Ne réessayez pas avec d’anciens identifiants expirés : cela pourrait masquer la véritable cause de l’erreur.

  1. Côté local :Désactivez le proxy ou changez de réseau pour comparer les résultats ; notez la version du client et le message d’erreur exact.
  2. Côté nœud :Si SSH fonctionne, vérifiez les processus du service graphique, l’espace disque disponible et la charge du système.
  3. Côté réseau :Comparez les résultats sur différents réseaux afin de déterminer si le problème se limite à un seul itinéraire.
  4. Envoi du ticket :Indiquez l’identifiant de commande, le nœud, l’heure de l’incident et des captures anonymisées ; ne fournissez pas le mot de passe de connexion.
Assistance à l’inférence MLX

Cinq points de contrôle pour localiser un problème de service de modèle

Commencez par confirmer l’intégrité de l’environnement d’exécution et des fichiers du modèle, puis vérifiez l’adresse d’écoute, l’interface de santé et les journaux. N’ouvrez que les ports nécessaires au service et limitez les sources autorisées.

01

Confirmer l’environnement

Notez les versions de macOS et de Python, le chemin de l’environnement virtuel, les versions des paquets MLX et l’espace disque disponible. Vérifiez que la tâche s’exécute sur un nœud physique dédié VMMini M4, M4, 16GB, 256GB SSD, et non avec des paramètres d’environnement partagé.

02

Préparer le modèle

Vérifiez le chemin des fichiers du modèle, leur nombre, le résultat de la vérification et l’espace requis. Placez le modèle et le cache dans des répertoires clairement définis afin d’éviter que le téléchargement et le service n’écrivent simultanément dans le même emplacement temporaire.

03

Vérifier l’écoute

Liez d’abord le service à l’adresse locale pour le valider, puis élargissez l’écoute selon les besoins réels. Vérifiez que le port n’est pas utilisé par un autre processus et que seuls les ports et sources nécessaires sont accessibles.

04

Effectuer le contrôle de santé

Appelez l’interface de santé depuis le nœud lui-même et notez le statut HTTP, le temps de réponse et le contenu renvoyé. Si l’appel local réussit mais l’accès externe échoue, examinez le port, les règles d’accès et le chemin réseau au lieu de redémarrer le modèle en boucle.

05

Collecter des journaux reproductibles

Conservez une version anonymisée de la commande de démarrage, la sortie standard, la sortie d’erreur, le code de sortie, le nom du modèle et l’heure de l’incident. Supprimez tout jeton d’accès, corps de requête ou donnée utilisateur avant l’envoi.

Contrôle de santé local

Valider d’abord le service via l’adresse de bouclage

Remplacez le port réel et le chemin de santé dans la commande. L’interface de santé doit rester légère et stable, sans lancer une tâche d’inférence complète.

curl --fail --show-error \
  --max-time 10 \
  http://127.0.0.1:<port>/health
Assistance à l’intégration continue

Un runner révocable, nettoyable et reproductible

Un self-hosted runner n’est pas qu’un processus permanent. L’enregistrement, les identifiants, le cache, les artefacts et la révocation doivent avoir un responsable et des limites de conservation clairement définis.

01

Enregistrer le runner

Utilisez un compte de service dédié et un répertoire de travail indépendant. Notez le nom du runner, ses étiquettes, le projet associé et la date d’enregistrement. Les étiquettes doivent décrire les capacités réelles afin d’éviter qu’un projet ne soit envoyé par erreur vers le même répertoire.

Critère de réussite Le runner est identifiable dans la file et la tâche de test renvoie un code de sortie explicite.
02

Isoler les identifiants du projet

Séparez les jetons par projet et par environnement, en privilégiant un gestionnaire de secrets contrôlé ou les variables d’environnement d’exécution. N’écrivez jamais d’identifiants longue durée dans le dépôt, les sauvegardes de configuration du runner ou les artefacts téléchargeables.

Critère de réussite Les journaux de tâche n’affichent aucun secret et la révocation d’un projet n’affecte pas les autres.
03

Gérer le cache de build

Utilisez des répertoires distincts pour le cache des dépendances, DerivedData, les fichiers temporaires et les archives. En cas de manque d’espace, identifiez d’abord la source de la croissance, puis nettoyez par projet ; ne supprimez pas directement un répertoire utilisé par une tâche en cours.

Critère de réussite Le chemin du cache est traçable et le nettoyage ne supprime pas les artefacts finaux.
04

Conserver les artefacts de build

Associez à chaque artefact la version commit, le numéro de build, la version de la chaîne d’outils et les informations de vérification. À la fin de la tâche, déplacez les fichiers à conserver hors du répertoire de travail du runner afin qu’ils ne soient pas supprimés lors du nettoyage du cache.

Critère de réussite Les journaux d’échec comme les artefacts réussis correspondent à la même exécution de build.
05

Révoquer le runner en toute sécurité

Arrêtez d’abord l’acceptation de nouvelles tâches et attendez la fin du travail en cours. Révoquez ensuite le jeton d’enregistrement depuis le projet et supprimez le service. Vérifiez enfin que le répertoire de travail, le cache et les identifiants ont été traités conformément au plan de migration des données.

Critère de réussite Le contrôleur ne planifie plus de tâches et aucun identifiant d’enregistrement réutilisable ne subsiste sur le nœud.
Petit glossaire

Huit termes pour parler le même langage

Employer une terminologie cohérente évite de confondre les problèmes de nœud, de logiciel, de réseau et de facturation.

Nœud physique
Hôte Mac Mini M4 réellement attribué à la commande. Il s’agit d’un nœud matériel Mac dans le cloud, et non d’une instance virtuelle.
Dédié
La commande utilise le processeur, la mémoire et le stockage local de toute la machine physique, sans partager ces ressources avec une autre commande.
VNC
Mode d’affichage distant permettant d’accéder à l’interface graphique de macOS. Lors du dépannage, distinguez la session graphique, le client et le réseau.
self-hosted runner
Agent d’exécution de l’intégration continue enregistré et géré par l’équipe ; il récupère les tâches, lance les builds et renvoie les journaux et artefacts.
MLX
Écosystème d’outils de machine learning pour Apple Silicon, utilisable pour préparer des modèles, expérimenter l’inférence et valider leur mise en service.
Cache de build
Données conservées pour éviter les téléchargements et compilations répétitifs, notamment le cache des dépendances, DerivedData et les fichiers intermédiaires générés par les outils.
Nœud
Région de service où se trouve l’hôte physique. Le catalogue actuel comprend quatre nœuds : Singapour, Japon (Tokyo), Corée du Sud (Séoul) et Hong Kong.
Cycle de facturation
Période d’utilisation choisie pour la commande, disponible à la journée, à la semaine, au mois ou au trimestre. Le cycle, la date de début et la date d’expiration sont ceux indiqués dans le portail.
Arbre de diagnostic

Choisissez l’étape suivante selon le symptôme ; ne modifiez pas plusieurs paramètres à la fois

Ne changez qu’une condition à la fois et consignez le résultat. Réinitialiser plusieurs réglages simultanément efface les limites du problème et empêche l’équipe d’assistance de le reproduire.

NET Impossible de se connecter au nœud Délai dépassé, connexion refusée, empreinte modifiée ou identifiants incompatibles
À vérifier d’abord

Vérifiez que la commande est valide, que l’adresse et le port correspondent au nœud actuel, que le réseau local atteint le port cible et que le nom d’utilisateur correspond à la clé.

Informations à collecter

Heure de l’incident, version du client, message exact, sortie détaillée anonymisée et comparaison après changement de réseau.

Quand envoyer un ticket

Si la connexion échoue sur deux réseaux indépendants, ou si l’empreinte de l’hôte diffère de celle du portail, cessez les tentatives et envoyez un ticket.

BLD Échec du build Résolution des dépendances, compilation, signature ou anomalie de tâche du runner
À vérifier d’abord

Vérifiez que le commit, le fichier de verrouillage, la chaîne d’outils, les variables d’environnement, les étiquettes du runner et le répertoire de travail correspondent au dernier build réussi.

Informations à collecter

Code de sortie complet, journaux avant et après l’étape en échec, commande de build, versions des outils et résultat comparatif après nettoyage du cache.

Quand envoyer un ticket

Envoyez un ticket si le même commit et la même configuration échouent encore systématiquement dans un répertoire propre et que les journaux indiquent un problème système ou disque du nœud.

DSK Espace disque insuffisant Le modèle, le cache de build, les journaux ou les archives augmentent continuellement
À vérifier d’abord

Mesurez l’espace occupé par répertoire et distinguez modèles, cache des dépendances, DerivedData, journaux, fichiers temporaires et artefacts finaux à déplacer.

Informations à collecter

Espace libre du système de fichiers, répertoires les plus volumineux, début de la croissance, tâches en cours et dernier nettoyage effectué.

Quand envoyer un ticket

Envoyez un ticket si le rapport du système de fichiers ne correspond pas aux statistiques des répertoires, ou si l’espace ne se libère pas après suppression des éléments nettoyables.

SRV Service sans réponse Le processus existe, mais l’interface de santé expire ou reste inaccessible de l’extérieur
À vérifier d’abord

État du processus, adresse d’écoute, occupation du port, contrôle de santé local, mémoire disponible et dernières sorties d’erreur standard.

Informations à collecter

Version anonymisée de la commande de démarrage, code de sortie, résultats des requêtes locales et externes, temps de réponse et période des journaux du service.

Quand envoyer un ticket

Envoyez un ticket si la requête locale échoue également avec une anomalie système dans les journaux, ou si plusieurs services cessent de répondre simultanément.

ORD Anomalie de commande dans le portail L’état, le cycle, le nœud ou les données de facturation ne correspondent pas aux attentes
À vérifier d’abord

Vérifiez que l’identifiant de commande, la configuration VMMini M4 choisie, le nœud, le cycle de facturation, les options et le paiement appartiennent à la même commande.

Informations à collecter

Identifiant de commande, état affiché, heure, étapes suivies et captures anonymisées. Ne transmettez pas les informations de paiement complètes.

Quand envoyer un ticket

Si l’incohérence persiste après actualisation et reconnexion, ou si l’opération sur la commande reste impossible, envoyez un ticket associé depuis le portail.

Disponibilité du service

Nœuds actifs toute l’année, événements vérifiés avec les commandes

Les nœuds VMMini sont conçus pour fonctionner normalement 365 jours par an. La disponibilité et les événements de chaque commande sont déterminés par les informations en temps réel et les enregistrements associés du portail.

Périmètre des quatre nœuds Tous les nœuds du catalogue peuvent être sélectionnés pour une commande VMMini M4 ; la disponibilité réelle est affichée en temps réel dans le portail.
Voir les événements de la commande

Singapour

Les équipes et charges de travail d’Asie du Sud-Est peuvent tester ce chemin en priorité.

Japon (Tokyo)

Convient aux comparaisons avec des dépôts de code japonais ou est-asiatiques.

Corée du Sud (Séoul)

Adapté aux tests de connexion depuis les réseaux d’Asie du Nord-Est.

Hong Kong

Permet de comparer les performances des liaisons avec le sud de la Chine et l’Asie du Sud-Est.

Comment déterminer s’il s’agit d’un incident de service : Testez la connexion sur deux réseaux indépendants, puis vérifiez le service local du nœud et l’état du logiciel utilisateur. Un chemin réseau externe, une configuration utilisateur ou l’échec d’un seul processus ne signifie pas nécessairement que le nœud physique est indisponible.
Envoyer une demande d’assistance

Que doit contenir un ticket directement exploitable ?

Pour une commande existante, utilisez de préférence le ticket du portail afin d’associer le nœud, le cycle et les événements. Si vous ne pouvez pas vous connecter, contactez l’équipe à support@vmmini.com.

Liste des informations à fournir

Six informations indispensables

Aucune clé de compte
  1. 01
    Identifiant de commande

    Indiquez l’identifiant de commande affiché dans le portail ; ne le remplacez pas par d’autres informations personnelles visibles sur une capture.

  2. 02
    Nœud concerné

    Indiquez Singapour, Japon (Tokyo), Corée du Sud (Séoul) ou Hong Kong, ainsi que l’hôte correspondant.

  3. 03
    Heure de l’incident

    Indiquez le fuseau horaire, la première occurrence, la dernière reproduction et si le problème persiste.

  4. 04
    Étapes de reproduction

    Énumérez dans l’ordre les commandes, conditions d’entrée, résultats attendus et résultats obtenus.

  5. 05
    Message d’erreur exact

    Conservez le code de sortie et le contexte clé ; n’écrivez pas seulement « impossible à utiliser » ou « échec du build ».

  6. 06
    Journaux anonymisés

    Supprimez les mots de passe, clés privées, jetons d’accès, données utilisateur et adresses complètes inutiles avant de joindre les journaux.

Sans commande ou sans accès au portail

Envoyez un e-mail à support@vmmini.com, en indiquant le type de problème dans l’objet. L’e-mail doit également contenir le nœud, l’heure, les étapes de reproduction et les journaux anonymisés.

Voir les coordonnées

N’envoyez pas ces informations

Mots de passe, clés privées, jetons d’accès, informations de récupération, informations de paiement complètes, données utilisateur non anonymisées et contenu de dépôts sans rapport avec le problème.

Lire la politique de confidentialité des données
Ajoutez les preuves au ticket

Commande existante : associez directement l’enregistrement du nœud pour poursuivre le diagnostic

Préparez l’identifiant de commande, le nœud, l’heure, les étapes de reproduction et les journaux anonymisés. Les tickets du portail servent aux problèmes techniques et de commande ; les demandes commerciales peuvent également être adressées à l’unique adresse d’assistance.

Envoyer un ticket via le portail Lire le guide de démarrage