ინფრასტრუქტურის მონიტორინგი

ინფრასტრუქტურის მონიტორინგი

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

• გააფრთხილეთ მომხმარებლის წინაშე წარუმატებლობის შესახებ (ადრეული გამოვლენა).
• მიეცით ძირითადი მიზეზის დიაგნოზი.
• მხარი დაუჭირეთ SLO გეიტინგის გამოშვებებს და მანქანების გამოტოვებას.
• იკვებეთ პოსტ-ინციდენტის ანალიზი.

დამხმარე პრინციპები: Observable by Design, ნაკლები ხმაური - მეტი სიგნალი, რეაქციების ავტომატიზაცია, ჭეშმარიტების ერთიანი პანელი.

2) დაკვირვებათა ტრიადა

მეტრიკები: სიჩქარე/მოთხოვნა/შეცდომები/გაჯერება (USE/RED).
ლოგიკა: ღონისძიების დეტალიზაცია კონტექსტით; არ შეიცავს საიდუმლოებებს/PII.
ტრეისი: განაწილებული განცხადებები მიზეზობრივი კავშირების შესახებ.

• პროფილირება (CPU/heap/lock/io), eBPF სისტემის დონეზე.
• მოვლენები/აუდიტი (K8s Events, კონფიგურაციის/საიდუმლოების ცვლილებები).

3) SLI/SLO/SLA - ხარისხის ენა

SLI (ინდიკატორი): 'availability', 'error _ rate', 'p95 _ latency', 'queue _ lag'.

SLO (მიზანი): "წარმატებული მოთხოვნები 99. 9% 30 დღეში."

Error Budget: დასაშვები გადახრა; გამოიყენება ავტომობილების გამოსვლის გაჩერებისთვის.

yaml service: "api-gateway"
slis:
- name: success_rate query_good: sum(rate(http_requests_total{status!~"5.."}[5m]))
query_total: sum(rate(http_requests_total[5m]))
slo: 99. 9 window: 30d

4) მონიტორინგის ფენის რუკა

1. მასპინძლები/VM/კვანძები: CPU/Load/Steal, RAM/Swap, Disk IOPS/Latence, Filesystem.
2. ქსელი/LB/DNS: RTT, პაკეტები/ფრენები, backlog, SYN/Timeout, health probes.
3. Kubernetes/Orchestrator: API სერვერი, etcd, კონტროლერები, სკედულერი; პოდები/კვანძები, pending/evicted, throttling, kube-events.
4. სერვისები/კონტეინერები: RED (Rate/Errors/Duration), readiness/liveness.
5. მონაცემთა ბაზები/ქეში: QPS, cock wait, რეპლიკა lag, buffer hit, slow queries.
6. რიგები/საბურავები: consumer lag, requeue/dead-letter, throughput.
7. საცავი/ღრუბელი: S3/Blob შეცდომები და ლატენტობა, პროვაიდერების 429/503.
8. პერიმეტრის საზღვრები: WAF/Rate Limits, 4xx/5xx მარშრუტებზე, CDN.
9. სინთეზური: HTTP სკრიპტის შემოწმება (ანაბარი/გამომავალი), TLS/სერთიფიკატები.
10. ეკონომიკა/შესაძლებლობები: cost სერვისის, utilization, headroom.

5) Whitebox и Blackbox

Whitebox: ექსპორტიორები/SDK სერვისების შიგნით (Prometheus, OpenTelemetry).
Blackbox: გარე ნიმუშები სხვადასხვა რეგიონიდან (availability, latence, TLS expiry).
დააკავშირეთ: „ნიშანი გარეთ“ + „დიაგნოზი შიგნით“.

yaml modules:
https_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"

6) Kubernetes: საკვანძო სიგნალები

Кластер: `apiserver_request_total`, `etcd_server_has_leader`, etcd fsync.
Узлы: `container_cpu_cfs_throttled_seconds_total`, `node_pressure`.
Pending/CrashLoopBackOff, OOMKilled, restarts.
გეგმები/ლიმიტები: Requests vs Limits, PodDisruption Budget, HPA/VPA.
ქსელი: ქსელის პოლიტიკა, conntrack exhaustion.

Дашборды: «Cluster health», «Workload saturation», «Top erroring services».

7) BD და რიგები

PostgreSQL/MySQL: replication lag, deadlocks, slow query %, checkpoint I/O.
Redis/Memcached: hit ratio, evictions, rejected connections.
Kafka/RabbitMQ: consumer lag, unacked, requeue, broker ISR, disk usage.

8) მეტრიკა RED/USE და ბიზნეს კორელაცია

RED: `rate` (RPS), `errors` (4xx/5xx), `duration` (p95/p99).
USE (რესურსებისთვის): Utilization, Saturation, Errors.
დაუკავშირდით პროდუქტს: ანაბრები/წარმატებები, ფროიდის დროშები, კონვერტაცია - ეს არის „მცველები“ კანარის გამოშვებისას.

9) ალერტინგის სტრუქტურა

Tier-1 (პეიჯი): ინციდენტები, რომლებიც გავლენას ახდენენ SLO- ზე (წვდომა, 5xx, ლატენტობა, კლასტერული კრიტიკული კომპონენტების უკმარისობა).
Tier-2 (ტიკეტი): ტევადობის დეგრადაცია, შეცდომების ზრდა SLO- ზე გავლენის გარეშე.
Tier-3 (ინფო): ტენდენციები, პრედიკულური კონტეინერი, სერთიფიკატების ამოწურვა.

ესკალაციის წესები: დუმილის დრო/დუბლიკატების შეკუმშვა, როტაცია on-call, „follow-the-sun“.

yaml route:
group_by: ["service","severity"]
receiver: "pager"
routes:
- match: { severity: "critical" }
receiver: "pager"
- match: { severity: "warning" }
receiver: "tickets"

10) Prometheus- ის წესების მაგალითები

10. 1 შეცდომები 5xx c SLO ბარიერი

yaml groups:
- name: api rules:
- alert: HighErrorRate expr:
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m])) > 0. 005 for: 10m labels: { severity: "critical", service: "api-gateway" }
annotations:
summary: "5xx > 0. 5% 10m"
runbook: "https://runbooks/api-gateway/5xx"

10. 2 error-budget დაწვა

yaml
- alert: ErrorBudgetBurn expr:
(1 - (
sum(rate(http_requests_total{status!~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
)) > (1 - 0. 999) 14 for: 5m labels: { severity: "critical", slo: "99. 9" }
annotations: { summary: "Fast burn >14x for 5m" }

10. 3 სისტემური გაჯერება (CPU Throttling)

yaml
- alert: CPUThrottlingHigh expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1 for: 10m labels: { severity: "warning" }
annotations: { summary: "CPU throttling >10%" }

11) Logs: კოლექცია, ნორმალიზაცია, ჭრა

სტანდარტიზაცია: JSON logs: 'ts', 'level', 'service', 'trace _ id', 'user/tenant'.
Paipline: აგენტი (Fluent Bit/Vector) - ბუფერი, ინდექსი/საცავი.
რედაქტორები: PII/საიდუმლოებების ნიღაბი ზღვარზე.
Retenshn: სწრაფი შენახვის კლასი (7-14 დღე), „ცივი“ არქივი (30-180 დღე).
სემანტიკა: error budgets/დეპრესიები - ცალკეული არხები.

12) ტრეისი და OpenTelemetry

მიუთითეთ შეყვანის წერტილები, კლიენტი - გამოწვევის სერვისი, BD/ქეში/ხაზი.
მიბმული მეტრიკები ტრეისის ატრიბუტებზე (Exemplars) სწრაფი ნავიგაციისთვის.
OTel Collector, როგორც ცენტრალური კარიბჭე: ფილტრაცია, ნიმუში, შერჩეული ბეკენდების ექსპორტი.

yaml receivers: { otlp: { protocols: { http: {}, grpc: {} } } }
processors: { batch: {}, tail_sampling: { policies: [ { name: errors, type: status_code, status_codes: [ERROR] } ] } }
exporters: { prometheus: {}, otlp: { endpoint: "traces. sink:4317" } }
service:
pipelines:
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }
traces: { receivers: [otlp], processors: [tail_sampling,batch], exporters: [otlp] }

13) სინთეზური და გარე შემოწმებები

ბიზნეს სცენარების HTTP გარბენი (ლოგინი, ანაბარი, დასკვნა, შეძენა).
TLS/დომენი: სერთიფიკატის ვადა/CAA/DNS health.
რეგიონალურობა: ნიმუშები ძირითადი ქვეყნებიდან/პროვაიდერებიდან (მარშრუტიზაცია/ბლოკის ფურცლები).
სინთეტიკა უნდა იყოს ალერტული, თუ ეს არ არის ხელმისაწვდომი მომხმარებლისთვის, თუნდაც მწვანე შიდა ტელემეტრიით.

14) პროფილირება და eBPF

Continuous profiling: ცხელი ფუნქციების იდენტიფიცირება, დაბლოკვა.
eBPF: სისტემური მოვლენები (syscalls, TCP retransmits), გაყიდვებზე მინიმალური overhead.
პროფილის ალერტები stuncing (tickets) გარეშე, ხოლო გამოშვების შემდეგ რეგრესიებისთვის - როგორც დაბრუნების სიგნალი.

15) დაშბორდი და „სიმართლის პანელი“

1. Platform Overview: SLI/SLO საკვანძო სერვისებში, error-budget, ალერტები.

2. API RED: RPS/ERRORS/DURATION მარშრუტებზე.

3. K8s Cluster: control-plane, узлы, capacity headroom.

4. DB/Cache: lag/locks/slow query %, hit ratio.

5. Queues: backlog/lag, უარყოფითი/განმეორებითი.

6. Per-release: მეტრის შედარება/შემდეგ (კანარის ფანჯრები).

7. FinOps: cost per namespace/service, idle/oversized ресурсы.

16) ინციდენტები, ალერტული ხმაური და ესკალაცია

დედუპლიკაცია: სამსახურის/მიზეზის ჯგუფი, კასკადების ჩახშობა.
სიჩუმე/maintenance: გამოშვებები/მიგრაცია არ უნდა „დახატოს“ ყველაფერი წითლად.
Runbooks: თითოეული კრიტიკული ალერტა, რომელსაც აქვს დიაგნოზის ნაბიჯები და გამოტოვების „ღილაკი“.
Postmortem: დრო, რაც მათ ისწავლეს, რა სიგნალები დაამატეს/გაიწმინდა.

17) უსაფრთხოების მონიტორინგი

RBAC წესების/datasors- ის კითხვისთვის/შესწორებისთვის.
საიდუმლოებები: ექსპორტიორების/აგენტების ნიშნები - საიდუმლო მენეჯერის მეშვეობით.
იზოლაცია: მომხმარებელთა/ტენანტების მეტრიკა - ცალკეულ სივრცეებში/ეტიკეტებში.
მთლიანობა: აგენტის/ბილეთების ხელმოწერა, კონფიგურაცია GitOps- ის მეშვეობით (merge revie).

18) ფინანსები და შესაძლებლობები (FinOps)

კვოტები და ბიუჯეტები; ალერტები არანორმალურ ზრდაზე.
Right-sizing: მოთხოვნების/ლიმიტების ანალიზი, CPU/RAM- ის განკარგვა, არ არის კრიტიკული დავალებების სპოტი.
„Cost per request/tenant“, როგორც KPI ეფექტურობა.

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

მხოლოდ ინფრასტრუქტურული მეტრიკა მომხმარებლის SLI- ს გარეშე.
100 + ალერტა „ყველასთვის“ - სიბრმავე on-call.
ლოგოები, როგორც ერთადერთი წყარო (მეტრიკის და ტრეიზის გარეშე).
მუტაბელური დაშბორდები ვერსიის/review- ის გარეშე.
სინთეზის ნაკლებობა: „ყველაფერი მწვანეა“, მაგრამ ფრონტი მიუწვდომელია.
გამოშვებასთან კავშირი არ არსებობს: თქვენ არ შეგიძლიათ უპასუხოთ „რა შეიცვალა X მომენტში“.

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

0-15 დღე

განსაზღვრეთ SLI/SLO 3-5 ძირითადი მომსახურებისთვის.
ჩართეთ ძირითადი ექსპორტიორები/აგენტები, სტანდარტიზებული JSON ლოგები.
Tier-1 Alerta- ს კონფიგურაცია (availability, 5xx, p95).

16-30 დღე

დაამატეთ სინთეტიკა კრიტიკულ სცენარებზე.
ჩართეთ ბილიკები (OTel) შეყვანის/კრიტიკულ სერვისებში.
დაშბორდები „Per-release“ და error-budget burn წესები.

31-60 დღე

დაფარეთ BD/რიგები/ქეში მოწინავე სიგნალებით.
შემოიღეთ eBPF/პროფილირება მაღალი CPU სერვისებისთვის.
GitOps წესების/დაშბორდების/ალერტებისთვის, რეგულარული ხმაურის გაწმენდა.

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

SLO საკვანძო სერვისების დაფარვა 95% -ს შეადგენს.
MTTA/MTTR (მიზანი: წთ/ათეული წუთი).
Alerta- ს წილი Tier-1, რომელიც დახურულია მანქანის მოქმედებით ან სწრაფი გამოტოვებით.
„სასარგებლო „/“ ხმაურიანი “ალერტების თანაფარდობა> 3:1.
ყველა „ფულადი“ ბილიკის სინთეზის დაფარვა = 100%.

22) პროგრამები: მინი შაბლონები

Prometheus - სტატუს კლასების ხელმისაწვდომობა

yaml
- record: job:http:availability:ratio_rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Grafana - კანარის მინიშნება

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

Alertmanager - მოვალეობა და დუმილი

yaml receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true inhibit_rules:
- source_match: { severity: "critical" }
target_match: { severity: "warning" }
equal: ["service"]

23) დასკვნა

მონიტორინგი არ არის გრაფიკების ერთობლიობა, არამედ SRE ოპერაციული სისტემა: SLI/SLO, როგორც ხარისხის ხელშეკრულება, მეტრიკა/ტრეისი/ლოგები, როგორც ჭეშმარიტების წყაროები, ალერტები, როგორც კონტროლირებადი სიგნალი, სინთეზური, როგორც „მომხმარებლის ხმა“, GitOps, როგორც ცვლილებების დისციპლინა. ააშენეთ ერთი წრე მასპინძელიდან API- მდე, გადაიტანეთ იგი გამოშვებებზე და გამოტოვებაზე - და პლატფორმა იქნება პროგნოზირებადი, სწრაფი და ეკონომიური.