Самые довольные пользователи систем наблюдаемости, которых мы встречаем, — это практически всегда те, кто создал собственный пользовательский интерфейс. В процессе разработки ClickStack и определения приоритетов функций мы постоянно сталкиваемся с этой мыслью.
Базовые рабочие процессы неплохо закрывают часть потребностей. Но всегда остается длинный хвост запросов на интерфейсы, адаптированные под конкретный бизнес, команду или подход к расследованию. Удовлетворение этих потребностей без усложнения продукта для всех остальных — знакомая дилемма продуктового дизайна, которая найдет отклик у продакт-менеджеров.
Однако генерация приложений наблюдаемости с помощью ИИ может предложить выход из этой тупиковой ситуации. Пользователи смогут подстраивать интерфейс под свои вопросы, а не подгонять свои вопросы под доступные экраны.
Мы создали ClickHouse Observability Apps, чтобы предоставить каждому пользователю индивидуальный интерфейс без необходимости выделять ресурсы на разработку UI наблюдаемости с нуля. Это интерактивные приложения, работающие с живыми данными и включающие связанные экраны, пользовательские визуализации и рабочие процессы, выходящие за рамки обычных дашбордов. Они используют наши API для расследований и основные компоненты, привнося устоявшуюся логику запросов и единообразное поведение в создаваемые командами интерфейсы.
За последние несколько лет мы видели, как такие компании, как Anthropic, DoorDash, Tesla и Netflix, создавали собственные инструменты наблюдаемости поверх ClickHouse. Они настраивают интерфейсы под свои системы, свои команды и те вопросы, на которые им нужно найти ответы. Если какого-то рабочего процесса не хватает, они просто создают его. Пытаться убедить такие команды использовать стандартный интерфейс вендора — это все равно что просить пользователя Vim сменить редактор только потому, что в вашем меню красивее.
Не у каждой компании есть ресурсы на создание собственного UI наблюдаемости, но каждой нужен интерфейс, отражающий ее системы, бизнес-процессы и критические пользовательские сценарии. Внутри компании этот интерфейс также должен подходить людям, которые им пользуются. Инженер платежной системы может начать с процента успешных транзакций у процессора, агент техподдержки — с незавершенного заказа клиента, а инфраструктурная команда — с сервисов, обеспечивающих оформление покупки. Каждому нужен свой собственный путь по одним и тем же исходным данным. Ожидать, что вендор предусмотрит и создает каждую возможную комбинацию, просто нереально.
Кроме того, мы постоянно слышали от пользователей две вещи. Одни считали существующий инструмент слишком сложным, хотя использовали лишь малую его часть. Другие хотели визуализации и рабочие процессы, которых мы не предлагали. Создание всего, о чем просила вторая группа, могло привести ровно к тому усложнению, избежать которого стремилась первая.
Поэтому мы решили попробовать другой подход. Мы создали ClickHouse Observability Apps, чтобы команды могли генерировать нужные им интерфейсы. Опишите приложение на естественном языке, и агент создаст его прямо внутри ClickHouse Observability, со своими представлениями и навигацией по живым данным. Уточняйте приложение в процессе диалога, адаптируйте его по мере изменения вопросов и делитесь им с командой.
Чтобы сделать это более наглядным, приведем несколько примеров. Они несколько условны, но в целом отражают те запросы, которые мы слышим от пользователей.
"Создай приложение, которое выводит список и визуализирует карты нашей инфраструктуры с акцентом на критические пользовательские сценарии, такие как оформление заказа и вход в систему. Позволь мне выбрать сценарий, изучить его зависимости и понять критичность каждого компонента на основе сценариев и функциональности, которые он поддерживает. При сбое компонента покажи, какие сценарии пострадали и к каким рискам для пользователей это приводит. Сделай его полезным как для повседневного понимания нашей инфраструктуры, так и для оценки последствий во время инцидента."
"Создай приложение, которое выводит список и визуализирует карты нашей инфраструктуры с акцентом на критические пользовательские сценарии, такие как оформление заказа и вход в систему. Позволь мне выбрать сценарий, изучить его зависимости и понять критичность каждого компонента на основе сценариев и функциональности, которые он поддерживает. При сбое компонента покажи, какие сценарии пострадали и к каким рискам для пользователей это приводит. Сделай его полезным как для повседневного понимания нашей инфраструктуры, так и для оценки последствий во время инцидента."
Важность компонента зависит от того, для чего его используют ваши клиенты. Пользовательская визуализация позволяет сделать эти взаимосвязи наглядными, даже если продукт по умолчанию этого не предлагает. Ни один вендор не способен предусмотреть архитектуру, общие сервисы и бизнес-приоритеты каждого клиента или точные визуализации, которые им понадобятся. Вместо этого позвольте своей команде создать представление, отражающее эти нюансы, не пытаясь убедить вендора в том, что то же самое нужно достаточному количеству других клиентов.
"Создай приложение, которое отслеживает значения флагов функций (feature flags) наряду с ключевыми показателями эффективности (KPI) приложений и инфраструктуры. Позволь мне выбрать изменение, сравнить затронутые тенанты и изучить запросы, стоящие за регрессией производительности."
"Создай приложение, которое отслеживает значения флагов функций (feature flags) наряду с ключевыми показателями эффективности (KPI) приложений и инфраструктуры. Позволь мне выбрать изменение, сравнить затронутые тенанты и изучить запросы, стоящие за регрессией производительности."
Инженер может исследовать задержки после релиза, в то время как служба поддержки должна выявить пострадавших клиентов. Каждый из них может адаптировать приложение под свои обязанности, добавляя представления или меняя ход расследования по мере возникновения новых вопросов. Возможно, такое приложение имеет смысл создать даже для разового релиза, а затем удалить, как только ответ будет найден. Либо коллеги могут поделиться им, создать ответвления (ветки) и доработать его до инструмента, используемого каждый день.
"Создай представление успешности платежей в разрезе типов кредитных карт, сравнивая их с нормальным показателем каждого процессора. Позволь переходить от сбоев к затронутым заказам и их трейсам. Проанализируй масштаб последствий и то, завершились ли заказы успехом в итоге. Покажи логи, трейсы и метрики за последние 36 часов."
"Создай представление успешности платежей в разрезе типов кредитных карт, сравнивая их с нормальным показателем каждого процессора. Позволь переходить от сбоев к затронутым заказам и их трейсам. Проанализируй масштаб последствий и то, завершились ли заказы успехом в итоге. Покажи логи, трейсы и метрики за последние 36 часов."
Команда контролирует экраны, то, как они связаны между собой, и то, что происходит на каждом этапе расследования. Сравнение процессоров приводит к проблемным заказам, затем к истории заказа, а затем к привычному просмотрщику трейсов, перенося с собой соответствующие фильтры и временной диапазон. Это выходит за рамки простого создания дашборда: приложение связывает живые данные и переиспользуемые инструменты расследования в соответствии с тем, как должна работать ваша команда.
Этим приложениям необходима свобода в формировании запросов к данным. Приложение, ограниченное фиксированными конечными точками запросов (endpoints), в основном может лишь переупаковывать ответы, которые эти точки уже предоставляют. Другая визуализация не поможет, если лежащий в ее основе анализ неспособен ответить на вопрос.
Поддержка SQL в ClickHouse дала нам возможность продвинуться гораздо дальше. Приложению для обработки платежей необходимо рассчитывать базовые показатели для каждого процессора, связывать попытки оплаты с заказами и определять, какие сбои в итоге разрешились. Объединение этих результатов с данными о заказах может выявить ценность покупок, которые все еще не завершены. Эту бизнес-логику необходимо где-то выразить.
Это также требует анализа отдельных клиентов, заказов, клиентов (тенантов) и запросов. Следующий вопрос может касаться конкретного развертывания или комбинации атрибутов, которую никто не ожидал. База данных и механизм запросов должны поддерживать анализ с высокой кардинальностью, с достаточной детализацией и оперативностью для проведения расследования.
Некоторые пользователи уже делают это самостоятельно. Наша собственная команда наблюдаемости пишет SQL в блокнотах Python для создания визуализаций, которые наши существующие инструменты не предоставляют. Например, временная шкала Plotly показывает точное начало и конец сбора логов, что позволяет выявить дубликаты. Перед расследованием проблемы команде пришлось создать это представление.
Здесь график Plotly сопоставляет время сбора данных с реальным временем, причем каждый прямоугольник охватывает точное время начала и окончания сбора. Аннотации выделяют окно дублирующихся сборов, подтверждая перекрытие данных в этом диапазоне. Прежде чем мы смогли исследовать проблему, нам пришлось создать визуализацию. Подробнее здесь.
Здесь график Plotly сопоставляет время сбора данных с реальным временем, причем каждый прямоугольник охватывает точное время начала и окончания сбора. Аннотации выделяют окно дублирующихся сборов, подтверждая перекрытие данных в этом диапазоне. Прежде чем мы смогли исследовать проблему, нам пришлось создать визуализацию. Подробнее здесь.
Агенты потенциально делают эту возможность доступной для большего числа людей. Имея соответствующую схему и контекст, они могут писать и тестировать запросы, а затем создавать приложение, которое коллеги смогут исследовать. По мере изменения вопроса запросы и интерфейс могут развиваться вместе, а SQL остается доступным для проверки.
Сложность заключается в том, чтобы убедиться, что анализ отвечает именно на тот вопрос, который задумывал пользователь. Запрос может выполняться успешно и при этом подсчитывать неудачные попытки, в то время как вам нужны клиенты, которые не смогли произвести оплату. Как мы обсуждаем ниже, это один из главных вопросов, который нам еще предстоит решить надлежащим образом.
Сгенерированные приложения используют тот же уровень API, что и наши инструменты расследования и MCP-сервер. Они могут повторно использовать устоявшиеся операции для поиска логов, трассировки по цепочке и сравнения событий. Работа, которую мы вложили в корректность и производительность, переносится на эти приложения, обеспечивая согласованность общих операций во всех созданных на их основе интерфейсах.
Под этим скрывается ClickHouse в качестве общего слоя данных, где логи, трейсы и метрики сосуществуют в едином хранилище данных, позволяя выполнять корреляции прямо в механизме запросов. Когда для расследования требуется анализ, выходящий за рамки существующих инструментов, агенты могут использовать SQL для объединения сигналов, применения специфичной для бизнеса логики и изучения других наборов данных, причем запросы доступны для проверки.
OpenTelemetry также дает нам документированную модель того, что означают данные. Его семантические конвенции определяют имена атрибутов, типы, значения и ожидаемые результаты для ресурсов, логов, трейсов и метрик. Для телеметрии, которая следует этим конвенциям, у агента есть спецификация, на которую можно опираться при интерпретации схемы и написании запросов. В сочетании с контекстом о доступных для команды источниках данных это сокращает объем необходимых ему предположений.
Тот же принцип применим и к интерфейсу. Агент может импортировать повторно используемые UI-компоненты и подключать их к существующим инструментам расследования. Он может собирать графики, элементы управления и подробные представления вокруг проблемы, одновременно используя уже созданные нами поведение и стили. Это означает меньше кода для генерации и проверки, а также более единообразные приложения.
Агент начинает с контекста об источниках данных вашей команды, схемах и о том, как запрашивать данные OpenTelemetry в ClickStack. Он также получает инструкции по созданию приложений с помощью Apps SDK. Он тестирует запросы в ClickHouse перед добавлением их в приложение, в то время как линтеры выявляют распространенные ошибки SDK и стилизации.
Сгенерированное приложение работает в вашем браузере внутри изолированного фрейма (iframe). Оно не может делать сетевые запросы, переходить на другие страницы, загружать неутвержденные скрипты или напрямую читать вашу сессию ClickStack. Вместо этого оно отправляет сообщения с запросом определенных действий: запустить запрос, открыть панель трейсов или логов, либо изменить выбор времени. ClickStack проверяет эти сообщения, выполняет разрешенное действие и возвращает результат.
Запросы доступны только для чтения и выполняются с правами доступа к базе данных просматривающего пользователя. Общий доступ к приложению не означает предоставление доступа его создателя. В рамках этих ограничений вы получаете живые данные и привычные инструменты расследования.
После этого вы можете попросить агента изменить приложение, исправить что-то или изучить другой подход. Если его улучшения окажутся «улучшениями», вы сможете мгновенно вернуться к более ранней версии.
Запрос может выполняться успешно и при этом отвечать на неправильный вопрос. Подсчет неудачных попыток оплаты — это не то же самое, что подсчет клиентов, которые не смогли заплатить. Тестирование запросов и проверка кода выявляют некоторые ошибки, но они не доказывают, что приложение отражает то, что вы имели в виду.
Мы продолжаем улучшать наши оценки для измерения этого соответствия, а затем используем результаты для улучшения контекста, инструкций и инструментов агента. Мы также работаем над браузерным тестированием взаимодействия, более строгой проверкой типов и линтингом, а также состязательным ревью. Цель состоит в том, чтобы дать агенту лучшие способы находить собственные ошибки до того, как это сделаете вы. RBAC и изоляция обеспечивают принудительные границы, но до бета-тестирования мы продолжим повышать устойчивость к prompt injection (инъекциям промптов). В настоящее время мы явно помечаем результаты запросов, код существующего приложения, промпты предыдущих пользователей и сообщения об ошибках как неаутентифицированные (ненадежные) входные данные. Запись в логе может содержать инструкции; это не значит, что она может отдавать приказ. Это снижает риск, но мы не считаем эту проблему решенной, пока функция находится в закрытом предварительном просмотре (private preview).
Мы также расширяем наши повторно используемые компоненты устоявшейся логикой запросов и поведения, чтобы агентам не приходилось изобретать каждый график и фильтр с нуля. В перспективе мы хотим, чтобы команды создавали приложения и управляли ими через собственные агенты по протоколу MCP и с помощью подхода конфигурации как кода (configuration as code).
Observability Apps, доступные сейчас в режиме закрытого предварительного просмотра, дают мощь SQL в руки вашей команды. Опишите вопрос, позвольте агенту создать анализ и превратите его в интерактивное приложение, которое ваши коллеги смогут исследовать, не написав запросы самостоятельно.
Мы хотим видеть нестандартные вопросы, специфичную для бизнеса логику и расследования, которые не вписываются в привычные экраны.
SQL дает вам свободу задавать вопросы. Ваш интерфейс должен давать вам свободу исследовать.
