Sprawdź się: Diagnostyka OpenClaw: /health, logi i procedura, gdy agent milczy

Pytania quizu

1. Podpinasz agenta pod zewnętrzny monitoring uptime z pingiem co 15 minut. Który adres wpisać?

   • GET /health — odpowiada natychmiast i nie zakłada sesji
   • POST /v1/chat/completions z krótką wiadomością testową
   • GET /v1/models, bo jest lekki i nie woła modelu
   • Połączenie WebSocket i sprawdzenie ramki hello-ok

   /health zwraca {"ok":true,"status":"live"} bez zakładania sesji i bez wywołania modelu. Kusi /v1/chat/completions, bo sprawdza „całą ścieżkę” — i właśnie dlatego jest zły: każdy ping bez nagłówka x-openclaw-session-key tworzy nową sesję, czyli około 96 dziennie po 4–22 KB. Ramka hello-ok faktycznie służy do sprawdzenia gatewaya, ale przez WebSocket, a nie w polu URL zewnętrznego monitoringu.

2. Dodałeś --verbose i dalej nie widzisz szczegółów w pliku logu. Dlaczego?

   • Bo logi plikowe rotują się przy 100 MB i szczegóły trafiły do archiwum .1
   • Bo --verbose podnosi tylko gadatliwość konsoli i styl logów WebSocket
   • Bo logging.consoleStyle stoi na compact
   • Bo plik logu jest usuwany po 24 godzinach

   Poziom logów w pliku ustawia wyłącznie logging.level — na jeden przebieg podniesiesz go zmienną OPENCLAW_LOG_LEVEL albo opcją --log-level. Rotacja przy 100 MB faktycznie zachodzi i archiwa .1–.5 istnieją, ale zawierają starsze linie, a nie brakujące szczegóły. Usuwanie po dobie też jest prawdą i psuje inne badania, tylko nie to.

3. Ktoś zgłasza, że agent zachował się dziwnie przedwczoraj. Otwierasz /tmp/openclaw i pliku z tamtego dnia nie ma. Co się stało?

   • Rotacja przy 100 MB nadpisała starsze archiwa
   • Datowane pliki logów są usuwane po 24 godzinach
   • Gateway pisze do pliku dopiero po ustawieniu consoleStyle na json
   • Logi z poprzednich dni leżą w katalogu profilu, a nie w /tmp/openclaw

   Datowane pliki w /tmp/openclaw znikają po dobie i jedynym zabezpieczeniem jest własna ścieżka w logging.file wskazująca katalog poza /tmp. Rotacja przy logging.maxFileBytes faktycznie zachodzi i zostawia pięć archiwów od .1 do .5, tylko dotyczy bieżącego pliku, nie poprzednich dni. Segment profilu w nazwie zmienia sam plik, a nie katalog.

4. W logu kanału widzisz, że kanał nie może przyjmować zdarzeń przychodzących, bo jego trwała kolejka wejściowa jest niedostępna, ale wychodzące mogą działać. Co to znaczy w praktyce?

   • Transport jest zerwany i trzeba przeparować kanał
   • Kanał wysyła odpowiedzi normalnie, ale nie wchodzi ani jedna wiadomość przychodząca
   • Kanał działa, tylko logi są opóźnione o jeden cykl
   • Skończyła się pamięć gatewaya i trzeba go zrestartować

   Połączenie kanału i przyjmowanie wiadomości to dwie osobne domeny awarii. Konto jest wtedy oznaczone jako niesprawne niezależnie od stanu transportu, a restarty mają w logu zapisany powód po stronie kolejki. Przeparowanie kanału nie pomoże, bo połączenie akurat działa — to najczęstszy odruch i najczęstsza strata czasu w tym scenariuszu.