Prometheus: მეტრიკის შეგროვება

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

Prometheus არის ინდუსტრიული სტანდარტი მეტრიკისთვის: ის HTTP targets, ინახავს სერიებს TSDB- ში, მიიჩნევს დანაყოფებს PromQL- ში და ალერტმანაგერის საშუალებით ალერტებს აყენებს. IGaming- ისთვის ეს არის SLO მიდგომის საფუძველი (RED/USE, ბიზნეს მეტრები), სწრაფი დიაგნოზი p95/p99 და ავტომატური გადაწყვეტილებები (freeze/rollback).

1) მონაცემთა მოდელი და კარდინალობა

მეტრიკა:' name {label1 =“ v1“, label2 =“ v2“} value @ timestamp'.
კარდინალობა = ეტიკეტების ყველა უნიკალური კომპლექტის შესაძლებლობების პროდუქტი; მთავარი ღირებულების ფაქტორი.

• базовые: `service`, `env`, `region`, `instance`, `pod`, `container`, `version`;
• დომენი: 'route', 'psp', 'tenant' (ფრთხილად!), 'game _ provider'.
• თქვენ არ შეგიძლიათ განათავსოთ 'user _ id', 'session _ id', შემთხვევითი/მაღალი კარდინალური მნიშვნელობები.

2) მეტრიკის ტიპები

ქვეყანა - მხოლოდ იზრდება (მაგალითად, 'http _ requests _ total').
Gauge არის მყისიერი მნიშვნელობები (მაგალითად, 'queue _ depth').
Histogram/Summary - ლატენტობის განაწილება. გაყიდვაში - Histogram ('histogram _ quantile ()' და exemplars) მხარდაჭერით.
Native Histograms არის ცვლადი ბაქტერიები, ზრდის სიზუსტეს და დაზოგავს ზომას (ჩართეთ იქ, სადაც ხელმისაწვდომია).

go var httpLatency = prometheus. NewHistogramVec(
prometheus. HistogramOpts{
Name:  "http_request_duration_seconds",
Help:  "HTTP latency",
Buckets: prometheus. DefBuckets ,//or custom
},
[]string{"route","method"},
)

3) ექსპორტიორები და რა უნდა გაზომოთ

მომსახურების კოდი: თქვენი კოდი (SDK Go/Java/Node/Python), RED მეტრიკა API, ბიზნეს მეტრიკა (გადახდის კონვერტაცია).
სისტემური: node _ exporter, cadisor/kubelet.
მესამე მხარის: BD/ქეში (mysqld _ exporter, postgres _ exporter, redis _ exporter), NGINX/HAProxy, Kafka/RabbitMQ.
OTel მეტრიკა: OpenTelemetry Collector- ის მეშვეობით, Prometheus Remote Write ან Prometheus-receiver, როგორც ზოგადი ნაკადი.

4) Scrape და relabel: როგორ დააკავშიროთ targets

ძირითადი 'prometheus. yml`

yaml global:
scrape_interval: 15s evaluation_interval: 15s external_labels:
env: "prod"
region: "eu-west"

scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['10. 0. 1. 10:9100','10. 0. 1. 11:9100']

- job_name: 'payments-api'
metrics_path: /metrics scheme: https tls_config:
ca_file: /etc/ssl/ca. crt cert_file: /etc/ssl/tls. crt key_file: /etc/ssl/tls. key relabel_configs:
- source_labels: [__address__]
regex: '(.):\d+'
target_label: instance replacement: '$1'

Kubernetes через Prometheus Operator

გამოიყენეთ შეტყობინებები Monitor/PodMonitor ნაცვლად სახელმძღვანელო „scrape _ configs“.

yaml apiVersion: monitoring. coreos. com/v1 kind: ServiceMonitor metadata: { name: payments-api }
spec:
selector: { matchLabels: { app: payments-api } }
namespaceSelector: { matchNames: [ "prod" ] }
endpoints:
- port: metrics interval: 15s scheme: http relabelings:
- action: replace targetLabel: service replacement: "payments-api"

K8s პრეზენტაციები (ოპერატორის გარეშე, გამარტივებული)

yaml metadata:
annotations:
prometheus. io/scrape: "true"
prometheus. io/port: "9102"
prometheus. io/path: "/metrics"

5) შენახვა: TSDB, WAL და ჭრელი

WAL (Write-Ahead Log) - სწრაფი აღდგენა გადატვირთვის შემდეგ.
კომპოზიცია: ბლოკების შეკუმშვა, დისკის დაზოგვა/CPU.
Retenshn: შეინახეთ ცხელი მონაცემები 7-30 დღის განმავლობაში; გრძელვადიანი - მიიღეთ (იხ. „მასშტაბი“).

• `--storage. tsdb. retention. time=15d`
• `--storage. tsdb. max-block-chunk-segment-size`
• დისკი: სწრაფი SSD/NVMe; ქსელის ტომების თავიდან აცილება საჭიროების გარეშე.

6) PromQL: საფუძვლები და ხშირი ნიმუშები

Rate/irate

promql rate(http_requests_total{route="/deposit"}[5m])

შეცდომები და წარმატების წილი

promql sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))

p95 ლატენტობა

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

რიგები/გაჯერება

promql max(queue_depth{queue="withdrawals"}) by (region)

7) Recording rules და შესრულება

წინასწარ ჩათვალეთ მძიმე გამონათქვამები და შეინახეთ, როგორც სერია.

yaml groups:
- name: api. rules interval: 30s rules:
- record: job:http:request_duration_seconds:p95 expr:
histogram_quantile(0. 95,
sum by (le, job) (rate(http_request_duration_seconds_bucket[5m])))
- record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))

პლუს: სწრაფი დაშბორდები, ნაკლები დატვირთვა CPU Prometheus- ზე.

8) Alerting и SLO (burn rate)

Burn-rate alerta (multi-window, multi-burn)

yaml groups:
- name: slo. payments rules:
- alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 5m labels: { severity: "page" }
annotations:
summary: "SLO fast burn"
runbook: "https://runbooks/payments/slo"
- alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }

Alertmanager: მარშრუტიზაცია სერვისებზე/რეგიონებში, დუბლიკატების ჩახშობა, ChatOps.

9) კორელაცია ტრეკებითა და ლოგოებით

ჩართეთ exemplars: clycabel 'trace _ id' ჰისტოგრამების ბაზრებში.
მოათავსეთ ეტიკეტები 'სერვისის', 'ვერსიის', 'region' „release compare- ისთვის“.
დაშბორდებზე - გამოშვების მენიუ (Git SHA/ვერსია).

10) მასშტაბები და გრძელვადიანი შენახვა

ფედერაცია: ზედა Prometheus აერთიანებს ქვედა (job/label ფილტრების მიხედვით).
Remote Write: რიგების გაგზავნა გრძელვადიანი შენახვის/მტევანი (Thanos/Cortex/Mimir).

უპირატესობები: გაუთავებელი რეტენინგი, ჰორიზონტალური სკალირება, გლობალური ხედვა.
უარყოფითი მხარეები: უფრო რთულია ოპერაცია, ღირებულება.
შარდინგი ფუნქციებში: ცალკეული ინსტანციები სისტემური მეტრიკისთვის, ბიზნესი, უსაფრთხო.

11) უსაფრთხოება

TLS/mTLS Prometheus targets/Alertmanager/remote _ write შორის.
ძირითადი/ავთენტიფიკაცია/targets და API (გაშვების კარიბჭის წინ).
RBAC: შეზღუდეთ UI/სერიებზე წვდომა როლებით; დაიმალეთ პირადი ეტიკეტები.
PII ჰიგიენა: არ დაწეროთ PII მეტრიკებში; გამოიყენეთ ჰეში/ფსევდონიმები.

12) Kubernetes პრაქტიკა

Prometheus Operator: CRD (ServiceMonitor, PodMonitor, Alertmanager, Prometheus).
kube-state-metrics + caDadisor - კლასტერის სრული სურათი.
Teinings და რესურსები: გამოყოფილი მოდელები მონიტორინგისთვის; CPU/RAM ლიმიტები.
ხმაურის დაქვეითება: სელექტორული ეტიკეტი „წარმოების“ ნეიმსპეისებისთვის, scrape _ interval პადინგი, სადაც შეგიძლიათ.

13) ბიზნეს მეტრიკა და პროდუქტი

Платежи: `payments_success_total{psp, currency}`, `payment_conversion_ratio`, `ttw_seconds_histogram`.
თამაშის აქტივობა: განაკვეთები/წუთები, სესიების გამართვა, როგორც gauge, შეცდომები.
რისკი/from: გამომწვევები სიჩქარის/გეოს ანომალიებში; ლოჯისტიკა ცალკე, მეტრიკა - აგრეგატები.

14) ღირებულება და შესრულება (FinOps)

აკონტროლეთ კარდინალობა (ახალი ეტიკეტის დამატებამდე).
ჰისტოგრამების სემპლინგი/იშვიათი ექსპორტიორები 'scrape _ interval' არაკრიტიკული ტარგეტებისთვის.
Downsampling გრძელი შენახვის ზურგჩანთებში.
დაშბორდის ქეშირება და ფართო მხარდაჭერა ჩანაწერებზე.

15) „სწრაფი დაწყების“ მაგალითები

RED- ის ექსპორტიორი განაცხადში (პითონი)

python from prometheus_client import Counter, Histogram, start_http_server reqs = Counter('http_requests_total','', ['route','method','status'])
lat = Histogram('http_request_duration_seconds','', ['route','method'])
start_http_server(8000)

def handle(req):
with lat. labels(req. route, req. method). time():
status = app(req)
reqs. labels(req. route, req. method, str(status)). inc()
return status

ბარიერი ალერტა p95

promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }

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

1. დაადგინეთ ძირითადი მეტრიკის (RED/USE) და აფეთქების ღუმელის ინდიკატორების ნაკრები.
2. კოორდინირებული ეტიკეტები და ჰაიდი კარდინალურად.
3. პარამეტრები scrape/Microsoft Monitor, TLS/mTLS, relabel.
4. ჩართეთ ჰისტოგრამები საკვანძო ბილიკებისა და ექსპლარებისთვის.
5. შექმენით ჩანაწერები p95, success ratio, ბიზნეს ერთეულებისთვის.
6. შეიყვანეთ SLO ალერტები (burn rate) და Alertmanager ruting.
7. ასწიეთ dashbords: სერვისის map, release compare, გადახდები.
8. გადაწყვიტეთ ფედერაცია/remote _ write და ჭრა.
9. შეზღუდეთ წვდომა (RBAC), შეამოწმეთ PII არარსებობა.
10. ჩართეთ runbooks და თამაშის დღის შემოწმება.

17) ანტი შაბლონები

მაღალი კარდინალური ეტიკეტები (user/session/request _ id).
Summary ნაცვლად Histogram საკვანძო SLO - არ არის 'histogram _ quantile'.
Scrape „ყველაფერი ზედიზედ“ ფილტრაციის/როტაციის გარეშე არის ხარჯების და ხმაურის ზრდა.
ალერტები ნედლეულ მეტრიკებში SLO- ს გარეშე - ალერტ ფეტიგი.
ჩანაწერების არარსებობა არის „მძიმე“ დაშბორდები.
TLS/mTLS- ის გარეშე მეტრიკებში ნდობა შეცვლის/გაჟონვის რისკი.

შედეგები

Prometheus იძლევა iGaming პლატფორმას სამიზნეებთან დაკავშირებული დაკვირვებით: ზუსტი ჰისტოგრამები, სტაბილური აგრეგატები, მკაფიო SLO ალერტები და მრავალი რეგიონალური რუქის მასშტაბები. ეტიკეტის დისციპლინა, სწორი ჩანაწერების რულეტები, ტრეკები/ლოგოები და გააზრებული შენახვის არქიტექტურა უზრუნველყოფს სწრაფ გამოშვებებს და პროგნოზირებადი p99, თუნდაც პიკის მომენტებში.