Розподіл сигналів і метрик

(Розділ: Екосистема та Мережа)

1) Мета і область

• Єдина мова телеметрії та контракти даних.
• Керовані QoS-канали: пріоритет критичних сигналів.
• Прозорі SLI/SLO і передбачуваний алертинг.
• Приватність, ізоляція та економія бюджету метрик.

2) Таксономія сигналів

1. Бізнес-події: онбординг, депозити/виплати, ігрові події, атрибуція.
2. Тех-метрики: latency/throughput/код помилки, черга, використання CPU/RAM/IO.
3. Логи: структуровані записи про операції та помилки.
4. Трасування: спани запитів/топіків, кореляція hop-to-hop.
5. Статуси здоров'я: synthetic probes, readiness/liveness, heartbeat узлов.
6. Сигнали ризику/комплаєнсу: KYC/KYB/AML хіти, санкційні події.

Кожен клас має свій рівень критичності та політику зберігання/доставки.

3) Архітектура розподілу (референс)

Edge-колектори (SDK/агенти) → Ingress (HTTP/OTLP/gRPC/QUIC) → Шина (Kafka/Pulsar) → Обробники (stream-jobs) → Сховища (TSDB для метрик, об'єктне/колонічне - для логів/подій, трасувальник) → Вітрини/дашборди/алерти.
Мульти-тенантність: namespace/tenant-id в ключах, окремі quota/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{service, region, tenant, version, route}`.
Гістограми для латентності/розмірів замість p99 в коді.

4. 3 Трейси

Обов'язкові поля: `trace_id`, `span_id`, `parent_id`, `service`, `peer`, `route`, `qos`.
Лінки між доменами (consumer/producer) і мережевими хопами (relay/bridge).

5) QoS і пріоритизація

P0 (критично): платежі/виплати SLI, статуси мостів/вузлів, burn-rate SLO → сувора доставка (acks, retries, ідемпотентність), мінімальні таймаути.
P1 (важливо): продуктові події/основні метрики → гарантована доставка в межах SLO.
P2 (фон): детальні логи, налагодження → best-effort, можна дропати при перевантаженні.

Політики: різні черги, quota на продюсерів, backpressure, rate-limits, дедуп по'idempotency _ key'.

6) Кардинальність і бюджет метрик

Правило 6 лейблів: не більше 6 ключів на метрику, фіксовані словники значень.
Кардинальність ≤ 10k часових рядів/метрику/тенант.
Семплювання: head-/tail-based для трасувань; downsampling метрик 10s→1m→5m→1h.
Quotas: ліміти точок/сек і байтів/сек на тентанта і на клас QoS.
Лінтер схем: відхиляє метрики з «вибухаючими» лейблами (id, email, ip тощо).

7) Збір і доставка: push vs pull

Push (OTLP/StatsD/HTTP): гнучкість, мобільні/edge-клієнти, P0 канали.
Pull (Prometheus): внутрішня інфраструктура, передбачувані таргети.
Гібрид: exporters→gateway→TSDB; federated scrapes для регіонів.
Transport: QUIC/HTTP/2, компресія, батчування, TLS/mTLS, ретраї з джиттером.

8) SLI/SLO і алертинг

8. 1 Базові SLI

Availability% ендпоінтів/шлюзів,

Latency p50/p95/p99 за критичними маршрутами,

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

Delivery lag по шині, Queue depth,

Freshness вітрин (затримка 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 алерти (приклад)

2-годинне вікно: 'error _ budget _ burn ≥ 2 ×'→ пейдж.
6-годинне вікно: 'error _ budget _ burn ≥ 1 ×'→ пейдж/ескалація.
Комбінувати з'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: логічне/фізичне розділення, ліміти і rate-limit per tenant.
Audit trail: незмінні журнали доступу/змін конфігів.

11) Потоки обробки (stream jobs)

Enrich: нормалізація, гео/версія/клас трафіку.
Aggregate: вікна 10s/1m/5m, гістограми, квантильні ескізи.
Detect: аномалії (EWMA/ESD), дрейф розподілів, сплески черг.
Route: фан-аут у вітрини/алертери/вебхуки партнерів.
Guard: «червона кнопка» - throttling/kill-switch за джерелом/темою.

12) Дашборди (референс-макети)

Ops Core (година/реал-тайм): p95 latency, error-rate, delivery lag, queue depth, success-rate ingest.
Pipelines Health: freshness per pipeline, drop-rate, backpressure, burn-rate SLO.
Tenant Usage: ряди/сек, байти/сек, кардинальність, top-labels.
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

Алерти 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, алерти, інциденти, масштабування.
Security/Compliance - ключі, доступи, PII, аудити.
Product/BI - вітрини KPI, аналітика, A/B-метрики.
Tenants (партнери) - коректна інтеграція SDK, дотримання контрактів.

16) Playbook інцидентів

А. Вибух кардинальності

1. Авто-блок продюсера/метрики, 2) відсікаємо «погані» лейбли, 3) ретро-агрегація, 4) пост-мортем і лінтер-правила.

B. зростання queue lag P0

1. Включити пріоритет, 2) розширити партії/консьюмери, 3) тимчасово знизити P2 sampling, 4) аналіз вузьких місць.

C. Падіння Freshness вітрин

1. Переключитися на резервний конектор, 2) включити деградаційний режим («останні фіналізовані»), 3) повідомити власників джерел.

D. витік PII в метриках

1. Негайне блокування потоку, 2) redaction на гарячому шарі, 3) повідомлення DPO/Compliance, 4) оновлення стрічок/SDK.

E. Масові 5хх/помилки трасувань

1. Пейдж, 2) семплінг tail-based ↑ для помилок, 3) трейс-діагностика критичного маршруту, 4) відкат релізу/фіча-прапор.

17) Чек-лист впровадження

1. Затвердити контракти подій/метрик/трейсів і список допустимих лейблів.
2. Завести QoS-класи, топіки/черги, quotas і бюджет метрик.
3. Налаштувати ingest (push/pull), TLS/mTLS, ретраї та ідемпотентність.
4. Включити каталоги метрик/подій і лінтери схем.
5. Визначити SLI/SLO, burn-rate алерти і ескалації.
6. Побудувати дашборди Ops/Pipelines/Tenant/Security.
7. Запустити chaos-тести телеметрії (втрати/джиттер/спайки).
8. Регулярно ревізувати кардинальність, ретенції і вартість зберігання.

18) Глосарій

QoS - клас якості/пріоритету доставки.
Freshness - затримка появи даних у вітрині.
Burn-rate - швидкість витрати бюджету помилок щодо SLO.
Cardinality - число унікальних рядів метрик (лейбл-комбінацій).
Tail-based sampling - вибірка «повільних/помилкових» трасувань.
Idempotency key - ключ для дедуплікації повторів подій.

Підсумок: розподіл сигналів і метрик - це не просто «зібрати і показати графіки», а дисципліна контрактів, QoS-каналів і бюджетів. Дотримуючись цього фреймворку, екосистема отримує передбачувану спостережуваність, стійку до сплесків, приватну до даних і корисну для рішень як в операційному, так і в бізнес-контурі.