Hoe je kunt bepalen of een Immich-fout door de client of de server wordt veroorzaakt

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

How to Tell Whether an Immich Error Comes From the Client or Server - Zima Store Online

Bepaal of een Immich-fout aan de client- of serverzijde ontstaat door dezelfde actie opnieuw uit te voeren met één gewijzigde variabele en het mislukte verzoek door de volledige route te volgen.

Een mobiele banner met de tekst “serverfout” kan nog steeds worden veroorzaakt door de clientstatus, TLS, een reverse proxy of een verzoek dat de server terecht heeft afgewezen. Evenzo bewijst een fout die alleen in de browser optreedt niet dat de browser defect is. Houd het account, het item en de actie gelijk; vergelijk clients en routes; gebruik vervolgens statuscodes en gesynchroniseerde logboeken om de eerste falende laag te vinden.

Voer dezelfde actie uit op een tweede client

Kies één deterministische actie, zoals inloggen, een bekend item openen, dezelfde kleine foto uploaden of dezelfde zoekopdracht uitvoeren. Herhaal deze actie met hetzelfde account in een browser en op een mobiele client, terwijl de netwerkroute ongewijzigd blijft. Noteer voor beide pogingen het exacte tijdstip en resultaat.

Een recent Immich-rapport waarin een Android-client niet werkte terwijl andere toegangsroutes werden getest, illustreert de waarde van een vergelijking tussen clients. De oorzaak in één discussie is niet algemeen toepasbaar, maar een client-specifiek resultaat beperkt de mogelijkheden voor het volgende onderzoek aanzienlijk.

Als elke client dezelfde actie op hetzelfde moment niet kan uitvoeren, komen de server, database, opslag of gedeelde netwerkroute hoger op de lijst te staan. Als slechts één client faalt terwijl een andere via hetzelfde eindpunt slaagt, controleer dan de clientversie, gecachte status, machtigingen, lokaal certificaatvertrouwen en het exacte verzoek dat afwijkt.

Wijzig de route zonder het account of item te wijzigen

Vergelijk vervolgens een vertrouwde lokale route met de gebruikelijke reverse proxy-, VPN-, tunnel- of externe route. Gebruik hetzelfde account en dezelfde actie. Een lokaal succes in combinatie met een externe fout wijst niet naar het mediabestand zelf, maar eerder naar DNS-, TLS-, proxy-, firewall- of upstream-routeringslagen.

De ZimaSpace-handleiding over diagnose van lokale versus externe routes legt uit waarom succes op het LAN en succes via internet verschillende bewijzen zijn. Pas die scheidslijn toe op Immich voordat je een mobiele app opnieuw installeert of de server opnieuw opbouwt.

Als beide routes identiek falen, stop dan met het wijzigen van proxy-instellingen en inspecteer het verzoek aan de applicatiezijde. Als alleen de proxyroutes falen, leg dan de proxystatus, het TLS-resultaat, de upstreamrespons en de time-out vast. Deze vergelijking met één variabele voorkomt dat een clientmelding het onderzoek naar de verkeerde laag stuurt.

Gebruik statuscodes als aanwijzingen, niet als definitieve conclusies

HTTP-statusklassen helpen bepalen waar je moet zoeken, maar identificeren niet automatisch het onderdeel dat de toestand heeft veroorzaakt. Een 4xx betekent vaak dat het verzoek, de authenticatie of de autorisatie niet werd geaccepteerd; een 5xx geeft aan dat een serveronderdeel het verzoek niet kon afhandelen. Proxies kunnen beide klassen genereren voordat Immich het verzoek ziet.

De handleiding voor toegangslogboeken benadrukt statuscode, URL-pad, aanvraagtijd, externe host en verzoek-ID's als nuttige velden voor probleemoplossing. Leg deze waarden vast voor de ene mislukte actie in plaats van duizenden irrelevante regels te doorzoeken.

Als de proxy een 502 of time-out registreert zonder overeenkomend Immich-verzoek, volg dan de upstreamroute. Als Immich een verzoek logt en een deterministische 4xx retourneert, controleer dan authenticatie, machtigingen of de inhoud van het verzoek. Als de client een fout meldt maar alle serverlagen 2xx tonen, inspecteer dan het parsen door de client, de lokale cache of vervolgaanvragen.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Breng foutenpercentage, latentie en serverlogboeken samen op één tijdstip

Eén mislukt verzoek kan een uitschieter zijn. Voer de actie vijf tot tien keer uit en noteer het succespercentage en de latentie terwijl je de relevante server- en proxylogboeken bekijkt. Als het aantal fouten stijgt tijdens capaciteitsdruk of pieken in wachtrijen, kan de server met tussenpozen onbeschikbaar zijn, ook al slaagt een tweede poging.

Het overzicht van Better Stack over fouten en latentie als servicesignalen maakt onderscheid tussen foutenpercentage, latentie en verkeer. Dit kader helpt om één verkeerd gevormd clientverzoek te onderscheiden van een serverroute die alleen onder belasting verslechtert.

Als de serverlogboeken dezelfde uitzondering voor meerdere clients bevatten, behandel die dan als een fout aan de serverzijde totdat het tegendeel is bewezen. Als de server het mislukte verzoek nooit ziet, traceer dan DNS, TLS, proxy en clientnetwerk. Als slechts één client een andere verzoekstructuur genereert, werk die client dan bij of reset hem nadat je voldoende bewijs hebt bewaard om het verschil te bevestigen.

Neem de definitieve beslissing met een vierkantstest

Gebruik twee clients en twee routes: browser-lokaal, browser-extern, mobiel-lokaal en mobiel-extern. Houd hetzelfde account en testitem aan. Deze matrix maakt onderscheid tussen client-specifieke fouten, route-specifieke fouten en serverfouten die elke combinatie beïnvloeden.

Een oorzaak aan de clientzijde is aannemelijk wanneer één client op beide routes faalt terwijl de andere slaagt. Een routeoorzaak is aannemelijk wanneer beide clients alleen via één route falen. Een serveroorzaak is aannemelijk wanneer alle vier combinaties dezelfde applicatiefout reproduceren en de serverlogboeken dezelfde mislukte bewerking tonen.

Voer na het oplossen van de vastgestelde laag alle vier combinaties opnieuw uit en herstart het getroffen onderdeel één keer. Stop wanneer de oorspronkelijk mislukte combinatie slaagt zonder dat de controles verslechteren. Escaleer met de matrix, tijdstippen, HTTP-statussen, fragmenten uit proxy- en serverlogboeken, clientversies en één reproduceerbaar verzoek in plaats van met een algemene schermafbeelding.