დაკვირვებადობა
AiHummer-ის დაკვირვებადობის მოდელი არის მხოლოდ OTLP push. gateway აქსპორტებს ტელემეტრიას თქვენ მიერ კონფიგურირებულ OpenTelemetry ბოლოწერტილზე — ის არ გამოაჩენს scrape ბოლოწერტილს. გადააგზავნეთ მონაცემები თქვენს კოლექტორთან და მოახდინეთ მათი ვიზუალიზაცია მომზადებული Grafana დაფებით.
[!WARNING] არ არსებობს Prometheus
/metricsბოლოწერტილი და არც pprof (/debug/pprof). დაკვირვებადობა მხოლოდ OTLP push-ია — არ დააკონფიგურიროთ scrape სამუშაო gateway-ის წინააღმდეგ; ნაცვლად ამისა მიუთითეთ AiHummer თქვენს OTLP კოლექტორზე.
OTLP push
დააყენეთ ერთი ცვლადი ტელემეტრიის ჩასართავად:
# gateway.env — export telemetry to your OTLP collector
AIHUMMER_OTEL_ENDPOINT=http://otel-collector:4317AIHUMMER_OTEL_ENDPOINT-ის დაყენებით gateway აგზავნის ტელემეტრიას ამ კოლექტორთან.
იქიდან გადაამისამართეთ ის თქვენს backend-თან (Tempo, მეტრიკების საცავი, ლოგები) და
Grafana-ში.
ცოცხალი ლოგები ადმინ UI-ში
ადმინ UI-ის გვერდი «ლოგები» არის gateway-ის ჟურნალის ცოცხალი კუდი: ახალი ხაზები ავტომატურად მოიზიდება ყოველ რამდენიმე წამში, ავტოგადახვევით ქვედა კიდესთან. ხელსაწყოთა ზოლში — ხაზების ძებნა და დონის ფილტრი (ყველა / შეცდომები / გაფრთხილებები / ინფო / debug). სხვა რიგი გვერდებიც (დაფა, სესიები, არხები) ავტომატურად ახლდება, ხოლო გრძელი სიები (აუდიტი, ცვლილებები, შეტყობინებები და ა.შ.) იტვირთება პორციებად ღილაკით «მეტის ჩვენება».
ყველა სერვისის სრული ჟურნალები კვლავ systemd-ში ცხოვრობს — aihummer logs [unit] ან journalctl -u aihummer-gateway.
Grafana დაფები
მზა Grafana დაფები მოყვება release-ს. შემოიტანეთ ისინი თქვენს Grafana ინსტანციაში, რათა მიიღოთ ოპერაციული ხედები პანელების ნულიდან აგების გარეშე.
რას ვადევნოთ თვალი
ეს არის სიგნალები, რომლებიც გეუბნებიან, რომ სისტემა ჯანმრთელია და მსვლელობები მიედინება:
| სიგნალი | რატომ აქვს მნიშვნელობა |
|---|---|
| მსვლელობის ლატენტობა | აგენტის მსვლელობების ბოლოდან ბოლომდე რეაგირება |
| შეცდომის სიხშირე | ჩავარდნილი მსვლელობები / მოთხოვნები — პრობლემის პირველი ნიშანი |
| მიწოდების განწყობები | აღწევენ თუ არა პასუხები რეალურად არხებამდე |
| Outbox / DLQ სიღრმე | მიუწოდებელი შეტყობინებების ჩამორჩენა; მზარდი DLQ ნიშნავს, რომ მიწოდება გაჩერებულია |
მზარდი outbox-ის ან dead-letter-queue-ის (DLQ) სიღრმე არის ყველაზე მკაფიო ადრეული გაფრთხილება, რომ მიწოდება გროვდება — ადევნეთ თვალი rollout-ებისა და ინციდენტების დროს.
სისტემის ბოლოწერტილები
OTLP-თან ერთად gateway გამოაჩენს მცირე HTTP ბოლოწერტილებს, რომლებიც სასარგებლოა ზონდებისთვის, საათებისა და კლიენტის დიაგნოსტიკისთვის:
| მეთოდი | ბოლოწერტილი | დანიშნულება |
|---|---|---|
GET |
/healthz |
სიცოცხლისუნარიანობა + ვერსია |
GET |
/readyz |
მზადყოფნა (ამოწმებს Postgres-ს; 503 თუ გათიშულია) |
GET |
/v1/ping |
მსუბუქი მისაწვდომობის შემოწმება |
GET |
/v1/time |
სერვერის დრო |
POST |
/v1/client-log |
კლიენტის მხარის ლოგ-მოვლენების მიღება |
ჯანმრთელობისა და მზადყოფნის ზონდები დეტალურადაა აღწერილი systemd და ჯანმრთელობის შემოწმებები-ის ქვეშ.
სად შემდეგ
- ზონდები და production-ის წინასწარი შემოწმების ჩამონათვალი: systemd და ჯანმრთელობის შემოწმებები.
- რას ვადევნოთ თვალი მოძრავი განახლების დროს: განახლების პოლიტიკა.