Observabilitate

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

Modelul de observabilitate al AiHummer este **doar prin push OTLP**. Gateway-ul exportă telemetria către un endpoint OpenTelemetry pe care îl configurezi — **nu** expune un endpoint de scraping. Trimite datele către colectorul tău și vizualizează-le cu tablourile de bord Grafana incluse. > [!WARNING] > **Nu există un endpoint Prometheus `/metrics` și nici pprof** (`/debug/pprof`). > Observabilitatea este doar prin push OTLP — nu configura un job de scraping > împotriva gateway-ului; în schimb, indică AiHummer către colectorul tău OTLP. ## Push OTLP Setează o singură variabilă pentru a activa telemetria: ```ini # gateway.env — export telemetry to your OTLP collector AIHUMMER_OTEL_ENDPOINT=http://otel-collector:4317 ``` Cu `AIHUMMER_OTEL_ENDPOINT` setat, gateway-ul împinge telemetria către acel colector. De acolo, direcționeaz-o către backend-ul tău (Tempo, un magazin de metrici, jurnale) și în Grafana. ## Loguri live în interfața de administrare Pagina **„Loguri”** a interfeței de administrare este coada live a jurnalului gateway-ului: liniile noi sunt preluate automat la fiecare câteva secunde, cu derulare automată la marginea de jos. În toolbar — **căutare în linii** și **filtru pe nivel** (toate / erori / avertismente / info / debug). Și alte pagini (Dashboard, Sesiuni, Canale) se actualizează automat, iar listele lungi (audit, modificări, notificări etc.) se încarcă paginat cu butonul „Arată mai mult”. Jurnalele complete ale tuturor serviciilor trăiesc în continuare în systemd — `aihummer logs [unit]` sau `journalctl -u aihummer-gateway`. ## Tablouri de bord Grafana Tablouri de bord Grafana gata făcute sunt livrate odată cu lansarea. Importă-le în instanța ta Grafana pentru a obține vizualizările operaționale fără a construi panouri de la zero. ## Ce să urmărești Acestea sunt semnalele care îți spun că sistemul este sănătos și că turele curg: | Semnal | De ce contează | |---|---| | **Latența turei** | Reactivitatea de la cap la cap a turelor agentului | | **Rata de erori** | Ture/cereri eșuate — primul semn de probleme | | **Dispoziții de livrare** | Dacă răspunsurile ajung efectiv la canale | | **Adâncimea outbox / DLQ** | Restanța de mesaje nelivrate; un DLQ în creștere înseamnă că livrarea este blocată | O **adâncime în creștere a outbox-ului sau a cozii de mesaje moarte (DLQ)** este cel mai clar avertisment timpuriu că livrarea se acumulează — urmărește-o în timpul lansărilor și incidentelor. ## Endpoint-uri de sistem Alături de OTLP, gateway-ul expune mici endpoint-uri HTTP utile pentru sonde, ceasuri și diagnostice de client: | Metodă | Endpoint | Scop | |---|---|---| | `GET` | `/healthz` | Vitalitate + versiune | | `GET` | `/readyz` | Pregătire (verifică Postgres; 503 dacă e oprit) | | `GET` | `/v1/ping` | Verificare ușoară de accesibilitate | | `GET` | `/v1/time` | Ora serverului | | `POST` | `/v1/client-log` | Preia evenimentele de jurnal din partea clientului | Sondele de sănătate și de pregătire sunt acoperite în detaliu sub [systemd și verificări de sănătate](/ro/v1.0/operations/systemd-health). ## Unde mergi mai departe - Sondele și lista de verificare prealabilă pentru producție: [systemd și verificări de sănătate](/ro/v1.0/operations/systemd-health). - Ce să urmărești în timpul unei actualizări progresive: [Politica de actualizare](/ro/v1.0/operations/upgrade-policy).