AiHummer
Беларуская▾
УвайсціАсабісты кабінет
v1.1.x▾
v1.2.xstablev1.1.xstablev1.0.xstable
{ }Swagger
Эксплуатацыя/Назіральнасць

Назіральнасць

v1.1.x · абноўлена 2026-07-07

АйХаммер мае магчымасць назірання два паверхні: гэты шлюз служыць Праметэй GET /metrics канец пункта, які можна скрэпаваць для асноў, і гэта можа быць па жаданні адправіць тэлеметрыю праз OTLP да канчатковага пункта OpenTelemetry, які вы наладжваеце. Збіраць /metrics для базавага маніторынгу; для слядоў і багатых метрык накіруйце AiHummer на ваш OTLP зборнік і візуалізуйце дадзеныя з дапамогай убудаваных панэляў Grafana.

[!NOTE] pprof (/debug/pprof) ёсць не выявлены.

Праметэй /metrics канчатковы пункт

GET /metrics падае метрыкі ў фармаце тэксту Prometheus без дадатковай наладкі. Выстаўляюцца толькі несакрэтныя паказчыкі — інфармацыя аб зборцы, час працы працэсу і выканання, стан пула злучэнняў БД і паказчык гатоўнасці; няма дадзеных арандатара, сакрэтаў і пазнак для кожнага запыту. Для трасіроўкі і пашыраных метрык выкарыстоўвайце OTLP push.

OTLP націснуць

Усталюйце адну зменную, каб уключыць тэлеметрыю:

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

З AIHUMMER_OTEL_ENDPOINT калі наладжана, шлюз адпраўляе тэлеметрыю на гэты зборшчык. Адтуль накіроўвайце яе ў ваш бэкенд (Tempo, сховішча метрык, журнал) і ў Grafana.

Апрацоўка панік і памылак

Паведамленні пра памылкі нікуды навонкі не адпраўляюцца: у шлюзе няма кліента знешняга трэкера памылак і няма знешняга DSN — даныя пра вашы памылкі не пакідаюць ваш контур.

Устойлівасць да панік пры гэтым поўная:

  • паніка ў HTTP-апрацоўшчыку ператвараецца ў звычайны адказ з кодам памылкі (500 з канвертам AIH-…) — працэс не падае і працягвае абслугоўваць астатнія запыты;
  • паніка ў фонавай гарутыне таксама перахопліваецца і не кладзе шлюз.

Абодва выпадкі трапляюць у структураваны журнал — глядзіце іх на старонцы Журналы (ніжэй) або праз journalctl.

Жыўыя журналы ў адміністрацыйным інтэрфейсе

Інтэрфейс адміністратара Журналы старонка з’яўляецца жывай стужкай журнала шлюзу: новыя радкі аўтаматычна падцягваюцца кожныя некалькі секунд з аўтаскролам, пакуль вы ўнізе. Панэль інструментаў мае лінейны пошук і а узроўневы фільтр (усё / памылкі / папярэджанні / інфармацыя / адладка). Некалькі іншых старонак (Панэль кіравання, Сесіі, Каналы) таксама абнаўляюцца аўтаматычна, а доўгія спісы (аўдыт, змены, паведамленні і г.д.) загружаюцца старонка за старонкай з кнопкай «Паказаць яшчэ».

Поўныя журналын рэкордаў кожнай службы ўсё яшчэ захоўваюцца ў systemd — aihummer logs [unit] ці journalctl -u aihummer-gateway.

Панэлі Grafana

Гатовыя панэлі Grafana пастаўляюцца з выпуску. Імпартуйце іх у сваю ўстаноўку Grafana, каб атрымаць аперацыйныя панарамы без стварэння панэляў з нуля.

Што глядзець

Гэта сігналы, якія кажуць вам, што сістэма здаровая і абароты адбываюцца бесперашкодна:

Сігнал Чаму гэта важна
Затрымка павароту Адзіная рэакцыя агента на зварот
Дзель памылак Невыкананыя звароты/запыты — першы знак праблем
Дастаўчыя ўмовы Ці сапраўды адказы даходзяць да каналаў
Чакаемыя пастаўкі Назапашванне неадказаных паведамленняў; устойлівы рост азначае, што дастаўка затрымліваецца

Пастаянны рост чыкаючыя або паўторна няўдалыя пастаўкі гэта самы ясны ранні сігнал, што пастаўка запавольваецца — назірайце за ім падчас разгортвання і інцыдэнтаў.

Канечныя пункты сістэмы

Паралельна з OTLP шлюз дае невялікія HTTP-канцы для зондоў, гадзіннікаў і дыягнастыкі кліента:

Метад Канчатковая кропка Мэта
GET /metrics Метрыкі Prometheus (зборка, час выканання, пул базы даных, гатоўнасць)
GET /healthz Жывучасць + версія
GET /readyz Гатоўнасць (правярае Postgres; 503, калі недаступна)
GET /v1/ping Лёгкая праверка дасяжнасці
GET /v1/time Час сервера
POST /v1/client-log Збіраць падзеі лагавання на баку кліента

Аспекты здароўя і гатоўнасці падрабязна асвятляюцца ў systemd і праверкі здароўя.

Куды далей