დაკვირვება: ლოგოები, მეტრიკები, ტრეკები

დაკვირვება: ლოგოები, მეტრიკები, ტრეკები

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

• მეტრიკა - კომპაქტური ერთეული SLI/SLO და ალერტინგი სიმპტომების მიხედვით.
• ტრეკები - მიზეზობრივი მოთხოვნის ჯაჭვები (end-to-end).
• Logs არის დეტალური მოვლენები გამოძიებისა და აუდიტის მიზნით.

მიზანი: სწრაფი RCA, პრევენციული ალერტები და კონტროლირებადი საიმედოობა error budget- ის ფარგლებში.

2) არქიტექტურის პრინციპები

ერთი კონტექსტი: ყველგან ვსეირნობთ 'trace _ id', 'spant _ id', 'tenant _ id', 'request _ id', 'user _ agent', 'client _ ip _ hash'.
სტანდარტები: OpenTelemetry (OTel) SDK/აგენტებისთვის, ლოგოების JSON ფორმატი (კანონიკური, სქემით).
სიმპტომები> მიზეზები: ალერტიმი მომხმარებლის სიმპტომების მიხედვით (ლატენტობა/შეცდომები), და არა CPU- ს მიხედვით.
სიგნალის კავშირი: მეტრიკიდან - სპანამდე (ექსპლუატაციაში) - სპეციფიკურ ლოგოებში „trace _ id“.
უსაფრთხოება და კონფიდენციალურობა: PII შენიღბვა ლოგოებში, დაშიფვრა in transit/at rest, უცვლელი აუდიტის ჟურნალები.
მრავალფეროვნება: სახელების/გასაღებების/პოლიტიკის სივრცეების გამიჯვნა.

3) სიგნალებისა და სქემების ტაქსონომია

3. 1 მეტრიკა

RED (Rate, Errors, Duration) მომსახურებისა და USE (Utilization, Saturation, Errors) ინფრასტრუქტურისთვის.
Типы: counter, gauge, histogram/summary. ლატენტობისთვის - histogram ფიქსირებული bucket 'ami.
Exemplars: ბმული 'trace _ id' ჰისტოგრამის „ცხელ“ ბინებში.

name: http_server_duration_seconds labels: {service, route, method, code, tenant}
type: histogram buckets: [0. 01, 0. 025, 0. 05, 0. 1, 0. 25, 0. 5, 1, 2, 5]
exemplar: trace_id

3. 2 ტრეკები

სპანი = ოპერაცია 'name', 'start/end', 'attributes', 'events', 'status'.
W3C Trace Context ტოლერანტობისთვის.
სიმულაცია: ძირითადი (head) + დინამიური (tail) + „მნიშვნელობის“ წესები (შეცდომები, მაღალი p95).

3. 3 ლოგიკა

მხოლოდ სტრუქტურირებული JSON; დონე: DEBUG/INFO/WARN/ERROR.
სავალდებულო ველები: 'ts _ utc', 'level', 'მესიჯი', 'trace _ id', 'spank _ id', 'tenant _ id', 'env', 'service', 'region', 'host', 'labels {'.
აკრძალულია: საიდუმლოებები, ნიშნები, PAN, პაროლები. PII - მხოლოდ ტოკნიზირებული/შენიღბული.

json
{"ts":"2025-10-31T12:05:42. 123Z","level":"ERROR","service":"checkout","env":"prod",
"trace_id":"c03c...","span_id":"9ab1...","tenant_id":"t-42","route":"/pay",
"code":502,"msg":"payment gateway timeout","retry":true}

4) შეკრება და ტრანსპორტი

აგენტები/ექსპორტიორები (daemonset/sidecar) - ბუფერი საბურავების/ინგესტის კვანძზე (TLS/mTLS) სიგნალის საცავი.
მოთხოვნები: უკუკავშირი, რესტავრაცია, დედუპლიკაცია, კარდინალობის შეზღუდვა (labels!), დაცვა „log storms“ - სგან.

მეტრიკი: pull (Prometheus თავსებადი) ან push OTLP- ით.
ტრეკები: OTLP/HTTP (gRPC), tail-samplers კოლექციონერზე.
Logs: ადგილობრივი შეგროვება (journald/docker/stdout) - პარსერი და ნორმალიზატორი.

5) შენახვა და გადაკეთება (tiered)

მეტრიკა: ცხელი TSDB 7-30 დღე (downsample- ით), აგრეგატები უფრო გრძელი ვადით (90-365 დღე).
ტრეკები: 1-7 დღე სავსეა, შემდეგ აგრეგატები/„ მნიშვნელოვანი “სერვისები; შეინახეთ ინდექსები 'სერვისის', 'status', 'error'.
ლოგოები: ცხელი ინდექსი 7-14 დღე, თბილი 3-6 თვე, არქივი 1-7 წლამდე (შესაბამისობა). აუდიტი - WORM.

ხარჯების ოპტიმიზაცია: downsampling, DEBUG ფილტრაცია გაყიდვაში, ეტიკეტის კვოტები, ბილიკების სიმულაცია.

6) SLI/SLO, ალერტინგი და მოვალეობა

SLI: ხელმისაწვდომობა (% წარმატებული მოთხოვნა), ლატენტობა (p95/p99), 5xx წილი, მონაცემთა სიახლე, წარმატებული ჯობების წილი.
SLO: მიზანი SLI- ში (მაგალითად, 99. წარმატებული 9% 400 ms).
Error budget: 0. 1% „შეცდომის უფლება“ არის ფიჩფრიზის/ექსპერიმენტების წესები.

• `ALERT HighLatency` если `p99(http_server_duration_seconds{route="/pay"}) > 1s` 5мин.
• `ALERT ErrorRate` если `rate(http_requests_total{code=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0. 02`.
• Silos Alerty (CPU/Disk) - მხოლოდ როგორც დამხმარე, paging გარეშე.

7) სიგნალების კორელაცია

მეტრიკა "წითელი" კლიშე ექსპროპლარში - კონკრეტული 'trace _ id "ჩვენ ვუყურებთ" ნელი "სპანს და ვხსნით ლოგებს იმავე" trace _ id "მიხედვით.
კორელაცია გამოშვებებთან: 'ვერსიის' ატრიბუტები, 'image _ sha', 'feature _ flag'.
მონაცემებისთვის/ETL: 'dataset _ urn', 'run _ id', კავშირი ხაზთან (იხ. შესაბამისი სტატია).

8) სემპლაცია და კარდინალობა

მეტრიკა: ჩვენ ვზღუდავთ ეტიკეტს ('user _ id', 'session _ id'); კვოტები/შესაბამისობა რეგისტრაციაში.
ტრეკები: შევაერთოთ head-sample (შესასვლელში) და tail-sample (კოლექციონერზე) წესებით: „ყველაფერი, რაც 5xx, p99, შეცდომები - 100%“.
ლოგიკა: დონე და დაშლა; ხშირი განმეორებითი შეცდომებისთვის - საერთო მოვლენები (dedupe გასაღები).

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_code: ERROR rate_allocation: 1. 0
- type: latency threshold_ms: 900 rate_allocation: 1. 0
- type: probabilistic hash_seed: 42 sampling_percentage: 10

9) უსაფრთხოება და კონფიდენციალურობა

Transit/At Rest: დაშიფვრა (TLS 1. 3, AEAD, KMS/HSM).
PII/საიდუმლოებები: გაგზავნამდე მედესანტეები, ტოკენიზაცია, შენიღბვა.
წვდომა: ABAC/RBAC კითხვისთვის; როლების გამიჯვნა producers/readers/admins.
აუდიტი: ლოგოების/ტრეკების დაშვების უცვლელი ჟურნალი; ექსპორტი - დაშიფრული ფორმით.
მრავალფეროვნება: namespaces/tenant-labels პოლიტიკოსებთან; დაშიფვრის გასაღებების იზოლაცია.

10) კონფიგურაციის პროფილები (ფრაგმენტები)

yaml global: { scrape_interval: 15s, evaluation_interval: 30s }
scrape_configs:
- job_name: 'app'
static_configs: [{ targets: ['app-1:8080','app-2:8080'] }]
rule_files: ['slo. rules. yaml']

yaml groups:
- name: http_slo rules:
- record: job:http_request_duration_seconds:p99 expr: histogram_quantile(0. 99, sum(rate(http_server_duration_seconds_bucket[5m])) by (le,route))
- alert: HighLatencyP99 expr: job:http_request_duration_seconds:p99{route="/pay"} > 1 for: 5m

python provider = TracerProvider(resource=Resource. create({"service. name":"checkout","service. version":"1. 8. 3"}))
provider. add_span_processor(BatchSpanProcessor(OTLPExporter(endpoint="otel-collector:4317")))
set_tracer_provider(provider)
with tracer. start_as_current_span("pay", attributes={"route":"/pay","tenant":"t-42"}):
business logic pass

python log. info("gw_timeout", extra={"route":"/pay","code":502,"trace_id":get_trace_id()})

11) მონაცემები/ETL და ნაკადი

SLI მონაცემებისთვის: სიახლე (max lag), სისრულე (rows vs expectation), „ხარისხი“ (შემსრულებლები/დუპლიკატები).
ალერტები: ფანჯრის გამოტოვება, კონსუმერის ლაგი, DLQ ზრდა.
კორელაცია: 'run _ id', 'dataset _ urn', ხაზის მოვლენები; კვალი plines (span batch/partition).
Kafka/NATS: მეტრიკის მწარმოებელი/კონსუმერი, lag/უარყოფა; headers ტრეკები (მათ შორის 'traceparent').

12) პროფილირება და eBPF (დამატებითი სიგნალი)

დაბალი დონის ცხელი გზები CPU/alloc/IO; პროფილები ინციდენტისთვის.
eBPF ტელემეტრია (ქსელის შეფერხებები, DNS, სისტემური გამოწვევები) 'trace _ id '/PID მითითებით.

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

სიგნალის ხელშეკრულება: მეტრული/ეტიკეტის/ჰისტოგრამების ექსპორტის შემოწმება CI- ში.
სინთეზური პარამეტრები: RUM/სიმულაციური მომხმარებლები გარე SLI- სთვის.
Chaos/Fire drills: დამოკიდებულების გამორთვა, დეგრადაცია - ჩვენ ვხედავთ, თუ როგორ რეაგირებენ ალერტები და მოვალეობები.
Smoke გაყიდვაში: პოსტ-დამატებითი შემოწმება, რომ ახალ endpoints- ს აქვს მეტრიკა და ტრეკები.

14) მოცულობის ღირებულება და კონტროლი

ბიუჯეტები სიგნალზე/გუნდში; deschboard „cost per signal“.
ბიუჯეტის კარდინალობა (SLO cardinality), ახალი ეტიკეტის ლიმიტები.
Downsampling, მონაცემთა კლასების რეცენზიები, „ცივი“ არქივები და WORM აუდიტი.

15) სადამკვირვებლო პლატფორმის ოპერაცია და SLO

SLO პლატფორმა: 99. წარმატებული ინგესტების 9%; შეფერხება მეტრიკის ინდექსამდე 30 წმ, ლოგოები - 2 წუთი, ბილიკები - 1 წთ.
პლატფორმის ალერტები: ინჟესტის ლაქი, ფრჩხილების ზრდა, ხელმოწერის/დაშიფვრის შეცდომა, ბუფერების გადინება.
DR/HA: მრავალმხრივი, რეპლიკაცია, კონფიგურაციის/წესების სარეზერვო ასლები.

16) ჩეკის ფურცლები

• ყველგან არის გადაყრილი 'trace _ id '/' span _ id'; JSON ლოგები სქემით.
• RED/USE მეტრი ჰისტოგრამებით; ექსპლარის ბილიკი.
• Tail-sampling შედის; წესები 5xx/p99 = 100%.
• ალერტები სიმპტომების მიხედვით + რუნიბუკი; მშვიდი საათი/anti-flap.
• მედდა PII; დაშიფვრა at rest/in transit; WORM აუდიტისთვის.
• რეტენციები და ბიუჯეტები მოცულობის/კარდინალობისთვის.

• ალერტების ყოველთვიური მიმოხილვა (ხმაური/სიზუსტე), ბარიერების tuning.
• მოხსენება error budget- ის შესახებ და მიღებული ზომები (ფიჩფრიზი, ჰარდენინგი).
• კრიტიკული ბილიკებისთვის დაშბორდის/ლოგოების/მარშრუტების დაფარვის შემოწმება.
• სასწავლო ინციდენტები და runbook- ის განახლება.

17) Runbook’и

RCA: ზრდა p99/ანაზღაურება

1. გახსენით RED dashbourd 'checkout'.
2. ექსპლარის გასწვრივ გადასვლა - ნელი ბილიკი - „ვიწრო სპანის“ იდენტიფიცირება (მაგ., 'gateway. call`).
3. 'trace _ id' - ის ლოგოების გახსნა.
4. ჩართეთ უკან დაბრუნების დროშა/RPS ლიმიტი, აცნობეთ დამოკიდებულების მფლობელებს.
5. სტაბილიზაციის შემდეგ - RCA, ოპტიმიზაციის თიკეტები, რეპროდუქციის ტესტი.

1. SLI „ახალი“ წითელი ჯობის გზატკეცილი არის სწრაფი ნაბიჯი.

2. შეამოწმეთ ბროკერის/DLQ, კონექტორის შეცდომები.

3. დაიწყეთ reprocess, აცნობეთ მომხმარებლებს (BI/პროდუქტი) სტატუს არხის საშუალებით.

18) ხშირი შეცდომები

ლოგოები სქემის გარეშე და 'trace _ id' გარეშე. გამოძიება რამდენჯერმე გადაიდო.
ინფრასტრუქტურის ალერტები სიმპტომების ნაცვლად. Paging მიდის „რძეში“.
მეტრიკის შეუზღუდავი კარდინალობა. ხარჯების აფეთქება და არასტაბილურობა.
ყველა მარშრუტი 100%. ძვირია და არ არის საჭირო; ჩართეთ ჭკვიანი ნიმუშები.
PII/საიდუმლოებები ლოგებში. ჩართეთ ექთნები და „წითელი სიები“.
„მუნჯი“ ფიჩები. ახალი კოდი მეტრიკის/ტრასების/ლოგოების გარეშე.

19) FAQ

გ: უნდა შევინარჩუნოთ ნედლეულის ტექსტი?
ო: დიახ, მაგრამ რეტენციით და არქივებით; ალერტებისა და SLO- სთვის საკმარისია აგრეგატები. აუდიტი - WORM- ში.

გ: რა უნდა აირჩიოთ ტრასებისთვის - head ან tail sampling?
O: კომბინაცია: head-probabilistic + tail-rules ძირითადი დაფარვისთვის შეცდომებისა და ანომალიებისთვის.

გ: როგორ დააკავშიროთ მომხმარებლის მეტრიკა და ტექნიკური?
O: ზოგადი 'trace _ id' და ბიზნეს ეტიკეტების საშუალებით ('მარშრუტი', 'tenant', 'plan'), ასევე პროდუქტის (კონვერტაციის) მოვლენების საშუალებით ტრასების კორელაციასთან.

გ: როგორ არ დაიხრჩო ალერტებში?
O: სიმპტომების ბიტი, შემოიტანეთ მშვიდი საათი, დედაპლაცია, ჯგუფი, SLO პრიორიტეტი და ნაგულისხმევი მფლობელი თითოეული ალერტისთვის.

• „აუდიტი და უცვლელი ჟურნალები“
• „დაშიფვრა In Transit/At Rest“
• საიდუმლო მენეჯმენტი
• „მონაცემთა წარმოშობა (Lineage)“
• «Privacy by Design (GDPR)»
• „ვებ ჰუკების მიწოდების გარანტიები“