W przepływach pracy agentów używaj
--json. Przechowuj poświadczenia w
chronionej konfiguracji lokalnej. Między ludźmi, narzędziami i agentami
przekazuj tylko nazwy zmiennych.Zanim zaczniesz
Przygotuj:- Node.js 18 lub nowszy.
- CLI LogBrew w wersji 0.1.30 lub nowszej.
jq.- Bash lub Zsh.
- Katalog pakietu aplikacji Node.js działającej po stronie serwera.
quickstart-node, środowiska development i wydania
quickstart@1. Oddziel ten test od środowiska produkcyjnego. Dla innego
środowiska uruchomieniowego skorzystaj z
przewodnika po integracji SDK.
Wyślij i odczytaj pierwszy log
1
Sprawdź stan konta
Zainstaluj CLI poleceniem z przewodnika po CLI. Następnie
sprawdź stan konta w CLI.Punkt kontrolny: status pokazuje uwierzytelniony dostęp do konta. Jeśli
tak nie jest, człowiek jednorazowo uruchamia
logbrew login. Potem ponownie
uruchom logbrew status --json. Agent nie może rozpoczynać nowego
logowania, gdy obecne uwierzytelnienie działa.2
Utwórz jeden projekt z CLI
Wskaż nowy plik w katalogu dostępnym tylko dla właściciela. CLI zapisuje
klucz wysyłania projektu w tym pliku, zanim zgłosi powodzenie. Nigdy nie
wypisuje klucza ani ścieżki jego pliku.Tworzenie projektu zmienia stan konta. Plik docelowy nie może istnieć.
Jeśli wynik jest niejasny, uruchom dokładnie to samo polecenie ponownie. CLI
ponownie użyje tożsamości oczekującego żądania. Użyj
--abandon-retry tylko
wtedy, gdy chcesz zacząć inną próbę.Punkt kontrolny: wynik pokazuje status: "created", status
konfiguracji created i rodzaj klucza wysyłania. Projekt istnieje, a klucz
jest zapisany. To nie potwierdza dostarczenia telemetrii. Zobacz
Projekty.3
Zainstaluj SDK dla Node.js
4
Wyślij jeden bezpieczny log z SDK
Wyślij znaczniki wydania i środowiska razem z jednym logiem Nie umieszczaj w zdarzeniu poświadczeń, nagłówków, treści żądań, danych
klientów ani ścieżek lokalnych.Punkt kontrolny: skrypt wypisuje
info, który
zawiera tylko wartości zastępcze. Klucz jest ustawiony tylko dla tego
procesu Node.js. Tożsamość aplikacji trafia do context.Każde uruchomienie tworzy nowe ID zdarzeń. Jeśli SDK ponawia dostarczenie w
tym samym uruchomieniu, wysyła tę samą treść z tymi samymi ID. LogBrew nie
zapisuje drugi raz przyjętego zdarzenia, gdy ponowienie wyśle je jeszcze
raz."ok":true i status_code z zakresu
2xx. Po ponowieniu attempts jest większe niż 1. Udane wysłanie nie
kończy sprawdzania.Jeśli dostarczenie się nie powiedzie, skrypt kończy działanie z kodem 1 i
wypisuje krótki błąd w formacie JSON, na przykład
{"ok":false,"error":"unauthenticated"}. Nie wypisuje treści żądania ani
klucza. Odrzucony klucz projektu powoduje unauthenticated. Nowe
logowanie w CLI tego nie naprawi.5
Odczytaj raport diagnostyki projektu
Do tego odczytu CLI używa zapisanego dostępu do konta. Nie używaj klucza
wysyłania projektu.Punkt kontrolny: raport ma
status: "ready". Odczytaj też każdy
element w checks. Kod wyjścia 0 nie pokazuje, że wszystkie sprawdzenia
się powiodły. Przy innym statusie postępuj zgodnie z next i
opisem raportu diagnostyki projektu.
Projekt ready nie potwierdza, że ten log testowy dotarł.6
Odczytaj log testowy
Użyj projektu, wydania i środowiska z paczki SDK.Punkt kontrolny:
LogBrew quickstart check pojawia się dla tego
projektu, wydania i środowiska. To potwierdza dostarczenie tylko logu
testowego.Odczytaj wynik testu
Przykład wysyła trzy zdarzenia. Tylko jedno z nich to log. Znaczniki wydania i środowiska dodają kontekst do logu.
Pozostaw test na poziomie
info. Nie zmieniaj go na error, żeby łatwiej go
znaleźć. Zamiast tego użyj filtrów projektu i czasu. Zobacz
Wartości ważności.
Wiersz console.log wypisuje wynik dostarczenia w terminalu. Wywołanie
client.log wysyła log do LogBrew. Udane pierwsze dostarczenie wypisuje:
--project w CLI
nie przenosi zdarzeń.
Ten log nie ma kontekstu śladu, ponieważ przykład nie tworzy spanu żądania.
Nie oznacza to, że wysłanie logu się nie powiodło. Odczyt w CLI to migawka.
Uruchom go ponownie, aby odczytać późniejsze zdarzenia, albo użyj
logbrew watch logs --json, aby oglądać strumień na żywo.
Typowe działania naprawcze
Jeśli telemetrii nadal brakuje, wykonaj
sprawdzenia pierwszej telemetrii.
Jeśli to nie pomoże, zgłoś problem. Nie załączaj
poświadczeń, surowej telemetrii, danych klientów, ścieżek lokalnych ani kodu
źródłowego.
Przejdź do swojej aplikacji
- Utwórz klienta jeden raz, w kodzie inicjalizującym aplikację.
- Przypnij wersje SDK w plikach pakietów. Testuj aktualizacje poza środowiskiem produkcyjnym.
- Wczytuj klucz wysyłania z istniejącej konfiguracji sekretów. Wymień go po możliwym wycieku. Zobacz Wymień klucz wysyłania.
- Używaj stałych nazw usługi, środowiska i wydania z konfiguracji wdrożenia. Zobacz Wydania.
- Pisz komunikaty logów, które podają operację i jej wynik, na przykład
Report generation completed. Nie umieszczaj w komunikacie prywatnych wartości. Nie kopiuj do logu całego żądania ani rekordu użytkownika. - Każdy log aplikacji powinien mieć jednego nadawcę, aby uniknąć duplikatów. Zanim dodasz LogBrew, znajdź integrację, która już wysyła każdy wpis.
- Przed wdrożeniem produkcyjnym wyślij jedno bezpieczne zdarzenie przez rzeczywistą ścieżkę kodu i odczytaj je. Sprawdź jego komunikat, usługę, wydanie i środowisko. Samodzielny przykład nie testuje ścieżki kodu twojej aplikacji.
Projekty
Sprawdzaj stan konfiguracji i zarządzaj kluczami wysyłania projektu.
Integracja SDK
Wybierz pakiet SDK dla swojego środowiska uruchomieniowego.
Zbadaj problem
Prześledź dowody ze śladu i powiązanych logów dla jednego problemu.
Zgłoś problem
Wyślij bezpieczne, prywatne zgłoszenie do pomocy technicznej.
