AiHummer
Polski
Zaloguj sięKonto
v1.1.x
{ }Swagger

Obserwowalność

v1.1.x · zaktualizowany 2026-07-07

Obserwowalność AiHummer ma dwie powierzchnie: brama służy jako Prometeusz GET /metrics punkt końcowy, z którego można pobierać podstawowe informacje, a opcjonalnie może wysyłać telemetrię przez OTLP do punktu końcowego OpenTelemetry, który konfigurujesz. Zbieraj /metrics do monitorowania bazowego; w przypadku śladów i bogatych metryk skieruj AiHummer na swój kolektor OTLP i wizualizuj dane za pomocą dołączonych pulpitów nawigacyjnych Grafana.

[!NOTE] pprof (/debug/pprof) jest nie odsłonięty.

Prometeusz /metrics punkt końcowy

GET /metrics udostępnia metryki w formacie tekstowym Prometheusa bez dodatkowej konfiguracji. Udostępniane są tylko niezawodne wskaźniki — informacje o kompilacji, czas działania procesu i czas wykonania, stan puli połączeń z bazą danych oraz wskaźnik gotowości; brak danych najemcy, brak sekretów, brak etykiet na żądanie. Do śledzeń i szczegółowych metryk użyj push OTLP.

OTLP push

Ustaw pojedynczą zmienną, aby włączyć telemetrykę:

# gateway.env — export telemetry to your OTLP collector
AIHUMMER_OTEL_ENDPOINT=http://otel-collector:4317

Z AIHUMMER_OTEL_ENDPOINT Po ustawieniu, brama wysyła telemetrię do tego kolektora. Stamtąd przekieruj ją do swojego zaplecza (Tempo, magazyn metryk, logi) i do Grafany.

Obsługa panik i błędów

Raporty o błędach nigdy nie są wysyłane nigdzie na zewnątrz: brama nie zawiera żadnego zewnętrznego klienta trackera błędów ani żadnego zewnętrznego DSN — dane o Twoich błędach nigdy nie opuszczają Twojego obwodu.

Mimo to odporność na paniki jest pełna:

  • panika w handlerze HTTP zamienia się w zwykłą odpowiedź błędu (500 z kopertą AIH-…) — proces nie umiera i nadal obsługuje pozostałe żądania;
  • panika w goroutynie działającej w tle również jest przechwytywana i nie kładzie bramy.

Oba przypadki trafiają do dziennika strukturalnego — czytaj je na stronie Dzienniki (poniżej) lub przez journalctl.

Dane logów na żywo w interfejsie administracyjnym

Interfejsy administracyjne Dzienniki strona to na żywo wyświetlany ogon dziennika bramy: nowe linie są pobierane automatycznie co kilka sekund, z automatycznym przewijaniem, gdy jesteś na dole. Pasek narzędzi ma przeszukiwanie linii i filtr poziomu (wszystkie / błędy / ostrzeżenia / informacje / debugowanie). Kilka innych stron (Panel, Sesje, Kanały) również odświeża się automatycznie, a długie listy (audyt, zmiany, powiadomienia i tak dalej) ładują się stronami za pomocą przycisku „Pokaż więcej”.

Pełne logi każdej usługi nadal znajdują się w systemd — aihummer logs [unit] lub journalctl -u aihummer-gateway.

Tablice rozdzielcze Grafana

Gotowe pulpity Grafana są dostarczane wraz z wydaniem. Zaimportuj je do swojej instancji Grafana, aby uzyskać widoki operacyjne bez konieczności tworzenia paneli od podstaw.

Co oglądać

To są sygnały, które mówią ci, że system jest zdrowy i że zmiany przebiegają płynnie:

Sygnał Dlaczego to ma znaczenie
Opóźnienie obrotu Całościowa responsywność ruchów agenta
Wskaźnik błędów Nieudane tury / prośby — pierwszy znak problemu
Dyspozycje dostawy Czy odpowiedzi faktycznie docierają do kanałów
Oczekujące dostawy Zaległości w niedostarczonych odpowiedziach; utrzymujący się wzrost oznacza, że dostawa stoi w miejscu

Utrzymujący się wzrost oczekujące lub wielokrotnie nieudane dostawy jest najjaśniejszym wczesnym sygnałem ostrzegawczym, że dostawa się opóźnia — obserwuj to podczas wdrożeń i incydentów.

Punkty końcowe systemu

Obok OTLP, brama udostępnia małe końcówki HTTP przydatne do sond, zegarów i diagnostyki klienta:

Metoda Punkt końcowy Cel
GET /metrics Metryki Prometheus (kompilacja, czas działania, pula DB, gotowość)
GET /healthz Żywotność + wersja
GET /readyz Gotowość (sprawdza Postgresa; 503, jeśli niedostępny)
GET /v1/ping Lekka kontrola dostępności
GET /v1/time Czas serwera
POST /v1/client-log Przechwytywanie zdarzeń logów po stronie klienta

Kontrole stanu zdrowia i gotowości są omówione szczegółowo w systemd i kontrole stanu.

Dokąd dalej