BYOC Logs решает задачу хранения логов (log management) на петабайтном уровне без потери наблюдаемости (observability). Это важно, когда рост telemetry начинает ломать классические self-hosted решения.
Проблема проявляется постепенно. С ростом cloud-native систем и AI-нагрузок объём логов растёт нелинейно. Каждый сервис и контейнер генерирует поток telemetry, который нужно хранить, анализировать и защищать. В self-hosted log management это приводит к фрагментации: данные размазаны по инструментам, масштабирование требует перераспределения данных, а эксплуатация превращается в постоянный rebalancing. Дополнительно накладываются требования по хранению и локализации данных (data residency), где часть логов нельзя выносить за пределы региона. В итоге команды теряют баланс между полной видимостью и контролем над данными.
Решение построено как гибридная модель: BYOC Logs (Bring Your Own Cloud) оставляет хранение в инфраструктуре пользователя, но сохраняет интеграцию с SaaS-платформой Datadog. Это компромисс между контролем и удобством. Ключевая архитектурная идея — разделение compute и storage. Логи хранятся в объектном хранилище (object storage), а вычислительный слой масштабируется независимо. Такой подход снимает необходимость перемещать данные при добавлении узлов. Trade-off здесь очевиден: зависимость от object storage как единого слоя хранения, но взамен — предсказуемое масштабирование и снижение операционных затрат.
Реализация опирается на несколько ключевых компонентов. Индексация происходит через запись “splits” напрямую в object storage. Метаданные отслеживаются через централизованный metastore, который делает данные доступными почти сразу. Поисковый слой stateless: coordinator получает запрос, находит нужные splits и распределяет нагрузку между search-узлами. Каждый узел читает данные напрямую из object storage, без локального хранения индексов. Это упрощает эксплуатацию и повышает отказоустойчивость. Дополнительно используются Observability Pipelines для нормализации, обогащения и фильтрации логов до индексации, что снижает стоимость и улучшает консистентность данных.
Отдельный слой — корреляция данных. BYOC Logs интегрирован с метриками и трассировками (APM), что позволяет анализировать инциденты в одном интерфейсе. В сценарии с деградацией API можно одновременно видеть logs, traces и metrics без переключения инструментов. Добавляется AI-слой: агент может формировать гипотезы и выполнять поиск через natural language query. Также заявлена поддержка MCP (Model Context Protocol), что даёт возможность подключать внешние AI-агенты для анализа observability-данных без кастомных интеграций.
С точки зрения результатов, система закрывает несколько узких мест. Масштабирование происходит без перераспределения данных. Хранение становится дешевле за счёт object storage и компрессии. Управление централизуется через единый UI. Однако точные метрики производительности или экономии в исходных данных не приведены. Можно говорить лишь о снижении операционной сложности и улучшении целостности наблюдаемости.
Отдельно стоит отметить use case безопасности. Логи от firewall, CDN и VPC традиционно создают high-volume нагрузку. В классической схеме это разбивается между SIEM и архивами, что увеличивает сложность. BYOC Logs консолидирует эти потоки, позволяя хранить большие объёмы и применять обогащение (например, через GeoIP или threat intelligence) до индексации. Это делает расследования более быстрыми за счёт структурированных данных и корреляции событий.
В итоге BYOC Logs — это эволюционное развитие log management архитектуры. Он переносит тяжёлую часть хранения в дешёвый и масштабируемый слой, оставляя аналитику и корреляцию на стороне платформы. Такой подход особенно актуален для гибридных и распределённых систем, где контроль над данными и единая observability-поверхность должны сосуществовать.