დაკვირვების დასტის

1) რატომ გვჭირდება დაკვირვება

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

მეთოდოლოგია: Golden Signals (latency/traffic/errors/saturation), RED, USE.

2) დასტის ძირითადი არქიტექტურა

კომპონენტები ფენებში

შეკრება/აგენტები: Exporters, Promtail/Fluent Bit, OTel SDK/Auto-Instr, Blackbox-probes.
Шина/ingest: Prometheus remote_write → Mimir/Thanos, Loki distributors/ingesters, Tempo/Jaeger ingesters.
საცავი: ობიექტის S3/GCS/MinIO (გრძელი სიცივე), SSD (ცხელი რიგები).
მოთხოვნები/ვიზუალიზაცია: Grafana (პანელები, SLO ვიჯეტები), Kibana (თუ ELK).
მენეჯმენტი: Alertmanager/Graphana Alerta, სერვისული კატალოგი, RBAC, საიდუმლო მენეჯერი.

განლაგების ნიმუშები

მენეჯმენტი (Grafana Cloud/ღრუბლოვანი მომსახურება) - სწრაფად და უფრო ძვირი მოცულობებით.
K8s Self-hosted არის სრული კონტროლი, საჭიროა ოპერაცია და FinOps.

3) მონაცემთა სტანდარტები: ერთიანი „დაკვირვების სქემა“

3. 1 მეტრიკა (Prometheus/OpenMetrics)

სავალდებულო ეტიკეტები: 'env', 'region', 'cluster', 'namespace', 'service', 'version', 'tenant' (თუ მულტფილმი-ტენანტი), 'endpoint'.
სახელწოდება: „snake _ case“, სუფიქსები '_ total', '_ seconds', '_ bytes'.
ჰისტოგრამა: ფიქსირებული 'buckets' (SLO ორიენტირებული).
კარდინალობა: ეტიკეტებში არ შედის 'user _ id', 'request _ id'.

3. 2 ლოგიკა

ფორმატი: JSON; სავალდებულო ველები 'ts', 'level', 'service', 'env', 'trace _ id', 'span _ id', 'msg'.
PII: შენიღბვა აგენტზე (PAN, ნიშნები, ელექტრონული ფოსტა და ა.შ.).
ლოკის ეტიკეტები: მხოლოდ დაბალი კარდინალობა ('app', 'namespace', 'elel', 'tenant').

3. 3 მარშრუტი

OTel სემანტიკა: 'მომსახურება. name`, `deployment. environment`, `db. system`, `http.`.
Sampling: სამიზნე მარშრუტები p99 - 'always _ on '/tail-sampling, დანარჩენი -' parent/ratio '.
ID ინტეგრაცია: გადაიტანეთ 'trace _ id/span _ id "ლოგებსა და მეტრიკებში (labels/fields).

4) კორელაცია M-L-T (Metrics/Logs/Traces)

ალერტის (მეტრიკის) გრაფიკიდან, ფილტრირებული logs 'trace _ id' - კონკრეტული ბილიკი.
გზატკეცილიდან (ნელი სპანი) არის კონკრეტული ზურგჩანთა მეტრის მოთხოვნა სპანის ინტერვალზე.
Drilldown ღილაკები პანელებში: „ლოგებისთვის“ და „ბილიკებამდე“ ცვლადი ცვლილებით ('env', 'service', 'trace _ id').

5) OpenTelemetry Collector: მინიშნება

yaml receivers:
otlp:
protocols: { http: {}, grpc: {} }
prometheus:
config:
scrape_configs:
- job_name: kube-nodes static_configs: [{ targets: ['kubelet:9100'] }]

processors:
batch: {}
memory_limiter: { check_interval: 1s, limit_mib: 512 }
attributes:
actions:
- key: deployment. environment value: ${ENV}
action: insert tail_sampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code: { status_codes: [ERROR] }
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/payments","/login"] }
- name: probabilistic type: probabilistic probabilistic: { sampling_percentage: 10 }

exporters:
otlphttp/mimir: { endpoint: "https://mimir/api/v1/push" }
otlphttp/tempo: { endpoint: "https://tempo/api/traces" }
loki:
endpoint: https://loki/loki/api/v1/push labels:
attributes:
env: "deployment. environment"
service: "service. name"

service:
pipelines:
metrics: { receivers: [prometheus, otlp], processors: [memory_limiter, batch], exporters: [otlphttp/mimir] }
logs:   { receivers: [otlp], processors: [batch], exporters: [loki] }
traces:  { receivers: [otlp], processors: [memory_limiter, attributes, tail_sampling, batch], exporters: [otlphttp/tempo] }

6) ალერტინგი: SLO და multi-burn

იდეა: ალერტიმი არა „CPU> 80%“ დონეზე, არამედ Error Budget მოხმარებაზე.

PromQL შაბლონები:

promql
5-minute error rate err_ratio_5m =
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m]))

Quick burn (1m window)
(err_ratio_1m / (1 - SLO)) > 14. 4

Slow burn (30m)
(err_ratio_30m / (1 - SLO)) > 2

ლატენტობა (ჰისტოგრამა):

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

7) დაშბორდი: საქაღალდეების სტრუქტურა

00 _ Overview - პლატფორმა: SLO, p95, 5xx%, capacity, აქტიური ინციდენტები.
10 _ სერვისები - სერვისებზე: RPS, p95/p99, შეცდომები, გამოშვებები (ვიდეოები).
20 _ Infra - K8s/nods/storight/ქსელი, etcd, კონტროლერები.
30_DB/Queues — PostgreSQL/Redis/Kafka/RabbitMQ.
40 _ Edge/DNS/CDN/WAF - ingress, LB, WAF წესები.
50 _ სინთეტიკური - აფთიაქი და headless სცენარები.
60 _ Cost/FinOps - შენახვა, მოთხოვნები, ცხელი/ცივი, პროგნოზი.

თითოეული პანელი: აღწერა, ერთეული, მფლობელი, runbook ბმული, drilldown.

8) ლოგები: LogQL პრაქტიკული

logql
API errors
{app="api", level="error"}     = "Exception"

Nginx 5xx in 5 minutes
{app="nginx"}      json      status=~"5.."      count_over_time([5m])

Extract Fields
{app="payments"}      json      code!=""      unwrap duration      avg()

9) ტრასები: TraceQL და ხრიკები

იპოვნეთ ყველაზე ნელი სპანები:


{ service. name = "api" }      duration > 500ms

სენდვიჩი „ნელი SQL ნელი თხოვნით“:


{ name = "HTTP GET /order" }      child. span. name = "SELECT" & child. duration > 50ms

10) სინთეზური და აფთიაქი

Blackbox-exporter: HTTP/TCP/TLS/DNS ტესტები 3 რეგიონიდან/ASN.
Headless: login/deposit გრაფიკული სცენარები.
É rum-alerta: სამუშაო, თუ 2 რეგიონს უარი ეთქვა.
სტატუსის გვერდი: ავტომატური აპდეიტები + სახელმძღვანელო კომენტარები.

11) შენახვა და ჭრა

მეტრიკა: ცხელი 7-30 დღე (სწრაფი რიგები), downsampling/რეკორდული რულეტები, ცივი - ობიექტის საცავი (თვეები).
ლოგოები: ცხელი 3-7 დღე, შემდეგ - S3/GCS ინდექსით (Loki chunk store/ELK ILM).
მარშრუტები: 3-7 დღე 'always _ on' + გრძელი შენახვა ნიმუშებისთვის (tail-sampled/შერჩევა).

რეკომენდაციები:

როლოვერი ზომით და დროით; ბიუჯეტი მოთხოვნებისთვის (კვოტები/ლიმიტები).
ცალკეული პოლიტიკოსები Stage/stage და უსაფრთხოების მონაცემებისთვის.

12) მულტფილმები და წვდომა

გაყოფილი 'tenant '/' namespace '/Spaces, ინდექსის ნიმუშები და ნებართვები.
დააგემოვნეთ რესურსები ბილინგისთვის: 'tenant', 'service', 'team'.
იმპორტირებული დაშბორდები/ალერტები კონკრეტული გუნდების სივრცეებშია.

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

TLS/mTLS აგენტებიდან ბეკენდებამდე, HMAC პირადი ჯანმრთელობისთვის.
RBAC კითხვაზე/ჩაწერაზე, ყველა მოთხოვნისა და ალერტის აუდიტზე.
PII გამოცემა ზღვარზე; საიდუმლოების აკრძალვა ლოგებში; DSAR/Legal Hold.
იზოლაცია: ინდივიდუალური მტევანი/ნეიმსპასი მგრძნობიარე დომენებისთვის.

14) FinOps: დაკვირვების ღირებულება

ჩვენ ვამცირებთ ეტიკეტების კარდინალობას და ლოგიკას ingest- ში (და არა მოთხოვნით).
Sampling trass + სამიზნე always-on კრიტიკული გზებისთვის.
Downsampling/recording rules მძიმე დანაყოფებისთვის.
ცივ ობიექტში იშვიათი წვდომის არქივი.
Метрики: `storage_cost_gb_day`, `query_cost_hour`, `cost_per_rps`, `cost_per_9`.

15) CI/CD და სადამკვირვებლო ტესტები

Linting metric/logs CI- ში: კარდინალების „აფეთქების“ აკრძალვა, ჰისტოგრამების/ერთეულების შემოწმება.
სადამკვირვებლო ტესტები: სავალდებულო მეტრიკა/ლოგოების ველები, „trace _ id“ middleware- ში.
არხი: გამოშვების სურათები გრაფიკებზე, SLO-auto-rollback.

16) მაგალითები: სწრაფი თხოვნა

შეცდომების ტოპ ენდოინები:

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

CPU throttling:

promql sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m])) > 0

Kafka lag:

promql max by (topic, group) (kafka_consumergroup_lag)

ლოგოებიდან ტრეკებამდე (Loki-Tempo): გადასცეს 'trace _ id "როგორც link Tempo UI/deshboard- ზე.

17) დასტის ხარისხი: ჩეკის სია

მეტრული/ლოგოების/ტრასების და გაზომვის ერთეულების შეთანხმებული სქემები.
'trace _ id' ლოგოებში და მეტრიკებში, პანელებისგან drilldown.
Multi-burn SLO-Alerta flapping (-- rum/multi-window).
Downsampling, მოთხოვნის კვოტები, ნაბიჯი/დიაპაზონი.
Retenschne და შენახვის კლასები დოკუმენტირებულია და გამოიყენება.
RBAC/აუდიტი/PII გამოცემა შედის.
Dashboards: მფლობელი, runbooks, 2-3 ეკრანზე, სწრაფი პასუხი.
FinOps Dashboard (მოცულობა, ღირებულება, ტოპ-მოლაპარაკებები).

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

1. MVP (2 კვირა): Prometheus - Mimir, Loki, Tempo; OTel Collector; ძირითადი დაშბორდები და SLO ალერტები; blackbox ტესტები.
2. Scale (3-4 კვირა): tail-sampling, downsampling, ingest მულტფილმის რეგიონი, RBAC/Spaces, FinOps Dashboards.
3. Pro (4 + კვირა): SLO auto-rollback, საკვანძო ბილიკების headless სინთეზური, Legal Hold, SLO პორტფელი და ანგარიშგებები.

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

„ლამაზი გრაფიკები SLO- ს გარეშე“ არ არის მოქმედება, არ არსებობს სარგებელი.
მაღალი კარდინალური ეტიკეტები ('user _ id', 'request _ id') - მეხსიერების და ღირებულების აფეთქება.
Logs JSON გარეშე და 'trace _ id' გარეშე არ არის კორელაცია.
რესურსების ალერტები სიმპტომების ნაცვლად არის ხმაური და წვიმა.
ჭარბი პოლიტიკის არარსებობა ხარჯების უკონტროლო ზრდაა.

20) მინი-FAQ

რა უნდა აირჩიოს: Loki ან ELK?
ELK რთული ძებნისთვის/ფასეტებისთვის; Loki არის იაფი და სწრაფი მსგავსი სცენარებისთვის. ხშირად გამოიყენება ჰიბრიდი.

ყველას სჭირდება ბილიკი?
დიახ, მინიმუმ საკვანძო გზებზე (login, checkout, payments) tail-sampling - ეს მკვეთრად აჩქარებს RCA- ს.

როგორ დავიწყოთ ნულიდან?
OTel Collector - Mimir/Loki/Tempo - ძირითადი SLO და blackbox ტესტები, შემდეგ dashbords და burn alert.

შედეგი

სადამკვირვებლო დასტის არ არის განსხვავებული ინსტრუმენტების ერთობლიობა, არამედ შეთანხმებული სისტემა: მონაცემთა ერთიანი სტანდარტები - M-L-T, SLO ალერტინგი და სინთეზური უსაფრთხოება და FinOps კორელაცია. დააფიქსირეთ სქემები, ეტიკეტის დისციპლინა და ჭუჭყიანი, დააკავშირეთ OTel, დაამატეთ drilldown და auto-rollback - და მიიღებთ კონტროლირებად საიმედოობას გასაგები ღირებულებით.

დაკვირვების დასტის

განლაგების ნიმუშები

შედეგი

დაგვიკავშირდით

სწრაფი კავშირი

ვიდეო მალე განახლდება

ჩვენ ახლა ძალიან დაკავებული ვართ პროექტებით