Pomiar czasu obsługi zadań w panelu

Panel potrafi odpowiadać wolno, a z zewnątrz wszystko wygląda normalnie. Dopóki nie ma zapisanego czasu obsługi, każde zgłoszenie o opóźnieniu jest tylko wrażeniem. Tego dnia dodałem pomiar, a przy okazji poprawiłem logi, które rosły bez kontroli.

Problem: brak śladu czasu obsługi

Logger gatewaya nie zapisywał linii wtyczki, więc nie dało się zmierzyć, ile trwa obsługa linku. Były komunikaty o błędach, ale nie było czasu ani wyniku wysyłki w jednym miejscu.

Drugi problem to szum. Worker przy pustej kolejce zapisywał co minutę wpis zadania poprawne: 0, co dawało około 13 tysięcy linii dziennie. Kolektor metadanych przeliczał puste sesje w każdym przebiegu, zapisując te same 36 wierszy.

Co zrobiłem: pomiar i ciszę tam, gdzie nic się nie dzieje

1. W commicie 1682fbb wtyczka zapisuje komendę, status, czas odpowiedzi API i wynik wysyłki do pliku logu. Treść linku i identyfikator konta nie trafiają do logu.
2. W 7dc96b7 worker pisze wpis tylko wtedy, gdy są zadania albo błędy. Test pilnuje ciszy przy pustej kolejce.
3. W 342063a kolektor pomija sesję bez aktywności, jeśli ma już status brak dla tej samej sesji.
4. W 3df629c nieudana wysyłka to ostrzeżenie z identyfikatorem czatu, a odrzucona nazwa testera to ostrzeżenie z powodem (bad_format, reserved, taken).

Limity rozmiaru logów kontenerów ustawiłem w 55ca1ad na 10 MB i pięć plików.

Dlaczego to ważne

Zapisany czas pozwala wrócić do konkretnego żądania, gdy pojawi się zgłoszenie. Bez tego każda diagnoza zaczyna się od zgadywania. Cisza w logu jest równie ważna: jeśli worker pisze o niczym co minutę, prawdziwy błąd ginie w szumie.

Czego się nauczyłem

• Pomiar daje widoczność, ale sam nie przyspiesza systemu. Pozwala tylko wskazać, gdzie szukać.
• Logi bez limitu rozmiaru są bombą z opóźnionym zapłonem. Limit ustawiony od początku kosztuje mniej niż późne czyszczenie dysku.
• Komunikat o pustym wyniku powinien być wpisem tylko wtedy, gdy wynik jest informacją. W przeciwnym razie zakopuje błędy.