Пока индустрия спорит, как называть современный стек наблюдаемости — observability 2.0 или уже 3.0, — за терминологией прячутся три конкретных сдвига. Инструментация ушла из кода в ядро (eBPF). Телеметрия стандартизировалась вокруг OpenTelemetry. А поиск причины начал переезжать с человека на машину. Каждый следующий слой окупается, только если нижний в порядке, — и именно порядок инвестиций команды чаще всего путают.
Мониторинг отвечает «работает ли». Observability — «почему нет»
Мониторинг отвечает на вопросы «работает ли система и насколько быстро». Observability — на «почему медленно и где именно». В Kubernetes без второго не закрываются кросс-компонентные инциденты: симптом «latency вырос» невозможно связать с причиной «нода ушла в MemoryPressure, kubelet выселил поды, endpoints сервиса флапали», если видишь только метрики приложения.
Поэтому к классическим трём столпам — метрики, логи, трейсы — в Kubernetes добавляется четвёртый сигнал: события кластера и метадата ворклоадов. OOMKill'ы, evictions, решения HPA, отказы scheduler'а, admission-реджекты — это лента решений оркестратора, и без неё разбор инцидента превращается в «ребутнули и заработало».
Инструментация ушла в ядро
Годами цена входа в distributed tracing была высокой: SDK в каждый сервис, релиз, регресс. eBPF снял этот барьер. OBI — OpenTelemetry eBPF Instrumentation — ставится DaemonSet'ом и за день даёт кластеру baseline без единого изменения кода: RED-метрики, трейсы HTTP и gRPC, service-to-service потоки, активность БД и — неожиданный бонус — видимость TLS-трафика без расшифровки, потому что перехват происходит на уровне syscall'ов до шифрования. Требования скромные: ядро Linux 5.8+ и права на BPF.
У eBPF есть потолок: он видит сеть и syscall'ы, но не бизнес-контекст — какой order_id, какой tenant. Отсюда рабочее правило «Observe first. Instrument later.»: сначала eBPF-baseline на весь кластер, затем auto-instrumentation на инфраструктурном уровне для polyglot-парка, и только на критичных, revenue-impacting путях — ручной SDK с кастомными атрибутами. Инструментация перестаёт быть заботой разработчика и становится заботой платформы.
OpenTelemetry — контракт, а не инструмент
OTel — это стандарт: единые SDK, семантические конвенции и wire-протокол. Инструментируешь приложение один раз — экспортируешь куда угодно, от Tempo до vendor-APM, без lock-in. Семантические конвенции (service.name, k8s.pod.name, http.status_code) дают всем сигналам общий словарь — а общий словарь и сквозной trace_id это то, что превращает три хранилища в одну систему.
Важно для brownfield: OTel не требует выбрасывать существующий Prometheus или VictoriaMetrics. Экспортёр prometheusremotewrite пишет метрики в тот же TSDB; scrape остаётся для legacy-целей, коллектор добавляется для новых. Миграция — эволюция, не революция.
AI-слой: LLM никогда не видит метрику первым
Соблазн «отправим метрики в GPT, он найдёт аномалии» разваливается на реальных данных: слишком медленно, слишком дорого, недетерминированно. Продакшн-паттерн другой — filter cheap, escalate smart. Дешёвые детекторы снимают 95–99% событий до всякого AI: Isolation Forest на метриках (инференс — микросекунды), Drain3-майнинг шаблонов на логах, частотные baseline'ы. LLM получает только эскалированный остаток — «неизвестное» и «всплески» — и делает то, что умеет: рассуждает над грязным контекстом, связывает сигнал с недавними деплоями и пишет черновик постмортема. Это разделение труда, а не конкуренция: ML — численный thresholding в масштабе, LLM — reasoning.
Вторая опора AI-слоя — корреляция с изменениями: 70–80% продакшн-инцидентов связаны с change'ами. Deploy-маркеры из ArgoCD, конфиг-изменения, IAM-мутации из audit-лога — отдельный поток событий рядом с телеметрией. При аномалии первый вопрос машины тот же, что у опытного SRE: «что деплоили за последний час?»
Цифры отрасли отрезвляют: лидеры снимают 40–70% MTTR, но полностью операционализировали AI лишь 4% организаций, а половина застряла в пилотах. Парадокс: бюджеты на observability выросли на 70%, а ручной toil — на 30%. Причина — AI, прикрученный поверх фрагментированного стека без единого контекстного слоя, работает с замочной скважиной вместо картины.
Порядок инвестиций
Слои окупаются строго снизу вверх. Сначала — единый сигнальный слой: OTel, сквозной trace_id, четвёртый сигнал из событий кластера. Затем — покрытие без кода: eBPF-baseline и auto-instrumentation от платформы. Потом — дешёвые ML-фильтры и поток change-событий. И только на этом фундаменте — LLM для root-cause. AI в observability — крыша, а не фундамент: строить с неё — значит оплачивать токенами просмотр десяти тысяч метрик, с которым справляется модель в пятьдесят строк.