Skip to main content
Zainstaluj pakiet SDK LogBrew dla swojego środowiska uruchomieniowego. SDK formatuje zdarzenia i je dostarcza. Przewodnik pakietu opisuje jego typy zdarzeń, limity i sposób ponawiania. Wykonaj te kroki dla każdej integracji:
  1. Zainstaluj pakiet SDK dla swojego środowiska uruchomieniowego.
  2. Przechowuj klucz wysyłania przypisany do projektu poza systemem kontroli wersji.
  3. Ustaw stałe wartości usługi, środowiska i wydania.
  4. Wyślij z aplikacji jedno bezpieczne zdarzenie testowe.
  5. Odczytaj wynik dostarczenia. Następnie znajdź zdarzenie w LogBrew.
Przyjęta paczka dotarła do API LogBrew. Filtry nadal mogą ukrywać jej zdarzenia. Wybierz właściwy projekt i zakres czasu. Następnie dopasuj usługę, środowisko, wydanie i typ sygnału. Zanim włączysz rejestrowanie, wybierz i przetestuj zatwierdzone pola. Aby zasilić danymi widok „Analityka”, wykonaj kroki z przewodnika Rejestrowanie zdarzeń produktowych.

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żywaj info, 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:
Plan dla opublikowanej wersji instaluje integrację z hostem:
Ustaw 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:
Bez 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 wykrywa pom.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:
W Mavenie dodaj opublikowany pakiet:
W Gradle Kotlin DSL dodaj ten sam artefakt z Maven Central:
Użyj Javy 11 lub nowszej. Aplikacje Spring Boot 3 i 4 mogą udostępnić własny bean 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 wykrywa CMakeLists.txt w katalogu głównym. Uruchom logbrew setup --json, aby wyświetlić podgląd tego planu konfiguracji bez zmieniania plików:
Główny target nie ma zależności. Aby wysyłać paczki przez opcjonalny transport libcurl, zastąp końcowe wywołanie FetchContent_MakeAvailable i powyższe linkowanie targetu tym kodem:
Skonfiguruj aplikację. Następnie zbuduj ją, aby przetestować wybraną wersję SDK:
Jeśli build nie może pobrać monorepo SDK, użyj osobnego pliku 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 Swift LogBrew. 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.
Nie umieszczaj w konfiguracji SDK treści wiadomości z kolejki, dowolnych nagłówków wiadomości, adresów URL brokerów ani tokenów sesji lub konta (bearer). Użyj serwerowej konfiguracji wysyłania z LogBrew przypisanej do projektu.

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 ma type 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 jako telemetry-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
Wczytaj wartość klucza wysyłania projektu do 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:
Odczytaj status HTTP i treść odpowiedzi. --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 zwraca 200 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 zwraca 401. Klucz innego projektu też zwraca 401:
Użyj klucza wysyłania przypisanego do projektu. Nie zastępuj go poświadczeniem konta. Klucz artefaktów nie może wysyłać telemetrii. Koperta, która narusza regułę pola, zwraca 422 z kodem validation_failed. Pole error wskazuje regułę. Pole next mówi, jak poprawić żądanie. Na przykład "items": [] zwraca:
Nie wysyłaj koperty, gdy nie ma zdarzeń. Koperta z więcej niż 512 elementami 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.
Ustaw wydanie i środowisko w konfiguracji SDK. Dla każdej operacji twórz lub kontynuuj kontekst śladu. Nie używaj jednego ID śladu do niezwiązanych ze sobą zadań.