Observability
Метрики, логи, distributed tracing, dashboards и alerting baseline.
Observability
Observability объединяет metrics, logs и traces. Один источник показывает симптом, но только их совместное использование позволяет восстановить маршрут и причину сбоя.
Обязательный контекст
Каждый telemetry event должен содержать или позволять определить:
- environment;
- component/service;
- API и operation;
X-Consumer-ID;X-External-Request-ID;- trace/span identifiers;
- result/error category;
- duration;
- version или deployment revision.
Idempotency-Key логируется только согласно data policy и не должен раскрывать чувствительную бизнес-информацию.
Metrics baseline
| Область | Сигналы |
|---|---|
| API | Request rate, latency, 2xx/4xx/5xx, 401/403/429 |
| Runtime | CPU, RAM, restart count, replicas, JVM/GC при необходимости |
| Kafka | Broker health, produce/fetch errors, lag, partition state |
| Kestra | Executions by state, failures, duration, queue, retries |
| Adapter | Backend latency, timeout, error category, connection pool |
| Callback | Delivery success, retry count, DLT, signature rejection |
| Database | Availability, connections, storage, query latency, backup status |
Logging
- используйте structured logs;
- не записывайте credentials, tokens и private keys;
- маскируйте персональные и чувствительные поля;
- разделяйте business outcome и technical error;
- сохраняйте stack trace только во внутреннем защищённом контуре;
- логи не должны теряться после restart pod;
- retention определяется политикой, а не локальной настройкой приложения.
Distributed tracing
Валидный W3C traceparent продолжается через WSO2, Router, Kafka context, Kestra и адаптер. Если Consumer его не передал, Gateway создаёт новый trace.
Асинхронная граница не завершает traceability
При передаче через Kafka или callback trace context и External Request ID сохраняются в message metadata/envelope. Новый технический trace при восстановлении всё равно связывается с исходным request ID.
Dashboards
Минимальный набор:
- ESB platform overview;
- API traffic and errors;
- Kafka transport health;
- orchestration executions;
- adapters and target systems;
- callback delivery;
- Kubernetes and infrastructure;
- database and storage health.
Alerts
Alert должен иметь condition, severity, owner, notification channel и runbook link. Численные thresholds задаются утверждённым service profile.
Избегайте alert на каждый единичный 4xx: alerting должен выявлять влияние на сервис, а не заменять аналитические dashboards.
SLI/SLO
Для API или компонента определяются availability, latency, correctness и delivery SLI. Пока целевые значения не утверждены, документируйте измеряемый baseline и не представляйте проектные числа как действующий SLA.