26 августа 2026 года в центре разговора про observability оказались не дашборды и не алерты, а банальная экономика хранения. Чем лучше компании собирают данные observability через OpenTelemetry, тем быстрее выясняется неприятная деталь: хранить, индексировать и разбирать этот поток становится слишком дорого, особенно если поверх обычных сервисов в проде появляются AI-агенты.
Об этом сообщает The New Stack: отрасль фактически закрыла старую проблему инструментирования, но вместо нее получила новую узкую горловину — телеметрию теперь можно собирать почти отовсюду, а вот дешево и без потерь работать с ней по-прежнему трудно. Для русскоязычной IT-аудитории это важный сигнал без лишней экзотики: если команда уже внедрила OpenTelemetry или только идет к нему, следующий счет за observability может оказаться более убедительным аргументом, чем любой архитектурный доклад.
Сбор стандартизировали, хранение осталось дорогим
Ключевой тезис материала простой: OpenTelemetry в 2026 году де-факто закрепился как стандартный слой для инструментирования и сбора телеметрии. На это прямо указывает Северин Нойманн, глава community в Bronto, мейнтейнер OpenTelemetry и участник governance committee проекта. По его словам, индустрия по сути решила проблему сбора данных и сильно снизила зависимость от проприетарных агентов. Но именно этот успех и вскрыл следующий уровень проблемы: если компания наконец может собирать больше трассировок, логов и метрик, ей нужно где-то это хранить так, чтобы не разориться и не потерять смысл по дороге.
Нойманн формулирует это без романтики: если предприятие не может хранить телеметрию и вынуждено выбрасывать большие ее куски, ни люди, ни AI-агенты не смогут нормально разобраться в происходящем. Это особенно болезненно для распределенных систем, где ценность часто сидит не в «средней температуре по больнице», а в редких аномалиях, длинных хвостах по latency и странных цепочках вызовов. Ирония в том, что observability много лет продавали как способ убрать слепые зоны, а теперь сами платформы нередко заставляют клиента решать, какие слепые зоны он готов себе позволить ради бюджета.
В материале The New Stack Парсонс описывает эту ситуацию еще жестче: заказчики режут retention, включают sampling, потом при необходимости пытаются «rehydrate» данные, то есть возвращать часть телеметрии в анализ из более дешевых слоев хранения. На практике это означает, что команда платит за инфраструктуру наблюдаемости, но видит не всю картину и не всегда в тот момент, когда это действительно нужно. Вендор вроде бы предлагает доступ к вашим же данным, но с оговорками: либо храните недолго, либо храните не все, либо готовьтесь к более медленному доступу. Компромисс, конечно, красиво упакован, но от этого не становится менее дорогим.
AI добавит не магии, а телеметрии
Отдельный нерв текста — влияние AI-нагрузок на уже перегретую модель observability. Если обычные сервисы генерируют много телеметрии, то AI-системы и особенно агентные сценарии делают это с гораздо меньшей дисциплиной. Они могут запускать повторные шаги, звать несколько моделей подряд, дергать инструменты, разветвлять workflow и создавать события там, где раньше был один линейный запрос. Для платформ observability это означает не просто рост объема, а рост шумного, неоднородного и местами плохо предсказуемого потока, который хочется сохранять ради расследований, но не хочется оплачивать по текущим тарифам.
Именно здесь всплывает главный конфликт бизнес-модели. По словам Парсонса, многие традиционные observability-вендоры до сих пор берут деньги прежде всего за хранение данных, а не за реальную ценность, которую команда из этих данных извлекает. Логика знакомая любому техдиректору: счет капает даже тогда, когда данные никто не ищет и не анализирует. Пользователь платит за сам факт накопления телеметрии, а не за полезный ответ на вопрос «почему упал сервис», «где деградировал API» или «что именно сделал агент перед инцидентом». Для клиентов это все больше похоже не на инженерный инструмент, а на очень дорогой склад, доступ к которому еще и не всегда удобен.
С этой оценкой в материале перекликается Ноэл Руэйн. Он прямо говорит, что крупные игроки вроде Datadog понимают шаткость своей модели и пытаются обороняться продуктовыми надстройками. В качестве примеров он упоминает Flex Logs и партнерство с ClickHouse. Но вместо простого ответа на вопрос о стоимости рынок, по его мнению, часто добавляет клиентам еще один слой сложности. И это, пожалуй, самый неприятный вывод для покупателя observability: проблема уже не в том, что данных мало или стандартов нет. Проблема в том, что стандарт появился, объем данных вырос, а экономика платформ и UX для работы с ними не успели перестроиться.
Для разработчиков и SRE здесь вывод вполне прикладной. Переход на OpenTelemetry сам по себе не гарантирует, что расходы станут контролируемыми. Скорее наоборот: после стандартизации сбора телеметрии организация получает техническую возможность собирать больше, чем раньше, и очень быстро упирается в вопрос политики хранения, маршрутизации и отбора сигнала. Для продактов и фаундеров урок еще прозаичнее: AI-фичи в продукте увеличивают не только расходы на модели и inference, но и стоимость сопровождения, потому что данные observability начинают разрастаться вместе с числом вызовов, ретраев и промежуточных шагов. Для HR и руководителей платформенных команд это тоже полезный маркер: рынок будет все активнее искать инженеров, которые умеют не просто подключить OTel SDK, а проектировать телеметрийные пайплайны с учетом retention, sampling и стоимости запроса к данным.
Если коротко, индустрия observability постепенно сдвигается из эпохи «собери все» в эпоху «собери осмысленно и храни по ценности». OpenTelemetry помог убрать барьеры на входе, но этим же вывел наружу старую слабость рынка: хранение и анализ телеметрии по-прежнему стоят так, будто данных мало и они идут от предсказуемых систем. С AI это допущение больше не работает. И следующий большой раунд конкуренции, похоже, пройдет уже не за лучший агент или самый красивый интерфейс, а за право убедительно ответить на вопрос, сколько на самом деле должны стоить данные observability и кто платит за их смысл, а не за их вес. Подробности разбора можно посмотреть в .