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

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

1) მიზანი და ჩარჩო

მეტრიკის მიკროსქემის ამოცანაა საიმედოდ შეაგროვოს და შეინახოს დროებითი რიგები, მისცეს სწრაფი PromQL RCA- სთვის, SLO- ს ალერტები და გასაგები დაშბორდები. ძირითადი წყვილი: Prometheus (scrape - store - query) და Grafana (ვიზუალიზაცია, ალერტები, გამოშვების სურათები). გრძელი შენახვისა და გლობალური მოთხოვნისთვის - Thanos/Cortex/Mimir.

2) მონაცემთა მოდელი და სემანტიკა

სერია = მეტრიკის სახელი + label's ნაკრები (გასაღები = მნიშვნელობა).
ტიპები: counter, gauge, histogram, summary (გაყიდვაში - უფრო ხშირად histogram).

• RED (API): 'rate', 'errors', 'duration' (ჰისტოგრამები).
• USE (ресурсы): Utilization, Saturation, Errors (CPU/RAM/Disk/Net).
• სახელწოდება: „namespace _ subsystem _ metric _ unit“ (მაგალითად, 'http _ server _ requests _ total', 'db _ connections _ current').

ანტი-კარდინალობა: მინიმუმამდე დაიყვანეთ label- ის სხვადასხვა მნიშვნელობები (არ არსებობს muser _ id, request _ id label).

3) გამოფენა და დისკუსია

ექსპორტიორები: node _ exporter, kube-state-metrics, cadisor, BD/ეტაპი (postgres _ exporter, redis _ exporter, kafka _ exporter).
საკუთარი სერვისები: კლიენტის ბიბლიოთეკები (Go/Java/Node/Python) - '/metrics '.
Service Discovery: Kubernetes, EC2/ASG, Consul, static files.

yaml global:
scrape_interval: 15s evaluation_interval: 15s scrape_configs:
- job_name: 'kubernetes-nodes'
kubernetes_sd_configs: [{ role: node }]
relabel_configs:
- action: labelmap regex: __meta_kubernetes_node_label_(.+)
- job_name: 'apps'
kubernetes_sd_configs: [{ role: pod }]
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep regex: "true"
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
target_label: __metrics_path__
regex: (.+)
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
target_label: __address__
regex: (.+)
replacement: $1

yaml prometheus. io/scrape: "true"
prometheus. io/path: /metrics prometheus. io/port: "8080"

4) Histograms და latency

• ვებ/API: '[10ms, 25.50,200,400,800,1600] "
• გადახდა/გადახდა: დაამატეთ კუდი 5-10s- მდე.

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

promql histogram_quantile(0. 95,
sum by (le, route) (rate(traces_spanmetrics_duration_bucket{route="/withdraw"}[5m]))
)

5) ჩაწერის წესები

ისინი ამცირებენ მძიმე მოთხოვნებს, სტანდარტიზებენ SLI.

yaml groups:
- name: api_sli interval: 30s rules:
- record: job:http:success_ratio:rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
- record: job:http:duration_p95:5m expr: histogram_quantile(0. 95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) SLO და alerty (multi-window burn)

SLO 99. წარმატებული მოთხოვნების 9 %/30d.

yaml groups:
- name: slo_burn rules:
- alert: ErrorBudgetBurnHighShort expr: (1 - job:http:success_ratio:rate5m) > (1 - 0. 999) 14 for: 5m labels: { severity: critical }
annotations: { summary: "Fast burn >14x for 5m" }

- alert: ErrorBudgetBurnHighLong expr: (1 - job:http:success_ratio:rate5m) > (1 - 0. 999) 6 for: 1h labels: { severity: critical }
annotations: { summary: "Long burn >6x for 1h" }

yaml route:
receiver: pager group_by: ["service"]
receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true

7) ლაბელის ჰიგიენა და დაზოგვა

Label- ის სახელები სტაბილურია და სტანდარტიზებულია: 'service', 'env', 'region', 'route', 'code', 'version'.
შეზღუდეთ კარდინალობა: მეტრიკებმა 'მარშრუტით' უნდა გამოიყენონ შაბლონის 'http. მარშრუტი '(და არა სრული URL).
ლოგიკის სემპლინგი - ტრეისებში; მეტრიკებში - არა user _ id.
გამოშვების თვისებები ('სერვისი. ვერსია ') სასარგებლოა ძველი/ახალი ვერსიის შედარებისთვის.

8) მასშტაბები და HA

• ორი Prometheus (A/B) ერთსა და იმავე მიზნებს ამცირებს (HA Alertes დუბლირებულია).
• Thanos: Sidecar თითოეული Prometheus, Store + Query გლობალური მოთხოვნებისა და გრძელვადიანი შენახვისთვის (S3/GCS).
• ალტერნატივა: Cortex/Mimir (remote-write, მრავალმხრივი, ჰორიზონტალური სკალირება).

yaml remote_write:
- url: https://mimir. example. com/api/v1/push basic_auth: { username: tenantA, password: $MIMIR_TOKEN }

yaml
--storage. tsdb. retention. time=15d
--storage. tsdb. max-block-duration=2h

9) Grafana: Dashbords, alerty, ვიდეოები

1. Platform Overview (SLO/RED, error-budget).

2. API by Route (RPS/5xx/p95, შედარება 'ვერსია').

3. K8s Cluster/Nodes (control-plane, saturation).

4. DB/Cache/Queues (lag/locks/hit ratio/backlog).

5. Per-Release (CI- დან გამოცემების ჩანაწერები).

Grafana Alerting: PromQL გამომწვევი, rotation on-call, mute-times „გამოშვების ფანჯრები“.

Annotations: CI ემატება გამოშვების მოვლენას 'commit', 'image. tag ', ბმულის მითითებით.

10) Kubernetes: რა უნდა გაზომოთ

Control-plane: `apiserver_request_total`, etcd leader/fsync, scheduler latency.
Workloads: restarts, 'container _ cpu _ cfs _ throttled _ seconds _ total', OOM, Pending/Evicted, PDB დარღვევები.
ქსელი: ფრენები, კონტრაკი, 'kube-proxy' შეცდომები.
კვოტები/ლიმიტები: Requests vs Limits, HPA/VPA, saturation კვანძები.

11) BD/ქეში/ხაზები: საკვანძო სიგნალები

PostgreSQL/MySQL: `connections`, `locks`, `deadlocks_total`, `xact_commit/rollback`, replication lag.
Redis: hit ratio, `evictions`, latency `instantaneous_ops_per_sec`.
Kafka/RabbitMQ: consumer lag, unacked, ISR, disk usage.

promql
Queue backlog sum by (topic) (kafka_consumergroup_lag)> 1000

Postgres replication lag max(pg_replication_lag_seconds) > 2

12) უსაფრთხოება და მრავალ ტენანტობა

RBAC Prometheus/Grafana, datasource permichens.
კომპონენტებს შორის TLS/mTLS ჯაჭვი.
მოიჯარეების იზოლაცია: ცალკეული Prometheus ან tenant-label Cortex/Mimir; სერიის ლიმიტები და მოთხოვნა.
საიდუმლოებები ალერტებში/ნოტიფიკაციებში - აკრძალულია (გამოიყენეთ ID თიკეტი და არა PII).

13) ინტეგრაცია გამოშვებებთან და მანქანებთან

SLO წესები AnalysisTemplate (Argo Rollouts) ან CI-gate.
როდესაც burn-alerts ხდება - pause/rollback canary; Dola/countations - ბმული გამოშვებაზე.
სტაბილური და კანარის ვერსიის შედარება label 'version- ის საშუალებით.

14) ტიპიური შეცდომები (ანტი-ნიმუშები)

ლაბელის უკონტროლო კარდინალობა (user _ id, url. სრული, დინამიური გასაღებები).
Stage და stage შერევა ერთ კლასტერში 'env' label- ის გარეშე.
მხოლოდ gauge RED/USE გარეშე; ჰისტოგრამების გარეშე p95/p99.
რკინის ალერტები SLO- ს მითითების გარეშე ხმაურია.
ჩანაწერების არარსებობა „მძიმე“ მოთხოვნაა პროდ ინციდენტებში.
არ არსებობს გამოცემების პრეზენტაციები - ძნელია შედარება ცვლილებებისა და დეგრადაციის შესახებ.

15) განხორციელების სიის სია (0-45 დღე)

0-10 დღე

Node/kube-state/caDadisor ექსპორტიორები; '/metrics 'სერვისებში.
ძირითადი RED/USE დაშბორდები; სტანდარტული ჰისტოგრამების ბაკეტები.
CI- სგან გამოცემების პრეზენტაციების ჩართვა.

11-25 დღე

ჩანაწერების რულეტები SLI- სთვის; multi window burn alerty.
HA Prometheus (ორმაგი სკრაპი), GitOps ჩამორთმევის სარეზერვო ასლი.
Alertmanager: მარშრუტები/მშვიდი რეჟიმი/rotation on-call.

26-45 დღე

Remote write in Thanos/Cortex/Mimir, გრძელი შენახვა.
კარდინალობის ოპტიმიზაცია, სერიების შეზღუდვები, მოთხოვნები.
SLO gating გამოშვებები და auto-rollback ინტეგრაცია.

16) სიმწიფის მეტრიკა

RED/USE დაფარვა საკვანძო სერვისებში 95% -ს შეადგენს.
„მძიმე“ PromQL <2 c (p95) შესრულების საშუალო დრო ჩანაწერების გამო.
სასარგებლო/ხმაურიანი ალერტების თანაფარდობა> 3:1.
კონტროლირებადი კარდინალობა: <10M აქტიური სერია კლასტერზე, ადიდების ნაკლებობა.
გამოშვებების 100% -ს აქვს Grafana- ს მენიუ და მეტრიკის შედარება/მის შემდეგ.

17) სასარგებლო snippets

Stable vs canary ვერსიის მიხედვით

promql histogram_quantile(0. 95,
sum by (le, version) (rate(http_request_duration_seconds_bucket{version=~"stable    canary"}[5m]))
)

5xx შეცდომები მარშრუტებზე

promql topk(5,
sum by (route) (rate(http_requests_total{status=~"5.."}[5m]))
)

CPU კონტეინერი

promql rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1

მეტრიკის კავშირი ტრეისებთან (Exemplars შედის)

promql sum (rate (http_request_duration_seconds_bucket[5m])) by (le) # clickable to the track

18) დასკვნა

Prometheus + Grafana არის დე ფაქტო სტანდარტი მეტრიკისთვის. სემანტიკა და დისციპლინა იმარჯვებს: RED/USE, სისუფთავე ლაბელი, ჰისტოგრამები SLO- ს, ჩანაწერების და SLO ალერტების ქვეშ. დაამატეთ HA და გრძელვადიანი შენახვა, რელიზების ვიდეოები და ავტომატური გამოტოვებით ინტეგრაცია - და თქვენ მიიღებთ სწრაფ, მასშტაბურ და ეკონომიურ მეტრულ მიკროსქემას, რაც ხელს უწყობს გადაწყვეტილების მიღებას გაყიდვაში.