Serverless упростил запуск кода, но сильно усложнил наблюдаемость. В обычных сервисах можно анализировать долгоживущие процессы, локальные логи и стабильные хосты. В serverless этого часто нет: функции живут секунды, масштабируются мгновенно и обрабатывают события параллельно. Поэтому трассировка здесь — не опция, а базовый инструмент. ⚙️
Что делает трассировку в serverless особенной
- Эфемерность окружения
Инстансы функций быстро создаются и уничтожаются. Привязка к серверу, контейнеру или PID почти бесполезна.
- Событийная архитектура
Запрос может проходить не по HTTP-цепочке, а через очередь, брокер или шину событий. Связать весь путь вручную сложно.
- Высокая параллельность
Один поток событий может породить десятки одновременных вызовов функций. Без trace/span ID картина распадается.
- Cold start
Задержки при первом запуске функции влияют на latency, но часто неочевидны без отдельной фиксации в telemetry. ❄️
- Ограниченный доступ к инфраструктуре
Нельзя просто поставить агент на хост и собрать всё как в VM или Kubernetes.
Какие данные обязательно собирать
- Traces — полный путь запроса или события через функции, очереди, API Gateway, базы и внешние сервисы
- Logs — структурированные, с trace_id и span_id
- Metrics — latency, error rate, throttling, duration, memory usage, cold starts, retries 📊
Главное правило: логи, метрики и трассировки должны быть связаны между собой. Иначе observability превращается в три разрозненных источника шума.
Ключевые сложности трассировки
-
Потеря контекста между сервисами
Если событие уходит в Kafka, SQS, Pub/Sub или EventBridge, trace context нужно передавать явно через headers, attributes или payload. -
Async-разрывы
Асинхронные вызовы ломают “прямую” цепочку. Нужна поддержка distributed tracing именно для event-driven сценариев. -
Сэмплирование
При большом потоке нельзя хранить 100% трасс. Но слишком агрессивное сэмплирование скрывает редкие ошибки. Нужен баланс: head-based или tail-based sampling в зависимости от критичности. -
Vendor lock-in
Нативные инструменты облаков удобны, но могут ограничивать переносимость. Поэтому всё чаще выбирают OpenTelemetry как стандарт. 🧩
Практические рекомендации
- Внедряйте OpenTelemetry для единых trace/span context
- Прокидывайте correlation ID через все события и очереди
- Логируйте cold starts отдельно
- Размечайте retry, timeout и DLQ-сценарии
- Стройте дашборды не только по HTTP, но и по event flow
- Проверяйте, где именно теряется trace context при переходе между managed services
Что в итоге
В serverless трассировка — это не просто “посмотреть запрос”, а способ восстановить поведение распределённой событийной системы. Хорошая observability помогает быстро находить узкие места, понимать влияние cold start, отслеживать сбои в асинхронных цепочках и не теряться в масштабе. 🚀
Подборка каналов про IT — хороший способ держать под рукой ещё больше практики, кейсов и инструментов для observability, cloud и backend-разработки.