Acasă
» MS OFFICE
»
Cum se depanează jurnalele de conexiune Collabora Online cu nivelul de jurnal coolwsd
Cum se depanează jurnalele de conexiune Collabora Online cu nivelul de jurnal coolwsd
Șablonul de configurare public actual al Collabora Online expune în continuare logging.levelîn coolwsd.xml, cu valori acceptate de la warningpână debugla și trace. În cazul unei erori de conexiune, ridicați nivelul pentru scurt timp, reproduceți o conexiune eșuată, inspectați destinația reală a jurnalului serviciului și restaurați nivelul normal când terminați. Valoarea afișată în XML nu este întotdeauna valoarea efectivă: o comandă de pornire sau o setare a containerului o poate suprascrie, iar zonele cu conținut ridicat de detalii, cum ar fi înregistrarea în jurnal WebSocket, pot fi dezactivate separat.
Acest ghid se concentrează pe diagnosticarea unei conexiuni de tip browser-Collabora sau a unei erori de deschidere a documentelor. Folosește coolwsd.xml.inșablonul sursă publică actual și materialul oficial Collabora verificat la 6 octombrie 2026. Valorile implicite ale pachetelor și numele serviciilor pot diferi în funcție de versiune și implementare, așadar confirmați instanța care rulează înainte de a copia căi sau comenzi de repornire.
Ce modifică nivelul jurnalului coolwsd
coolwsdeste daemonul WebSocket Collabora Online, procesul serverului care gestionează sesiunile de browser și activitatea documentelor. Nivelul său de jurnalizare determină cât de multe detalii emite procesul. Șablonul sursă curent listează nivelurile denumite, inclusiv fatal, critical, error, warning, notice, , information, debug, și trace, precum și nivelurile numerice de la 0 la 8. Valorile numerice sunt ordonate de la cel mai puțin detaliat la cel mai detaliat. Pentru o primă trecere de diagnosticare, debugeste un pas înainte rezonabil; utilizați tracenumai atunci când aveți nevoie de detalii mai fine ale conexiunii.
Setarea separată level_startupcontrolează înregistrarea în timpul pornirii inițiale, apoi înregistrarea revine la nivelul din level. Șablonul curent setează înregistrarea la pornire la trace; aceasta nu înseamnă că funcționarea normală rămâne la urmă. Evitați modificarea level_startupatunci când problema apare după ce serviciul rulează deja.
Rezultatele mai detaliate pot crește volumul jurnalelor și pot include adrese URL, adrese, identificatori de sesiune sau alte detalii operaționale. Tratați jurnalele ca fiind sensibile; colectați doar intervalul de timp necesar și redactați secretele înainte de a le partaja.
Pasul 1: Identificați cum rulează această instanță Collabora
Mai întâi, stabiliți dacă Collabora Online rulează ca serviciu de sistem, în Docker sau Podman sau în Kubernetes. Acest lucru este important deoarece modificarea unui fișier dintr-un container care rulează poate să nu persiste, iar jurnalele containerului pot ajunge la ieșirea standard în loc de un fișier.
Pachet sistem: verificați serviciul care rulează și numele unității sale, de obicei coolwsd. Configurația este de obicei /etc/coolwsd/coolwsd.xml. Versiunile mai vechi pot utiliza o loolwsdcale moștenită.
Docker sau Podman: identifică numele containerului și modul în care este furnizată configurația sa. Un fișier montat prin bind sau o variabilă de implementare este de obicei sursa persistentă de configurare.
Kubernetes: inspectați valorile Helm, ConfigMap sau manifestul de implementare care furnizează coolwsd.xml. Editarea directă a unui pod este temporară.
Șablonul de configurare public curent afișează valori separate pentru înregistrarea normală în jurnal și faza inițială de pornire.
Înainte de editare, faceți o copie de rezervă a fișierului de configurare propriu-zis sau salvați o copie a valorilor de implementare. Dacă nu sunteți sigur ce fișier citește procesul care rulează, verificați mai întâi definiția serviciului sau comanda de pornire. O cauză frecventă a unei erori aparente este editarea unui fișier exemplu în loc de configurația activă.
Pasul 2: Ridicați temporar nivelul activ
În secțiunea activă coolwsd.xml, localizați <logging>secțiunea și modificați doar valoarea din interiorul acesteia <level>. Începeți cu debug. Dacă încercarea de conectare tot nu produce suficiente detalii, utilizați pe scurt tracepentru o singură reproducere. Păstrați level_startupneschimbate setările fișierului , și configurația fără legătură.
Folosește temporar funcția de urmărire atunci când depanarea nu afișează suficiente detalii; păstrează setările de pornire și alte opțiuni XML.
Acesta este un exemplu prescurtat al structurii XML relevante, nu un înlocuitor pentru fișierul de configurare complet. Pentru implementările de containere, setați opțiunea prin mecanismul persistent acceptat de imaginea sau diagrama respectivă. Sursa oficială Collabora include suprascrieri de configurare din linia de comandă, așa că, dacă valoarea pare ignorată, verificați argumentele de pornire sau parametrii de implementare pentru o a doua logging.levelvaloare.
Dacă jurnalele ajung într-un fișier, șablonul sursă curent documentează calea fișierului sub logging.file, de obicei /var/log/coolwsd.log. Înregistrarea în jurnal a fișierelor poate fi însă dezactivată într-o versiune de producție. Dacă activați ieșirea fișierului sau utilizați o cale personalizată, confirmați că un coolcont de serviciu poate scrie acolo și că systemd permite serviciului să scrie în acea locație. Nu faceți ca jurnalul să fie lizibil de către toți utilizatorii pentru a rezolva o problemă de permisiuni.
Pasul 3: Reporniți sau redistribuiți, apoi reproduceți o dată
Majoritatea configurațiilor pachetizate intră în vigoare după repornirea unui serviciu. Reporniți în timpul unei ferestre de mentenanță adecvate sau a unei instanțe de testare, deoarece sesiunile de editare active pot fi întrerupte. Pentru un serviciu systemd, o comandă tipică este:
sudo systemctl restart coolwsd
sudo systemctl status coolwsd --no-pager
Folosește numele serviciului real de pe gazdă. Pentru un container, actualizează configurația persistentă și repornește sau reimplementează containerul respectiv. Pentru Kubernetes, aplică modificarea manifestului sau a Helm prin procesul normal de lansare. Confirmă că procesul pornește corect înainte de a reproduce problema.
Înregistrați ora exactă, utilizatorul sau contul de test afectat, pasul de deschidere a documentului și eroarea vizibilă în browser. Reproduceți eroarea o dată, apoi opriți generarea de solicitări. O singură încercare cu marcaj temporal este mai ușor de corelat între Collabora, proxy-ul invers și spațiul de stocare sau gazda WOPI decât un flux lung de sesiuni fără legătură.
Pasul 4: Citiți sursa jurnalului pentru implementarea dvs.
Pentru un serviciu systemd, urmați jurnalul în timp ce reproduceți problema:
sudo journalctl -u coolwsd -f
Pentru a inspecta o fereastră recentă delimitată, utilizați sudo journalctl -u coolwsd --since "10 minutes ago". Dacă unitatea dvs. are un alt nume, înlocuiți-l. Pentru Docker, utilizați docker logs --since 10m --follow CONTAINER_NAMEși înlocuiți CONTAINER_NAMEcu numele sau ID-ul real al containerului. Podman și Kubernetes au propriile comenzi de jurnal; verificați documentația de execuție a implementării, în loc să presupuneți că există un fișier gazdă.
Citește din sink-ul de jurnal activ; textul numelui containerului din comanda Docker este un substituent care trebuie înlocuit cu containerul real.
Dacă este activată înregistrarea în jurnal a fișierelor, verificați calea configurată, de exemplu sudo tail -F /var/log/coolwsd.log. Calea din fișierul dvs. poate fi diferită. Un fișier lipsă nu înseamnă în sine că serviciul nu a produs jurnale; este posibil să scrie în jurnal sau în ieșirea containerului.
Pasul 5: Corelați secvența de conectare
Începeți cu intrările la marcajul temporal înregistrat. Căutați marcaje de avertizare și eroare și termeni legați de conexiune, cum ar fi WOPI, WebSocket, Socket, sau calea de solicitare relevantă. Într-un fișier, un prim filtru focalizat poate fi:
Apoi urmați secvența: a ajuns browserul la adresa URL publică, a redirecționat proxy-ul invers cererea, a finalizat actualizarea WebSocket și a contactat Collabora gazda documentului? Jurnalele de acces și erori ale unui proxy pot răspunde la întrebări pe care jurnalul coolwsd nu le poate răspunde, cum ar fi dacă cererea a ajuns la serviciu. Dacă browserul raportează o eroare de conexiune WebSocket, dar coolwsd nu înregistrează nicio cerere potrivită, investigați DNS, terminarea TLS, regulile firewall și rutarea reverse-proxy înainte de a modifica permisiunile documentului.
Șablonul de configurare curent listează Socket, WebSocket, Admin, și Pixelprintre valorile implicite disabled_areaspentru ieșirea cu conținut ridicat de detalii. Dacă înregistrarea în jurnal a urmăririlor este activă, dar detaliile socketului lipsesc, verificați această setare. Pentru o diagnosticare scurtă, eliminați doar zona relevantă Socketsau WebSocketdin lista de dezactivate separate prin virgulă, păstrând intacte excluderile fără legătură. Reporniți sau redistribuiți și repetați același test controlat. Restaurați lista originală după colectarea dovezilor.
Pasul 6: Restaurați înregistrarea normală și protejați dovezile
Reveniți <level>la valoarea de producție anterioară, de obicei warningîn șablonul sursă publică, și restaurați orice modificări disabled_areas. Reporniți sau redistribuiți dacă este necesar în pachet. Confirmați că serviciul este sănătos și că mesajele noi de depanare sau urmărire s-au oprit. Păstrați doar extrasul de diagnostic limitat în timp într-o locație restricționată.
Restaurați nivelul normal al jurnalului după test, apoi examinați un extras relevant și restrâns, în loc să partajați o imagine completă a jurnalului.
Înainte de a trimite un extras de jurnal către asistența Collabora sau către un administrator, eliminați token-urile de acces, anteturile de autorizare, adresele URL semnate, numele de utilizator, numele de gazdă private și numele documentelor, acolo unde este posibil. Păstrați marcajele temporale și contextul de eroare nesensibil necesar pentru a reproduce secvența.
Greșeli frecvente de depanare
Numai modificare level_startup: această setare se aplică fazei inițiale de pornire și apoi revine la level. Pentru o eroare după pornire, modificați level.
Presupunând tracecă se activează fiecare categorie: zonele dezactivate pot suprima mesajele socket sau WebSocket cu conținut ridicat de detalii. Verificați lista de filtre.
Căutare greșită: jurnalul, ieșirea containerului și un fișier sunt registre de jurnal diferite. Determinați care dintre ele este activ înainte de a depana un fișier gol.
Lăsarea urmăririi activată: înregistrarea în volum mare poate crește rapid și expune mai multe detalii operaționale. Restaurați valoarea anterioară imediat ce testul este finalizat.
Modificarea mai multor setări simultan: devine mai greu de identificat ce setare a afectat rezultatul. Ajustați o valoare, reproduceți o eroare și înregistrați rezultatul.