დაშბორდის ინფრასტრუქტურა

1) რატომ არის ეს აუცილებელი?

სახელმწიფოს ერთიანი სურათი: კლასტერიდან და ქსელებიდან მონაცემთა ბაზებამდე და რიგებში.
სწრაფი RCA და პოსტ-mortems: მეტრიკის ლიგატი - ლოგოები და ბილიკები.
SLO სერვისებსა და პლატფორმაზე: კონტროლი ხელმისაწვდომობასა და ლატენტობაზე.
FinOps გამჭვირვალობა: მოცულობა/ღირებულება მომსახურებებზე, ფენანტებსა და ოთხშაბათს.
შესაბამისობა/უსაფრთხოება: პატჩების/დაუცველების სტატუსი, წვდომა, ანომალიები.

მეთოდოლოგია: Golden Signals (latence, traffic, errors, saturation), RED (Rate, Errors, Duration) მოთხოვნებისთვის, USE (Utilization, sion, stion, s- ის, erration, ers, ers) რესურსებისთვის.

2) კარგი დაშბორდის პრინციპები

მოქმედება: თითოეული პანელი პასუხობს „რა უნდა გავაკეთოთ შემდეგ“.
იერარქია: მიმოხილვა - დომენები - deep dive - raw.
შაბლონები/ცვლადები: 'cluster', 'namespace', 'service', 'tenant', 'env'.
ერთი ერთეული: ms ლატენტობისთვის,%, RPS, ოპერაციები/s, ბაიტი.
Consistent timpicer: სტანდარტულად 1-6 საათი, სწრაფი პრესეტები 5 მ/15 მ/24h.
Drilldown: Loki/ELK პანელიდან და ტრეკიდან (Tempo/Jaeger).
ფლობა: დაშბორდზე მითითებულია მფლობელი, SLO, runbook, კონტაქტი on-call.

3) საქაღალდეების სტრუქტურა და როლები

00 _ Overview არის პლატფორმის ზედა დონის მიმოხილვა.
10 _ Kubernetes - მტევანი, nods, workloads, NRA/HPA, კონტეინერები.
20_Network_Edge — Ingress/Envoy/Nginx, LB, DNS, CDN, WAF.
30 _ Storage _ DB - PostgreSQL/MySQL, Redis, Kafka/RabbitMQ, ობიექტის საცავი.
40 _ CICD _ Runner - რიგები, აგენტები, არტეფაქტები, რეგისტრი.
50 _ Security _ Compliance - დაუცველობა, პატჩი, RBAC, audit events.
60 _ FinOps _ Cost - მომსახურების ღირებულება/tenant/მტევანი, განკარგვა.
99 _ Runbooks - ბმულები ინსტრუქციებსა და SLO ბარათებზე.

როლები: Platform-SRE (სრული წვდომა), Service-Owner (საკუთარი სივრცეები), Security/Compliance, Finance/FinOps, View-only.

4) მიმოხილვის დაშბორდის პლატფორმა (Landing)

მიზანი: 30 წამის განმავლობაში იმის გაგება, ყველაფერი წესრიგშია.

• SLO პლატფორმა (API edge- ის ხელმისაწვდომობა): მიზნობრივი მნიშვნელობა, ფაქტობრივი, შეცდომების ერა, burn-rate.
• ლატენტობა p50/p95/p99 მთავარ შესასვლელ წერტილებში.
• 4xx/5xx შეცდომები და ტოპ ენდოინტები რეგრესიებით.
• რესურსების სატურაცია (CPU, RAM, ქსელი, დისკი) - p95 მტევანი.
• ინციდენტები/ალერტები (აქტიური) და უახლესი გამოშვებები.
• ღირებულება/საათი (სავარაუდოა) და ტენდენცია კვირაში.

ცვლადის შაბლონები: 'env', 'region', 'cluster', 'tenant'.

5) Kubernetes: მტევანი და worcloads

1. მტევანი/nods

CPU/Memory, pressure (memory/cpu), IO დისკი, inode.
ქვესისტემები: kube-api, etcd, კონტროლერები; kubelet health.

2. Workloads

RPS/RPM, latency p95, error rate, restarts, throttling, OOMKills.
HPA targets vs ფაქტობრივი მეტრიკა.

3. ქსელის ბილიკი კლასტერში

eBPF/Netflow: top talkers, drops, retransmits.

4. K8s მოვლენები

Rate по Warning/FailedScheduling/BackOff.

promql
API (5xx) errors by sum by (service) (rate (http_requests_total{status=~"5"..}[5m]))

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

Throttling CPU контейнеров sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m]))

6) Edge, beach და DNS

• Ingress/Envoy/Nginx: RPS, p95, 4xx/5xx, upstream_errors, active_conns.
• LB/Anycast: ტრეფიკის განაწილება ზონებში, სამართლიანი მოვლენები.
• DNS: რეზინის ლატენტობა, NXDOMAIN/SERVFAIL rate, hit-ratio kash.
• CDN/WAF: ბლოკირება წესების მიხედვით, არანორმალური ტრაფიკი (ბოტები/სკრიპტები).

promql sum(rate(nginx_http_requests_total[5m])) by (status)

7) მონაცემთა ბაზები და სორტირება

PostgreSQL/MySQL: qps, latency, lock waits, replication lag, bacaps/წარუმატებლობები.
Redis: hit ratio, evictions, მეხსიერება, ნელი გუნდები.
Kafka/RabbitMQ: lag consumer ჯგუფებში, rebalances, unacked messages.
ობიექტის საცავი: მოთხოვნები, შეცდომები, egress, lat p95.

promql
Replication lag in seconds max by (replica) (pg_replication_lag_seconds)

Slow Queries> 1s rate (pg_stat_activity_longqueries_total[5m])

promql
Lag by group max by (topic, group) (kafka_consumergroup_lag)

8) CI/CD და არტეფაქტები

Pipeline overview: წარმატება/შესრულების დრო, რანერების ჯერი.
Eployment Health: ვერსიები, canary/blue-green სტატუსი, დათბობის დრო.
სურათების რეესტრი: ზომა, ბოლო push 'და, განკარგვა.

promql
Rate (ci_pipeline_success_total[1h] )/rate (ci_pipeline_total[1h]) success rate

9) უსაფრთხოება და შესაბამისობა

Patchi და დაუცველობა: nod/სურათების წილი კრიტიკული CVE, საშუალო „დრო პატჩამდე“.
RBAC და საიდუმლოებები: დაშვების, საიდუმლოებების დაცვის წარუმატებელი მცდელობები.
აუდიტის მოვლენები: შეყვანა/ცვლილებები კრიტიკულ კომპონენტებში, დრიფტი.
WAF/DLP/PII გამოცემა: წესების დაბლოკვა, შენიღბვის შეცდომები.

10) ლოგები და მარშრუტები: მიმოხილვა

შეცდომების შეჯამება ლოგებისგან (Loki/ELK): ტოპ ექსკლუზიები, ახალი ხელმოწერები.
ღილაკი „გადასვლა ლოგებზე ფილტრებით“ (LogQL/ES query).
ბილიკები: ყველაზე ძილი სპანები, მოთხოვნის პროცენტი ტრასის კონტექსტის გარეშე.

{app="api", level="error"}     = "NullReference"
{app="nginx"}      json      status="5.."      count_over_time([5m])

11) FinOps: ღირებულება და განკარგვა

ღირებულება სერვისებზე/ტენანტებზე/მტევნებზე (ბილინგის/ექსპორტიორების მიხედვით).
ცხელი/ცივი კვანძები: idle რესურსები, rightsizing რეკომენდაციები (CPU/Mem).
Datetegress, L7 მოთხოვნები და მათი ღირებულება.
დინამიკა: კვირა/თვე, პროგნოზი.

• cost_per_rps, cost_per_request, storage_cost_gb_day, idle_cost.
• ეფექტურობის კოეფიციენტი: 'RPS/$' ან 'SLO წუთი/$'.

12) SLO, შეცდომები და burn-rate

SLO ბარათი დომენის თითოეულ დაშლაზე: მიზანი, პერიოდი, შეცდომები (budget).
Burn-rate ალერტა (ორი სიჩქარე: სწრაფი/ნელი).

promql
Bad budget: 5xx as a fraction of sum (rate (http_requests_total{status=~"5"..}[5m])) traffic
/
sum(rate(http_requests_total[5m]))

Burn-rate (fast channel ~ 1h)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14. 4

13) ვიზუალიზაციის სტანდარტები

პანელის ტიპები: დრო სერია რიგებისთვის, KPI- სთვის stat, table for top-N, heatmap ლატენტობისთვის.
ლეგენდები და დანაყოფები: სავალდებულო; შემცირებული ეტიკეტები, SI ფორმატი.
ფერის ზონები: მწვანე/ყვითელი/წითელი SLO/threshold (ერთგვაროვანი).
პანელის აღწერა: რას ვზომავთ, წყაროს, runbook ბმულს, მფლობელს.

14) პანელის შაბლონები (სწრაფი დასაწყისი)

(A) API Overview

KPI: `RPS`, `p95`, `5xx%`, `error_budget_remaining`.
Top endpoints by error/latency.
Drilldown logs 'trace _ id = trace'.

(B) Node Health

CPU/Memory/Disk/Network - p95, „ცხელი“ სია.
Pressure, throttling, პაკეტების drops.

(C) DB Health

TPS, latency p95, locks, replication lag, slow queries.
Becap სტატუსი/ბოლო წარმატება.

(D) Kafka Lag

ჯგუფებში Lag, vs წარმოების მოხმარების სიჩქარე, rebalances.

(E) Cost & Util

Cost/hour მომსახურებისთვის, idle%, rightsizing hints, პროგნოზი.

15) ცვლადი და ტეგები (რეკომენდებული ნაკრები)

`env` (prod/stage/dev)

`region`/`az`

`cluster`

`namespace`/`service`/`workload`

`tenant`

`component` (edge/db/cache/queue)

`version` (release/git_sha)

16) ინტეგრაცია ალერტინთან და ინციდენტის მენეჯმენტთან

წესები Alertmanager/Graphana Alertach- ში სწორი დაშბორდის და უკვე შემცირებული ცვლადის ბმულებით.
P1/P2 SLO კრიტერიუმების მიხედვით, auto-assign on-call.
გამოშვების/ინციდენტების სურათები გრაფიკებზე.

17) დაშბორდის ხარისხი: შემოწმების სია

• მეპატრონე და კონტაქტი.
• SLO/thresholds დოკუმენტირებულია.
• ცვლადი მუშაობს და ზღუდავს მოთხოვნის რაოდენობას.
• ყველა პანელი ერთეული და ლეგენდა.
• Drilldown ლოგოებში/მარშრუტებში.
• პანელები მოთავსებულია 2-3 „ეკრანზე“ (კილომეტრზე ასვლის გარეშე).
• მოთხოვნის პასუხის დრო არის 2-3 c (ქეში, downsample).
• არ არსებობს „მკვდარი“ პანელები და მკვდარი მეტრული.

18) თავად დაშბორდის პროდუქტიულობა და ღირებულება

Downsampling/recording rules მძიმე დანაყოფებისთვის.
ქეშირება (query-frontend/დამრიგებელი) და limites range/step.
ტესტის საკიდი: დატვირთვა TSDB/მტევანი ტიპიური დაშბორდის მოთხოვნებზე.
ეტიკეტების რეორგანიზაცია (დაბალი კარდინალობა), ველური ბარათების უარყოფა.

19) განხორციელების გეგმა (გამეორება)

1. კვირა 1: Landing + K8s/Edge მიმოხილვები, ძირითადი SLO, მფლობელები.
2. კვირა 2: DB/Queues, Drilldown ინტეგრაცია, burn-rate ალერტები.
3. კვირა 3: FinOps Dashboards, rightsizing რეკომენდაციები, ანგარიში ღირებულებით.
4. კვირა 4 +: უსაფრთხოება/კომპლექსი, SLO ბარათების ავტომატური წარმოება, დაშბორდის რეგრესიული ტესტები.

20) მინი-FAQ

რამდენი დაშბორდია საჭირო?
მინიმუმ 1 მიმოხილვა + თითო დომენში (K8s, Edge, DB, Queues, CI/CD, Security, Cost). დანარჩენი სიმწიფეა.

რა არის უფრო მნიშვნელოვანი - მეტრიკა ან ლოგები?
სიმპტომების მეტრიკა და SLO, მიზეზები. ბმული 'trace _ id' და თანმიმდევრული ეტიკეტები.

როგორ არ „დაიხრჩო“ პანელებში?
იერარქია, აშკარა მეპატრონეები, ჰიგიენის მეტრიკა, რეგულარული შურისძიება და „მკვდარი“ პანელების მოცილება.

შედეგი

ინფრასტრუქტურული დაშბორდები არ არის „ლამაზი გრაფიკა“, არამედ მენეჯმენტის ინსტრუმენტი: SLO კონტროლი, სწრაფი RCA და შეგნებული FinOps. სტანდარტიზებული ცვლადი, ვიზუალური შაბლონები და მფლობელები; უზრუნველყეთ drilldown logs/ტრასებზე და ავტომატიზირდით burn-rate ალერტას. ეს მისცემს პროგნოზირებას, რეაქციის სიჩქარეს და ღირებულების გამჭვირვალობას მთელი პლატფორმის დონეზე.