Jak ustalić, czy błąd Immich pochodzi od klienta, czy od serwera

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

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

Ustal, czy błąd Immich występuje po stronie klienta, czy serwera, odtwarzając tę samą czynność przy zmianie jednej zmiennej i śledząc nieudane żądanie na całej trasie.

Mobilny baner z komunikatem „błąd serwera” może w rzeczywistości wskazywać na stan klienta, TLS, odwrotny serwer proxy albo żądanie prawidłowo odrzucone przez serwer. Podobnie błąd występujący tylko w przeglądarce nie dowodzi, że przeglądarka jest uszkodzona. Ustal konto, zasób i czynność; porównaj klientów i trasy; następnie użyj kodów statusu oraz zsynchronizowanych dzienników, aby zlokalizować pierwszą warstwę, w której wystąpił błąd.

Odtwórz tę samą czynność na drugim kliencie

Wybierz jedną deterministyczną czynność, taką jak logowanie, otwarcie znanego zasobu, przesłanie tego samego małego zdjęcia lub wykonanie tego samego wyszukiwania. Powtórz ją na tym samym koncie w przeglądarce i na kliencie mobilnym, zachowując niezmienioną trasę sieciową. Zapisz dokładny czas i wynik obu prób.

Niedawne zgłoszenie dotyczące Immich, w którym klient Android nie nawiązywał połączenia, podczas gdy testowano inne ścieżki dostępu, pokazuje wartość porównania między klientami. Przyczyna z jednego wątku nie musi być uniwersalna, ale wynik zależny od klienta znacznie zawęża obszar dalszej diagnostyki.

Jeśli każdy klient nie może wykonać tej samej czynności w tym samym czasie, na liście podejrzanych wyżej znajdą się serwer, baza danych, pamięć masowa lub wspólna ścieżka sieciowa. Jeśli tylko jeden klient zawodzi, a drugi działa przez ten sam punkt końcowy, sprawdź wersję klienta, stan pamięci podręcznej, uprawnienia, lokalne zaufanie do certyfikatu oraz dokładne żądanie, które się różni.

Zmień trasę bez zmiany konta ani zasobu

Następnie porównaj zaufaną trasę lokalną ze standardową trasą przez odwrotny serwer proxy, VPN, tunel lub połączenie zdalne. Użyj tego samego konta i wykonaj tę samą czynność. Sukces lokalnie przy jednoczesnym niepowodzeniu zdalnie wskazuje raczej nie na sam rekord multimedialny, lecz na warstwy DNS, TLS, proxy, zapory sieciowej lub routingu do serwera nadrzędnego.

Przewodnik ZimaSpace dotyczący diagnostyki tras lokalnych i zdalnych wyjaśnia, dlaczego poprawne działanie w sieci LAN i poprawne działanie przez internet są odrębnymi dowodami. Zastosuj tę zasadę do Immich, zanim ponownie zainstalujesz aplikację mobilną lub przebudujesz serwer.

Jeśli obie trasy zawodzą w identyczny sposób, przestań zmieniać ustawienia proxy i sprawdź żądanie po stronie aplikacji. Jeśli zawodzi tylko trasa przez proxy, zarejestruj status proxy, wynik TLS, odpowiedź serwera nadrzędnego i przekroczenie limitu czasu. To porównanie jednej zmiennej zapobiega skierowaniu diagnostyki do niewłaściwej warstwy przez komunikat klienta.

Traktuj kody statusu jako wskazówki, nie ostateczny werdykt

Klasy statusów HTTP pomagają określić, gdzie szukać, ale nie wskazują automatycznie komponentu, który spowodował problem. Kod 4xx często oznacza, że żądanie, uwierzytelnianie lub autoryzacja były nieakceptowalne; kod 5xx wskazuje, że komponent serwerowy nie mógł zrealizować żądania. Proxy może wygenerować obie klasy, zanim Immich zobaczy żądanie.

Przewodnik po polach dzienników dostępu wskazuje kod statusu, ścieżkę adresu URL, czas żądania, host zdalny oraz identyfikatory żądań jako przydatne pola diagnostyczne. Zapisz te wartości dla jednej nieudanej czynności zamiast przeszukiwać tysiące niezwiązanych wpisów.

Jeśli proxy rejestruje kod 502 lub przekroczenie limitu czasu, ale nie ma odpowiadającego mu żądania Immich, prześledź ścieżkę do serwera nadrzędnego. Jeśli Immich rejestruje żądanie i zwraca deterministyczny kod 4xx, sprawdź uwierzytelnianie, uprawnienia lub treść żądania. Jeśli klient zgłasza błąd, ale wszystkie warstwy serwerowe pokazują kod 2xx, sprawdź analizowanie odpowiedzi przez klienta, lokalną pamięć podręczną lub kolejne żądania.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Skoreluj wskaźnik błędów, opóźnienie i dzienniki serwera w jednym czasie

Jedno nieudane żądanie może być wyjątkiem. Odtwórz czynność od pięciu do dziesięciu razy i zapisuj odsetek powodzeń oraz opóźnienie, obserwując odpowiednie dzienniki serwera i proxy. Jeśli liczba błędów rośnie podczas przeciążenia zasobów lub skoków długości kolejek, serwer może okresowo być niedostępny, nawet jeśli druga próba się powiedzie.

Przegląd Better Stack dotyczący błędów i opóźnienia jako sygnałów działania usługi rozdziela wskaźnik błędów, opóźnienie i ruch. Takie ujęcie pomaga odróżnić pojedyncze nieprawidłowo sformułowane żądanie klienta od ścieżki serwerowej, której działanie pogarsza się dopiero pod obciążeniem.

Jeśli dzienniki serwera zawierają ten sam wyjątek dla wielu klientów, uznaj problem za występujący po stronie serwera, dopóki nie zostanie wykazane inaczej. Jeśli serwer w ogóle nie widzi nieudanego żądania, prześledź DNS, TLS, proxy i sieć klienta. Jeśli tylko jeden klient generuje żądanie o innym kształcie, zaktualizuj go lub zresetuj po zachowaniu wystarczających dowodów potwierdzających tę różnicę.

Wydaj ostateczną ocenę za pomocą testu dwa na dwa

Użyj dwóch klientów i dwóch tras: przeglądarka-lokalnie, przeglądarka-zdalnie, urządzenie mobilne-lokalnie i urządzenie mobilne-zdalnie. Zachowaj to samo konto i zasób testowy. Ta macierz pozwala oddzielić błędy zależne od klienta od błędów zależnych od trasy oraz od błędów serwera wpływających na każdą kombinację.

Przyczyna po stronie klienta jest prawdopodobna, gdy jeden klient zawodzi na obu trasach, a drugi działa. Przyczyna po stronie trasy jest prawdopodobna, gdy obaj klienci zawodzą tylko na jednej trasie. Przyczyna po stronie serwera jest prawdopodobna, gdy wszystkie cztery kombinacje odtwarzają ten sam błąd aplikacji, a dzienniki serwera pokazują tę samą nieudaną operację.

Po naprawieniu zidentyfikowanej warstwy ponownie wykonaj wszystkie cztery testy oraz jeden restart dotkniętego komponentu. Zakończ, gdy pierwotnie nieudana kombinacja działa, a testy kontrolne nadal przechodzą. Zgłoszenie uzupełnij o macierz, znaczniki czasu, kody statusu HTTP, fragmenty dzienników proxy i serwera, wersje klientów oraz jedno odtwarzalne żądanie zamiast ogólnego zrzutu ekranu.