Comment déterminer si une erreur Immich provient du client ou du serveur

Déterminez si une erreur Immich provient du client ou du serveur en reproduisant la même action avec une seule variable modifiée, puis en suivant la requête échouée tout au long de son parcours.

Une bannière mobile indiquant une « erreur du serveur » peut tout de même provenir de l’état du client, de TLS, d’un proxy inverse ou d’une requête correctement rejetée par le serveur. De même, un échec qui ne se produit que dans le navigateur ne prouve pas que celui-ci est défectueux. Conservez le même compte, le même élément et la même action ; comparez les clients et les routes, puis utilisez les codes d’état et des journaux synchronisés pour localiser la première couche qui échoue.

Reproduire la même action sur un deuxième client

Choisissez une action déterministe, comme se connecter, ouvrir un élément connu, téléverser la même petite photo ou lancer la même recherche. Répétez-la avec le même compte dans un navigateur et dans un client mobile, en conservant la même route réseau. Notez l’heure exacte et le résultat des deux tentatives.

Un rapport récent concernant Immich, dans lequel le client Android échouait tandis que d’autres chemins d’accès étaient testés, illustre l’intérêt de la comparaison entre clients. La cause identifiée dans une discussion ne se généralise pas, mais un résultat propre à un client réduit fortement le nombre de pistes à examiner ensuite.

Si tous les clients échouent lors de la même action au même moment, le serveur, la base de données, le stockage ou le chemin réseau partagé deviennent plus probables. Si un seul client échoue tandis qu’un autre réussit via le même point de terminaison, vérifiez la version du client, l’état mis en cache, les autorisations, la confiance accordée localement au certificat et la requête exacte qui diffère.

Modifier la route sans changer le compte ni l’élément

Comparez ensuite une route locale fiable avec la route habituelle passant par un proxy inverse, un VPN, un tunnel ou un accès distant. Utilisez le même compte et la même action. Une réussite en local suivie d’un échec à distance éloigne la responsabilité de l’enregistrement multimédia lui-même et l’oriente vers le DNS, TLS, le proxy, le pare-feu ou les couches de routage en amont.

Le guide de ZimaSpace consacré au diagnostic des chemins locaux et distants explique pourquoi une réussite sur le réseau local et une réussite sur Internet constituent des preuves différentes. Appliquez cette distinction à Immich avant de réinstaller une application mobile ou de reconstruire le serveur.

Si les deux routes échouent de manière identique, cessez de modifier les paramètres du proxy et examinez la requête côté application. Si seule la route passant par le proxy échoue, capturez le statut du proxy, le résultat TLS, la réponse en amont et le délai d’expiration. Cette comparaison à variable unique évite qu’un message du client n’oriente l’enquête vers la mauvaise couche.

Utiliser les codes d’état comme indices, pas comme verdicts définitifs

Les classes de codes HTTP permettent de déterminer où chercher, mais elles n’identifient pas automatiquement le composant à l’origine du problème. Un code 4xx signifie souvent que la requête, l’authentification ou l’autorisation n’était pas acceptable ; un code 5xx indique qu’un composant du serveur n’a pas pu traiter la requête. Les proxies peuvent générer l’une ou l’autre classe avant même qu’Immich ne reçoive la requête.

Le guide des champs des journaux d’accès met en avant le code d’état, le chemin URL, l’heure de la requête, l’hôte distant et les identifiants de requête comme champs utiles pour le dépannage. Capturez ces valeurs pour l’action échouée au lieu de parcourir des milliers de lignes sans rapport.

Si le proxy consigne un code 502 ou un délai d’expiration sans requête Immich correspondante, suivez le chemin vers l’amont. Si Immich consigne une requête et renvoie un code 4xx déterministe, examinez l’authentification, les autorisations ou le contenu de la requête. Si le client signale un échec alors que toutes les couches côté serveur affichent un code 2xx, examinez l’analyse effectuée par le client, le cache local ou les requêtes suivantes.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Corréler le taux d’erreur, la latence et les journaux du serveur à un même horodatage

Une requête échouée peut être un cas isolé. Reproduisez l’action cinq à dix fois et notez le taux de réussite ainsi que la latence tout en surveillant les journaux concernés du serveur et du proxy. Si les erreurs augmentent pendant une forte pression sur les ressources ou des pics dans les files d’attente, le serveur peut être temporairement indisponible, même si une deuxième tentative réussit.

La présentation de Better Stack consacrée aux erreurs et à la latence comme signaux de service distingue le taux d’erreur de la latence et du trafic. Cette approche aide à différencier une seule requête client mal formée d’un chemin serveur qui ne se dégrade que sous charge.

Si les journaux du serveur contiennent la même exception pour plusieurs clients, considérez le problème comme côté serveur jusqu’à preuve du contraire. Si le serveur ne voit jamais la requête échouée, tracez le DNS, TLS, le proxy et le réseau du client. Si un seul client génère une forme de requête différente, mettez-le à jour ou réinitialisez-le après avoir conservé suffisamment d’éléments pour confirmer la différence.

Rendre le diagnostic final avec un test deux par deux

Utilisez deux clients et deux routes : navigateur-local, navigateur-distant, mobile-local et mobile-distant. Conservez le même compte et le même élément de test. Cette matrice distingue les échecs propres au client, ceux propres à la route et ceux du serveur qui touchent toutes les combinaisons.

Une cause liée au client est probable lorsqu’un client échoue sur les deux routes tandis qu’un autre réussit. Une cause liée à la route est probable lorsque les deux clients échouent uniquement via une route donnée. Une cause liée au serveur est probable lorsque les quatre combinaisons reproduisent la même erreur applicative et que les journaux du serveur montrent la même opération en échec.

Après avoir corrigé la couche identifiée, réexécutez les quatre cas et redémarrez une fois le composant concerné. Arrêtez-vous lorsque le cas initialement défaillant réussit sans compromettre les contrôles. Pour l’escalade, fournissez la matrice, les horodatages, les codes d’état HTTP, des extraits des journaux du proxy et du serveur, les versions des clients et une requête reproductible, plutôt qu’une simple capture d’écran générique.