- Zainstaluj pakiet SDK dla swojego środowiska uruchomieniowego.
- Przechowuj klucz wysyłania przypisany do projektu poza systemem kontroli wersji.
- Ustaw stałe wartości usługi, środowiska i wydania.
- Wyślij z aplikacji jedno bezpieczne zdarzenie testowe.
- Odczytaj wynik dostarczenia. Następnie znajdź zdarzenie w LogBrew.
Sygnały i wspólny kontekst
Pierwszych pięć kart opisuje sygnały. Wydanie i środowisko to kontekst tych sygnałów. Nie są osobnym typem zdarzenia.log
Ustrukturyzowany komunikat z poziomem ważności, źródłem, czasem i
bezpiecznym kontekstem.
trace_span
Jedna mierzona operacja powiązana ze swoim śladem przez ID śladu i spanu.
issue
Zarejestrowany błąd, jego poziom ważności i szczegóły błędu wysłane przez
aplikację.
action
Akcja w twojej aplikacji z opcjonalnym podmiotem, sesją i bezpiecznymi
właściwościami.
metric
Jeden pomiar liczbowy z nazwą, rodzajem, wartością, jednostką i
temporalnością.
release i environment
Wersja kodu i środowisko dołączane do późniejszych zdarzeń w tym samym
zakresie SDK.
Wartości ważności
Dla logów i problemów używajinfo, warning, error lub critical.
Zestawy SDK i środowiska uruchomieniowe mogą wysyłać aliasy, takie jak
trace, debug, warn lub fatal. LogBrew zamienia przyjęte aliasy na
wartości kanoniczne.
Instalacja przez menedżer pakietów
Zainstaluj pakiet SDK dla środowiska uruchomieniowego, które wysyła telemetrię. Użyj konfiguracji SDK lub konfiguracji wysyłania z LogBrew przypisanej do projektu. Nie używaj danych logowania do konta jako konfiguracji SDK.Śledzenie żądań w Node.js
Do korelacji śladów, w których spanem głównym jest żądanie, użyj@logbrew/sdk 0.1.16 lub nowszego i @logbrew/node 0.1.11 lub nowszego.
Express wymaga @logbrew/express 0.1.5 lub nowszego. Fastify i NestJS
wymagają swojego pakietu LogBrew w wersji 0.1.6 lub nowszej.
Te integracje tworzą lub kontynuują jeden span żądania. Nazwa spanu to
dopasowany szablon trasy. Logi, problemy, akcje i metryki w ramach żądania
dziedziczą jego kontekst śladu i spanu. Nowszy pakiet nie dodaje kontekstu do
zdarzeń wysłanych przed aktualizacją.
Domyślna integracja żądań nie rejestruje treści żądań ani odpowiedzi, ciągów
zapytań, dowolnych nagłówków ani surowych wartości traceparent.
ASP.NET Core
CLI w wersji 0.1.55 lub nowszej wykrywa projekty .NET 10, które używająMicrosoft.NET.Sdk.Web. Wyświetl podgląd planu konfiguracji z katalogu
głównego projektu. To polecenie nie zmienia twoich plików:
LOGBREW_SERVER_API_KEY, LOGBREW_SERVICE_NAME,
LOGBREW_ENVIRONMENT i LOGBREW_RELEASE poza systemem kontroli wersji.
Zarejestruj LogBrew w hoście i umieść jego middleware po routingu:
LOGBREW_SERVER_API_KEY oba wywołania rejestrujące bezpiecznie nic nie
robią.
Pakiet NuGet ASP.NET Core
wskazuje opublikowaną integrację z hostem. Jego publiczny przewodnik opisuje
cykl życia hosta, rejestrowanie żądań, rejestrowanie problemów, ograniczenia
prywatności i odzyskiwanie po błędach.
Java: Maven lub Gradle
CLI w wersji 0.1.54 lub nowszej wykrywapom.xml, build.gradle i
build.gradle.kts. Wyświetl podgląd planu konfiguracji z katalogu głównego
projektu. To polecenie nie zmienia twoich plików:
LogBrewClient.
Włącza on opcjonalne integracje żądań, wyjątków, klienta HTTP, JDBC i pamięci
podręcznej.
Rejestrowanie Spring Kafka trzeba jawnie włączyć ustawieniem
logbrew.kafka.enabled=true. Korzysta ono z istniejącej w aplikacji
zależności Spring Kafka i beana klienta.
Artefakt Java SDK w Maven Central
wskazuje opublikowany pakiet. Jego publiczny przewodnik opisuje dostarczanie
przez HTTP z limitami, zamykanie, logowanie, konfigurację Springa, korelację
Kafka i ograniczenia prywatności.
C++ z CMake
SDK dla C++ wymaga C++17 i CMake 3.16 lub nowszego. CLI w wersji 0.1.39 lub nowszej wykrywaCMakeLists.txt w katalogu głównym. Uruchom
logbrew setup --json, aby wyświetlić podgląd tego planu konfiguracji bez
zmieniania plików:
FetchContent_MakeAvailable i
powyższe linkowanie targetu tym kodem:
logbrew-cpp-0.2.3.tar.gz z
wydania C++ 0.2.3.
Rozpakowany pakiet obsługuje cmake --install i
find_package(LogBrew 0.2.3 CONFIG REQUIRED). Jego przewodnik opisuje
typowany kontekst, dowody problemów, zdarzenia spanów, metryki, akcje i
dostarczanie przez HTTP.
Mapy źródeł JavaScript
Dla buildów Vite wykonaj kroki z przewodnika Mapy źródeł JavaScript. Opisuje on wtyczkę, klucz artefaktów, sprawdzanie przesyłania i nowy problem z oryginalnymi lokalizacjami w kodzie źródłowym.Apple, Flask i React Native
Do telemetrii użyj produktu SwiftLogBrew. Dodaj LogBrewCrash tylko do
rejestrowania awarii lub zawieszeń na platformach Apple. Przesyłanie plików
dSYM i hostowaną symbolizację opisuje przewodnik
Awarie i zawieszenia Apple.
Dla Flaska wykonaj kroki z przewodnika Flask.
Dla React Native i Expo wykonaj kroki z przewodnika
React Native. Opisuje on klucz projektu, bezpieczny
log testowy, błędy dostarczania i konfigurację Expo Metro dla produkcyjnych
map źródeł (source maps).
Śledzenie kolejek w JavaScript
Integracje kolejek dla Node to osobne pakiety npm. Zainstaluj podstawowe pakiety JavaScript LogBrew, pakiet integracji i klienta kolejki lub brokera, którego twoja aplikacja już używa.
Używaj tych pakietów do jawnej korelacji śladów wokół wybranych wywołań
kolejki. Tę korelację kontroluje aplikacja. LogBrew nie zarządza połączeniem z
brokerem, nie tworzy kolejek i domyślnie nie modyfikuje globalnie każdego
klienta.
Bezpośrednie wysyłanie natywnej koperty
POST /api/telemetry/ingest jest tylko dla własnych klientów, dla których nie
ma publicznego SDK LogBrew. Publiczne zestawy SDK używają własnego formatu
paczek. Ten endpoint nie przyjmuje tego formatu.
W jednej natywnej kopercie wyślij od 1 do 512 elementów. Wszystkie elementy w
jednej kopercie mają wspólny projekt, usługę, wydanie, środowisko i
opcjonalny kontekst śladu.
Pola elementów
Każdy element matype i obiekt data. Element logu używa level. Element
problemu używa severity. Oba przyjmują wartości opisane w sekcji
Wartości ważności.
Jeśli twój klient może ponawiać wysyłkę, wysyłaj
id z każdym elementem. Gdy
ponowienie wyśle przyjęty już element z tym samym id i tą samą treścią,
LogBrew nie zapisze go drugi raz. Odpowiedź policzy ten element w
already_accepted.
Przykładowe żądanie
Zapisz poniższy JSON jakotelemetry-envelope.json. Zastąp przykładowe ID
projektu dokładnym ID projektu twojego klucza wysyłania. Ustaw znaczniki czasu
na bieżący czas UTC zdarzenia testowego. Użyj własnych wartości usługi i
wydania.
telemetry-envelope.json
LOGBREW_INGEST_BEARER z
chronionej konfiguracji. Nie wypisuj jej i nie używaj poświadczenia konta.
Poniższe polecenie wysyła plik jeden raz. Wymaga curl 7.76.0 lub nowszego:
--fail-with-body zachowuje treść
błędu i przy błędach HTTP zwraca niezerowy kod wyjścia. Błąd sieci lub
przekroczenie limitu czasu nie mówi, czy LogBrew przyjął żądanie. Wyślij ten
sam plik ponownie tylko wtedy, gdy jego elementy mają wartości id. Bez
wartości id drugie wysłanie może zapisać elementy dwa razy.
Odpowiedź
Udane żądanie zwraca200 z liczbą nowych elementów w każdym strumieniu.
already_accepted liczy elementy, które dostarczyło już wcześniejsze żądanie.
Błędy
Nieprawidłowy lub unieważniony klucz wysyłania zwraca401. Klucz innego
projektu też zwraca 401:
422 z kodem validation_failed.
Pole error wskazuje regułę. Pole next mówi, jak poprawić żądanie. Na
przykład "items": [] zwraca:
422 z błędem native telemetry envelope exceeds the item limit.
Podziel ją na paczki po najwyżej 512 elementów. W każdej paczce zachowaj
projekt i wspólny kontekst.
W przypadku limitów wykorzystania, limitów żądań i błędów usługi postępuj
zgodnie ze zwróconym code opisanym na stronie Błędy API.
