console.log nie taki zły!

🪄 Odczarujmy nieco console.log i samo logowanie. Na koniec dnia jest to coś znacznie lepszego niż tylko siermiężny zastępca debuggera…

Zacznijmy od tego, że - no właśnie - cały ten console.log to głównie kojarzy nam się z tymczasowym wyrzucaniem jakiejś porcji danych w różnych częściach aplikacji. Ewentualnie ze sprawdzeniem, czy aplikacja w ogóle dotarła do miejsca, w którym został on postawiony. Czyli używamy go jako ubogiej wersji debuggera.

Jego budowa jest bardzo prosta. Node.js udostępnia nam narzędzia (w postaci paczki node:console), więc w prosty sposób możemy zrobić jego kopię:

import { Console } from "node:console";

const console2 = new Console(process.stdout, process.stderr);

console2.log("Nie widać różnicy!");

Taki interfejs dostarczany przez Node daje spore możliwości. Przede wszystkim, nie każdy log musi lecieć na stdout, czyli być wyświetlanym. Warunkiem jest przekazanie do Console jako parametrów WritableStream-ów - np. strumienia zapisu do pliku, który będzie agregował informacje zamiast wyświetlać je na monitorze.

🚨 A logowanie samo w sobie jest szalenie istotne. Nasza aplikacja, oprócz tego, że ma działać i przechodzić testy, ma również dostarczać nam informacje o swoim stanie. Logowanie i monitorowanie tych logów jest integralną częścią procesu deweloperskiego, jak również utrzymaniowego. To nasza najlepsza “czarna skrzynka”, do której możemy zerknąć po katastrofie. Nie można jej pomijać. Bez logów i monitoringu możemy się jedynie domyślać, czy wszystko jest w porządku.

Na co zwracam uwagę w pracy z logami?

1. Nie loguję wrażliwych danych, loguję zdarzenia. Logi nie powinny być lustrem dla bazy danych, nie powinny narażać użytkowników na wycieki.

2. Jeden system logowania. Jeśli używam console, to sukcesywnie. Jeżeli korzystam z bibliotek bądź customowej implementacji Console - również sukcesywnie. Mieszanie rozwiązań powoduje utratę kontroli.

3. Logi nie muszą być prostymi wiadomościami. Możemy przyjąć konkretną strukturę naszych logów, jeśli to poprawi ich czytelność. Warto jednak utrzymać konsystencję takich informacji.

4. Nie krzyczę, jeśli nie muszę. Jeśli błąd - to error. Jeśli informacja o zdarzeniu - to log. Jeśli ostrzeżenie - warn. Nie ma nic gorszego niż przeszukiwanie tysięcy logów w poszukiwaniu błędu, który został przekazany jako tysiąc innych, normalnych wpisów.

5. Przeszukiwanie logów. Dobrze jest mieć do tego narzędzia, takie jak Kibana, która daje wgląd w logi zagregowane na ElasticSearchu. DataDog? Oczywiście! Grep też się nada, ale czasem dobrze jest móc założyć dodatkowe filtry z możliwością alertowania, jeśli z aplikacją będą działy się niepożądane rzeczy.

Czy coś dołożylibyście do tej listy? Macie jakieś dobre praktyki warte wdrożenia?