სააფთიაქო და heartbeat მონიტორინგი

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

პერიმეტრზე და შიგნით სტაგნაციების ადრეული გამოვლენა (edge-core).
მომხმარებლის ხელმისაწვდომობის დადასტურება (და არა მხოლოდ „ცოცხალია პოდები“).
SLA/SLO ხელშეკრულების ანგარიში და იურიდიული ვალდებულებები.
ფონის პროცესების კონტროლი (cron, ETL, გადახდის სისხლჩაქცევები) heartbeat- ის საშუალებით.

მეთოდოლოგია: Golden Signals (latence/traffic/errors/saturation), RED, SLO კავშირი და მცდარი ბიუჯეტი.

2) ინსპექტირების ტიპები (სინთეტიკა)

ICMP: საბაზო ბადურა/IP წვდომა.
TCP: პორტი ცოცხალია/handshake (მაგალითად, 443/5432).
TLS: შესაბამისობა/ვადა/სერთიფიკატების ჯაჭვი.
HTTP (S): პასუხის კოდი, ლატენცია, სათაურები, ძირითადი ქვესადგურები ბოდიში.
DNS: საჭრელი, TTL, NXDOMAIN/SERVFAIL.
Headless ბრაუზერი (მომხმარებლის გზა): login - მოქმედება logout.
Custom probes: გადახდის ავტორიზაცია sandbox PSP- ში, შიდა ბიზნეს სინთეზში (deposit simulation).

რჩევები: შეამოწმეთ როგორც edge, ასევე პირადი endpoints (შიგნიდან VPC/K8s) - ეს არის სხვადასხვა რისკის დომენები.

3) სააფთიაქო მონიტორინგის არქიტექტურა

რეგიონების საცდელი აგენტები (მინიმუმ 3 გეო წერტილი).
Blackbox ექსპორტიორი HTTP/TCP/TLS/DNS.
სინთეზური ბილიკების გასწვრივ (sequential steps) ცალკე; შეინახეთ სკრიპტები.
Prometheus/Mimir/Thanos: მეტრიკის შეგროვება, SLO/alerts წესი.
Alertmanager/Pager: მარშრუტი P1/P2, ესკალაცია.
Status Page: გამჭვირვალე განახლება ბიზნესისთვის/მომხმარებლებისთვის.
ლოგები/მარშრუტები: drilldown 'trace _ id '/კორელაცია.

4) Health endpoints: დიზაინი

/ healthz (liveness) - „პროცესი ცოცხალია“.
/ readyz (რეალობა) - „მზად არის მიიღოს ტრაფიკი“ (დამოკიდებულია რეიდებთან).
/ startupz - „გაიარა ინიციალიზაცია“.
/ ჩეკი - გაფართოებული ბიზნეს ჯანმრთელობის (მსუბუქი შემოწმება BD/ქეში ტაიმაუტით და ცირკუიტ-ბრეიკერით).
Semantic health: კოდი 200 მხოლოდ კრიტიკული დამოკიდებულებების შესრულებით; დეგრადაცია - 503.

წესები: ტაიმუთი 2-3s, შეზღუდული შემოწმება, პასუხებში PII- ის გარეშე, მძიმე ნაწილების ქეშირება.

5) Heartbeat ჯობებისა და ვორკერებისთვის

Dead Man's Switch მოდელი: თუ „თიკი“ დროულად არ მოსულა - ალერტი.
გამოყენება: cron/ETL/invois Jobe, off-chain გადახდის შემოწმება, ფონის ვორკერები.

• Push-heartbeat HTTP: ჯობა ბოლოს აკეთებს 'POST/heartbeat/< job>'.
• Metrics-pull: გამოფენილი 'last _ success _ timestamp' და ალერტიტი „N წუთზე უფროსი“.
• Watchdog: მუდმივი სიგნალი აგენტისგან; დაიკარგა - ალერტი „მონიტორინგის კლდე“.

6) კონფიგურაციის მაგალითები

6. 1 Blackbox-exporter (HTTP + TLS + DNS)

yaml modules:
http_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"
fail_if_not_ssl: true valid_http_versions: ["HTTP/1. 1","HTTP/2"]
tls_config:
insecure_skip_verify: false headers:
User-Agent: "uptime-probe"
body: ""
ip_protocol_fallback: false

tls_cert:
prober: tcp tcp:
query_response: []
tls: true tls_config:
insecure_skip_verify: false

dns:
prober: dns dns:
query_name: "api. example. com"
valid_rcodes: ["NOERROR"]
preferred_ip_protocol: "ip4"

6. 2 Prometheus: targets და joba

yaml scrape_configs:
- job_name: 'blackbox-http'
metrics_path: /probe params:
module: [http_2xx]
static_configs:
- targets:
- https://api. example. com/healthz
- https://pay. example. com/readyz relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- target_label: __address__
replacement: blackbox-exporter:9115
- source_labels: [__param_target]
target_label: instance

6. 3 Heartbeat მეტრიკა ჯობისთვის (Prometheus exporter)

job_last_success_timestamp_seconds{job="settlement"} 1. 730000e+09

promql
(time() - job_last_success_timestamp_seconds{job="settlement"}) > 900

6. 4 Watchdog (Dead Man’s Switch)

Alertmanager- ში ჩართეთ მარშრუტი ალერტისთვის 'Watchdog' (ყოველთვის firing), თუ შეტყობინება არ მოდის, მონიტორინგი გატეხილია.

7) PromQL მაგალითები აფთიაქისთვის

promql probe_success{job="blackbox-http"} == 1

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

promql
(min_over_time(probe_ssl_earliest_cert_expiry[5m]) - time()) < 7243600

promql rate(probe_dns_rcode{rcode!="NOERROR"}[5m]) > 0

promql sum_over_time((probe_success==1)[28d]) / (28246060)

8) ალერტინგი: ბარიერები და ანტი-ხმაური

Multi-region èrum: ის მუშაობს იმ შემთხვევაში, თუ 2 რეგიონს დაეცემა.
მრავალფუნქციური ფანჯარა: 1-5 წუთი (სწრაფი არხი) + 30-60 წუთი (სტაბილური ტენდენცია).
მგრძნობელობა: debounce/for: 2-5 წუთი ფუფუნების წინააღმდეგ.
კორელაცია: დააკავშირეთ სააფთიაქო ალერტი მეტრის ლეიერთან (edge, DNS, WAF, Origin).
Maintenance windows: ალერტების ჩახშობა 'maintenance = true'.

promql
≥2 regions simultaneously failed sum by (target) (max_over_time (probe _ success = = 0) [3m]))> = 2

9) მრავალი რეგიონალური და მრავალი მოვაჭრე შემოწმება

მინიმუმ 3 გეოგრაფია (EU/NA/APAC) და სხვადასხვა ASN.
გამოაქვეყნეთ: საკუთარი ნიმუშები + გარე აფთიაქის პროვაიდერი.
IPv4/IPv6, HTTP/2/3, სხვადასხვა CDN ROR და WAF პროფილები.

10) შემოწმების უსაფრთხოება

Allowlist IP ნიმუშების დიაპაზონი WAF/LB.
Rate-limits და capcha baipas indpoints health/ნიმუშებისთვის.
სათაურების ხელმოწერა (HMAC) პირადი ჯანმრთელობისთვის.
ცალკეული დომენები: საჯარო ნიმუშები და პირადი (/internal/health).
არ დააბრუნოთ შიდა ვერსიები/კონფისკაცია/healthz; მხოლოდ სტატუსები.

11) SLO და აფთიაქის ანგარიში

SLI Availability: წარმატებული HTTP ნიმუშების წილი 2xx/3xx.
SLO მაგალითი: 99 ევრო. რეგიონების უმეტეს ნაწილში 28 დღის განმავლობაში 95%.
არასწორი ბიუჯეტი: '1 − SLO' მართავს გამოშვებებს.
Burn-rate ალერტები: სწრაფი/ნელი არხი ნიმუშების წარუმატებლობის წილისთვის.

12) Heartbeat გადახდის და კრიტიკული ჯობებისთვის

ჯობა „ფულის გარშემო“ (ტრანსფერები, რეესტრები) - ორმაგი კონტროლი: heartbeat + ბიზნეს მრიცხველები (რამდენი ჩანაწერი დამუშავებულია).
ალერტები „სიჩუმეში“ (არ არსებობს ახალი მოვლენები> N წუთი) და ლაგში (რეალურ დროში ჩამორჩენა).

13) სტატუსის გვერდები

გამოყავით კომპონენტები (API, გადახდები, ზურგჩანთები, CDN).
ავტომატური აფდეიტები ალერტებისგან, სახელმძღვანელო კომენტარები Comms როლის საშუალებით.
ინციდენტების ისტორია, პოსტმოდერნული ბმულები, დაგეგმილი სამუშაოები.

14) ინციდენტის პროცესთან ინტეგრაცია

Alert SEV წესების შესაბამისად, rum + ხანგრძლივობა.
ინციდენტის ბარათის ავტო შექმნა, ომის ოთახი, IC- ის დანიშვნა.
კომუნიკაციის შაბლონები (შიდა/გარე), იურიდიული ჰოლდი, საჭიროების შემთხვევაში.
პოსტების გადამოწმება: მწვანე სინთეტიკა X წუთამდე Resolved- მდე.

15) პროდუქტიულობა და ღირებულება

ნიმუშების სიხშირე: კრიტიკული - თითოეული 30-60s; მეორადი - 1-5 წთ

შენახვა: გრძელი ფანჯრებისთვის downsampling/recording rules.
გარე პროვაიდერების ბიუჯეტი: შეზღუდეთ მოწინავე ბრაუზერის გრაფიკის სცენარები.

16) ხარისხის შემოწმება

• არსებობს/healthz ,/readyz ,/startupz მკაფიო სემანტიკით.
• ნიმუშები 3 რეგიონიდან/ASN, IPv4/IPv6.
• TLS/DNS შემოწმებები და ალერტები T-30/T-7/T-1 დღე.
• Heartbeat ყველა კრიტიკული ჯობი (და ბიზნეს „დუმილი“).
• Multi-window + èrum, flapping გარეშე.
• Drilldown: ღილაკები ლოგებზე/ტრასებზე/დაშბორდებზე.
• სტატუსის გვერდი და კომუნიკაციის შაბლონები.
• SLO/მეტრიკის და მფლობელების დოკუმენტაცია.

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

1. კვირა 1: blackbox ტესტები HTTP/TLS/DNS კრიტიკულ დომენებში, სტატუსის გვერდი, ძირითადი ალერტები.
2. კვირა 2: მრავალი რეგიონულობა, èrum წესები, heartbeat ტოპ-ჯობი, Watchdog.
3. კვირა 3: headless სცენარები (login/deposit), SLO ანგარიშები, ინციდენტის პროცესთან ინტეგრაცია.

18) მინი-FAQ

რა არის უკეთესი, ვიდრე გარე ნიმუშები, ვიდრე შინაგანი?
გარე ხედავს მომხმარებლის რეალურ გზას (DNS/CDN/WAF), შიდა - ორიგინის მდგომარეობა. ორივე საჭიროა.

აუცილებელია ფასიანი PSP- ების შემოწმება?
დიახ: სინთეზური sandbox და სტატუსის გვერდების მონიტორინგი; დეგრადაციის დროს - ავტომატური smart-routing.

როგორ შევამციროთ ხმაური?
Érum, multi window, შეფერხება, მხარდაჭერა maintenance, მკაფიო SLO ბარიერები და საკუთრება.

შედეგი

სააფთიაქო მონიტორინგი არ არის მხოლოდ პინგი. ეს არის სისტემა: მრავალი რეგიონალური სინთეტიკა + მაღალი ხარისხის health endpoints + heartbeat job + SLO/Alerting + სტატუს გვერდები. სტანდარტიზებული შემოწმებები, შეამცირეთ ხმაური, დაიცავით ნიმუშები და დააკავშირეთ ყველაფერი ინციდენტის პროცესთან - ასე რომ თქვენ შეამცირებთ MTTR- ს და შეინარჩუნებთ არასწორ ბიუჯეტს.