Przykłady dochodzeń

Te przykłady pokazują, jak odpowiadać na typowe pytania za pomocą Dzienników audytu. Każdy z nich zawiera pytanie, filtry i kliknięcia, których należy użyć, oraz to, na co zwrócić uwagę. Te same kroki sprawdzają się w każdym rodzaju lokalizacji, więc dostosuj filtry do własnego pytania.

Skrócone informacje

Gdzie to znaleźć: Settings (ikona koła zębatego w lewym dolnym rogu) → Dzienniki audytu

Kto może z tego korzystać: Potrzebujesz roli, która obejmuje Dzienniki audytu oraz Identity & Access Management w Twojej organizacji, takiej jak Organisation Administrator. Zobacz Kto może korzystać z Dzienników audytu.

Cel: Przejście od pytania do żądań, które na nie odpowiadają

Kto odblokował główne wejście?

Siłownia lub centrum rekreacyjne: główne wejście zostało zdalnie odblokowane, a kierownik zmiany chce wiedzieć, kto to zrobił i dlaczego.

1. Na karcie Logs kliknij Endpoint, wpisz /api/door-gate-access/* i kliknij Apply. Lista pokazuje tylko żądania Door & Gate Access.
2. Ustaw filtr Range tak, aby obejmował czas odblokowania.
3. Kliknij żądanie, którego punkt końcowy kończy się na /front-entrance/unlock.

Rysunek 1: Wszystkie żądania dotyczące drzwi, z otwartym żądaniem odblokowania głównego wejścia

Na co zwrócić uwagę: pole User pokazuje, kto odblokował drzwi — tutaj oscar.tran@example.com. Sekcja Request POST Body pokazuje podany powód, "Member forgot access card", a sekcja Response Body pokazuje, że drzwi zostały odblokowane.

Dalej: sprawdź rejestr samych drzwi w sekcji Rejestry dostępu modułu Door & Gate Access, który zapisuje każdą próbę odblokowania drzwi, w tym z aplikacji mobilnej.

Dlaczego pracownik nie mógł zmienić czyjejś roli?

Gabinet fizjoterapii: koordynator próbował nadać współpracownikowi nową rolę, ale się nie udało.

1. Na karcie Logs kliknij Status i wybierz 403 Forbidden.
2. Kliknij żądanie 403 Forbidden z czasu zmiany roli.
3. W sekcji AI Error Summary kliknij Generate summary.

Rysunek 2: Podsumowanie wyjaśnia, dlaczego zmiana roli została odrzucona

Na co zwrócić uwagę: podsumowanie mówi, że osoba "does not have permission to assign that role". Porównaj to z sekcją Response Body, w której widnieje komunikat "You don't have permission to assign this role." Sekcja Request POST Body pokazuje, jaką rolę próbowano nadać.

Dalej: poproś Organisation Administrator o wprowadzenie zmiany lub przejrzyj rolę tej osoby. Zobacz Zmienianie ról użytkownika i Szablony ról.

Nasza integracja z systemem rezerwacji przestała synchronizować dane w nocy

Centrum wodne lub obiekt gminny: w nocy przestały pojawiać się zameldowania z systemu rezerwacji.

1. Na karcie Logs kliknij Endpoint, wpisz /partner/v1/* i kliknij Apply.
2. Ustaw filtr Range na Last 24 hours.
3. Sprawdź stan na początku każdego wiersza, a następnie kliknij nieudane żądania, aby odczytać ich sekcję Response Body.

Na co zwrócić uwagę: żądania z plakietką api-key od integrations@example.org. W tym przypadku lista pokazuje 429 Too Many Requests, gdy integracja wysłała zbyt wiele żądań w krótkim czasie, oraz 503 Service Unavailable. Zanotuj, kiedy zaczęły się błędy i czy po nich pojawiły się udane żądania.

Dalej: kliknij Eksportuj CSV i wyślij plik partnerowi integracyjnemu, aby mógł sprawdzić swoją stronę. Zobacz Eksportowanie dzienników oraz stronę Błędy w dokumentacji Partner API.

Webhook nie został zapisany

Kawiarnia, sklep lub obiekt hotelarski: kierownik skonfigurował webhook do wysyłania danych odwiedzających do innego systemu, ale nie został on zapisany.

1. Na karcie Logs kliknij Email i wpisz pełny adres e-mail kierownika — tutaj leo.hargreaves@example.com.
2. Znajdź dwa żądania POST z chwili, gdy kierownik zapisywał webhook: 400 Bad Request i 201 Created dla tego samego punktu końcowego.
3. Kliknij 400 Bad Request, a następnie 201 Created kilka minut później i porównaj je.

Na co zwrócić uwagę: sekcja Response Body żądania 400 zawiera komunikat "url must start with https://". W jego sekcji Request POST Body adres nie ma https:// na początku. W żądaniu 201 kierownik dodał https:// i webhook został zapisany.

Dalej: w przypadku nieudanego żądania kliknij Generate summary, aby uzyskać wyjaśnienie prostym językiem. Zobacz AI Error Summary.

Co robił odchodzący pracownik w zeszłym tygodniu?

Biuro lub przestrzeń coworkingowa: zanim pracownik odejdzie, jego przełożony chce mieć zapis jego ostatniej aktywności.

1. Na karcie Logs kliknij Email i wpisz pełny adres e-mail tej osoby.
2. Ustaw filtr Range na Last 7 days.
3. Przewiń na sam dół listy, aby wczytać wszystkie żądania. Eksport obejmuje tylko wczytane wiersze.
4. Kliknij Eksportuj CSV, a następnie Export.

Na co zwrócić uwagę: zmiany, a nie odczyty. Ustawiaj kolejno filtr Method na POST, PUT, PATCH lub DELETE, aby zobaczyć żądania, które coś tworzyły, zmieniały lub usuwały. W przypadku czegoś nieoczekiwanego otwórz żądanie i odczytaj jego sekcję Request POST Body.

Dalej: gdy pracownik odejdzie, odbierz mu dostęp. Zobacz Usuwanie użytkowników. Przechowuj plik CSV zgodnie z zasadami obowiązującymi w Twojej organizacji.

Która lokalizacja miała najwięcej nieudanych żądań?

Operator wielu lokalizacji: kilka lokalizacji zgłosiło wczoraj problemy, a centrala chce wiedzieć, od czego zacząć.

1. Na karcie Panel ustaw opcję Window tak, aby obejmowała cały dzień.
2. Na wykresie Errors Over Time kliknij przedział, w którym błędów było najwięcej. Otworzy się karta Logs z nieudanymi żądaniami z tego czasu.
3. Kliknij Obiekt i wybieraj kolejno każdą lokalizację, porównując, ile nieudanych żądań ma każda z nich.

Na co zwrócić uwagę: lokalizacja z dużo większą liczbą błędów niż pozostałe lub błędy dotyczące jednego punktu końcowego. Otwórz kilka jej żądań i odczytaj sekcję Response Body lub kliknij Generate summary.

Dalej: pozostałe wykresy opisano na stronie Panel, a lokalizacje w Twojej organizacji — na stronie Obiekty.

Powiązane strony

• Wyszukiwanie żądań: wszystkie filtry
• Odczytywanie wpisu w dzienniku: pola, treści i kody stanu
• Eksportowanie dzienników: eksport do pliku CSV