Torrent Gear

API და ინფრასტრუქტურის მონიტორინგის ინსტრუმენტები

1) პრინციპები: მიზნებიდან ინსტრუმენტებამდე

SLO-first: შეარჩიეთ და ჩამოაყალიბეთ ინსტრუმენტები სასურსათო მიზნებისათვის (ლოგინი, ანაბარი, განაკვეთი) და არა პირიქით.

Open Standards: OpenTelemetry (ტრეისი/მეტრიკა/ლოგები), Prometheus exposition format, Loki JSON-logs.

ერთი კონტექსტი: 'trace _ id '/' spank _ id' ლოგოებში და მეტრიკებში; საბრძოლო „dashbord trais log“.

Cost-aware: მეტრიკის კარდინალობა, TTL ლოგოები, სამგზავრო ტრეისები - წინასწარ.

2) მეტრიკა: შეგროვება, შენახვა, ვიზუალიზაცია

Сбор: Prometheus / Agent-режим (VictoriaMetrics Agent, Grafana Agent, OpenTelemetry Collector).

საცავი (TSDB): Prometheus (სინგლი), Thanos/Cortex/Mimir (ჰორიზონტალური სკალირება), VictoriaMetrics (დანაზოგი CPU/RAM).

ვიზუალიზაცია: Grafana, როგორც „შუშის პანელი“.

რა უნდა გაზომოთ API (RED) და ინფრასტრუქტურისთვის (USE):

RED: `rate(requests)`, `error_ratio`, `latency p95/p99` по `route`, `method`, `provider`.
USE: CPU/Mem, file descriptors, connection pools, queue lag, GC pauses.

სასარგებლო ექსპორტიორები:

k8s: kube-state-metrics, node-exporter, cAdvisor, ingress/gateway exporters.
БД/кэши: postgres_exporter, mysql_exporter, redis_exporter, kafka_exporter, rabbitmq_exporter.
მომსახურება: Envoy metrics, istio/Linkerd dashboards.
PSP/внешние: custom exporters (webhook success, PSP success ratio, callback latency).

PromQL მაგალითები (ესკიზები):

promql
დეპოზიტების წარმატება (SLI)
sum(rate(ig_payments_requests_total{route="/payments/deposit",status=~"2.."}[5m]))
/
sum(rate(ig_payments_requests_total{route="/payments/deposit"}[5m]))

p95 latency API histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

კავშირის აუზის გაჯერება BD db _ connections _ in _ use/db _ connections _ max

3) Logs: ძებნა, კორელაცია, უცვლელი

დასტის: OpenSearch/Elasticsearch + Beats/Vector/Fluent Bit ან Grafana Loki (იაფია შენახვა, „log-lock-strim“).

ფორმატი: JSON სტანდარტული ველებით 'ts, level, service, env, trace _ id, user _ pid, route, status, latency _ ms'.

პრაქტიკა: შენიღბვა PII, WORM აუდიტის ბაკეტები, TTL/ILM პოლიტიკა, განაწილება 'env/region/brand'.

4) ტრეკი: სად იკარგება მილიწამები

Стек: OpenTelemetry SDK/Collector → Jaeger/Tempo/Honeycomb/New Relic Traces.

სემპლაციის პოლიტიკა: შეცდომების 100%, ადაპტირება „ნელი“ მოთხოვნებისთვის, 1-5% წარმატებული.

Теги iGaming: `provider`, `psp`, `risk_decision`, `bonus_id`, `market`, `ws_table_id`.

სწრაფი რეცეპტი: წითელი გრაფიკიდან SLO - პრობლემური მარშრუტის ტრეისი - „სქელი“ სპანი PSP/თამაშის პროვაიდერზე - ვებჰუკის ლოგო.

5) APM პლატფორმები: როდესაც „ყველაფერი ერთზე“

კომერციული გადაწყვეტილებები (Datadog, New Relic, Dynatrace, Grafana Cloud) ფარავს APM, logs, ტრეისი, სინთეზური, RUM.

უპირატესობები: განხორციელების სიჩქარე, კორელაცია „ყუთიდან“. უარყოფითი: ღირებულება/გამყიდველი-ლოკი.

ჰიბრიდი: ბირთვი OSS- ზე (Prometheus + Grafana + Tempo + Loki), კრიტიკული flow კომერციული მოდულებით სინთეზური/ალერტინგი.

6) სინთეზური და RUM: „გარეთ“ და „მოთამაშის თვალებით“

Синтетика: Checkly, Grafana Synthetic Monitoring, k6 Cloud, Uptrends, Pingdom, Catchpoint, ThousandEyes.

სკრიპტები: ლოგინი - ანაბარი (sandbox), თამაშის დაწყება, ვებჰუკის შემოწმება.

გეო: EU/LatAm/MEA/APAC, მობილური ქსელები, ASN მიქსი.

RUM: Web-SDK (TTFB/LCP/CLS), მობილური SDK; ქვეყნის/ქსელის/მოწყობილობის სეგმენტი.

7) Kubernetes მონიტორინგის ზედაპირი

Control plane: etcd, API-server (apiserver_request_total, latency), scheduler/controllermanager.

Data plane: kubelet, CNI, ingress/gateway; `PodDisruptionBudget` и эвикшены.

Autoscaler: HPA/VPA/Cluster Autoscaler მეტრები და მოვლენები; warm აუზები.

ქსელის პოლიტიკოსები: drops/deny events, DNS latence.

8) მონაცემთა ბაზები, რიგები, ქეში

Postgres/MySQL: რეპლიკაციის ლაგი, deadlocks, bloat, WAL, checkpoint duration, Timauts.

Kafka/RabbitMQ: consumer lag, rebalances, queue depth, redeliveries.

Redis: evictions, blocked clients, latency percentiles, რეპლიკა-lag.

PITR/bacaps: backup ოპერატორების დავალებები + დაშბორდი „გამოჯანმრთელებამდე დრო“.

9) ქსელი, CDN, WAF, თამაშების პროვაიდერები და PSP

CDN/Edge: hit-ratio, TTFB რეგიონებში, shield hit, „გამოტოვების ქარიშხალი“.

WAF/bot მენეჯერი: sharchallenge/ბლოკი, ASN/ქვეყნები, FPR ლოგინზე/ანაბარზე.

Game providers: მაგიდის/სლოტის გაშვების დრო, უარყოფა/ტაიმაუტები სტუდიებში.

PSP: success ratio/latence მეთოდით/ქვეყანაში/BIN, შეცდომების კოდი 3DS/AVS, webhooks success & delay.

10) ალერტინგი და მოვალეობა

როუტინგი: Alertmanager - PagerDuty/Opsgenie/Slack.

წესები: სიმპტომები (SLO) + მიზეზობრივი (რესურსები).

ანტიშუმი: ჯგუფი, ჯაჭვური ალერტების ჩახშობა, დუმილის ფანჯრები გამოშვებისთვის.

SLO კარიბჭეები CD- ში: ავტომატური პაუზა/გამოტოვება დარღვევების დროს (Argo Rollouts/Flagger AnalysisRun).

ალერტების მაგალითები (გამარტივებული):

`login_success_ratio < 99. 9% for 10m`
`p95 /payments/deposit > 0. 4s for 10m`
`db_connections_saturation > 0. 85 for 5m`
`kafka_consumer_lag > 30s`
`cdn_hit_ratio drop > 15% in 10m (per region)`

11) დაშბორდები, რომლებიც ნამდვილად ეხმარებიან

Flow ანაბარი: ძაბრი, p95/p99, შეცდომები PSP/BIN/ქვეყნებში, ვებჰუკების შეფერხება.

ცოცხალი თამაშები/WS: კავშირები, RTT, resend/reconnect, პროვაიდერების შეცდომები.

API- ის ჯანმრთელობა: RED მარშრუტებზე, საიტებზე, შემდეგ slow endpoints - ტრეისი.

DR პანელი: რეპლიკა lag, WAL shipping, სინთეზური ლოგინი/დეპოზიტი DR რეგიონიდან.

უსაფრთხოება: WAF, bot score, 401/403 ანომალიები, ხელმოწერილი ვებჰუკები.

12) ტელემეტრიული კონტროლი

მეტრიკის კარდინალობა: არ ჩართოთ 'user _ id' ეტიკეტებში, „მარშრუტისა“ და „პროვაიდერის“ ლიმიტები.

Downsampling და retention კლასები (ცხელი 7-14 დღე, თბილი 30-90, ცივი არქივი).

ლოგიკა: მოვლენების ნახტომი - ჩართეთ ნიმუშები/ბაბუა; ცალკე შეინახეთ stacktrace.

ტრეისი: დინამიური გაფართოება „ძვირადღირებულ“ მარშრუტებზე (გადახდები/დასკვნები).

13) უსაფრთხოება და კონფიდენციალურობა მონიტორინგში

mTLS აგენტებიდან კოლექციონერებამდე; დაშიფვრა at-rest.

ფსევდონიმიზაცია 'user _ pid', ელექტრონული ფოსტის/ტელეფონის/დოკუმენტების აკრძალვა ლოგებში.

RBAC/MFA, WORM აუდიტისთვის; DPA მესამე მხარის მონიტორინგის პროვაიდერთან.

14) ინტეგრაცია CI/CD- ით და ავტო განაწილებით

SLI ექსპოზიცია, როგორც CD- ტესტების პრომ მეტრიკა.

Release labels ('version', 'rollout _ step') მეტრიკებში/ლოგოებში/ტრეისებში.

ავტომატური კანარის კარიბჭეები: უკანა მხარე გაგრძელდება მხოლოდ მწვანე SLO- ით.

15) სწრაფი დაწყება (რეფერენდუმი)

შეკრება/ტრანსპორტი: OTEL Collector + Prometheus/VM Agent + Fluent Bit.

საცავი: VictoriaMetrics/Thanos (მეტრიკა), Loki/OpenSearch (ლოგოები), Tempo/Jaeger (ტრეისები).

ვიზუალიზაცია: Grafana + მზა დაშბორდები k8s/Envoy/Postgres.

სინთეზური & RUM: Checkly/k6 + Grafana RUM (ან კომერციული ანალოგი).

ალერტინგი: Alertmanager, PagerDuty/Slack; runbooks ბმულები.

16) განხორციელების შემოწმების სია

განისაზღვრება SLO/SLI ლოგინის/ანაბრის/განაკვეთების/გამომავალი.
მეტრიკა RED/USE + ბიზნეს SLI; ეტიკეტების ერთიანი ონტოლოგია.
Logs JSON 'trace _ id', შენიღბვა PII, WORM აუდიტისთვის.
OpenTelemetry end-to-end; შეცდომების ნიმუშები 100%.
სინთეტიკა ძირითადი რეგიონებიდან + RUM გაყიდვაში.
დაშბორდები „დეპოზიტის ფლოუ“, „WS“, „API ჯანმრთელობა“, „DR“.
ალერტინგი: SLO სიმპტომები + რესურსების მიზეზები; ანტიშუმი.
SLO კარიბჭეები უკავშირდება CD- ს; ავტო გადაზიდვა.
ღირებულების გეგმა: retenschen/sempling/კარდინალობა.
DPA/უსაფრთხოება: mTLS, RBAC, ლოგოების კონფიდენციალურობა.

რეზიუმე

ძლიერი მონიტორინგი არ არის „ლამაზი გრაფიკების“ ერთობლიობა, არამედ დაკავშირებული სისტემა: მეტრიკა RED/USE, logs 'trace _ id', OpenTelemetry ტრეკები, სინთეზური და RUM, პლუს დაშბორდები, ალერტინგი და SLO კარიბჭეები. შეაგროვეთ დასტური ღია სტანდარტების გარშემო, აკონტროლეთ ტელემეტრიის ღირებულება და სტანდარტიზებული ეტიკეტის ონტოლოგია - მაშინ API- სა და ინფრასტრუქტურასთან დაკავშირებული ნებისმიერი პრობლემა წინასწარ გამოჩნდება და შეკეთდება, სანამ მოთამაშეები შეამჩნევენ მათ.