Skip to main content
Utwórz zgłoszenie do pomocy technicznej, gdy problem wymaga dalszych działań. Osoba lub agent AI może potem śledzić zgłoszenie i dodawać kontekst, o który poproszono. Zgłoszenie mogą odczytać tylko konto, które je utworzyło, i zespół pomocy technicznej LogBrew.
Użyj tokena bearer konta, na przykład $LOGBREW_TOKEN. Nigdy nie używaj klucza wysyłania projektu. Zanim napiszesz tytuł, opis lub diagnostykę, usuń prywatne dane. Automatyczne maskowanie nie zastępuje tego przeglądu.

Utwórz zgłoszenie

W CLI uruchom:
CLI ustawia source na cli. --diagnostics dodaje tylko nazwę pliku binarnego, wersję CLI, system operacyjny i architekturę. Wszystkie flagi pokazuje logbrew support --help. CLI nie wysyła klucza ponowienia przy tworzeniu zgłoszenia. Jeśli wynik jest niepewny, uruchom logbrew support list --json, zanim ponownie uruchomisz polecenie. W przeciwnym razie możesz utworzyć drugie zgłoszenie. Przez API wyślij POST /api/support/tickets z polami source, category, title i description. Aby ponowienie było bezpieczne, utwórz jeden klucz ponowienia dla zgłoszenia i wyślij go w nagłówku Idempotency-Key. Ten przykład używa fikcyjnych wartości:
Klucz ponowienia zawiera od 1 do 128 widocznych znaków ASCII, bez spacji. Aby ponowić żądanie, wyślij ten sam klucz z tą samą treścią. Odpowiedź zwróci wtedy to samo zgłoszenie. Dla innego zgłoszenia użyj nowego klucza. Przekroczenie limitu czasu nie dowodzi, że zgłoszenie nie zostało utworzone. Nagłówek Idempotency-Key jest opcjonalny. Bez niego powtórzone żądanie może utworzyć kolejne zgłoszenie. Pola opcjonalne to project_id, environment, runtime, framework, sdk_package, sdk_version, release, trace_id, event_id i diagnostics. Pomiń project_id, gdy problem nie dotyczy konkretnego projektu. project_id musi wskazywać aktywny projekt na twoim koncie. Udane żądanie zwraca HTTP 200:
ID zgłoszeń zaczynają się od sup_. next to wskazówka dla człowieka, a next_action służy do sterowania programem. Aby usunąć projekt, użyj ustawień projektu lub logbrew projects delete. Nie proś o usunięcie projektu w zgłoszeniu do pomocy technicznej.

Napisz przydatne zgłoszenie

  • W każdym zgłoszeniu opisz jeden problem.
  • Wybierz najlepiej pasującą wartość category. Użyj other tylko wtedy, gdy żadna kategoria nie pasuje.
  • W title podaj jeden objaw i jedną część produktu.
  • W description opisz kroki, a potem oczekiwany i zaobserwowany wynik.
  • Dodaj ID projektu, wydania, śladu lub zdarzenia tylko wtedy, gdy dotyczą tego samego błędu.
Używaj tych kluczy diagnostics: diagnostics to obiekt JSON o rozmiarze do 16 KB po zamaskowaniu. LogBrew zastępuje wartość tekstem [redacted], gdy jej klucz wskazuje poświadczenie, sesję lub adres e-mail. Zastępuje też tekst, który wygląda jak poświadczenie, adres URL lub ścieżka lokalna. LogBrew skraca też długie ciągi znaków i ogranicza zagnieżdżenie, liczbę kluczy i liczbę elementów list. Nie polegaj na tym maskowaniu. Zanim wyślesz żądanie, usuń prywatne dane.

Śledź zgłoszenie

Lista przyjmuje project_id, status, source, category, release i limit. Domyślny limit to 100, a maksymalny to 500. Aby użyć paginacji kursorowej, wyślij pagination=cursor. Na kolejnych stronach powtórz te same filtry i wyślij cursor_time oraz cursor_id z next_cursor. ID kursora to ID zgłoszenia z prefiksem sup_. Zakończ, gdy next_cursor ma wartość null. CLI używa flag --project, --status, --source, --category, --release, --limit, --pagination, --cursor-time i --cursor-id. Wartości statusu to open, routed, in_progress, waiting_on_user, resolved i closed. Możesz ustawić tylko open lub closed. Powtórzone żądanie zamknięcia lub ponownego otwarcia kończy się powodzeniem i niczego nie zmienia, więc możesz ponowić dokładnie to samo żądanie. Postępuj zgodnie ze zwróconym statusem i next_action:

Dodaj kontekst, o który poproszono

Odpowiedz, gdy zgłoszenie prosi o kontekst. Takie zgłoszenie ma status waiting_on_user, a next_action.code ma wartość provide_context.
Treść żądania API zawiera context i opcjonalnie diagnostics. Tekst context musi mieć od 1 do 4000 znaków. Nie umieszczaj w context poświadczeń, adresów URL, nazw hostów ani ścieżek lokalnych. API odrzuca taki tekst z kodem 422. Wyślij klucz ponowienia w nagłówku Idempotency-Key. Trasa kontekstu wymaga tego nagłówka. Klucz zawiera od 1 do 128 widocznych znaków ASCII, bez spacji. Dla każdej odpowiedzi użyj nowego klucza. Użyj klucza ponownie tylko wtedy, gdy ponawiasz tę samą odpowiedź. API przyjmuje kontekst, gdy zgłoszenie ma status open, routed, in_progress lub waiting_on_user. Przyjmuje 1 odpowiedź na każdy stan zgłoszenia. Po odpowiedzi poczekaj na zmianę statusu, zanim wyślesz więcej kontekstu. Odpowiedź na zgłoszenie waiting_on_user zmienia jego status na open. Nie zakładaj tej zmiany, tylko odczytaj zwrócony status. Udana odpowiedź zwraca ticket_id, context_id, status, created_at, next i next_action. context_id zaczyna się od ctx_. Zanim odpowiesz na kolejną prośbę, odczytaj zgłoszenie ponownie. GET /api/support/tickets/{ticket_id}/context zwraca 20 najnowszych wpisów kontekstu, od najstarszego. Każdy wpis zawiera context_id, context, diagnostics i created_at. Ta lista nie ma kursora. Odpowiedź na zgłoszenie resolved lub closed zwraca 422 z code: "validation_failed". Otwórz zgłoszenie ponownie tylko wtedy, gdy użytkownik chce kontynuować tę sprawę. next_action nie daje agentowi uprawnień do zmiany stanu konta.

Obsłuż błędy

Odpowiedzi z błędem zawierają error, code, next i next_action. Zobacz Błędy API.

Zadbaj o bezpieczeństwo zgłoszenia

Nigdy nie wysyłaj sekretów, tokenów, nagłówków autoryzacji, kluczy wysyłania, surowych logów, danych klientów, ścieżek lokalnych, hostów ani niezwiązanego kodu źródłowego. Wyślij krótkie, zamaskowane podsumowanie. Sprawdzenia, które możesz wykonać samodzielnie, opisuje strona Rozwiązywanie problemów.