Перейти к основному содержимому

Observability Tooling Baseline — Технологический baseline наблюдаемости, трассировки и операционной диагностики

Версия: 1.0
Дата: 24.04.2026
Статус: Готов к обсуждению

Назначение документа​

Этот документ фиксирует технологический baseline для observability tooling в платформе vitrip.store.

Он не заменяет Observability And Incident Response — Наблюдаемость и реагирование на инциденты, а дополняет его.

Его задача — ответить на вопрос:

какой набор инструментов и технических практик лучше всего обслуживает уже зафиксированную операционную модель наблюдаемости.

Опорные документы​

Почему Этот Документ Нужен Отдельно​

У нас уже зафиксирована правильная логика observability:

  • domain-chain visibility;
  • correlation across contours;
  • queue awareness;
  • operator-oriented diagnostics;
  • incident triage and recovery.

Но без tooling baseline это остаётся правильной операционной идеей без технологического фундамента.

Главный Принцип​

Tooling observability должно обслуживать доменную цепочку платформы, а не превращать её в набор disconnected dashboards.

Из этого следует:

инструменты должны выбираться по способности связывать supplier trace, canonical update, offer/quote, booking, settlement, queues and operator action в одну расследуемую картину.

Обязательные Классы Tooling​

1. Metrics Stack​

Нужен baseline для:

  • service metrics;
  • infrastructure metrics;
  • queue metrics;
  • domain aggregate counters;
  • SLO-oriented views.

Рекомендуемый baseline:

  • Prometheus-compatible metrics collection;
  • Grafana-class visualization and dashboarding.

2. Logs Stack​

Нужен baseline для:

  • structured logs;
  • searchable error narratives;
  • cross-service diagnosis;
  • queue and retry explanations;
  • operator and case drill-down.

Рекомендуемый baseline:

  • centralized structured log ingestion;
  • Elasticsearch/OpenSearch-compatible searchable store or comparable log backend;
  • log fields standardized around domain correlation ids.

3. Distributed Tracing Stack​

Нужен baseline для:

  • request-path analysis;
  • cross-service latency breakdown;
  • async/sync boundary tracing;
  • quote and booking path investigation;
  • replay and incident diagnostics.

Рекомендуемый baseline:

  • OpenTelemetry instrumentation as default instrumentation model;
  • OTEL-compatible collector pipeline;
  • Jaeger/Tempo-class trace backend or a comparable tracing store.

4. Alerting Stack​

Нужен baseline для:

  • SLO/SLA alerting;
  • queue lag alerts;
  • booking-path degradations;
  • settlement/reconciliation backlog alerts;
  • supplier degradation and publication integrity alerts.

5. Operational Case Visibility​

Нужны не только dashboards, но и operational views around:

  • stuck booking flows;
  • replay backlog;
  • anomaly queues;
  • reconciliation aging;
  • partner abuse or throttling conditions.

OpenTelemetry As Baseline Instrumentation Model​

Для платформы такого типа OTEL-подход выглядит наиболее сильным baseline choice.

Почему:

  • единая модель instrumentation across languages;
  • metrics + traces + context propagation;
  • better future-proofing than tightly coupled vendor SDKs;
  • пригодность для mixed-language runtime.

Structured Logging Discipline​

Платформа не должна рассчитывать на “свободный текст в логах”.

Structured logs должны держать как минимум:

  • service/component;
  • event or operation name;
  • supplier id where relevant;
  • ingest trace id;
  • offer id;
  • quote id;
  • booking id;
  • settlement event id;
  • tenant / partner / workspace identifiers where permitted;
  • queue job id;
  • incident/case id if applicable.

Queue Observability Is Mandatory​

Для этой платформы queue and stream tooling должны быть first-class part of observability:

  • lag;
  • consumer failures;
  • poison rates;
  • retry storms;
  • scheduling drift;
  • backlog aging.

Без этого observability baseline неполон.

Domain Dashboard Baseline​

Минимально должны существовать dashboard families для:

  • supplier and ingestion health;
  • offer and quote health;
  • booking reliability;
  • settlement and reconciliation;
  • publication integrity;
  • partner API usage and abuse;
  • queue and replay health;
  • release and migration watch.

Alerting Philosophy​

Платформа не должна алертить только по infra symptoms.

Alerting baseline должен включать:

  • domain alerts;
  • queue health alerts;
  • financial backlog alerts;
  • publication-safety alerts;
  • partner abuse / quota alerts;
  • deployment/release regression alerts.

Retention And Cost Discipline​

Observability stack должен быть полезным, но не бесконтрольным по стоимости.

Нужно различать:

  • hot retention for incident response;
  • longer retention for audit-significant signals;
  • sampled traces vs mandatory traces for critical flows;
  • high-cardinality metrics that are justified and those that are not.

Tooling Baseline Recommendation​

На текущем этапе наиболее разумный baseline выглядит так:

  • OpenTelemetry for instrumentation and context propagation;
  • Prometheus-compatible metrics stack;
  • Grafana-class dashboards;
  • centralized structured log backend;
  • Jaeger/Tempo-class tracing backend;
  • alert routing and escalation stack integrated with operations workflows.

Это не vendor lock statement, а shape recommendation.

Что Должно Быть Сделано Дальше​

После фиксации этого baseline нужно:

  • синхронизировать observability-and-incident-response, deployment, implementation-technology-baseline, eventing-and-queue-baseline;
  • определить minimum correlation field set;
  • определить alert taxonomy;
  • определить trace sampling and retention policy;
  • оформить implementation-ready observability package.

Уточнение под Фазы 4–6 (28.04.2026) — связи с SLI/SLO, security audit, capacity​

Документ опубликован 24.04.2026 в Фазе 3 как технологический baseline observability tooling (Prometheus, Grafana, Loki, Tempo). После Фаз 4–6 этот baseline интегрируется со специализированными доменами; эта секция фиксирует связи.

Связь со SLI/SLO measurement​

operations/sla-and-on-call-model.md (Фаза 6) определяет 10 каноничных SLI metrics, которые собираются через этот tooling baseline:

  • availability per surface — Prometheus counter rate;
  • latency p95/p99 — Prometheus histogram;
  • webhook delivery — Prometheus + structured logs;
  • search freshness — custom metric (cache age);
  • booking confirmation latency — distributed tracing (Tempo);
  • unknown_external_state ratio — custom metric от booking-state-machine;
  • payment success rate — Prometheus counter from payment-service;
  • restoration success — DR drill events;
  • MTTR — incident lifecycle metrics;
  • support response — ticket system integration.

SLO calculation tools — Pyrra или Sloth на верхнем уровне Prometheus (см. рекомендацию в development/proposal-stack-roadmap-by-product-tier.md). Это формализует SLI → SLO → error budget pipeline.

Связь с security audit logging​

reference/security-architecture.md (Фаза 10) определяет отдельный канал для security/audit events с особыми требованиями:

  • Immutable storage — WORM-grade (write-once-read-many);
  • Tamper detection — periodic integrity checks (hash chains);
  • Retention — 7 лет (Tier 1 storage class);
  • Access controls — отдельные роли для read/query, no delete capability;
  • Tamper-evident encryption.

Caнoничный observability baseline (Loki) не подходит для audit log как primary storage. Audit log требует отдельную инфраструктуру:

  • ClickHouse с partition lock или dedicated immutable storage;
  • S3 Object Lock (Compliance Mode);
  • или specialized SIEM (Wazuh/Datadog Security/Splunk) с immutable storage.

В фазе 4+ — dedicated SIEM для security events; Loki остаётся для operational logs.

Связь с capacity monitoring​

operations/disaster-recovery-and-capacity.md (Фаза 6) использует tooling baseline для:

  • Capacity utilization metrics per resource type (compute, database, storage, bandwidth, cache, queue);
  • Forecast dashboards — historical trends + projection;
  • Threshold alerts — alert level (более 70% утилизации) и critical level (более 85%);
  • Peak load tracking — sезонные/региональные/партнёрские/маркетинговые/ad-hoc peaks.

С фазы 5 — AI-based prediction (упомянуто в operational-spine как Phase 4-5 feature) использует ML модели поверх historical metrics.

Связь с booking, payment, tour saga events​

Domain events этих доменов попадают в analytical pipelines (через reference/data-platform-and-events-tracking.md), но operational metrics также строятся:

  • Booking funnel metrics — Prometheus counters per state transition;
  • Payment success/failure rates — Prometheus + alerts на anomalies;
  • Tour saga compensation rate — alert при превышении threshold (saga health indicator);
  • Tenant-specific metrics — labelled per tenant_id для partner-facing dashboards.

Связь с partner-facing analytics​

reference/analytics-and-bi.md (Фаза 4) — partner-facing dashboards используют subset operational metrics:

  • Grafana с tenant-aware views;
  • k-anonymization для cross-tenant comparisons;
  • separate Grafana organization per Enterprise tenant (фаза 4+).

Связь с runbooks automation​

operations/runbooks-incident-playbooks.md (Фаза 6) предполагает runbook automation через ChatOps integration:

  • Slack / Microsoft Teams + bot для запуска runbook steps;
  • PagerDuty / Grafana OnCall integration;
  • automated alerting → runbook suggestion;
  • audit log per runbook execution step.

Каноничный итог уточнения​

Этот документ остаётся технологическим baseline tooling (Prometheus, Grafana, Loki, Tempo + OpenTelemetry collector). Расширения и интеграции:

Уточнение выполнено через no-destruction.