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

(Раздел: Экосистема и Сеть)

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 инцидентов

A. Взрыв кардинальности

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. Массовые 5xx/ошибки трассировок

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-каналов и бюджетов. Следуя этому фреймворку, экосистема получает предсказуемую наблюдаемость, устойчивую к всплескам, приватную к данным и полезную для решений как в операционном, так и в бизнес-контуре.