Наблюдаемость (Observability)

Наблюдаемость — это степень, в которой вы можете понять, что происходит внутри работающей системы, изучая данные, которые она производит вовне — логи (дискретные события с временными метками), метрики (числовые измерения во времени, такие как задержка запросов или частота ошибок) и трейсы (сквозной путь одного запроса при его прохождении через несколько сервисов). Это связано с традиционным «мониторингом», но шире: мониторинг обычно означает наблюдение за заранее определённым набором дашбордов на известные режимы отказа, тогда как наблюдаемость нацелена на то, чтобы позволить вам отвечать на новые вопросы о поведении системы — включая вопросы, которые вы заранее не предполагали задавать, — исследуя лежащие в основе телеметрические данные. Инструменты включают Datadog, New Relic, Grafana + Prometheus и Honeycomb, а также открытый стандарт OpenTelemetry для инструментирования приложений вендоронезависимым способом. Почему это важно для разработчиков AI/SaaS: по мере того как система вырастает за пределы одного монолитного сервера, понимание того, почему конкретный запрос был медленным или почему частота ошибок подскочила в 3 часа ночи, становится по-настоящему сложным без хорошей наблюдаемости — нужная информация разбросана по нескольким сервисам, а «просто добавь print и передеплой» неприменимо, когда вы отлаживаете production-инцидент, затрагивающий реальных клиентов. Для функций на базе ИИ наблюдаемость также должна охватывать специфичные для LLM сигналы — использование токенов и стоимость на запрос, задержку вызовов модели и метрики качества, такие как то, как часто ответ получает «дизлайк» — ничего из этого традиционный мониторинг инфраструктуры не захватывает из коробки. Как это работает: приложения инструментируются для выдачи структурированных логов (в формате JSON, с согласованными полями вроде `request_id`, `user_id`, `duration_ms`) и метрик (счётчики, датчики, гистограммы) в значимых точках, а распределённая трассировка распространяет уникальный ID трейса через каждый сервис, к которому обращается один запрос, позволяя восстановить полный путь — «этот запрос попал в API-шлюз, затем в сервис аутентификации, затем в сервис оркестрации ИИ, который вызвал Claude и занял 1,2 секунды, затем записал в Postgres» — как единую связанную временную линию вместо не связанных между собой логов в пяти разных местах. Практический пример: у SaaS-компании происходит всплеск жалоб клиентов на медленный экспорт отчётов, сгенерированных ИИ. Вместо того чтобы гадать, инженер открывает дашборд наблюдаемости и фильтрует трейсы для эндпоинта `export_report` за последний час, сортируя по длительности. Он видит, что все медленные трейсы имеют один общий паттерн: спан с меткой `claude_api_call` занимает 8–12 секунд вместо обычных 2–3, тогда как каждый другой спан в трейсе (запросы к базе данных, рендеринг PDF) выглядит нормально. Это сразу сужает расследование до «что-то изменилось в наших вызовах ИИ или в задержке API Anthropic», вместо смутной, общесистемной охоты за производительностью по всему стеку — превращая потенциально многочасовое расследование в пятиминутную диагностику, основанную на фактах.