Observabilitate

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

Observabilitatea AiHummer are **două suprafețe**: poarta servește ca **Prometeu `GET /metrics`** punct final pe care îl poți extrage pentru elementele de bază și, opțional, poate **trimite telemetria prin OTLP** către un endpoint OpenTelemetry pe care îl configurezi. Preia `/metrics` pentru monitorizarea de bază; pentru urme și metrici detaliate, îndreptați AiHummer către colectorul vostru OTLP și vizualizați datele cu panourile Grafana incluse. > [!NOTE] > pprof (`/debug/pprof`) este **nu** expus. ## Prometeu `/metrics` punct final `GET /metrics` servește metrici în format text Prometheus fără configurare suplimentară. Sunt expuse doar instrumente non-sensibile — informații despre build, timp de funcționare al procesului și timpul de execuție, starea pool-ului de conexiuni DB și un indicator de pregătire; fără date ale chiriașilor, fără secrete, fără etichete per cerere. Pentru trasări și metrici detaliate, folosiți push-ul OTLP. ## OTLP push Setați 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` set, gateway-ul trimite telemetria către acel colector. De acolo, ruteaz-o către backend-ul tău (Tempo, un magazin de metrici, jurnale) și în Grafana. ## Gestionarea panicilor și a erorilor Rapoartele de eroare **nu sunt trimise niciodată în exterior**: gateway-ul nu include niciun client de tracker de erori extern și niciun DSN extern — datele despre erorile tale nu îți părăsesc niciodată perimetrul. Cu toate acestea, rezistența la panici este completă: - o panică într-un handler HTTP devine un răspuns de eroare obișnuit (un 500 care poartă un plic `AIH-…`) — procesul nu moare și continuă să servească celelalte cereri; - o panică într-o gorutină de fundal este de asemenea recuperată și nu doboară gateway-ul. Ambele cazuri ajung în jurnalul structurat — citește-le pe pagina **Jurnale** (mai jos) sau prin `journalctl`. ## Jurnale live în interfața de administrare UI-ul de administrare **Jurnale** pagina este un jurnal live al gateway-ului: liniile noi sunt preluate automat la fiecare câteva secunde, cu defilare automată în timp ce te afli în partea de jos. Bara de instrumente are un **căutare pe linie** și un **filtru de nivel** (toate / erori / avertismente / informații / depanare). Mai multe alte pagini (Tablou de bord, Sesiuni, Canale) se reîncarcă de asemenea automat, iar listele lungi (audit, modificări, notificări și așa mai departe) se încarcă pagină cu pagină cu un buton „Vezi mai mult”. Jurnale complete ale fiecărui serviciu există încă în systemd — `aihummer logs [unit]` sau `journalctl -u aihummer-gateway`. ## Tablouri de bord Grafana Tablourile de bord Grafana gata făcute sunt livrate odată cu versiunea. Importați-le în instanța dvs. 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ă fluxurile circulă: | Semnal | De ce contează | |---|---| | **Întârziere la rotire** | Reactivitatea de la un capăt la altul a rundelor agentului | | **Rată de eroare** | Întoarceri / cereri eșuate — primul semn al problemelor | | **Dispoziții de livrare** | Dacă răspunsurile ajung efectiv la canale | | **Livrări în așteptare** | Întârziere în răspunsurile nedistribuite; creșterea susținută înseamnă că livrarea este blocată | O creștere susținută a **livrări în așteptare sau eșuate repetat** este cea mai clară avertizare timpurie că livrarea se acumulează — urmărește-o în timpul lansărilor și incidentelor. ## Puncte finale ale sistemului Împreună cu OTLP, gateway-ul expune mici endpointuri HTTP utile pentru probe, ceasuri și diagnosticarea clienților: | Metodă | Punct final | Scop | |---|---|---| | `GET` | `/metrics` | Metrice Prometheus (construcție, rulare, pool DB, pregătire) | | `GET` | `/healthz` | Veridicitate + versiune | | `GET` | `/readyz` | Pregătire (verifică Postgres; 503 dacă este oprit) | | `GET` | `/v1/ping` | Verificare a accesibilității ușoară | | `GET` | `/v1/time` | Timp server | | `POST` | `/v1/client-log` | Preia evenimentele de jurnal de pe partea clientului | Probele de sănătate și de disponibilitate sunt acoperite în detaliu în cadrul [systemd și verificări de sănătate](/ro/v1.0/operations/systemd-health). ## Unde următor? - Sondele și lista de verificare înainte de zbor pentru producție: [systemd și verificări de sănătate](/ro/v1.0/operations/systemd-health). - Ce să urmăriți în timpul unei actualizări în rolling: [Politică de actualizare](/ro/v1.0/operations/upgrade-policy).