სიგნალების განაწილება და მეტრიკა

(განყოფილება: ეკოსისტემა და ქსელი)

1) მიზანი და რეგიონი

• ტელემეტრიული ერთიანი ენა და მონაცემთა კონტრაქტები.
• კონტროლირებადი QoS არხები: კრიტიკული სიგნალების პრიორიტეტი.
• გამჭვირვალე SLI/SLO და პროგნოზირებადი ალერტინგი.
• მეტრიკის კონფიდენციალურობა, იზოლაცია და დაზოგვა.

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

1. ბიზნეს ღონისძიებები: ონბორდი, ანაბრები/გადახდები, სათამაშო ღონისძიებები, ატრიბუტი.
2. მეტრიკა: latency/throughput/შეცდომის კოდი, ხაზი, CPU/RAM/IO გამოყენება.
3. ლოგიკა: სტრუქტურირებული ჩანაწერები ოპერაციებისა და შეცდომების შესახებ.
4. ტრეკები: მოთხოვნის/ტოპიკის სპანები, ჰოპის კორელაცია.
5. ჯანმრთელობის სტატუსი: სინთეზური პრობლემები, რეციდივი/ცხოვრება, heartbeat კვანძები.
6. რისკის/შესაბამისობის სიგნალები: KYC/KYB/AML ჰიტები, სანქციების მოვლენები.

თითოეულ კლასს აქვს საკუთარი კრიტიკული დონე და შენახვის/მიწოდების პოლიტიკა.

3) განაწილების არქიტექტურა (რეფერენდუმი)

Edge კოლექციონერები (SDK/აგენტები) - Ingress (HTTP/OTLP/gRPC/QUIC) - Shina (Kafka/Pulsar) - Stream-jobs (TSDB B OOOOB- ისთვის, ობიექტებისთვის, ობიექტი/სვეტი - ლოგებისთვის/მოვლენებისთვის, ტრეკერი) - ვიტრინი/დაშბორდი/ალერტა.
მულტფილმი-ტენანტობა: namespace/tenant-id კლავიშებში, ცალკეული @ ta/limits/ACL.
QoS სეგმენტი: კრიტიკული (P0), მნიშვნელოვანი (P1), ფონი (P2).
Egress: აბონენტები (Ops/BI/Third-party) ტოპებისა და materialized views- ის გამოწერის გზით.

4) კონტრაქტები და სქემები (მოვლენები/მეტრიკა/ტრეისი)

4. 1 მოვლენები (გამარტივებული, YAML)

yaml event:
id: uuid kind: business    ops    risk ts: timestamp    # ISO8601 tenant: string    # org_id/namespace source: string    # service/peer-id trace_id: string type: string     # deposit. created    payout. failed    probe. ok...
attrs: object # semantic fields (no PII)
severity: info    warn    error    critical qos: P0    P1    P2

4. 2 მეტრიკა (OpenMetrics/OTLP)

Gauge/Counter/Histogram სტაბილური ეტიკეტებით (შეზღუდული კარდინალობა).
იდენტიფიკატორები: „metric _ name {სერვისი, რეგულირება, მენანტი, ვერსია, მარშრუტი“.
ჰისტოგრამა ლატენტობისთვის/ზომისთვის, კოდი p99-ის ნაცვლად.

4. 3 ტრეისი

სავალდებულო ველები: 'trace _ id', 'spank _ id', 'parent _ id', 'service', 'peer', 'route', 'qos'.
ლინკები დომენებს შორის (consumer/producer) და ქსელის ჰოპებს შორის (relay/bridge).

5) QoS და პრიორიტეტიზაცია

P0 (კრიტიკულად): SLI გადახდა/გადახდა, ხიდების/კვანძების სტატუსები, burn-rate SLO - მკაცრი მიწოდება (acks, retries, imempotence), მინიმალური ტაიმაუტები.
P1 (მნიშვნელოვანია): პროდუქტის მოვლენები/ძირითადი მეტრიკა, გარანტირებული მიწოდება SLO- ში.
P2 (ფონი): დეტალური ბუკლეტები, განბაჟება - საუკეთესო-ეფორტი, გადატვირთვა შესაძლებელია.

პოლიტიკოსები: სხვადასხვა რიგები, @ ta მწარმოებლებისთვის, backpressure, საბაზო-ლიმიტები, დედაპლატი 'idempotency _ key'.

6) მეტრიკის კარდინალობა და ბიუჯეტი

წესი 6 ეტიკეტი: მეტრიკის არაუმეტეს 6 გასაღები, ფიქსირებული მნიშვნელობების ლექსიკონი.
10k დროის სერიების/მეტრიკის/ტენანტის კარდინალობა.
ნიმუშები: head-/tail-based ტრეკებისთვის; downsampling მეტრიკი 10s-1m-5m-1h.
É tas: წერტილების/s და ბაიტის/წმ შეზღუდვები tentant- ზე და QoS კლასზე.
ლინტერი სქემები: უარყოფს მეტრიკებს „ფეთქებადი“ ეტიკეტებით (id, email, ip და ა.შ.).

7) შეგროვება და მიწოდება: push vs pull

Push (OTLP/StatsD/HTTP): მოქნილობა, მობილური/edge კლიენტები, P0 არხები.
Pull (Prometheus): შიდა ინფრასტრუქტურა, პროგნოზირებადი ტარგეტები.
ჰიბრიდი: ექსპორტიორები - gateway - TSDB; federated scrapes რეგიონებისთვის.
ტრანსპორტი: QUIC/HTTP/2, კომპრესია, ტრამპლინი, TLS/mTLS, ჯიტერი.

8) SLI/SLO და ალერტინგი

8. 1 ძირითადი SLI

Availability% endpoint/კარიბჭე,

Latency p50/p95/p99 კრიტიკულ მარშრუტებზე,

Error-rate (5xx/timeout/abort),

Delivery lag ავტობუსში, Queue depth,

Freshness witrin (შეფერხება ingest-serve).

8. 2 SLO მაგალითები

P0 pipelines: Availability ≥ 99. 95%, p99 latency ≤ 400 мс, Delivery lag p95 ≤ 2 с.
P1: Availability ≥ 99. 9%, Freshness p95-3.
P2: Freshness p95 ≤ 15 мин, no-page.

8. 3 Burn-rate Alerta (მაგალითი)

2-საათიანი ფანჯარა: 'error _ budget _ burn' 2 × 'page.
6-საათიანი ფანჯარა: 'error _ budget _ burn - 1 ×' page/escalation.
დააკავშიროთ 'queue _ lag' და 'drop _ rate' P0.

9) საცავი და რეტენციები

TSDB მეტრიკა: მაღალი სიხშირე - 7-14 დღე; აგრეგატები - 6-12 თვე.
მოვლენები/ლოგოები: ცხელი საცავი 7-30 დღე, ცივი (ობიექტი) 6-24 თვე.
ტრეისი: ნიმუში 1-10%; „ნელი/მცდარი“ სპანების შენარჩუნება (tail-based).
წაშლის/რედაქციის პოლიტიკოსები PII და მონაცემთა სუბიექტების მოთხოვნები.

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

PII მინიმიზაცია: ველების ტოქსიკაცია/ფსევდონიზაცია, მეტრიკებში „ნედლეული“ იდენტიფიკატორების აკრძალვა.
mTLS/მოვლენების ხელმოწერები, მწარმოებლების გასაღებების პინგი.
ACL/ABAC თემებზე/სერვისებზე/ტენანტებზე, ცალკეული გასაღებები write/read.
Tenant sandboxing: ლოგიკური/ფიზიკური დაყოფა, limites და rate-limit per tenant.
Audit trail: შეუცვლელი დაშვების/ჩამორთმევის ცვლილებები.

11) დამუშავების ნაკადები (stream jobs)

Enrich: ნორმალიზაცია, გეო/ვერსია/ტრაფიკის კლასი.
აგრეგატი: ფანჯრები 10s/1m/5 მ, ჰისტოგრამები, ქინძისთავები.
Detect: ანომალიები (EWMA/ESD), განაწილების დრიფტი, რიგების ადიდება.
მარშრუტი: პარტნიორების ფანჯრები/ალერტერი/ვებჰუკი.
Guard: „წითელი ღილაკი“ - წყაროს/თემის მიხედვით throttling/kill-switch.

12) დაშბორდი (რეფერენდუმის განლაგება)

Ops Core (საათი/რეალი დრო): p95 ლატენტი, error-rate, მიწოდების lag, queue depth, success-rate ingest.
Pipelines Health: freshness per pipeline, drop-rate, backpressure, burn-rate SLO.
Tenant Usage: რიგები/წმ, ბაიტი/წმ, კარდინალობა, ტოპ-ლაბორატორია.
Security/Compliance: mTLS სტატუსები, გაწმენდის გასაღებები, წვდომა, PII რედაქციები.
Business Lens: კონვერტაცია/გადახდა/ხიდის SLI იმ მეტრიკის გვერდით.

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

QoS კლასები და ლიმიტები (YAML)

yaml telemetry:
qos:
P0:
topics: [payout. sli, bridge. finality, gateway. availability]
delivery: guaranteed retry:
attempts: 3 backoff_ms: [100, 400, 800]
max_queue_lag_ms: 2000
P1:
topics: [product. events, api. metrics]
delivery: at-least-once sampling: 1. 0
P2:
topics: [debug. logs, verbose. traces]
delivery: best-effort sampling: 0. 1 quotas:
tenant_default:
metrics_points_per_sec: 50_000 logs_mb_per_hour: 500 traces_spans_sampled_pct: 5

ეტიკეტები მეტრიკი (პოლიტიკა)

yaml metrics_policy:
allowed_labels: [service, route, code, region, tenant, version]
forbidden_labels: [user_id, email, ip, session_id]
max_label_value_count: 1000

Alerta burn-rate

yaml alerts:
- name: "p0_error_burn_2h"
expr: burn_rate_p0_2h > 2 action: [page_oncall, open_incident]
- name: "queue_lag_p0"
expr: queue_lag_ms_p95 > 2000 action: [page_oncall]

14) მონაცემთა სქემები და მოთხოვნები

მეტრიკის რეესტრი (კატალოგი)

sql
CREATE TABLE metric_catalog(
name TEXT PRIMARY KEY,
unit TEXT, description TEXT,
labels JSONB, owner TEXT, qos TEXT, sla JSONB
);

რიგები და ლაგი

sql
SELECT topic,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY lag_ms) AS lag_p95,
SUM(dropped) AS drops
FROM queue_metrics
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY topic;

ტენტანტის კარდინალობა

sql
SELECT tenant, metric_name, COUNT(DISTINCT series_id) AS series
FROM tsdb_series
WHERE day = current_date
GROUP BY tenant, metric_name
ORDER BY series DESC
LIMIT 50;

15) პროცესები და როლები

Telemetry Owner - სქემები/პოლიტიკა/კვოტები, დრამატული კონტროლი.
SRE/Ops - SLO, ალერტები, ინციდენტები, სკალირება.
უსაფრთხოება/კომპლექსი - გასაღებები, წვდომა, PII, აუდიტი.
Product/BI - KPI ფანჯრები, ანალიტიკა, A/B მეტრიკა.
Tenants (პარტნიორები) - SDK- ის სწორი ინტეგრაცია, ხელშეკრულებების შესრულება.

16) Playbook ინციდენტები

A. რადიკალური აფეთქება

1. მწარმოებლის/მეტრიკის მანქანის ბლოკი, 2) მოწყვეტილი „ცუდი“ ეტიკეტები, 3) რეტრო აგრეგაცია, 4) პოსტ-mortem და ლინტერი წესები.

B. Rost queue lag P0

1. ჩართეთ პრიორიტეტი, 2) გააფართოვოს წვეულებები/კონსუმერები, 3) დროებით შეამციროს P2 sampling, 4) ვიწრო ადგილების ანალიზი.

C. Freshness witrin

1. 2) სარეზერვო კონექტორზე გადასვლა, დეგრადაციის რეჟიმის ჩართვა („ბოლო ფინალიზაცია“), 3) წყაროების მფლობელებს აცნობეთ.

დ. PII გაჟონვა მეტრიკებში

1. ნაკადის დაუყოვნებლივი დაბლოკვა, 2) ცხელ ფენაზე გადაკეტვა, 3) შეტყობინება DPO/Compliance, 4) ლენტერების განახლება/SDK.

E. მასობრივი 5xx/ტრეკების შეცდომები

1. Page, 2) tail-based (შეცდომების დასადგენად, 3) კრიტიკული მარშრუტის ტრეისის დიაგნოზი, 4) გამოშვება/fich დროშა.

17) განხორციელების შემოწმების სია

1. დამტკიცდეს ღონისძიების კონტრაქტები/მეტრიკა/ტრეისი და მისაღები ეტიკეტების სია.
2. დაიწყეთ QoS კლასები, ტოპები/რიგები, 5.tas და მეტრიკის ბიუჯეტი.
3. კონფიგურაცია ingest (push/pull), TLS/mTLS, retrais და idempotence.
4. ჩართეთ მეტრიკის/მოვლენების კატალოგები და სქემების ლინზები.
5. განსაზღვრეთ SLI/SLO, burn-rate ალერტები და ესკალაცია.
6. Dashbords Ops/Pipelines/Tenant/Security აშენება.
7. დაიწყეთ ტელემეტრიული ქაოსის ტესტები (ზარალი/ჯიტერი/სპაიკი).
8. რეგულარულად გადაამოწმეთ კარდინალობა, რენტგენოლოგია და შენახვის ღირებულება.

18) გლოსარიუმი

QoS არის ხარისხის კლასი/მიწოდების პრიორიტეტი.
Freshness არის მონაცემთა შეფერხება ფანჯარაში.
Burn-rate - შეცდომების ბიუჯეტის მოხმარების სიჩქარე SLO- სთან შედარებით.
Cardinality არის უნიკალური მეტრიკის მწკრივების რაოდენობა (ეტიკეტის კომბინაციები).
Tail-based sampling - „ნელი/მცდარი“ ტრეკების ნიმუში.
Idempotence key არის მოვლენის განმეორების შუამდგომლობის გასაღები.

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