Jak debugować dzienniki połączeń Collabora Online z poziomem dziennika coolwsd
Obecny publiczny szablon konfiguracji Collabora Online nadal jest dostępny logging.levelw [ brakuje nazwy coolwsd.xmlużytkownika], z obsługiwanymi wartościami od warning[brakuje nazwy użytkownika debug] tracedo [brakuje nazwy użytkownika] do [brakuje nazwy użytkownika] i [brakuje nazwy użytkownika]. W przypadku awarii połączenia, należy na krótko podnieść poziom, odtworzyć jedno nieudane połączenie, sprawdzić rzeczywiste miejsce docelowe dziennika usługi i przywrócić normalny poziom po zakończeniu. Wartość wyświetlana w pliku XML nie zawsze jest wartością efektywną: polecenie startowe lub ustawienie kontenera może ją zastąpić, a obszary o dużej szczegółowości, takie jak rejestrowanie WebSocket, mogą zostać wyłączone osobno.
Ten przewodnik koncentruje się na diagnozowaniu problemów z połączeniem przeglądarki z Collabora lub otwieraniem dokumentów. Wykorzystuje on aktualny coolwsd.xml.inszablon źródłowy i oficjalne materiały Collabora sprawdzone 6 października 2026 r. Domyślne ustawienia pakietów i nazwy usług mogą się różnić w zależności od wersji i wdrożenia, dlatego przed skopiowaniem ścieżek lub ponownym uruchomieniem należy sprawdzić działającą instancję.
Co zmienia poziom dziennika coolwsd
coolwsdto demon WebSocket Collabora Online, proces serwera obsługujący sesje przeglądarki i aktywność dokumentów. Jego poziom logowania określa, ile szczegółów emituje proces. Aktualny szablon źródłowy zawiera nazwane poziomy, takie jak fatal, critical, error, warning, notice, information, debugi trace, a także poziomy numeryczne od 0 do 8. Wartości numeryczne są nadawane od najmniej do najbardziej szczegółowych. W przypadku pierwszego przebiegu diagnostycznego debugjest to rozsądny krok naprzód; należy go używać tracetylko wtedy, gdy potrzebne są bardziej szczegółowe informacje o połączeniu.
Oddzielne level_startupustawienie kontroluje rejestrowanie podczas początkowego uruchomienia, a następnie rejestrowanie powraca do poziomu z level. Obecny szablon ustawia rejestrowanie podczas uruchamiania na trace; nie oznacza to, że normalne działanie pozostaje w stanie śledzenia. Unikaj zmiany, level_startupgdy problem wystąpi po uruchomieniu usługi.
Bardziej szczegółowe dane wyjściowe mogą zwiększyć objętość logów i mogą obejmować adresy URL, adresy, identyfikatory sesji lub inne szczegóły operacyjne. Traktuj logi jako poufne; zbieraj tylko niezbędne dane i usuwaj poufne dane przed ich udostępnieniem.
Krok 1: Określ sposób działania tej instancji Collabora
Najpierw ustal, czy Collabora Online działa jako usługa systemowa, w Dockerze, Podmanie, czy w Kubernetesie. Ma to znaczenie, ponieważ zmiany w pliku w działającym kontenerze mogą nie zostać zapisane, a logi kontenera mogą trafiać na standardowe wyjście zamiast do pliku.
Pakiet systemowy: sprawdź działającą usługę i nazwę jej jednostki, zazwyczaj coolwsd. Konfiguracja jest zazwyczaj /etc/coolwsd/coolwsd.xml. Starsze wersje mogą używać starszej loolwsdścieżki.
Docker lub Podman: zidentyfikuj nazwę kontenera i sposób dostarczania jego konfiguracji. Plik montowany metodą bind lub zmienna wdrożenia jest zazwyczaj trwałym źródłem konfiguracji.
Kubernetes: sprawdź wartości Helm, ConfigMap lub manifest wdrożenia, który je dostarcza coolwsd.xml. Bezpośrednia edycja kontenera jest tymczasowa.
Obecny szablon konfiguracji publicznej zawiera oddzielne wartości dla normalnego rejestrowania i początkowej fazy uruchamiania.
Przed edycją wykonaj kopię zapasową pliku konfiguracyjnego lub zapisz kopię wartości wdrożenia. Jeśli nie masz pewności, który plik odczytuje działający proces, najpierw sprawdź jego definicję usługi lub polecenie startowe. Częstą przyczyną pozornego braku operacji (no-op) jest edycja pliku przykładowego zamiast aktywnej konfiguracji.
Krok 2: Tymczasowo podnieś poziom aktywności
W sekcji aktywnej coolwsd.xmlzlokalizuj <logging>sekcję i zmień tylko wartość w niej <level>. Zacznij od debug. Jeśli próba połączenia nadal nie przyniesie wystarczającej ilości szczegółów, użyj krótko tej opcji tracedo jednego powtórzenia. Zachowaj niezmienione istniejące level_startupustawienia pliku i niezwiązaną konfigurację.
Użyj śledzenia tymczasowo, gdy debugowanie nie pokazuje wystarczającej ilości szczegółów; zachowaj ustawienia startowe i inne opcje XML.
To skrócony przykład odpowiedniej struktury XML, a nie zamiennik pełnego pliku konfiguracyjnego. W przypadku wdrożeń kontenerowych należy ustawić opcję za pomocą trwałego mechanizmu obsługiwanego przez dany obraz lub wykres. Oficjalne źródło Collabora zawiera nadpisania konfiguracji z poziomu wiersza poleceń, więc jeśli wartość jest ignorowana, należy sprawdzić argumenty startowe lub parametry wdrożenia pod kątem drugiej logging.levelwartości.
Jeśli logi trafiają do pliku, bieżący szablon źródłowy dokumentuje ścieżkę do pliku w logging.file, zazwyczaj /var/log/coolwsd.log. Rejestrowanie plików może być jednak wyłączone w wersji produkcyjnej. Jeśli włączysz wyjście pliku lub użyjesz niestandardowej ścieżki, upewnij się, że coolkonto usługi może tam zapisywać i że systemd zezwala usłudze na zapis w tej lokalizacji. Nie ustawiaj dziennika jako odczytywalnego dla wszystkich, aby rozwiązać problem z uprawnieniami.
Krok 3: Uruchom ponownie lub wdróż ponownie, a następnie odtwórz raz
Większość konfiguracji pakietowych zaczyna obowiązywać po ponownym uruchomieniu usługi. Należy uruchomić ponownie w odpowiednim oknie konserwacji lub w trakcie instancji testowej, ponieważ aktywne sesje edycji mogą zostać przerwane. W przypadku usługi systemd typowe polecenie to:
sudo systemctl restart coolwsd
sudo systemctl status coolwsd --no-pager
Użyj rzeczywistej nazwy usługi na swoim hoście. W przypadku kontenera zaktualizuj konfigurację trwałą i uruchom ponownie lub wdróż ponownie ten kontener. W przypadku Kubernetes zastosuj manifest lub zmianę Helm w ramach standardowego procesu wydawania. Przed odtworzeniem problemu upewnij się, że proces rozpoczyna się poprawnie.
Zarejestruj dokładny czas, użytkownika lub konto testowe, którego dotyczy problem, krok otwierania dokumentu oraz błąd widoczny w przeglądarce. Powtórz błąd raz, a następnie zatrzymaj generowanie żądań. Pojedynczą próbę z sygnaturą czasową łatwiej jest skorelować w Collabora, odwrotnym serwerze proxy oraz w pamięci masowej lub hoście WOPI niż długi strumień niepowiązanych sesji.
Krok 4: Przeczytaj źródło dziennika wdrożenia
W przypadku usługi systemd postępuj zgodnie z instrukcjami w dzienniku podczas odtwarzania problemu:
sudo journalctl -u coolwsd -f
Aby sprawdzić ograniczone ostatnie okno, użyj sudo journalctl -u coolwsd --since "10 minutes ago". Jeśli jednostka ma inną nazwę, zastąp ją. W przypadku Dockera użyj docker logs --since 10m --follow CONTAINER_NAMEi zastąp CONTAINER_NAMErzeczywistą nazwą lub identyfikatorem kontenera. Podman i Kubernetes mają własne polecenia dziennika; sprawdź dokumentację środowiska uruchomieniowego wdrożenia, zamiast zakładać, że plik hosta istnieje.
Odczytaj z aktywnego odbiornika dziennika; tekst nazwy kontenera w poleceniu Docker jest symbolem zastępczym, który należy zastąpić rzeczywistym kontenerem.
Jeśli rejestrowanie plików jest włączone, sprawdź skonfigurowaną ścieżkę, na przykład sudo tail -F /var/log/coolwsd.log. Ścieżka w Twoim pliku może się różnić. Brak pliku sam w sobie nie oznacza, że usługa nie wygenerowała żadnych logów; zamiast tego może zapisywać dane wyjściowe do dziennika lub kontenera.
Krok 5: Powiąż sekwencję połączeń
Zacznij od wpisów z zarejestrowanym znacznikiem czasu. Wyszukaj znaczniki ostrzeżeń i błędów oraz terminy związane z połączeniem, takie jak WOPI, WebSocket, Socketlub odpowiednią ścieżkę żądania. W pliku pierwszym filtrem może być:
Następnie wykonaj następujące kroki: czy przeglądarka dotarła do publicznego adresu URL, czy odwrotny serwer proxy przesłał żądanie, czy aktualizacja WebSocket została ukończona i czy Collabora skontaktowała się z hostem dokumentu? Dzienniki dostępu i błędów serwera proxy mogą odpowiedzieć na pytania, na które nie ma odpowiedzi dziennik coolwsd, takie jak to, czy żądanie w ogóle dotarło do usługi. Jeśli przeglądarka zgłasza błąd połączenia WebSocket, ale coolwsd nie rejestruje żadnego pasującego żądania, przed zmianą uprawnień dokumentu sprawdź ustawienia DNS, zakończenie TLS, reguły zapory sieciowej i routing odwrotnego serwera proxy.
Bieżący szablon konfiguracji zawiera domyślne wartości Socket, WebSocket, Admini dla danych wyjściowych o wysokiej szczegółowości. Jeśli rejestrowanie śledzenia jest aktywne, ale brakuje szczegółów gniazda, sprawdź to ustawienie. W celu przeprowadzenia krótkiej diagnostyki usuń tylko odpowiedni obszar lub z listy wyłączonych elementów rozdzielonych przecinkami, zachowując niezwiązane wykluczenia. Uruchom ponownie lub wdróż ponownie i powtórz ten sam kontrolowany test. Przywróć oryginalną listę po zebraniu dowodów.Pixeldisabled_areasSocketWebSocket
Krok 6: Przywróć normalne rejestrowanie i chroń dowody
Wróć <level>do poprzedniej wartości produkcyjnej, zazwyczaj warningw publicznym szablonie źródłowym, i przywróć wszelkie zmiany disabled_areas. Uruchom ponownie lub wdróż ponownie, jeśli wymaga tego pakiet. Sprawdź, czy usługa działa prawidłowo i czy nowe komunikaty debugowania lub śledzenia zostały zatrzymane. Przechowuj tylko ograniczony czasowo fragment diagnostyczny w ograniczonej lokalizacji.
Przywróć normalny poziom dziennika po teście, a następnie przejrzyj wąski, istotny fragment, zamiast udostępniać cały zrzut dziennika.
Przed wysłaniem fragmentu dziennika do działu pomocy technicznej Collabora lub administratora, usuń tokeny dostępu, nagłówki autoryzacji, podpisane adresy URL, nazwy użytkowników, prywatne nazwy hostów i nazwy dokumentów, o ile to możliwe. Zachowaj znaczniki czasu i niewrażliwy kontekst błędu potrzebny do odtworzenia sekwencji.
Typowe błędy debugowania
Zmiana tylko level_startup: to ustawienie dotyczy początkowej fazy uruchamiania, a następnie wraca do level. W przypadku awarii po uruchomieniu zmień level.
Zakładając, traceże wszystkie kategorie są włączone: wyłączone obszary mogą blokować komunikaty o gnieździe lub WebSocket o dużej liczbie szczegółów. Sprawdź listę filtrów.
Szukanie w złym miejscu: dziennik, dane wyjściowe kontenera i plik to różne odbiorniki logów. Przed rozwiązywaniem problemów z pustym plikiem należy ustalić, który z nich jest aktywny.
Pozostawienie śledzenia włączonego: rejestrowanie dużej ilości danych może szybko rosnąć i ujawniać więcej szczegółów operacyjnych. Przywróć poprzednią wartość natychmiast po zakończeniu testu.
Zmiana wielu ustawień jednocześnie: trudniej jest zidentyfikować, które ustawienie wpłynęło na wynik. Dostosuj jedną wartość, odtwórz jedną awarię i zapisz wynik.