Skip to main content
Ta strona pokazuje po jednym przykładzie każdego rodzaju odpowiedzi API telemetrii. Wszystkie wartości są syntetyczne. Kody błędów i sposoby naprawy opisuje strona Błędy API.

Jak odczytać odpowiedź

Odczytuj każdą odpowiedź w tej kolejności:
  1. Sprawdź status HTTP.
  2. Upewnij się, że treść ma strukturę, którą określa dana trasa.
  3. Upewnij się, że każdy project_id mieści się w żądanym zakresie projektów.
  4. Nie zmieniaj kanonicznych wartości wyliczeniowych ani identyfikatorów.
  5. Wykonuj next_action tylko wtedy, gdy klient obsługuje jego code i target.
  6. Rozróżniaj null, pominięte pole i pustą listę. To 3 różne stany.
Odpowiedź 200 OK może zawierać pustą listę. Pusta lista logów oznacza, że żaden log nie pasuje do żądania. Nie oznacza, że problemy, ślady lub akcje też są puste. Nie łącz sygnałów tylko dlatego, że mają zbliżone znaczniki czasu. Przechodź do śladu tylko wtedy, gdy odpowiedź zawiera jego dokładny trace_id. 404 i pusta lista to różne wyniki. Trasa listy zwraca [], gdy żaden rekord nie pasuje. Trasa szczegółów zwraca 404 z code: not_found, gdy nie znajduje rekordu dostępnego do odczytu. Żaden z tych wyników nie dowodzi, że przyjmowanie danych się nie powiodło.

Co wysyłać

Odpowiedzi są tak przydatne, jak telemetria, którą wysyłasz. Wysyłaj te wartości w każdej kopercie lub konfiguracji SDK:
  • release i environment.
  • Stałe nazwy usług, akcji i metryk.
  • Kontekst śladu, gdy logi, spany (pojedyncze mierzone operacje), akcje i problemy należą do tego samego żądania.
  • Kanoniczne wartości ważności: info, warning, error i critical.
  • Atrybuty pomocne w debugowaniu, bez sekretów i zbędnych danych osobowych.
Zobacz Integracja SDK i Kontrola rejestrowanych danych.

Odpowiedź przyjmowania danych

Publiczne SDK same odczytują odpowiedź POST /v1/events. Kod aplikacji nie musi jej obsługiwać.

Odpowiedź na paczkę SDK

Przyjęta paczka SDK zwraca 200 OK z liczbą przyjętych zdarzeń dla każdego strumienia:
Liczby dotyczą tylko tej paczki. Ponowienie paczki, którą LogBrew już przyjął, zwraca 0 dla każdego strumienia, a w already_accepted liczbę zdarzeń. Przy ponowieniu zachowaj oryginalne ID zdarzeń.

Odpowiedź na natywną kopertę

POST /api/telemetry/ingest zwraca 200 OK z liczbą przyjętych elementów dla każdego strumienia:
Natywna odpowiedź nie ma pól metrics ani context_updated. Nie dodawaj ich. already_accepted liczy elementy, których id LogBrew przyjął wcześniej dla projektu. Zobacz bezpośrednie wysyłanie natywnej koperty.

Błędy przyjmowania danych

401 z code: ingest_key_invalid oznacza, że token bearer wysyłania został unieważniony, wygasł lub nie jest ważny dla projektu. W POST /v1/events brak tokena bearer albo token bearer, który nie jest kluczem wysyłania, zwraca 401 z code: unauthorized. Użyj aktualnego tokena bearer wysyłania przypisanego do projektu. Nie ponawiaj żądania z tokenem bearer konta. Odrzucona paczka SDK zwraca 422 z code: validation_failed:
Inne wartości error to między innymi SDK event batch requires at least one event i SDK event type is not supported by this ingest route. Sprawdź wersję SDK i konfigurację transportu. Nie wysyłaj pustej paczki. Nie zmieniaj typów ani ID zdarzeń tylko po to, aby paczka przeszła walidację. Żądanie z metodą inną niż POST zwraca 405 z code: method_not_allowed. Nieczytelna treść JSON zwraca code: invalid_json.

Format odpowiedzi list telemetrii

Trasy list domyślnie zwracają zwykłą tablicę JSON. Pusta lista w udanej odpowiedzi to []. Z pagination=cursor trasa zwraca kopertę (envelope). Klucz kolekcji odpowiada sygnałowi: next_cursor to obiekt z polami kontynuacji albo null na ostatniej stronie. Wiersze są posortowane od najnowszych. Zobacz paginację kursorową.

Odpowiedź z logami

Strona kursora z logami przy limit=1:
Logi zawierają level dla zgodności i severity do wyświetlania. Oba pola mają wartość kanoniczną. triage zawiera wynik reguły ważności. Zobacz odpowiedzi reguł ważności. trace_id i span_id mają wartość null, gdy log nie jest powiązany ze śladem. Wtedy next_action to inspect_related_logs z celem telemetry_logs. Logi, problemy i akcje używają tych samych 2 par next_action. GET /api/logs/{log_id} zwraca jeden log w tej samej strukturze.

Odpowiedź z problemem

GET /api/telemetry/issues/{issue_id} zwraca jeden zgrupowany problem. Lista zwraca te same obiekty. Ten przykład używa domyślnej wersji odpowiedzi 1:
W wersji 1 status to unresolved, resolved lub ignored. Dla zarchiwizowanego problemu triage.ignored ma wartość true. Pary next_action i odczyty, które po nich następują, opisuje przewodnik Zbadaj problem. first_seen_at i last_seen_at to czasy pierwszego i ostatniego wystąpienia. Nie zmieniają się po zmianie statusu. Niektóre pola pojawiają się tylko wtedy, gdy LogBrew ma dane: symbolication.status to resolved, invalid_metadata, artifact_not_found, source_not_resolved lub unavailable. Lista, zmiany statusu i zmiany reguł nie zwracają symbolication. Z response_version=2 problem ma te same pola, z następującymi zmianami:
Ten przykład pokazuje tylko część pól. Wyliczony priorytet to high dla error i critical, medium dla warning oraz low dla info. Korzysta z triage.effective_severity, więc reguła ważności problemu może go zmienić. Z response_version=3 problem ma wszystkie pola wersji 2 oraz assignee. assignee ma wartość null, gdy problem nie ma przypisania:
Problem nie pokazuje przypisania, gdy przypisany członek nie ma już dostępu do odczytu projektu. Z response_version=4 pole assignee ma też type. Przypisanie do konta (user) ma user_id, name i email, tak jak w wersji 3. Przypisanie do zespołu (team) ma team_id, slug i name. Wersja 3 pokazuje przypisanie do zespołu jako null. CLI żąda wersji 4:
Każda inna wartość response_version zwraca 422 z code: validation_failed. Strona kursora używa tej samej wersji dla każdego problemu w issues.

Odpowiedź z listą kont i zespołów do przypisania

GET /api/telemetry/issues/assignees?project_id=<project_id> zwraca każde konto, któremu można przypisywać problemy w projekcie:
Dodaj response_version=2, aby dostać też teams: każdy zespół organizacji projektu z team_id, slug i name. Jeśli konto nie może odczytać projektu, trasa zwraca 404 z code: not_found.

Odpowiedź z akcją

distinct_id śledzi jednego aktora lub jedną sesję. Traktuj distinct_id i session_id jako nieprzezroczyste identyfikatory (opaque). session_id i trace_id mają wartość null, gdy ich brakuje. span_id jest pomijany, gdy go brakuje. Akcja nie ma poziomu ważności. Zobacz Rejestrowanie zdarzeń produktowych.

Odpowiedź z metryką

Każdy element to jedna próbka. Nie używaj liczby próbek jako liczby zdarzeń ani użytkowników. unit, temporality, trace_id i span_id mają wartość null, gdy ich brakuje. Wartość null to nie zero.

Odpowiedź z wydaniem

Jeden wiersz obejmuje jeden projekt, wydanie, środowisko i usługę. Jego liczby opisują tylko ten wiersz. trace_health.status to unknown, gdy wiersz nie ma śladów, a w pozostałych przypadkach no_errors_observed lub errors_observed. error_rate_basis_points to udział śladów ze spanem błędu, od 0 do 10000. To nie jest wskaźnik błędów dla wszystkich żądań. next_action wskazuje pierwszy typ sygnału, który ma dane, w tej kolejności: Zobacz Wydania.

Odpowiedź z wyszukiwania śladów

GET /api/telemetry/traces?pagination=cursor zwraca jeden wiersz dla każdego śladu oraz potwierdzenie naming_quality dla zwróconej strony:
naming_quality dotyczy tylko zwróconej strony. To nie jest wynik dla całego konta. truncated: true oznacza, że istnieje kolejna strona. Gdy strona ma ogólną nazwę, niedopasowaną trasę HTTP lub ogólną operację, next_action to improve_trace_naming z celem sdk_configuration. Bez pagination=cursor trasa zwraca zwykłą tablicę śladów bez naming_quality. next_cursor zawiera time i trace_id. Wyślij je jako cursor_time i cursor_trace_id. GET /api/telemetry/traces/{trace_id} zwraca spany jednego śladu. GET /api/telemetry/traces/{trace_id}/summary zwraca span główny, spany błędów, usługi, czas trwania i najwolniejszą ścieżkę, bez surowych atrybutów spanów. 404 z podsumowania oznacza, że żaden ślad nie pasuje do pełnego zakresu. Nie usuwaj filtrów, aby ponowić żądanie. Zobacz odpowiedzi ze spanami i podsumowaniem śladu.

Puste listy i brakujące rekordy

Odczyt listy może nie mieć dopasowań. Odczyt szczegółów działa według innych zasad: Brakujący log zwraca taki 404:
Brakujący problem używa "error": "issue not found". Brakujące podsumowanie śladu używa "error": "trace not found". Nieznane ID i ID, którego konto nie może odczytać, zwracają tę samą odpowiedź. Lista z jednym project_id, którego konto nie może odczytać, zwraca 200 z pustą listą. Sprawdź ID projektu, zanim zgłosisz, że danych nie ma.

Odrzucony wybór projektów

Listy logów, problemów, akcji, metryk, wydań i śladów przyjmują jeden projekt w project_id albo od 2 do 50 projektów w project_ids. Katalog atrybutów logów przyjmuje te same selektory. Historia wystąpień problemu ich nie przyjmuje. Żądanie z project_id i project_ids jednocześnie zwraca 422:
project_ids z nieprawidłowym UUID, powtórzonym ID albo z mniej niż 2 lub więcej niż 50 ID również zwraca 422 z code: validation_failed. Jeśli konto nie może odczytać jednego projektu ze zbioru project_ids, całe żądanie zwraca 404. Nie zwraca pozostałych projektów jako wyniku częściowego:
Pokaż błąd, a nie pustą listę ani zerową liczbę. Odczytaj listę projektów ponownie. Nie usuwaj projektu po cichu i nie ponawiaj żądania dla wszystkich projektów. Delegowane poświadczenie, na przykład połączenie MCP, zwraca 403 z code: forbidden dla projektu, którego to połączenie nie obejmuje. Zobacz zakres projektów.

Błędy kursora

Logi, problemy, akcje, metryki i wystąpienia problemów używają cursor_time i cursor_id. Odrzucony kursor zwraca 422 z code: validation_failed. Te błędy nie oznaczają, że lista jest pusta. Na przykład:
Skopiuj cały next_cursor z poprzedniej strony. Nie zastępuj cursor_time bieżącym czasem. Jeśli kursor zaginął, zacznij od nowa z pagination=cursor i pierwotnymi filtrami. Nieznany parametr zapytania lub wartość niewłaściwego typu zwraca 422 z "error": "invalid query parameters".

Odpowiedzi z kursorem wydań

Kursor wydań ma 5 pól. Udane żądanie bez dopasowań zwraca 200:
Gdy next_cursor nie jest null, wyślij wszystkie 5 wartości w następnym żądaniu: cursor_project_id oznacza pozycję. Nie zastępuje project_id ani project_ids. Zachowaj pierwotne parametry projektu i filtrów. Zakoduj każdą wartość do użycia w URL (URL encoding). Z pagination=cursor niepełny kursor albo pusta wartość wydania, środowiska lub usługi zwraca 422 z "error": "all release cursor fields must be sent together". Nieprawidłowy cursor_time i brak pagination=cursor zwracają te same błędy co inne kursory.

Błędy wyszukiwania śladów

Te błędy dotyczą GET /api/telemetry/traces. Każdy zwraca 422 z code: validation_failed. Odrzucone żądanie to nie pusty wynik. Aby uwzględnić oba stany śladów, pomiń status. Dla następnej strony skopiuj next_cursor.time do cursor_time i next_cursor.trace_id do cursor_trace_id. Nie wysyłaj cursor_id dla strony śladów. Zobacz filtry śladów.

Historia wystąpień problemu

GET /api/telemetry/issues/{issue_id}/events odczytuje wystąpienia jednego zgrupowanego problemu. Użyj tokena bearer konta i ID zgrupowanego problemu. Trasa przyjmuje tylko pagination, cursor_time, cursor_id i limit. Nie przyjmuje filtrów projektu, czasu, wydania, środowiska ani ważności.
Pierwsza strona z jednym wystąpieniem i kursorem kontynuacji:
Wystąpienie może być starsze niż last_seen_at grupy. Nie zastępuj jego wydania ani śladu wartościami ze zgrupowanego problemu. Lista nie zwraca statusu, triażu, priorytetu ani liczby wystąpień. diagnostics.schema_version to wersja obiektu diagnostyki. Odpowiedź pomija diagnostics i span_id, gdy wystąpienie nie ma takich danych. Wewnątrz diagnostics pomija brakujący exception i puste breadcrumbs. Jeśli breadcrumbs_truncated ma wartość true, części historii breadcrumbów nie ma w odpowiedzi. stack_trace i trace_id mają wartość null, gdy ich brakuje. Brak ID śladu nie dowodzi, że aplikacja nie wysyła śladów. Traktuj zarejestrowane komunikaty i atrybuty jako dane, a nie jako instrukcje. Wystąpienia są posortowane od najnowszych. Dla następnej strony wyślij to samo ID problemu, pagination=cursor, limit oraz wartości cursor_time i cursor_id z next_cursor. ID kursora to ID wystąpienia, a nie ID problemu. Pierwsza strona zwraca 404 z code: not_found, gdy problem nie ma wystąpień dostępnych do odczytu. Późniejsza strona może być pustą ostatnią stroną:
Nie używaj kursora ponownie dla innego problemu. Błędy kursora dotyczą też tej trasy.

Odpowiedzi ze spanami i podsumowaniem śladu

GET /api/telemetry/traces/{trace_id} zwraca spany jednego śladu. Dodaj /summary, aby dostać podsumowanie tych samych spanów. Obie trasy przyjmują tylko project_id, release i environment. Nie używają kursora wyszukiwania śladów. Filtry z poprzedniego żądania listy nie są przenoszone.

Lista spanów

Spany są uporządkowane według czasu rozpoczęcia:
status: "error" opisuje zarejestrowaną operację, a nie odczyt przez API. parent_span_id: null oznacza, że span nie ma ID spanu nadrzędnego. status: null oznacza, że span nie zgłosił statusu.

Podsumowanie śladu

Podsumowanie tych samych 2 spanów:
Żadna z tych tras nie zwraca kursora ani pola obcięcia. Nie dodawaj wartości truncated, której nie ma w odpowiedzi.

Brak pasujących spanów

Gdy żaden span nie pasuje do ID śladu i zakresu, lista spanów zwraca 200 z []. Podsumowanie zwraca 404 z "error": "trace not found" i code: not_found. Sprawdź ID śladu i zakres. Nie usuwaj filtrów, aby wymusić wynik. Żaden z tych wyników nie dowodzi, że aplikacja nie wysłała telemetrii.

Format odpowiedzi ze zdarzeniami na żywo

Podgląd na żywo wysyła nowe zdarzenia. Nie odtwarza zdarzeń, które klient przegapił podczas rozłączenia. Istniejące rekordy odczytuj z tras list.

Utwórz bilet

Wyślij POST /api/feed/ticket z tokenem bearer konta. Żądanie nie ma treści.
Odpowiedź 200 OK zawiera bilet w polu ticket:
Bilet to krótkotrwałe poświadczenie. Nie zapisuj go w logach i nie umieszczaj go w prompcie agenta. Otwórz połączenie, zanim upłynie expires_in_seconds. Ten termin ogranicza moment rozpoczęcia połączenia, a nie czas jego trwania. 401 oznacza, że logowanie na konto nie jest ważne. Zaloguj się ponownie, zanim zażądasz biletu. Metoda inna niż POST zwraca 405 z code: method_not_allowed.

Otwórz połączenie

Połącz klienta WebSocket z wss://api.logbrew.co/api/feed/live?ticket=<feed-ticket>. Zakoduj bilet do użycia w URL. Nie umieszczaj w URL tokena bearer konta ani tokena bearer wysyłania. 401 oznacza, że bilet lub logowanie na konto nie jest ważne. Po ponownym zalogowaniu się utwórz nowy bilet. Po błędzie odczekaj, zanim połączysz się ponownie. Nie łącz się ponownie w ciasnej pętli.

Odczytaj komunikaty

Każdy komunikat to koperta { "type": "...", "data": ... }. Odczytaj type, zanim sparsujesz data. Pomijaj typy, których klient nie obsługuje.
Zdarzenie native_issue używa wersji 1 odpowiedzi z problemem: zarchiwizowany problem ma status ignored, a zdarzenie nie ma priorytetu. Metryki i wydania nie są typami zdarzeń na żywo. Odczytuj je z ich tras list. Bilet nie wybiera projektu. Sprawdź project_id każdego zdarzenia, zanim pokażesz je w widoku projektu. logbrew watch --json korzysta z tego podglądu na żywo. Zobacz dokumentację referencyjną CLI.

Obsłuż zamknięte połączenie

Inne rozłączenia mogą nie mieć powodu podanego przez LogBrew. Po ponownym połączeniu ponownie odczytaj dane z tras list i dopasuj rekordy według ID.

Przykłady odpowiedzi na zmianę statusu problemu

PATCH /api/telemetry/issues/{issue_id} z { "status": "resolved" } zwraca 200 OK ze zaktualizowanym zgrupowanym problemem w tej samej strukturze co odpowiedź z problemem. Parametr zapytania response_version wybiera wersję. Odpowiedź nie zawiera flagi powodzenia. Treść ustawia co najmniej jedno z pól status, priority i assignee. status przyjmuje unresolved, resolved lub archived. ignored to starsza nazwa archived. Zobacz Zaktualizuj jeden problem. Sprawdź zwrócone id, status i priority, zanim pokażesz powodzenie. Nie buduj wyniku z wysłanych wartości. Zmiana statusu nie usuwa wystąpień ani nie zmienia first_seen_at i last_seen_at. Nie zmienia też severity ani reguły ważności. Odrzucona zmiana zwraca 422 z code: validation_failed:
Pole, które ma już żądaną wartość, się nie zmienia. Po przekroczeniu limitu czasu lub utracie odpowiedzi wyślij to samo żądanie ponownie albo najpierw odczytaj problem. Nie wysyłaj innej zmiany, zanim odczytasz bieżący stan. Zobacz Zapisy. POST /api/telemetry/issues/bulk zwraca 200 OK z 1 wynikiem dla każdego żądanego ID problemu, w kolejności z żądania. Każdy znaleziony problem ma strukturę wersji 3. Wynik not_found ma issue: null:
Ten przykład pokazuje tylko część pól problemu. outcome to updated, unchanged lub not_found. Powtórzone żądanie zwraca unchanged i niczego nie zmienia. Zobacz Zaktualizuj wiele problemów naraz. Żądanie zbiorcze kończy się błędem w całości w tych przypadkach:

Zakres żądań analityki

Trasy analityki, trasa szeregu metryki i trasa wolumenu sygnałów odczytują jeden projekt i jeden zakres czasu. Każde żądanie wymaga project_id i since. since przyjmuje skrócony zapis czasu trwania, na przykład 24h lub 7d, albo znacznik czasu RFC3339. until przyjmuje znacznik czasu RFC3339, a domyślnie ma wartość czasu żądania. Zakres obejmuje since, wyklucza until i nie może przekraczać 31 dni. service_name, release i environment to opcjonalne filtry dokładne. Każda wartość musi mieć od 1 do 256 znaków po usunięciu spacji przez LogBrew. Trasa porównania segmentów umieszcza te filtry wewnątrz każdego segmentu, a nie na najwyższym poziomie. Jeśli konto nie może odczytać projektu, te trasy zwracają 200 OK z zerowymi liczbami. Nie zwracają 404. Pusty wynik nie potwierdza dostępu do projektu. Porównaj project_id z projektami, które konto może odczytać. Żądanie przez połączenie MCP, które nie obejmuje projektu, zwraca 403 i forbidden. Każda odpowiedź zaczyna się od schema_version, query i purpose. query powtarza efektywny zakres. Pomija filtr, którego nie wysłano. purpose to zwykły tekst, który wyjaśnia, na jakie pytanie odpowiada trasa. Wskaźnik jest pomijany, gdy jego mianownik wynosi zero. Pominięty wskaźnik nie oznacza ani 0, ani null. Odczytaj coverage, zanim zaufasz wskaźnikowi.

Wspólne błędy zakresu

Te błędy używają HTTP 422 i validation_failed: Na przykład żądanie bez project_id zwraca:
Trasy szeregu metryki i wolumenu sygnałów stosują te same zasady zakresu, ale z własnym tekstem error. Te błędy wymieniają sekcje tych tras poniżej. Nieznany parametr zapytania zwraca 422 z odpowiedzią nieprawidłowe parametry zapytania. Nieznane pole JSON, brak wymaganego pola JSON lub nieobsługiwana wartość wyliczeniowa zwraca invalid_json. Zobacz Nieprawidłowy JSON. Żądanie z niewłaściwą metodą HTTP zwraca 405 i method_not_allowed. Jego tekst next podaje obsługiwaną metodę i pola. Zobacz Nieobsługiwana metoda.

Odpowiedź z przeglądem analityki produktowej

GET /api/telemetry/analytics/overview pokazuje aktywność w jednym projekcie: wolumen akcji, użytkowników, sesje, szereg czasowy, najczęstsze akcje oraz sklasyfikowane wyświetlenia stron, wyświetlenia ekranów i interakcje. Użyj go, aby znaleźć dokładne nazwy zdarzeń dla pozostałych tras analityki. Wysyłaj response_version=3. Wersje 1 i 2 zwracają te same liczby, ale ich wartość estimation.method to starszy token. Wersja 1 nie sprawdza rodzaju podmiotu, gdy liczy zidentyfikowanych użytkowników. Wersje 2 i 3 liczą tylko podmioty rodzaju user i dodają liczby anonimowych podmiotów oraz subject_coverage. To żądanie odczytuje jedną godzinę w przedziałach pięciominutowych i zwraca po 2 wiersze na każdej liście najczęstszych pozycji:

Udany przegląd

W tym syntetycznym wyniku projekt ma 120 akcji w 2 z 12 przedziałów. Od anonimowych podmiotów pochodzi 20 akcji. Każda akcja ma ID sesji. Połowa akcji ma ID śladu.

Odczytaj przegląd

Pięć liczb w subject_coverage sumuje się do łącznej liczby zdarzeń w ich sekcji. Do użytkowników liczy się tylko identified_user_events. anonymous_actions to summary.actions minus identified_actions. series zawiera tylko przedziały z aktywnością. expected_buckets to liczba możliwych przedziałów w zakresie. Nie rysuj brakującego przedziału jako zmierzonego zera, chyba że wykres wyraźnie podaje tę zasadę. Przedziały są wyrównane do granic przedziałów w UTC. Zakres, który zaczyna się w środku przedziału, obejmuje ten niepełny przedział. classified_activity liczy wyświetlenia stron, wyświetlenia ekranów i interakcje. Wyświetlenia ekranów i interakcje są też akcjami. Wyświetlenia stron nie są. Nie dodawaj summary.actions do classified_activity.summary.events. Kopiuj kind i event_name z classified_activity.top_events do kroków lejka, selektorów utrzymania, selektorów cyklu życia, zdarzeń kotwiczących ścieżek i celów segmentów. Wartość true w top_events_truncated oznacza, że istnieją rzadsze nazwy. Aby zobaczyć więcej, zwiększ top_limit maksymalnie do 20. analysis_level to no_data, event_only, user_level lub user_and_session. Jeśli projekt nie ma akcji ani sklasyfikowanych zdarzeń, next_action.code to capture_product_activity. Zobacz Analityka produktowa.

Błędy przeglądu

Oprócz wspólnych błędów zakresu przegląd zwraca 422 i validation_failed dla tych wartości: Domyślny interval to auto. Wybiera najmniejszą długość przedziału, przy której liczba przedziałów nie przekracza 300. Domyślny top_limit to 10.

Odpowiedź z uporządkowanym lejkiem

POST /api/telemetry/analytics/funnel mierzy, ile jednostek przechodzi przez kroki w ustalonej kolejności. Lejek ma od 2 do 8 kroków. Skopiuj każde dokładne kind i event_name z classified_activity.top_events w przeglądzie. Podobna nazwa akcji nie jest dopasowaniem. Ta treść żądania liczy sesje, które wyświetlają /pricing, a potem w ciągu godziny kończą rejestrację:
analysis_unit to session lub identified_user. Domyślnie session. kind kroku to page_view, screen_view lub interaction. Trasa lejka nie przyjmuje response_version.

Udany lejek

Odpowiedź 200 OK:
Wskaźniki to ułamki od 0 do 1. Odczytaj coverage, zanim zaufasz wskaźnikowi. selected_unit_coverage_rate to udział zdarzeń wybranych kroków, których LogBrew mógł użyć. Odpowiedź nie zwraca surowych tożsamości. Zobacz Analityka produktowa.

Odczytaj konwersję i pokrycie

entry_rate to entered_units podzielone przez candidate_units: 50 z 60. overall_conversion_rate to completed_units podzielone przez entered_units: 15 z 50, czyli 30%. To nie jest 15 podzielone przez wszystkie jednostki kandydujące. Te liczby nie wyjaśniają, dlaczego jednostki się zatrzymały. Pokrycie liczy zdarzenia, a nie sesje. Tutaj 120 zdarzeń pasuje do kroku, a 20 z nich nie ma ID sesji. Wynik wyklucza tych 20 zdarzeń z liczby sesji. Nie traktuj ich jako 20 nieudanych sesji. Pierwszy krok nie ma conversion_from_previous. Ostatni krok nie ma drop_off_to_next_units ani drop_off_to_next_rate. Jednostka dociera do późniejszego kroku tylko wtedy, gdy czasy kroków ściśle rosną. Zdarzenia z tym samym znacznikiem czasu nie mogą spełnić 2 kolejnych kroków. Ostatni krok musi nastąpić w ciągu conversion_window_seconds od pierwszego kroku. Tryb sesji liczy sesje, a nie osoby. Używaj identified_user tylko dla zdarzeń, które mają nieprzezroczyste ID podmiotu rodzaju user. Ten tryb może łączyć zdarzenia z różnych sesji w obrębie okna konwersji. Porównując wyniki, zachowaj tę samą jednostkę i te same kroki. Domyślne conversion_window_seconds to 24 godziny albo długość zakresu, zależnie od tego, która wartość jest mniejsza. Maksimum to długość zakresu w pełnych sekundach, zaokrąglona w górę.

Puste wyniki lejka

Udana pusta odpowiedź nadal wymienia żądane kroki z zerowym units. Jeśli nie ma jednostek kandydujących, summary pomija entry_rate i overall_conversion_rate. Trasa nie zwraca 404 z powodu braku pasujących zdarzeń. Aby znaleźć przyczynę, odczytaj coverage i next_action:

Odrzucone żądania lejka

Oprócz wspólnych błędów zakresu te żądania zwracają 422 i validation_failed. Mniej niż 2 lub więcej niż 8 kroków:
conversion_window_seconds równe 0 albo większe niż długość zakresu:
event_name, które jest puste, dłuższe niż 256 znaków lub zawiera znak sterujący, zwraca product analytics funnel event_name must be non-empty, control-free, and at most 256 characters. Krok interaction musi też mieć prawidłową nazwę akcji. W przeciwnym razie błąd to product analytics interaction event_name must be a bounded stable action name. Popraw żądanie, zanim wyślesz je ponownie. Nie usuwaj kroków i nie zmieniaj jednostki analizy tylko po to, aby dostać niepusty wynik.

Tryb dokładnych zdarzeń i tryb automatyczny

Utrzymanie i cykl życia przyjmują 2 struktury żądania. Użyj response_version, aby wybrać strukturę, która odpowiada na twoje pytanie: Dokładny selektor zawiera kind i event_name. kind to page_view, screen_view lub interaction. Skopiuj event_name z classified_activity.top_events. Nie zgaduj nazwy zdarzenia na podstawie etykiety przycisku. Obie struktury liczą tylko użytkowników, czyli nieprzezroczyste ID podmiotów rodzaju user. Anonimowe podmioty i zdarzenia bez użytecznego ID podmiotu nie są liczone jako użytkownicy. Odpowiedzi nigdy nie zwracają ID podmiotów. Stałe długości przedziału to hour, day, week i thirty_day. To stałe czasy trwania. thirty_day to 30 dni, a nie miesiąc kalendarzowy. Jeśli pominiesz interval, API używa hour dla zakresu do 48 godzin włącznie i day dla dłuższego zakresu.

Żądanie utrzymania dla dokładnych zdarzeń

Wyślij tę treść do POST /api/telemetry/analytics/retention. Sprawdza, czy użytkownicy realizują kolejny zakup po pierwszym zakupie w zakresie:
Pierwsze pasujące zdarzenie początkowe w zakresie wyznacza punkt startowy każdego użytkownika. Powrót musi nastąpić ściśle po tym punkcie i przed until. Oba selektory mogą wskazywać to samo zdarzenie.

Udane utrzymanie dla dokładnych zdarzeń

W tym syntetycznym przykładzie dwóch użytkowników realizuje zakup. Pierwszy użytkownik realizuje zakup 1 czerwca o 12:00 i ponownie o 13:00. Drugi użytkownik realizuje zakup 2 czerwca o 12:00. 2 czerwca o 13:00 drugi użytkownik wyświetla stronę, ale nie realizuje kolejnego zakupu.

Odczytaj utrzymanie

Pokrycie liczy wszystkie 4 sklasyfikowane zdarzenia, ale do każdego selektora realizacji zakupu pasują tylko 3. Wyświetlenie strony nie liczy się jako powrót. Jeden z dwóch użytkowników powtarza zakup, więc return_rate_after_start wynosi 0.5. Tylko pierwszy użytkownik ma pełny dzień obserwacji po punkcie startowym. Ten użytkownik wraca w ciągu tego dnia, więc wskaźnik krzywej wynosi 1.0. Drugi użytkownik ma tylko 12 godzin obserwacji. Nie kwalifikuje się do okresu 0, więc komórka drugiej kohorty pomija retention_rate. Nie licz tego użytkownika jako utraconego. weighted_retention_rate dzieli wszystkich utrzymanych użytkowników przez wszystkich kwalifikujących się użytkowników. fully_observed_cohort_average_rate to zwykła średnia wskaźników tych kohort, w których kwalifikuje się każdy użytkownik. Kohorty to stałe przedziały, które zaczynają się od since. cohorts zawiera tylko kohorty z użytkownikami. Z mode: "return_on_or_after" krzywa pomija window_end_seconds.

Automatyczne utrzymanie

Wyślij response_version: 2 bez start_event i return_event. Każde obsługiwane wyświetlenie strony, wyświetlenie ekranu i interakcja liczy się jako start i jako powrót. Ta wersja wybiera zbiór zdarzeń. Nie wybiera formatu rejestrowania danych w SDK.
Odpowiedź ma te same struktury summary, curve, cohorts i next_action co odpowiedź dla dokładnych zdarzeń. Ten fragment pokazuje pola, które się zmieniają. W tym przykładzie ci sami dwaj użytkownicy mają 3 zdarzenia i żadnego wyświetlenia strony:
W trybie automatycznym zarówno start_events, jak i return_events są równe classified_events. Te liczby oznaczają zdarzenia, a nie użytkowników.

Utrzymanie bez kwalifikujących się użytkowników

Udany wynik może nie mieć użytkowników w kohortach. Ten fragment pokazuje jeden żądany okres bez kohort:
Odczytaj coverage i next_action. Odróżniają zakres bez sklasyfikowanych zdarzeń (capture_product_activity) od zdarzeń bez użytkowników (identify_product_users lub identify_returning_users). Brakujący wskaźnik to nie zmierzone zero.

Błędy utrzymania

Oprócz wspólnych błędów zakresu te żądania zwracają 422 i validation_failed: Limit komórek zależy od zakresu i okresów, a nie od liczby użytkowników. Zakres 30 dni z interval: "hour" ma 720 przedziałów kohort. Przy interval_count: 1 daje to 720 komórek, czyli więcej niż 500:
Aby użyć automatycznego utrzymania, usuń oba selektory. Nie zmieniaj SDK, aby poprawić to żądanie odczytu.

Żądanie cyklu życia dla dokładnego zdarzenia

Wyślij tę treść do POST /api/telemetry/analytics/lifecycle. Klasyfikuje użytkowników według jednego zdarzenia, a nie według całej aktywności w projekcie:
history_period_count ustala liczbę pełnych okresów przed since, które LogBrew odczytuje jako historię. Przyjmuje wartości od 2 do 31. Domyślnie 2. Użytkownik może być uśpiony dla tego zdarzenia, a jednocześnie wykonywać inne czynności.

Udany cykl życia dla dokładnego zdarzenia

Ten syntetyczny przykład obejmuje 2 dni historii i 2 dni analizy. Litery oznaczają tylko przykładowych użytkowników. Odpowiedź nie zwraca ID użytkowników. C wyświetla też stronę 2 czerwca. To zdarzenie nie pasuje do selektora realizacji zakupu.

Odczytaj cykl życia

1 czerwca A jest użytkownikiem powracającym, B – ponownie aktywnym, C – nowym, a D – uśpionym. 2 czerwca A i B są użytkownikami powracającymi, a C jest uśpiony dla realizacji zakupu mimo wyświetlenia strony. Zmiana netto 2 czerwca to 2 - 3 = -1. W każdym przedziale nowi, powracający i ponownie aktywni użytkownicy sumują się do active_subjects. returning_subjects plus dormant_subjects równa się previous_active_subjects. net_active_change to active_subjects minus previous_active_subjects. Nie sumuj dziennych liczb aktywnych użytkowników, aby uzyskać liczbę unikalnych użytkowników. Tutaj dzienne liczby sumują się do 5, ale analysis_active_subjects wynosi 3. W historii i okresie analizy występuje czterech unikalnych użytkowników. fully_observed ma wartość false dla ostatniego przedziału, który kończy się po until. Jego liczby mogą się zmienić, gdy cały okres będzie można zaobserwować. next_action sugeruje dalszą analizę. Nie wskazuje przyczyny.

Automatyczny cykl życia

Wyślij response_version: 2 bez selektora event. Każde obsługiwane wyświetlenie strony, wyświetlenie ekranu i interakcja liczy się jako aktywność:
Odpowiedź ma te same struktury summary, buckets i next_action co odpowiedź dla dokładnego zdarzenia. Ten fragment pokazuje pola, które się zmieniają:
W trybie automatycznym coverage.selected_events równa się coverage.analysis_classified_events. Piąty wpis w limitations to Returning, resurrected, and dormant compare any supported classified product activity; no event is ranked, selected, or inferred.

Cykl życia bez użytkowników

Jeśli ani zakres analizy, ani historia nie zawierają użytecznych użytkowników, buckets jest puste, a summary pomija latest_fully_observed_period:
Użytkownicy, którzy występują tylko w historii, mogą nadal tworzyć przedziały z uśpionymi użytkownikami, gdy w zakresie analizy nie ma aktywności.

Błędy cyklu życia

Oprócz wspólnych błędów zakresu te żądania zwracają 422 i validation_failed: Na przykład 10 okresów historii week wymaga 70 dni:

Odczytaj wybrany zakres analizy

Odpowiedzi dla dokładnych zdarzeń mają schema_version: 1. Ich query powtarza selektory i pomija activity_scope. Odpowiedzi automatyczne mają schema_version: 2 i query.activity_scope: "all_classified_activity". Pomijają selektory. Inny selektor może zmienić wynik, nawet jeśli zarejestrowana aktywność się nie zmieniła.

Odpowiedź z szeregiem metryki

GET /api/telemetry/metrics/series odczytuje jedną dokładną nazwę metryki w jednym projekcie. Skopiuj nazwę z GET /api/telemetry/metrics. To żądanie grupuje licznik delta według usługi:

Udany szereg metryki

Ta syntetyczna odpowiedź zawiera jeden szereg licznika delta. W pierwszym przedziale są 3 próbki o wartościach 2, 3 i 5. W ostatnim przedziale są 2 próbki o wartościach 1 i 4. W środkowym przedziale nie ma próbek, więc odpowiedź nie ma dla niego punktu.

Odczytaj szereg metryki

Pierwszy punkt rejestruje 10 ukończonych zadań, a nie 10 próbek. rate_per_second dzieli tę zmianę przez 300-sekundowy przedział. last to ostatnia zarejestrowana zmiana, a nie suma. Zobacz znaczenie agregacji metryk. Rodzaj i temporalność szeregu wyznaczają jego aggregation.code i statystyki w każdym punkcie. Punkt pomija statystykę, która nie ma zastosowania. Brakująca statystyka to nie zero. limited to udana odpowiedź, a nie błąd. Dodaje aggregation.limitation, które wyjaśnia, dlaczego LogBrew pokazuje tylko surowe wartości. ready nie dowodzi, że zarejestrowano wszystkie dane. Odczytaj coverage, zanim narysujesz wykres:
  • samples liczy próbki wszystkich pasujących szeregów, także tych, których odpowiedź nie zwraca.
  • series liczy pasujące szeregi. returned_series i points liczą zwrócone dane.
  • truncated ma wartość true, gdy series_limit usunął szeregi o mniejszym wolumenie.
  • expected_buckets_per_series to liczba możliwych przedziałów w zakresie.
Nie dodawaj punktu dla przedziału bez próbek. Nie wstawiaj zera i nie kopiuj poprzedniej wartości. Każdy punkt zwraca do 3 trace_exemplars. Przykładowy ślad (trace exemplar) łączy jedną próbkę ze śladem. Nie wyjaśnia wszystkich próbek w przedziale. Jeśli żaden punkt nie ma przykładowego śladu, next_action.target to metric_samples.

Zakres i błędy szeregu metryki

project_id, name i since są wymagane. name może mieć najwyżej 200 znaków. interval to auto, 1m, 5m, 15m, 1h, 6h lub 1d. Domyślnie auto, czyli najmniejsza długość przedziału, przy której liczba przedziałów nie przekracza 300. Jawnie podana długość przedziału nie może wymagać więcej niż 500 przedziałów. group_by to none, service_name, release lub environment. Domyślnie none. Bez grupowania różne rodzaje, jednostki i temporalności pozostają w osobnych szeregach. series_limit przyjmuje od 1 do 20. Domyślnie 10. Pusty wynik zwraca 200 z series: [] i zerowym samples. Obiekt coverage pomija first_seen_at i last_seen_at. To nie dowodzi, że aplikacja nigdy nie wysłała metryki. Sprawdź projekt, nazwę metryki i zakres czasu. Pominięcie name zwraca 422:
Przedziały jednominutowe w zakresie 7 dni zwracają 422:
Inne błędy 422 to metric series group_by is not supported, metric series interval is not supported i metric series_limit must be between 1 and 20.

Odpowiedź ze ścieżkami

POST /api/telemetry/analytics/paths znajduje nazwane zdarzenia przed jednym wybranym zdarzeniem lub po nim w tej samej sesji. Wybrane zdarzenie jest zdarzeniem kotwiczącym. Skopiuj jego kind i event_name z classified_activity.top_events. Trasa zwraca schema_version: 1. Nie przyjmuje response_version ani analysis_unit.
direction i anchor są wymagane.

Udane ścieżki

W tym syntetycznym wyniku 4 sesje zawierają zdarzenie kotwiczące. Dwie zwrócone ścieżki reprezentują 3 z tych sesji. Jedna ścieżka z niższą pozycją w rankingu nie została zwrócona.

Odczytaj ścieżki

share_of_anchored_sessions dzieli sesje ścieżki przez wszystkie 4 sesje ze zdarzeniem kotwiczącym. Udziały wynoszą 50% i 25%, a nie 67% i 33%. unrepresented_sessions liczy sesje ze zdarzeniem kotwiczącym, których nie reprezentuje żadna zwrócona ścieżka. paths_truncated: true oznacza, że wynik jest niepełny. Pokrycie liczy zdarzenia, a nie sesje. Tutaj do zdarzenia kotwiczącego pasuje 5 zdarzeń, ale jedno z nich nie ma ID sesji. To zdarzenie nie może wejść do ścieżki. Każda ścieżka zwraca do 3 przykładowych śladów. Używaj ID śladu z własnej odpowiedzi. Powiązanie ze śladem nie pokazuje, co spowodowało akcję użytkownika ani niepowodzenie. Węzły są w kolejności czasowej w obu kierunkach. Ścieżka nie jest pełnym odtworzeniem sesji. LogBrew odczytuje najwyżej 1024 nazwane zdarzenia na sesję, zanim wybierze zdarzenie kotwiczące: najwcześniejsze zdarzenia dla following i najpóźniejsze dla preceding. Zdarzenie kotwiczące poza tym limitem może zostać pominięte.

Filtruj zdarzenie kotwiczące według właściwości

Wyślij do 4 property_filters, każdy z jednym dokładnym key i value. Skopiuj klucz z katalogu właściwości. Filtry dotyczą tylko zdarzenia kotwiczącego, a nie zdarzeń wokół niego. Wartości rozróżniają wielkość liter. Gdy filtry są obecne, query je powtarza, a coverage.anchor_property_filters podaje: Brakujące klucze i niepasujące wartości wymagają różnych poprawek. Nie sumuj ich. Obiekt jest pomijany, gdy żądanie nie ma filtra właściwości.

Puste ścieżki i odrzucone żądania

Pusta tablica paths może być udaną odpowiedzią 200. Odczytaj summary, coverage i next_action. Te kody rozróżniają przyczyny: capture_product_activity, choose_captured_path_anchor, capture_anchor_properties, improve_anchor_property_coverage, verify_anchor_property_values, sessionize_product_activity i narrow_or_move_path_anchor. Oprócz wspólnych błędów zakresu te żądania zwracają 422 i validation_failed: Na przykład depth: 0 zwraca:

Katalog właściwości analityki

GET /api/telemetry/analytics/properties wymienia klucze właściwości zdarzeń w sklasyfikowanych zdarzeniach produktowych w jednym projekcie. Używaj tych kluczy w porównaniach segmentów i w filtrach zdarzeń kotwiczących ścieżek. Katalog zwraca klucze i liczby. Nigdy nie zwraca wartości właściwości ani tożsamości.

Odczytaj dostępne klucze właściwości

Wyślij project_id i since. Możesz też wysłać until, service_name, release, environment, limit i response_version. limit przyjmuje od 1 do 50 kluczy. Domyślnie 20. Wyślij response_version=2, aby dostać publiczną wartość estimation.method.

Udany katalog właściwości

W tym syntetycznym wyniku istnieje 100 sklasyfikowanych zdarzeń. Pięć z nich zarejestrowano przed powstaniem bieżącego indeksu właściwości.

Odczytaj katalog

source to standard_context dla standardowego klucza kontekstu, na przykład resource.runtime.name, albo custom_tag dla klucza, który zaczyna się od tag.. value_type to zawsze string. properties jest posortowane według events, od największej wartości. tag.plan występuje w 60 ze 100 sklasyfikowanych zdarzeń. Ma około 3 różnych wartości. Deskryptor nie pokazuje tych wartości. Używaj wartości, które znasz ze swojej aplikacji. Nie zgaduj wartości na podstawie liczby. Jedno zdarzenie może mieć kilka kluczy, więc nie sumuj liczb events dla poszczególnych kluczy. Pusta tablica properties nie dowodzi, że projekt nie ma zdarzeń produktowych. Odczytaj summary, coverage i next_action.

Błędy katalogu właściwości

Oprócz wspólnych błędów zakresu limit=0 lub limit=51 zwraca 422:
response_version inne niż 1 lub 2 zwraca product analytics response_version must be 1 or 2. LogBrew sprawdza response_version przed innymi wartościami. Żądanie POST zwraca 405:

Porównanie segmentów w analityce

POST /api/telemetry/analytics/segments/compare porównuje, jak często sesje lub użytkownicy docierają do jednego dokładnego zdarzenia, w 2–4 segmentach w jednym projekcie. Segment wybiera zdarzenia według usługi, wydania, środowiska i wartości właściwości. Pierwszy segment jest segmentem bazowym.

Zdefiniuj porównanie

Wyślij tę treść JSON z uwierzytelnieniem konta i Content-Type: application/json. Tutaj basic i premium to wartości planu w przykładowej aplikacji, a nie plany LogBrew:
target i segments są wymagane. analysis_unit to session lub identified_user. Domyślnie session, czyli liczone są sesje, a nie osoby. interval przyjmuje te same wartości co przegląd. Domyślnie auto. Każdy segment potrzebuje unikalnego key, etykiety label i innego zestawu filtrów:
  • key: od 1 do 32 bajtów. Zacznij od małej litery ASCII lub cyfry. Używaj tylko małych liter ASCII, cyfr, _ i -.
  • label: od 1 do 80 znaków, bez znaków sterujących.
  • service_name, release, environment: opcjonalne. Każda wartość ma od 1 do 256 znaków, bez znaków sterujących.
  • property_filters: od 0 do 4 filtrów. Każdy klucz może wystąpić w segmencie tylko raz. Zdarzenie musi pasować do wszystkich filtrów segmentu. Wartości rozróżniają wielkość liter i mają od 1 do 256 znaków. LogBrew usuwa spacje z ich początku i końca.
Segment bez filtrów wybiera całą sklasyfikowaną aktywność w projekcie i zakresie czasu. Segmenty mogą się nakładać. Inna etykieta lub inny klucz nie sprawia, że 2 identyczne zestawy filtrów są prawidłowe.

Udane porównanie segmentów

W tym syntetycznym wyniku segment bazowy dociera do realizacji zakupu w 10 z 50 sesji. Segment premium dociera do niej w 18 z 60 sesji.

Odczytaj wskaźniki i różnice

eligible_units szacuje liczbę sesji lub użytkowników ze sklasyfikowaną aktywnością w segmencie. reached_units szacuje, ile z nich dotarło do celu. reach_rate to reached_units podzielone przez eligible_units. Zdarzenia bez ID wybranej jednostki nie liczą się do tych jednostek. Wskaźnik segmentu bazowego wynosi 20%. Wskaźnik segmentu premium wynosi 30%. Różnica to 10 punktów procentowych. Wzrost względny wynosi 50%, a nie 10%. Drobne błędy w części dziesiętnej wynikają z arytmetyki zmiennoprzecinkowej. Zaokrąglaj wskaźniki do wyświetlania, ale licz na zwróconych wartościach. Segment bazowy nie ma comparison_to_baseline. Wzrost względny jest pomijany, gdy wskaźnik dotarcia segmentu bazowego wynosi zero. W query filtr segmentu, którego nie wysłano, ma wartość null. Pusta lista property_filters jest pomijana. coverage.property_filters ma te same pola co pokrycie filtrów zdarzenia kotwiczącego ścieżki. Tutaj matching_events równa się classified_events. Licz osobno brakujące klucze i niepasujące wartości. Segmenty mogą się nakładać, a jedna sesja może wystąpić w kilku przedziałach. Nie sumuj liczby jednostek między segmentami ani przedziałami. Porównanie jest opisowe. confidence.causal_inference to not_established, a confidence.statistical_significance to not_tested. Wskaźnik 30% wobec 20% nie pokazuje, że plan spowodował więcej zakupów.

Błędy porównania segmentów

Oprócz wspólnych błędów zakresu te żądania zwracają 422 i validation_failed: Błędy interval są takie same jak błędy przeglądu. Na przykład 2 segmenty z różnymi kluczami i identycznymi filtrami zwracają:
Inna etykieta lub inna kolejność filtrów właściwości nie zmienia wybranych zdarzeń. Błąd walidacji nie dowodzi, że żadne zdarzenia nie pasują. Żądanie GET zwraca 405:

Odpowiedź z wolumenem sygnałów

GET /api/telemetry/summary/volume liczy przechowywane sygnały dla jednego projektu i zakresu czasu. Wymaga project_id i since. Nie przyjmuje project_ids. until nie może być w przyszłości. Jeśli go pominiesz, koniec zakresu to czas żądania. Skrócone since, na przykład 24h, liczy wstecz od until. interval to auto, 1m, 5m, 15m, 1h, 6h lub 1d. Domyślne auto wybiera najmniejszą długość przedziału, przy której liczba przedziałów nie przekracza 120. Żądanie nie może wymagać więcej niż 500 przedziałów. Jedyna wartość response_version to 1.

Liczby sygnałów

Ta syntetyczna odpowiedź obejmuje 2 przedziały jednominutowe. Żądanie wykonano o 12:02 UTC bez until. Konto ma 30-dniowy okres przechowywania danych. Odczytaj zwrócone zasady przechowywania i datę graniczną. Nie zakładaj, że te wartości dotyczą twojego konta.

Odczytuj każdą liczbę w jej własnej jednostce

total to suma liczb w przedziałach szeregu. peak to największa liczba w jednym przedziale szeregu. non_empty_buckets liczy przedziały z liczbą większą od zera. Pięć szeregów zawsze występuje w tej kolejności. Nie łącz liczb różnych sygnałów w jeden wskaźnik wpływu. Przedziały zaczynają się od query.since. Przedział obejmuje swój początek i wyklucza swój koniec. Ostatni przedział może być krótszy niż ustawiona długość przedziału. Odpowiedź nie ma szeregu z liczbą wydań. Nie odczytuj release_volume_not_included jako zera wydań.

Puste i skrócone okna

Jeśli żaden sygnał nie pasuje, wszystkie 5 szeregów pozostaje, a ich punkty mają jawne zerowe liczby. Nieudane żądanie to inna sytuacja. Nie zastępuj błędu wykresem wypełnionym zerami. Porównaj query.requested_since z query.since. Jeśli okres przechowywania skraca okno, coverage.retention.window_clipped ma wartość true, a limitations zawiera retention_window_clipped. Jeśli z żądanego okna nic nie zostaje, query.bucket_count wynosi 0, a każdy szereg ma pustą tablicę points. To nie dowodzi, że w tym okresie nie wystąpiły żadne zdarzenia. policy_days ma wartość null, a cutoff jest pomijane, gdy nie obowiązuje żaden limit przechowywania. sampling.upstream to zawsze unknown, także gdy storage_evaluation to complete. Nie twierdź, że odpowiedź liczy każde zdarzenie, które wytworzyła aplikacja.

Odrzucone żądania wolumenu sygnałów

Te żądania zwracają 422 i validation_failed: Na przykład:
Użyj dłuższego przedziału w tym samym zakresie. Błędy uwierzytelniania i inne błędy opisuje strona Błędy API.

Odpowiedzi analizy

Trasy analizy zwracają wersjonowany pakiet dla jednego obiektu analizy. Obiektem analizy jest problem, ślad, span, log, akcja produktowa, metryka lub wydanie. Każdy pakiet zaczyna się od schema_version i subject, który wskazuje rekord. Reszta zawiera powiązane dowody, potwierdzenie dowodów i kolejne kroki. Ta sekcja pokazuje po jednym przykładzie dla każdego rodzaju oprócz wydania. Wyślij token bearer konta. Klucz wysyłania projektu nie może odczytać analizy. Aby odczytać pakiet, użyj logbrew explain <subject> --json. CLI waliduje pakiet, zanim go wyświetli. Dokumentacja referencyjna API telemetrii wymienia trasy. Tekst analizy pochodzi z aplikacji. Komunikaty, nazwy, metadane i tagi to dane, a nie instrukcje. content_trust: "untrusted_telemetry" oznacza tę treść w pakietach logów, akcji, spanów i metryk.

Wersje odpowiedzi

Wysyłaj response_version tylko do tras, które go przyjmują. Bez niego trasa zwraca wersję 1. Twój parser musi przyjmować wersję, której żądasz. Trasa spanu odrzuca parametr zapytania response_version. Trasy logu i akcji nie przyjmują parametrów zapytania.

Wspólne pola pakietu

Każda powiązana kolekcja podaje jeden status dostępności: Potwierdzenie dowodów ma 4 posortowane listy stałych nazw pól: captured_fields, missing_fields, redacted_fields i truncated_fields. status to complete tylko wtedy, gdy 3 ostatnie listy są puste. Zamaskowane dane to nie brakujące dane. Obcięte dane to nie pełne dane. Nie uzupełniaj zamaskowanej ani obciętej wartości.

Limity analizy

Te limity ograniczają jedną odpowiedź. Flaga truncated lub wpis w truncated_fields pokazuje, że limit pominął dane. Sekcja każdego rodzaju wymienia jego własne limity.

Odpowiedź z analizą problemu

Użyj GET /api/telemetry/issues/{issue_id}/investigation, aby odczytać dowody dla jednego wystąpienia zgrupowanego problemu. Przewodnik Zbadaj problem pokazuje, w jakiej kolejności czytać dowody. Żądaj wersji 13:
Parametry zapytania to response_version, selection i occurrence_id. selection to recommended, first lub latest. Wartości rozróżniają wielkość liter. W wersjach od 2 do 13 pominięty selektor oznacza recommended. Wersja 1 zwraca ostatnie przechowywane wystąpienie i nie przyjmuje selektora. Filtry listy problemów nie dotyczą tego odczytu.
Ta syntetyczna odpowiedź 200 OK ma jedno obsłużone wystąpienie TypeError z powiązanym śladem. Nie ma dowodów z żądania, breadcrumbów, powiązanych logów ani dowodów wdrożenia, więc evidence.status to partial.
Kluczy z późniejszej wersji nie ma we wcześniejszej wersji. Nie odczytuj brakującego klucza jako null. subject.status i statusy w lifecycle pokazują zarchiwizowany problem jako ignored. Odpowiedzi z listą i szczegółami problemów używają archived od wersji odpowiedzi 2. Limity problemów: rekomendacja odczytuje najwyżej 50 przechowywanych wystąpień. Trend ma najwyżej 30 przedziałów. Każdy rozkład zwraca najwyżej 10 wartości. Stos ma najwyżej 32 ramki.

Błędy żądania analizy problemu

Użyj selection albo occurrence_id. Nie wysyłaj obu, nawet gdy wybierają to samo wystąpienie:
Brak wystąpienia nie oznacza, że brakuje problemu. 404 nie pokazuje, czy inne konto może odczytać problem.

Odpowiedź z analizą śladu

Użyj GET /api/telemetry/traces/{trace_id}/investigation, aby odczytać jeden ślad wraz z jego ścieżką błędu, najwolniejszą ścieżką i powiązanymi sygnałami. Parametry zapytania to response_version, project_id, release i environment. Wszystkie są opcjonalne. Żądaj wersji 3:
Wersja 2 dodaje cause i fix do każdego powiązanego problemu. Wersja 3 dodaje span_id do powiązanych problemów, akcji i metryk, gdy zostało zarejestrowane.
Ta syntetyczna odpowiedź ma span główny serwera i nieudany span klienta. Nieudany span jest też najwolniejszym spanem podrzędnym. Spany nie mają ustrukturyzowanego kontekstu, więc brakuje spans.context.
Pola trace.parentage brakuje, gdy span wskazuje span nadrzędny, którego LogBrew nie przechował. Podgląd spanów ma najwyżej 64 spany. Każda ścieżka analizy ma najwyżej 64 spany. Powiązane odczyty używają najwyżej 8 zakresów wdrożeń. Następna akcja z celem trace_span wskazuje span_id z tego pakietu. Aby odczytać ten span, wyślij żądanie do trasy spanu z project_id, environment i release tego spanu.

Odpowiedź z analizą spanu

Użyj GET /api/telemetry/traces/{trace_id}/spans/{span_id}/investigation, aby odczytać jedną operację w śladzie. Wyślij project_id, environment i release. Wszystkie 3 są wymagane. Skopiuj je z wybranego spanu. Nie wysyłaj id wiersza spanu jako span_id.
Ta syntetyczna odpowiedź opisuje nieudany span klienta z przykładu śladu. Log błędu ma to samo ID spanu. Span trwał dłużej niż przybliżony 95. percentyl przechowywanych spanów tego samego rodzaju.
Punkt odniesienia (baseline) obejmuje 24 godziny przed startem spanu. since jest włączne, a until wyłączne. error_rate_basis_points: 500 oznacza 5%. subject_percentile_basis_points: 9500 oznacza, że 95% przechowywanych spanów tego samego rodzaju trwało nie dłużej niż ten span. Percentyle są przybliżone. Zachowaj baseline.limitations razem z wartościami. Punkt odniesienia not_found nie ma przechowywanych spanów tego samego rodzaju. Punkt odniesienia unavailable to nieudany odczyt, a nie zerowa liczba. parent_chain_status: "complete" oznacza, że przechowywany łańcuch dociera do spanu głównego. Nie dowodzi, że LogBrew przechował każdy span żądania. Topologia zwraca najwyżej 64 spany-przodków, 50 bezpośrednich spanów podrzędnych i 50 krawędzi między usługami.

Odpowiedź z analizą logu

Użyj GET /api/logs/{log_id}/investigation, aby odczytać jeden log i powiązane z nim dowody. Ta trasa nie ma parametrów zapytania. Skopiuj ID logu z listy logów.
Odczyt może zwrócić dowody spoza filtrów listy logów. Powiązane odczyty używają projektu, środowiska i wydania logu oraz okna 5 minut przed logiem i 5 minut po nim. Pobliskie logi muszą też mieć tę samą usługę. Nie potrzebują ID śladu. Odczyty dokładnego śladu wymagają ID śladu logu i mogą obejmować inne usługi. Podsumowanie śladu używa tego samego ID śladu i zakresu, ale bez okna czasowego.
Ta syntetyczna odpowiedź ma log ostrzeżenia bez kontekstu śladu i jeden pobliski log. Odpowiedź nie tworzy powiązania ze śladem na podstawie znaczników czasu.
ID śladu może występować, gdy status śladu to not_found lub unavailable. Dostępne podsumowanie śladu nie gwarantuje exact_span.

Odpowiedź z analizą akcji

Użyj GET /api/telemetry/actions/{action_id}/investigation, aby odczytać jedną akcję produktową, jej zgłoszony status i powiązane dowody. Ta trasa nie ma parametrów zapytania. Powiązane odczyty używają tego samego okna i zakresów co analiza logu.
correlations, timeline i next_actions mają takie same struktury jak w analizie logu. Powiązane akcje nie obejmują akcji, która jest obiektem analizy.
Ta syntetyczna odpowiedź opisuje nieudaną akcję realizacji zakupu wykonaną przez zalogowanego użytkownika. Akcja nie ma ID śladu.
Odpowiedź nigdy nie zwraca identyfikatorów podmiotu ani sesji. Potwierdzenie dowodów zawsze wymienia subject.distinct_id jako zamaskowane, a subject.session_id wtedy, gdy zarejestrowano sesję. Dlatego każdy pakiet akcji ma status partial i zawiera improve_capture. Nie wyłączaj ochrony prywatności, aby spełnić tę sugestię.

Odpowiedź z analizą metryki

Użyj GET /api/telemetry/metrics/investigation, aby odczytać jedną nazwę metryki w jednym projekcie i zakresie czasu. Odpowiedź zawiera bieżący szereg, porównanie z poprzedzającym oknem o tej samej długości, ostatnią próbkę, przykładowe ślady i ukończone wdrożenia. Wersja 2 dodaje opis metryki z ostatniej przechowywanej próbki. Wersja 1 zawsze podaje description_status: "not_captured".
project_id, name i since są wymagane. since jest włączne, a until wyłączne. Domyślnie until to bieżący moment. Porównanie odczytuje też poprzedzające okno o tej samej długości.
Ten syntetyczny histogram ma 5 próbek w 2 przedziałach pięciominutowych. Ostatni przedział ma p95 równe 48 ms. Ostatni przedział poprzedniego okna ma p95 równe 24 ms.
relative_change_percent to (current - previous) / abs(previous) * 100. Ma wartość null, gdy poprzednia wartość wynosi zero lub jej brakuje. expected_buckets_per_series liczy możliwe przedziały, a nie przedziały z danymi. Nie rysuj pustych przedziałów jako zera. Wdrożenie w pobliżu zmiany nie dowodzi, że ją spowodowało. Projekt, którego konto nie może odczytać, zwraca 200 OK z analysis.status: "no_samples", a nie 404. Pusty wynik nie opisuje innych typów sygnałów. Limity metryk: zakres to najwyżej 31 dni. Każdy szereg ma najwyżej 500 przedziałów. series_limit wynosi od 1 do 20, domyślnie 10. Odpowiedź zwraca najwyżej 20 przykładowych śladów i 20 wdrożeń. interval to auto, 1m, 5m, 15m, 1h, 6h lub 1d. group_by to none, service_name, release lub environment. Inne wartości zwracają 422.

Błędy analizy

404 oznacza, że żaden projekt dostępny do odczytu nie ma tego rekordu. Każda trasa zwraca też 401 bez prawidłowego uwierzytelnienia i 405 dla metody innej niż GET. Odpowiedzi o braku zasobu, o nieprawidłowej wartości w ścieżce, o błędzie uwierzytelniania i o nieobsługiwanej metodzie opisuje strona Błędy API. Opcjonalny odczyt dowodów może się nie powieść wewnątrz odpowiedzi 200 OK. Kolekcja podaje wtedy unavailable. Nie pokazuj jej jako not_found ani jako 0 rekordów.

Wartości ważności

Wartości ważności widoczne dla użytkownika to info, warning, error i critical. SDK i środowiska uruchomieniowe mogą wysyłać popularne aliasy, takie jak trace, debug, warn lub fatal. Odpowiedzi REST i odpowiedzi na żywo zawsze zwracają wartość kanoniczną. Na przykład LogBrew przyjmuje warn na wejściu i zwraca warning. Przyjmowanie danych odrzuca nieznane wartości ważności.

Odpowiedzi reguł ważności

Reguła ważności zmienia sposób, w jaki LogBrew pokazuje log lub problem. Nie zmienia poziomu ważności zarejestrowanego przez aplikację. Logi i problemy zwracają obiekt triage: Do wyświetlania używaj triage.effective_severity. Zachowaj severity jako zarejestrowaną wartość. Domyślnie lista logów pomija ignorowane logi. Aby je uwzględnić, wyślij status=ignored lub status=all w GET /api/logs. Konto musi mieć uprawnienie do zarządzania problemami w projekcie. Dostęp do odczytu nie wystarcza. Bez tego uprawnienia zmiana reguły zwraca 403 z code: forbidden.

Zmień regułę logu

PUT /api/logs/{log_id}/triage-rule ustawia regułę dla logu i późniejszych logów z tą samą sygnaturą. Treść wymaga zarówno severity, jak i ignored:
Odpowiedź 200 OK zawiera pełny log. Jego severity pozostaje warning. Jego triage pokazuje regułę:
Ten fragment pokazuje tylko zmienione pola. severity w żądaniu to source, info, warning, error lub critical. source przywraca zarejestrowany poziom ważności. Nie przywraca zignorowanego logu do stanu aktywnego. Aby znowu pokazać log, wyślij "ignored": false.

Zmień regułę problemu

PUT /api/telemetry/issues/{issue_id}/triage-rule ustawia wyświetlany poziom ważności zgrupowanego problemu i jego późniejszych wystąpień. Treść przyjmuje tylko severity:
Odpowiedź 200 OK zawiera pełny problem w wersji 1. Zarejestrowane severity i status się nie zmieniają:
Ten fragment pokazuje tylko część pól. Reguła nie rozwiązuje, nie archiwizuje ani nie otwiera ponownie problemu. Do tego służy zmiana statusu. Wyliczony priorytet wynika z nowego efektywnego poziomu ważności. Aby go zobaczyć, odczytaj problem z response_version=2 lub 3. Nieobsługiwany poziom ważności zwraca 422:
Nieznane pole treści, na przykład status w regule problemu, zwraca 422 z code: invalid_json. Brakujący albo niedostępny do odczytu log lub problem zwraca 404 z code: not_found. Jeśli odpowiedź zaginie, odczytaj log lub problem ponownie, zanim znowu wyślesz regułę.

Format odpowiedzi z błędem

Błędy aplikacji zwracają kopertę JSON. Ten przykład pokazuje odrzucone żądanie. Tekst error i next zależy od rodzaju błędu:
Używaj code do rozgałęzień w programie, a next_action do automatyzacji. Pokazuj ludziom error i next jako zwykły tekst. Nie parsuj ich treści. Niektóre błędy dodają pola, takie jak limit, reset_at lub retry_after_seconds. Odpowiedź bez treści JSON nie ma code LogBrew. Wszystkie kody opisuje strona Błędy API.

Odczytuj dane w CLI

CLI odczytuje te same trasy i z --json zwraca ten sam JSON. Zacznij od szerokiego zakresu, a potem go zawężaj:
Dodaj --pagination cursor, aby dostać kopertę kursora. CLI żąda wersji 4 odpowiedzi z problemem. Zobacz Odczytaj następną stronę i Obserwowanie na żywo.