Раунд Series C на $100 млн от Groundcover меняет подход к выбору инструментов observability

Каждый VP Engineering, у которого в ближайшие два квартала заканчивается контракт с Datadog или New Relic, получил новый аргумент для разговора с CFO. Groundcover — тель-авивский вендор observability, построенный на eBPF и OpenTelemetry, — закрыл раунд Series C на $100 миллионов на неделе 31 июля. Значимость раунда определяется не столько тем, что он говорит о самой Groundcover, сколько тем, что он говорит о структуре статьи расходов на observability в вашем бюджете на 2027 год.

Что произошло

Как сообщил Network World, раунд Series C компании Groundcover возглавил One Peak при участии Morgan Stanley Expansion Capital, Zeev Ventures, Angular Ventures, Heavybit и Jibe. Таким образом, общий объём финансирования компании, основанной в 2021 году, достиг $160 миллионов. Раунду предшествовал Series B на $35 миллионов в апреле 2025 года — темп весьма агрессивный: примерно пятнадцать месяцев между B и C при почти утроении размера раунда.

Главная идея компании, по словам CEO и сооснователя Шахара Азулая, заключается в том, что observability переживает смену категории. «Я думаю, то, что сейчас происходит с observability, — это захватывающе», — сказал он Network World. Технологическая ставка — на eBPF, технологию ядра Linux на основе расширенного Berkeley Packet Filter, которая позволяет безопасно выполнять код внутри ядра Linux без кастомного модуля. Это даёт Groundcover такой угол обзора, которого не может обеспечить SDK-инструментирование. Коммерческая ставка — на то, что телеметрия из рабочих процессов агентного AI будет экспоненциально расти по объёму и чувствительности, и предприятия не захотят отправлять её в общий бэкенд стороннего вендора.

Именно поэтому Groundcover хранит телеметрию внутри облачной среды самого клиента. По этой же причине компания активно разрабатывает AI-продукты: Agent Mode — встроенный ассистент, позволяющий инженерам строить дашборды и анализировать логи и трейсы без написания запросов вручную, — а также интеграцию с Model Context Protocol, которая связывает Agent Mode с агентами для написания кода и инструментами рабочих процессов, включая Linear. Азулай отметил, что принятие MCP шло быстрее, чем ожидала компания.

Техническая архитектура

Здесь работают два архитектурных решения, и технические руководители должны разобраться в обоих, прежде чем соглашаться с питчем вендора.

Первое — eBPF как уровень сбора данных. Традиционная observability требует от разработчиков инструментировать код, подключать SDK и генерировать телеметрию в понятном вендору формате. Эта модель ломается, как только инженеры начинают подключать агентов LangChain, MCP-серверы и сторонних вендоров моделей, которых никто не каталогизировал. «eBPF — это своеобразная страховочная сеть: даже если вы ничего не инструментировали, даже если у вас нет полного контроля, вы будете знать, какие агентные рабочие процессы запущены в проде, какие модели используются, каких вендоров они используют», — сказал Азулай. Работа ниже прикладного уровня означает, что инструмент observability видит трафик и системные вызовы независимо от того, позаботилась ли команда разработки добавить трейсинг. Для команд, развёртывающих AI-функциональность на Kubernetes, это разница между знанием своих расходов на токены и неприятным сюрпризом в конце квартала.

Второе — хранение данных в облаке клиента (bring-your-own-cloud). Большинство SaaS-вендоров observability собирают телеметрию клиентов в мультитенантный бэкенд, который они сами и обслуживают. Это нормально работает для HTTP-логов запросов. Но работает плохо, когда трейсы содержат, как указал Азулай, реальный промпт клиента, а не только структурированные данные запроса. Промпты — это пользовательский контент. В зависимости от юрисдикции и отрасли они могут быть и регулируемым контентом. Хранение телеметрии внутри VPC клиента меняет разговор о месте хранения данных с анкеты вендора на архитектурную схему.

Третий сдвиг, который является следствием первых двух, касается того, что команды измеряют. Задержка и процент ошибок никуда не делись. Теперь рядом с ними появились использование токенов и процент галлюцинаций. Распределённый трейсинг, который предполагал предсказуемое количество переходов между сервисами, должен учитывать одну агентную сессию, разветвляющуюся на десятки вызовов инструментов и внутренних обращений к модели без фиксированного паттерна. Азулай прямо говорит: это не переименованный APM-продукт. «Это не будет тот же продукт. AI observability — это не то же самое, что APM».

Кто окажется в проигрыше

Текущие лидеры рынка. Если AI observability действительно является отдельной продуктовой категорией, а не надстройкой над существующим функционалом, то Datadog, New Relic, Splunk и Dynatrace оказываются в положении, в котором находились on-prem вендоры мониторинга примерно в 2015 году: они всё ещё продают старый продукт, наблюдая, как вокруг финансируется новый. Это не значит, что они проиграют. Это значит, что их модели ценообразования «за хост» и «за ГБ» начинают выглядеть неправильно для рабочих нагрузок, где один агентный трейс может содержать промпт размером в несколько килобайт.

CFO любой компании стадии Series B и выше со значительными расходами на AI-функциональность должен на этой неделе задать VP Engineering конкретный вопрос: какой процент нашего счёта за observability сейчас формируется телеметрией AI-нагрузок, и растёт ли эта статья быстрее, чем базовые вычислительные ресурсы? Если да, то разговор о продлении контракта с текущим вендором — это уже не разговор о продлении. Это разговор о пересмотре архитектуры, и инициатива остаётся за тем, кто принесёт альтернативное предложение.

Инженерные команды также несут потери — более скрытым образом. Если ваша платформенная команда два года назад стандартизировалась на SDK-инструментировании и написала внутренние библиотеки, оборачивающие клиент вендора, подход на основе eBPF не интегрируется чисто. Либо вы запускаете оба варианта (двойные расходы, двойная путаница), либо беретёсь за миграционный проект, который поглощает четверть мощностей платформенной команды. Ни то ни другое не бесплатно.

Рынок найма тоже меняется. Инженеры по observability, разбирающиеся в eBPF, трейсинге на уровне ядра и конвейерах OpenTelemetry, всегда были редкостью и стоили дорого. Добавьте к этому опыт интеграции MCP и проектирования телеметрии с учётом промптов — и вы получите узкий пул кандидатов, за которых будут конкурировать Groundcover, Chronosphere, Honeycomb и каждый AI-нативный стартап. Планируйте бюджет соответственно.

Практические рекомендации для инженерных команд

Во-первых, проверьте, что именно ваш текущий вендор observability реально фиксирует из ваших AI-нагрузок. Если ответ — «всё, что разработчики инструментировали вручную», у вас есть пробел в видимости, который проявится как инцидент в проде раньше, чем как строка в счёте. Азулай сравнил нынешний пробел в видимости AI с эпохой до observability примерно десятилетней давности. Он не ошибается, и команды, пережившие тот переход, помнят, насколько много боли было самоинфлировано из-за запоздалых решений по инструментарию.

Во-вторых, привлеките главного юрисконсульта к разговору об observability. Если трейсы теперь содержат промпты клиентов, ваши соглашения об обработке данных с вендором observability должны это отражать. Общий мультитенантный бэкенд, хранящий содержимое промптов, — это принципиально иная регуляторная позиция, чем хранение структурированных метаданных запросов. Архитектуры bring-your-own-cloud стоят операционных накладных расходов, если они снимают с повестки дня разговор о соответствии требованиям.

В-третьих, рассматривайте интеграцию с MCP как реальный критерий оценки, а не как пункт в демо. Описанная Азулаем модель, когда одни клиенты запрашивают observability через MCP вместо дашборда, а другие используют её для написания исправлений напрямую, — именно так будет работать дежурство по инцидентам в течение ближайших восемнадцати месяцев. Вендоры без убедительной MCP-истории уже негласно вытесняются в корпоративных RFP.

В-четвёртых, смоделируйте unit-экономику. Стоимость одного трейса, стоимость одного хранимого ГБ, стоимость одного активного агента. Если ваш роудмап AI-функциональности предполагает утроение объёма агентов в следующем году, просчитайте это число против вашего текущего контракта, прежде чем подписывать что-либо сроком более двенадцати месяцев.

Ключевые выводы

• Раунд Series C на $100 млн от Groundcover под руководством One Peak доводит общее финансирование до $160 млн и подтверждает AI observability как отдельную категорию, отличную от традиционного APM.
• Сбор данных на основе eBPF устраняет необходимость в SDK-инструментировании — это важно, когда инженерные команды теряют контроль над тем, какие агентные рабочие процессы и вендоры моделей работают в проде.
• Хранение телеметрии в облаке клиента (bring-your-own-cloud) становится регуляторным требованием, а не предпочтением, как только трейсы начинают содержать сырые промпты пользователей.
• Использование токенов и процент галлюцинаций теперь являются метриками observability первого класса наравне с задержкой и процентом ошибок. Контракты с вендорами, написанные до этого сдвига, имеют неправильное ценообразование.
• Принятие интеграции с MCP опережает ожидания вендоров. Команды, оценивающие платформы observability в этом квартале, должны спрашивать не о наличии AI-ассистента у вендора, а о том, как он передаёт контекст агентам для написания кода.