Спостережуваність: логи, метрики, трасування

Спостережуваність: логи, метрики, трасування

1) Навіщо це потрібно

• Метрики - компактні агрегати для SLI/SLO і алертингу за симптомами.
• Трасування - причинно-наслідкові ланцюжки запитів (end-to-end).
• Логи - детальні події для розслідувань та аудиту.

Мета: швидкий RCA, превентивні алерти і керована надійність в рамках error budget.

2) Принципи архітектури

Єдиний контекст: скрізь прокидаємо'trace _ id','span _ id','tenant _ id','request _ id','user _ agent','client _ ip _ hash'.
Стандарти: OpenTelemetry (OTel) для SDK/агентів, JSON-формат логів (канонічний, зі схемою).
Симптоми> причини: алертим по призначених для користувача симптомів (латентність/помилки), а не по CPU.
Зв'язок сигналів: від метрики → в спани (exemplars) → в конкретні логи по'trace _ id'.
Безпека і приватність: маскування PII в логах, шифрування in transit/at rest, незмінні журнали для аудиту.
Багатоарендність: розділення просторів імен/ключів/політик.

3) Таксономія сигналів і схеми

3. 1 Метрики

RED (Rate, Errors, Duration) для сервісів і USE (Utilization, Saturation, Errors) для інфраструктури.
Типи: counter, gauge, histogram/summary. Для латентності - histogram з фіксованими bucket'ами.
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`, `message`, `trace_id`, `span_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) → сховища сигналів.
Вимоги: back-pressure, ретраї, дедуплікація, обмеження кардинальності (labels!), захист від «log storms».

Метрики: pull (Prometheus-сумісно) або push через OTLP.
Трасування: OTLP/HTTP (gRPC), tail-семплери на колекторі.
Логи: локальний збір (journald/docker/stdout) → парсер → нормалізатор.

5) Зберігання та ретенція (tiered)

Метрики: гарячі TSDB 7-30 днів (з downsample), агрегати на більш довгий термін (90-365 днів).
Трасування: 1-7 днів повно, потім аггрегати/спани «важливих» сервісів; зберігати індекси за «service», «status», «error».
Логи: гарячий індекс 7-14 днів, теплий 3-6 міс, архів до 1-7 років (комплаєнс). Аудит - WORM.

Оптимізація витрат: downsampling, фільтрація DEBUG в проді, квоти на лейбли, sampling для трас.

6) SLI/SLO, алертинг і чергування

SLI: доступність (% успішних запитів), латентність (p95/p99), частка 5xx, свіжість даних, частка успішних джоб.
SLO: ціль на SLI (наприклад, 99. 9% успішних ≤ 400 мс).
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`.
• Силос-альберти (CPU/Disk) - тільки як допоміжні, без paging.

7) Кореляція сигналів

Метрика «червона» → клікаємо в exemplar → конкретний'trace _ id'→ дивимося «повільний» спан → відкриваємо логи по тому ж'trace _ id'.
Кореляція з релізами: атрибути'version','image _ sha','feature _ flag'.
Для даних/ETL: 'dataset _ urn','run _ id', зв'язок з lineage (див. відповідну статтю).

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) Безпека і приватність

In 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', події lineage; трасування для пайплайнів (span на батч/partition).
Kafka/NATS: метрики продюсер/консьюмер, лаг/відмова; трасування по headers (в т. ч. «traceparent»).

12) Профілювання та eBPF (доп. сигнал)

Низькорівневі гарячі шляхи CPU/alloc/IO; профілі на інцидент.
eBPF-телеметрія (мережеві затримки, DNS, системні виклики) з прив'язкою до'trace _ id '/PID.

13) Тестування спостережуваності

Контракт сигналів: перевірка експорту метрик/лейблів/гістограм в CI.
Synthetic probes: сценарії RUM/симульовані клієнти для зовнішніх SLI.
Chaos/Fire drills: вимкнення залежностей, деградація - дивимося, як алерти і чергові реагують.
Smoke в проді: пост-деплою перевірка, що нові ендпоінти мають метрики і трасування.

14) Вартість і контроль обсягів

Бюджети за сигналом/командою; дешборд «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 метрики з гістограмами; exemplar → траси.
• Tail-sampling включений; правила 5xx/p99 = 100%.
• Алерти за симптомами + рунібуки; тихий годинник/anti-flap.
• Санітайзери PII; шифрування at rest/in transit; WORM для аудиту.
• Ретенції та бюджети на обсяги/кардинальність.

• Щомісячний огляд алертів (шум/точність), тюнінг порогів.
• Звіт по error budget і вжиті заходи (фічфриз, hardening).
• Перевірка покриттів дашбордів/логів/трас для критичних шляхів.
• Навчальні інциденти та оновлення runbook'ів.

17) Runbook’и

RCA: зростання p99/pay

1. Відкрити дашборд RED для'checkout'.
2. Перейти по exemplar → повільна траса → виявити «вузький спан» (напр.,'gateway. call`).
3. Відкрити логи по'trace _ id'→ подивитися таймаути/ретраї.
4. Увімкнути фіча-прапор відкату/ліміт RPS, повідомити власників залежності.
5. Після стабілізації - RCA, тікети на оптимізацію, тест відтворення.

1. SLI «свіжість» червоний → траси джоба → failing крок.

2. Перевірити лаг брокера/DLQ, помилки конектора.

3. Запустити reprocess, повідомити споживачів (BI/продукт) через статус-канал.

18) Часті помилки

Логи без схеми і без'trace _ id'. Розслідування затягуються в рази.
Алерти по інфраструктурі замість симптомів. Paging йде «в молоко».
Безмежна кардинальність метрик. Вибух витрат і нестабільність.
Всі траси 100%. Дорого і не потрібно; вмикайте розумне семплювання.
PII/секрети в логах. Включайте санітайзери і «червоні списки».
«Німі» фічі. Новий код без метрик/трас/логів.

19) FAQ

В: Чи потрібно зберігати сирий текст логів?
ПРО: Так, але з ретенцією та архівами; для алертів і SLO достатньо агрегатів. Аудит - в WORM.

В: Що вибирати для трас - head або tail sampling?
ПРО: Комбінувати: head-probabilistic для базового покриття + tail-rules для помилок і аномалій.

В: Як зв'язати призначені для користувача метрики і технічні?
ПРО: Через загальний'trace _ id'і бізнес-лейбли ('route','tenant','plan'), а також через події продукту (конверсії) з кореляцією до трас.

В: Як не потонути в алертах?
ПРО: Бийте за симптомами, вводьте тихі години, дедуплікацію, угруповання, пріоритизацію по SLO і власник-по-замовчуванню на кожен алерт.

• «Аудит і незмінні журнали»
• «Шифрування In Transit/At Rest»
• «Менеджмент секретів»
• «Походження даних (Lineage)»
• «Privacy by Design (GDPR)»
• «Гарантії доставки вебхуків»