Если вы управляете инфраструктурой для ИИ-агентов, то уже знаете: автономные системы генерируют колоссальный объем телеметрии. Традиционные платформы наблюдаемости, которые часто тарифицируют сбор и хранение данных, могут сделать масштабирование менее предсказуемым. Стартап groundcover предлагает другой подход, но его преимущества зависят от структуры вашей инфраструктуры и требований к данным. (source)
Компания привлекла 100 млн долларов в раунде под руководством One Peak, доведя общий объем финансирования до 160 млн долларов. По данным самой компании, у нее более 250 платящих клиентов, а годовая регулярная выручка за последний год утроилась. Эти показатели не подтверждены независимыми исследованиями, но показывают интерес инвесторов к альтернативам традиционной модели наблюдаемости.
Почему рост ИИ-телеметрии меняет расчет стоимости
Классические платформы вроде Datadog и New Relic исторически строили значительную часть экономики вокруг объема данных. ИИ-агенты меняют нагрузку: они выполняют многошаговые сценарии, вызывают внешние инструменты и взаимодействуют с рабочими системами в реальном времени. Вместе с этим растет объем логов, метрик и трассировок, которые организациям важно сохранить для отладки и анализа.
Чтобы не допустить резкого роста счета, инженеры часто сокращают сроки хранения, используют сэмплирование, то есть сохраняют только часть событий, или ограничивают сбор данных отдельными узлами. Расходы снижаются, но вместе с ними исчезает контекст, который особенно нужен при расследовании ошибок в автономных системах.
«Мы не берем деньги за объем данных. Мы берем деньги за размер инфраструктуры», сказал основатель и генеральный директор groundcover Шахар Азулай.
Именно здесь появляется главный вопрос для покупателя: станет ли объем телеметрии узким местом при масштабировании ИИ или текущая платформа уже справляется с этой нагрузкой по приемлемой цене.
BYOC переносит основной массив данных в облако клиента
groundcover использует модель Bring Your Own Cloud (BYOC). В ней полный дата-плейн наблюдаемости, то есть компоненты, которые собирают, обрабатывают и хранят телеметрию, разворачивается в облачной учетной записи клиента. Поддерживаются AWS, Microsoft Azure и Google Cloud. Контрольный план отвечает за управление сервисом, а пользовательский интерфейс дает доступ к данным и расследованиям.
Это не означает автоматически, что абсолютно никакая информация не покидает облако клиента. Перед внедрением стоит отдельно проверить, какие метаданные, сведения о конфигурации, учетные данные, данные поддержки и сетевые запросы обрабатываются компонентами groundcover. В документации также следует уточнить регион размещения и полный маршрут данных для конкретного варианта развертывания.
1. Предсказуемее расходы при высокой плотности телеметрии
Компания заявляет, что тарифицирует инфраструктуру по числу хостов, а не по объему телеметрии. В опубликованном 22 марта 2026 года материале самообслуживаемый Enterprise-план указан по цене 35 долларов за хост в месяц. Это ориентир из публикации компании, а не универсальная итоговая стоимость: отдельно нужно учитывать расходы на собственное облако, хранение, обработку и сетевой трафик.
Такая модель может быть особенно интересна организациям, где каждый хост генерирует много данных. Если серверов много, а событий мало, тарификация по хостам может оказаться менее выгодной, чем модель с оплатой за объем.
2. Больше контроля над чувствительной телеметрией
По материалам groundcover, в BYOC-модели чувствительные промпты и ответы ИИ остаются в облачной учетной записи клиента. Это потенциально упрощает внутренний контроль над данными, но само по себе не гарантирует соответствие требованиям безопасности или законодательства. Для этого нужно сопоставить фактические потоки данных с правилами вашей организации и применимыми требованиями.
Для российских команд важна и практическая сторона закупки: продукт представлен в российской локали Microsoft Azure Marketplace. Однако перед покупкой стоит проверить доступность нужного региона, способ оплаты и условия конкретного предложения.
eBPF сокращает объем ручной настройки
Чтобы собирать данные, groundcover использует eBPF. Это технология Linux, которая позволяет наблюдать за сетевым трафиком, системными вызовами и работой приложений из ядра операционной системы. Проще говоря, часть наблюдения выполняется на уровне самой системы, поэтому разработчикам не всегда нужно вручную добавлять код в каждое приложение.
Такой подход может ускорить развертывание и расширить покрытие, особенно в Kubernetes-кластерах и других распределенных системах. При этом eBPF не является уникальной особенностью groundcover. Его используют и другие поставщики наблюдаемости. Отличие, на котором настаивает компания, состоит в сочетании eBPF, BYOC, совместимости с OpenTelemetry и тарификации по хостам.
Agent Mode показывает, как наблюдаемость меняется вместе с ИИ
В продукте есть Agent Mode. Он помогает инженерам расследовать инциденты на естественном языке, используя логи, метрики, трассировки и события Kubernetes. Для неспециалиста это означает более простой способ задать вопрос о сбое без ручного поиска по нескольким разделам интерфейса.
В будущем производственный контекст может использоваться как обратная связь для кодинг-агентов. Тогда наблюдаемость будет нужна не только человеку, который ищет причину сбоя, но и ИИ, который оценивает последствия изменений. Сейчас, согласно описанию компании, человек остается в контуре принятия решений.
2 июня 2026 года groundcover объявила о нативной поддержке Microsoft Azure и расширении Agent Mode. 17 июня компания опубликовала материалы по наблюдаемости LLM, включая сбор данных без ручного внедрения кода в отдельные модели и приложения. Это показывает направление развития продукта, но не доказывает, что автоматизация уже полностью заменяет инженера.
Когда переход имеет смысл, а когда лучше сравнить цены
BYOC не является универсальным решением. Он выглядит логичнее, если ваша инфраструктура создает много телеметрии на один хост, счета за сбор данных трудно прогнозировать, а контроль над размещением телеметрии важен для внутренних процессов.
Если у вас много малоактивных серверов, собственные расходы на облако уже высоки или действующая платформа дает нужную глубину анализа по приемлемой цене, переход может не окупиться. Сравнивать нужно не только тариф вендора, но и стоимость хранения, обработки, исходящего трафика, сопровождения и миграции.
Практичный следующий шаг прост: возьмите фактический объем телеметрии за месяц, число хостов и требования к хранению, затем посчитайте оба сценария. Если рост ИИ-нагрузки увеличивает данные значительно быстрее, чем число хостов, модель с оплатой за инфраструктуру может сделать расходы спокойнее и сохранить больше операционного контекста. Но окончательное решение стоит принимать только после проверки полного маршрута данных и условий именно вашего развертывания.
