Раунд Series C Groundcover на $100M змінює підхід до вибору інструментів моніторингу

Кожен VP Engineering, якому найближчі два квартали загрожує продовження контракту з Datadog або New Relic, щойно отримав новий аргумент для розмови з CFO. Groundcover, тель-авівський вендор у сфері моніторингу (observability), побудований на eBPF та OpenTelemetry, закрив раунд Series C на $100 мільйонів на тижні 31 липня. Цей раунд важливий не стільки тим, що він говорить про сам Groundcover, скільки тим, що він говорить про вигляд рядка «моніторинг» у вашому бюджеті на 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 — технологія ядра розширеного Berkeley Packet Filter, яка дозволяє безпечно виконувати код усередині ядра Linux без кастомного модуля — дає Groundcover таку точку огляду, якої не може досягти інструментування на основі SDK. Комерційна ставка полягає в тому, що телеметрія від агентних AI-робочих процесів вибухнеобразно зростатиме в обсязі та чутливості, і підприємства не захочуть передавати її на спільний бекенд вендора.

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

Технічна анатомія

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

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

Друге — це зберігання даних у власній хмарі клієнта (bring-your-own-cloud). Більшість SaaS-вендорів з моніторингу приймають клієнтську телеметрію в мультитенантний бекенд, яким вони керують. Це чудово працює для логів HTTP-запитів. Але погано працює тоді, коли трейси містять, як зазначив Азулай, реальний промпт клієнта, а не лише структуровані дані запиту. Промпти — це контент користувача. Залежно від юрисдикції та галузі, вони також можуть бути регульованим контентом. Зберігання телеметрії всередині VPC клієнта перетворює розмову про резидентність даних із опитування вендора на архітектурну схему.

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

Хто програє

Старі гравці. Якщо AI observability справді є окремою категорією продуктів, а не просто доданою функцією, то Datadog, New Relic, Splunk і Dynatrace перебувають у тому самому становищі, що й вендори on-prem моніторингу приблизно у 2015 році: продають старе, спостерігаючи, як навколо них фінансується нове. Це не означає, що вони програють. Це означає, що їхні моделі ціноутворення за хостом і за ГБ починають виглядати неправильно для навантажень, де один агентний трейс може містити промпт-навантаження розміром у кілька кілобайт.

CFO будь-якої компанії на рівні Series B або вище зі значними витратами на AI-функції має поставити VP Engineering конкретне запитання цього тижня: який відсоток нашого рахунку за моніторинг зараз зумовлений телеметрією AI-навантажень, і чи цей рядок зростає швидше, ніж базові обчислення? Якщо так, то розмова про продовження контракту з поточним вендором — це вже не розмова про продовження. Це розмова про переархітектуру, і перевага на боці того, хто принесе альтернативну пропозицію.

Інженерні команди також страждають, але менш очевидним чином. Якщо ваша платформна команда два роки тому стандартизувала інструментування на основі SDK і написала внутрішні бібліотеки, що обгортають клієнт вендора, то підхід на основі eBPF не вписується туди органічно. Або ви запускаєте обидва (подвійні витрати, подвійна плутанина), або берете на себе проект міграції, який з'їдає чверть потужності платформи. Жоден варіант не є безкоштовним.

Ринок найму теж змінюється. Інженери з моніторингу, які розуміються на eBPF, трасуванні на рівні ядра та пайплайнах OpenTelemetry, були рідкісними й дорогими. Додайте досвід інтеграції MCP і проектування телеметрії з урахуванням промптів — і ви дивитеся на невелику кількість кандидатів, за яких конкуруватимуть Groundcover, Chronosphere, Honeycomb і кожен AI-нативний стартап. Плануйте бюджет відповідно.

План дій для інженерних команд

По-перше, проведіть аудит того, що ваш поточний вендор з моніторингу реально збирає з ваших AI-навантажень. Якщо відповідь — «те, що наші розробники інструментують вручну», у вас є прогалина у видимості, яка проявиться як виробничий інцидент раніше, ніж як рядок у звіті. Азулай порівняв поточну прогалину у видимості AI із до-моніторинговою ерою приблизно десятиліття тому. Він правий, і команди, які пережили той перехід, пам'ятають, скільки болю було завдано самостійно через відкладені рішення щодо інструментів.

По-друге, залучіть головного юрисконсульта до розмови про моніторинг. Якщо трейси тепер містять промпти клієнтів, ваші угоди про обробку даних з вендором моніторингу мають це відображати. Спільний мультитенантний бекенд, що зберігає вміст промптів, — це інша регуляторна позиція, ніж структуровані метадані запитів. Архітектури bring-your-own-cloud варті операційних витрат, якщо вони знімають з порядку денного розмову про відповідність нормативним вимогам.

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

По-четверте, змоделюйте юніт-економіку. Вартість за трейс, вартість за збережений ГБ, вартість за активного агента. Якщо ваш роадмап AI-функцій передбачає потроєння обсягу агентів наступного року, прорахуйте цю цифру відносно вашого поточного контракту, перш ніж підписувати будь-що на строк понад дванадцять місяців.

Ключові висновки

• Раунд Series C Groundcover на $100M, очолений One Peak, доводить загальне фінансування до $160M і підтверджує AI observability як окрему категорію від традиційного APM.
• Збір даних на основі eBPF усуває необхідність інструментування через SDK, що стає дедалі важливішим, коли інженерні команди втрачають контроль над тим, які агентні робочі процеси та постачальники моделей працюють у продакшені.
• Зберігання телеметрії у власній хмарі клієнта стає регуляторною вимогою, а не лише перевагою, щойно трейси починають містити сирі промпти клієнтів.
• Використання токенів і частота галюцинацій тепер є метриками моніторингу першого рівня поряд із затримкою та частотою помилок. Контракти з вендорами, укладені до цього зсуву, мають неправильне ціноутворення.
• Впровадження інтеграції MCP випереджає очікування вендорів. Команди, що оцінюють платформи моніторингу цього кварталу, мають запитувати не про те, чи є у вендора AI-асистент, а про те, як він передає контекст кодувальним агентам.