Monitorowanie stanu urządzenia FoxIDs i logów urządzenia

Operatorzy platformy mogą monitorować dostępność FoxIDs, zależności, aktywność użytkowników oraz błędy, łącząc testy sprawności z ustrukturyzowanymi logami. Należy korzystać z systemu monitorowania dostosowanego do danego wdrożenia:

  • Wdrożenia usługi aplikacji Azure mogą wysyłać logi do serwerów Azure Log Analytics lub Application Insights.
  • Wdrożenia Docker i Kubernetes zapisują logi kontenerów do stdout, skąd mogą być one pobierane przez moduł zbierający logi platformy.
  • W każdym obsługiwanym wdrożeniu można skonfigurować Azure Application Insights lub Log Analytics jako strumień logów FoxIDs.

Twórz powiadomienia i pulpity nawigacyjne dotyczące dostępności usług, zużycia zasobów, nieudanych prób logowania oraz błędów aplikacji. Przydatne kontrole dostępności obejmują:

  • https://--foxids-domain--/health
  • https://--foxids-domain--/master/master/foxids_control_client(*)/.well-known/openid-configuration
  • https://--foxids-control-domain--/master
  • https://--foxids-control-domain--/api/health
  • https://--foxids-control-domain--/api/swagger/v2/swagger.json

Parametry zapytania dotyczącego kontroli stanu zdrowia

Punkt końcowy /health akceptuje opcjonalne parametry zapytania, które umożliwiają indywidualną weryfikację poszczególnych zależności. Jeśli nie podano żadnych parametrów, punkt końcowy zwraca kod 200 OK, potwierdzając, że witryna działa, bez sprawdzania dostępności usług zewnętrznych. Należy użyć jednego lub kilku z poniższych parametrów (wielkość liter nie ma znaczenia):

Parametr Opis Działa w przypadku
?db Sprawdza, czy dane są zapisane, weryfikując istnienie dokumentu głównego dzierżawcy. Wszystkie obsługiwane bazy danych.
?log Przeprowadza kontrolę logowania. OpenSearch weryfikuje aliasy rollover; Application Insights wysyła ślad. Gdy logowanie jest skonfigurowane dla OpenSearch lub Application Insights.
?cache Wykonuje polecenie PING w Redis. Gdy skonfigurowano pamięć podręczną Redis.
?all Automatycznie sprawdza każdy komponent włączony w konfiguracji.

Żądanie sprawdzenia komponentu niedostępnego w bieżącej konfiguracji zwraca 400 Bad Request ze stałym komunikatem Requested health check is unavailable.. Nieznane parametry zapytania są ignorowane. Jeśli którykolwiek z żądanych komponentów nie działa prawidłowo, punkt końcowy zwraca 503 Service Unavailable i wyświetla listę nieudanych testów; w przeciwnym razie zwraca 200 OK.

Odpowiedzi na testy kondycji zawierają ogólny stan, czas sprawdzenia i wyniki poszczególnych komponentów. Każdy komponent używa jednego ze stałych komunikatów: Health check succeeded., Health check failed. lub Health check skipped.. Odpowiedzi nie zawierają komunikatów wyjątków, śladów stosu, odpowiedzi zależności ani szczegółów konfiguracji. Do badania błędów służą dzienniki.