Я 18 лет работаю с инфраструктурой. И вот что заметил. Инструменты мониторинга становятся мощнее с каждым годом, а инциденты всё равно разбирают одни и те же люди руками. Открываешь пять дашбордов, сравниваешь графики глазами, ищешь корреляцию между логами и метриками вручную. На дворе 2026 год, а мы до сих пор играем в детектива.

Observability 3.0 - попытка это изменить. Не заменить инженера, а дать ему AI-напарника. Такого, который уже посмотрел на все дашборды, прочитал логи и готов ответить на вопрос - что сейчас не так и почему.

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

Что вы получите после прочтения

Конкретно. Без воды.

Понимание стека. Когда кто-то скажет посмотри в Grafana или проверь трейсы в Tempo, вы будете знать, что это такое и где искать. Не придётся гуглить каждый термин.

Скорость при инцидентах. Вместо 40 минут ручного поиска по SSH - 2 минуты в дашборде. А с AI-слоем - вопрос на человеческом языке и готовый анализ.

Язык для общения с DevOps. Термины exporter, scrape interval, trace span - не магия, а конкретные вещи, которые легко объяснить.

Что нужно для экспериментов

Чтобы попробовать весь стек у себя на машине, достаточно ноутбука и Docker Desktop. Вот минимальный набор.

Ноутбук или настольный ПК

Windows 10/11, macOS или Linux
8 GB RAM минимум, 16 GB рекомендуется
20 GB свободного места на диске

Docker Desktop

Для Windows и macOS - скачать с docker.com/products/docker-desktop
Для Linux - можно поставить Docker Engine через пакетный менеджер, docs.docker.com/engine/install
Docker Compose идёт в комплекте с Docker Desktop

Текстовый редактор

VS Code (code.visualstudio.com) подойдёт для редактирования конфигурационных файлов

Терминал

На macOS и Linux уже есть
На Windows используйте PowerShell или Windows Terminal

Весь стек разворачивается одной командой docker compose up. Конфигурационные файлы можно взять из репозитория автора оригинальной статьи на GitHub.

Три сценария. Было, стало, будет

Было. Классический мониторинг

Пользователь пишет - сайт тормозит. Вы заходите по SSH, запускаете top, free -m, df -h, читаете логи через tail -f /var/log/. Через 40 минут находите, что диск забит. Или не находите и эскалируете с пометкой - что-то тормозит, надо смотреть.

Стало. Observability 2.0, дашборды

Пользователь пишет - сайт тормозит. Вы открываете Grafana, видите красный график CPU на одном из серверов. Кликаете и видите, что контейнер api-gateway съел всю память 15 минут назад. Рядом в Loki логи с OutOfMemoryError. Причина найдена за 2 минуты.

Будет. Observability 3.0, AI

Пользователь пишет - сайт тормозит. Вы спрашиваете AI - что сейчас не так с рабочей средой. Ответ - контейнер api-gateway перезапускался 3 раза за последний час. Потребление памяти выросло с 512MB до 2GB за 4 часа. В логах повторяется ошибка на эндпоинте /api/reports, не освобождаются соединения с базой. Рекомендация - проверить connection pool в конфигурации сервиса. Эскалируете с конкретной причиной и рекомендацией.

Из чего состоит стек

Весь стек делится на три слоя. Каждый делает свою работу. Поток данных идёт снизу вверх

┌─────────────────────────────────────────────────┐
│  AI-слой                                        │
│  Open WebUI → GTS/MCP → n8n → Grafana API       │
│  Ollama (LLaMA, Mistral, Phi-4)                 │
├─────────────────────────────────────────────────┤
│  Хранение и визуализация                        │
│  Prometheus (метрики) + Loki (логи) + Tempo      │
│  Grafana (дашборды) + Alertmanager (алерты)      │
├─────────────────────────────────────────────────┤
│  Сбор данных                                    │
│  Node Exporter + cAdvisor + PG Exporter          │
│  Promtail/Alloy + OpenTelemetry Collector        │
│  ваши серверы, контейнеры, базы данных           │
└─────────────────────────────────────────────────┘

Слой 1. Сбор данных, агенты

На каждом сервере и в каждом контейнере работают маленькие программы. Они собирают числа и текст, и отправляют дальше.

Node Exporter - здоровье самого Linux-сервера. CPU, память, диск, сеть
cAdvisor - здоровье каждого Docker-контейнера
PostgreSQL Exporter - здоровье базы данных. Запросы, кэш, блокировки
Promtail - читает файлы логов и отправляет их на хранение
OpenTelemetry - универсальный коллектор. Умеет собирать и метрики, и логи, и трейсы

Подробнее об этих инструментах в статье Метрики и дашборды.

Слой 2. Хранение и визуализация

Данные от агентов надо где-то хранить и как-то показывать.

Prometheus - хранит метрики. Числа вроде CPU 85%, память 2GB, 500 запросов в секунду
Loki - хранит логи. Текстовые записи вроде ERROR connection refused at 14:32:05
Tempo - хранит трейсы. Путь запроса через сервисы - от API до базы и обратно
Grafana - показывает всё это в виде дашбордов с графиками
Alertmanager - отправляет уведомления когда что-то пошло не так

Подробнее в статьях Метрики и дашборды и Логи и трейсы.

Слой 3. AI, то самое 3.0

Поверх мониторинга ставится AI, который умеет читать данные из Prometheus, Loki и Tempo и отвечать на вопросы.

Ollama - запускает AI-модель прямо на вашем сервере. Данные никуда не уходят
MCP - протокол, через который AI подключается к Grafana и другим системам
Claude Desktop / Open WebUI - интерфейс, где вы задаёте вопросы AI
n8n - автоматизация. Когда пришёл алерт, спросить AI о причинах и отправить анализ в Slack

Подробнее в статье AI-слой. Ollama, MCP и автоматизация.

Плюсы и минусы. Честно

Что реально хорошо

Всё бесплатное и open-source. Prometheus, Grafana, Loki, Tempo, OpenTelemetry, Ollama. Ни за что платить не надо
AI работает локально. Через Ollama модель крутится на вашем сервере. Данные мониторинга не уходят наружу. Это важно для компаний с требованиями по безопасности
Корреляция из коробки. Grafana умеет связывать метрики, логи и трейсы. Видите всплеск ошибок - кликаете и читаете конкретные логи за этот период. Без ручного поиска
Снижает порог входа. С AI-слоем не надо помнить синтаксис PromQL или LogQL. Спрашиваешь на человеческом языке, AI пишет запрос за тебя
Масштабируется. Один сервер или тысяча - стек работает одинаково

Что стоит учитывать

Порог входа при установке. Настроить весь стек с нуля - задача не на один вечер. Docker Compose помогает, но конфигурация каждого компонента требует понимания
Ресурсы. Prometheus, Loki, Tempo, Grafana, Ollama - каждый сервис ест память и CPU. На слабом сервере всё вместе не поместится
AI галлюцинирует. Модель может уверенно написать чушь. Всегда проверяйте то, что AI выдал, по реальным данным в дашборде. AI - помощник, не источник истины
Promtail устарел. Grafana Labs объявили о прекращении поддержки Promtail с февраля 2025 года. Замена - Grafana Alloy. Если ставите с нуля, лучше сразу Alloy
Кривая обучения. PromQL и LogQL - мощные языки запросов, но не интуитивные. Без AI-слоя придётся их учить

Ресурсы. Что нужно для запуска

Вот минимальные требования для каждого варианта.

Минимальный стек. Метрики и дашборды

Prometheus + Grafana + Node Exporter + Alertmanager

CPU - 2 ядра
RAM - 4 GB
Диск - 20 GB, хватит на 2 недели метрик
Подходит - небольшая команда, 3-5 серверов

Полный стек наблюдаемости

Добавляем Loki + Tempo + Promtail/Alloy + OpenTelemetry

CPU - 4 ядра
RAM - 8-16 GB
Диск - 50-100 GB. Логи занимают много места
Подходит - средняя инфраструктура, 10-50 серверов

Полный стек + AI

Добавляем Ollama с моделью 7-8B параметров

CPU - 4-8 ядер
RAM - 16-32 GB. Модель на 7B занимает около 4-8 GB RAM
GPU - не обязателен, но с ним быстрее. Модель на 7B работает и на CPU
Диск - 100+ GB
Подходит - команда, которая хочет AI-анализ инцидентов

Для облака - один VPS на 8 ядер, 32 GB RAM, 200 GB SSD обойдётся в $50-100 в месяц в зависимости от провайдера. Это цена одного не вовремя найденного инцидента.

Где это применимо, а где нет

Имеет смысл

Микросервисы и контейнеры. Когда у вас 20 сервисов в Docker или Kubernetes и непонятно, где именно тормозит
Команда поддержки L2. Когда надо быстро находить причину и эскалировать с данными, а не с формулировкой - что-то не работает
Dev и staging окружения. Ловить проблемы до того, как они дойдут до рабочей среды
Несколько серверов. Как только серверов больше двух, ходить по SSH на каждый уже боль

Не имеет смысла

Один сервер с одним приложением. Проще поставить htop и смотреть логи напрямую. Стек мониторинга будет занимать больше ресурсов, чем само приложение
Нет человека для поддержки. Стек требует внимания. Обновления, ротация логов, настройка алертов. Если некому этим заниматься, он превратится в ещё одну проблему
Закрытые корпоративные среды. Если в компании уже есть Zabbix/Nagios/Datadog и бюджет на них, переход на open-source стек может не стоить усилий

Заключение

Observability 3.0 - не новый продукт и не маркетинговый термин. Это идея. Мониторинг должен не просто собирать данные, а помогать их понимать. AI-слой поверх Prometheus, Grafana, Loki и Tempo превращает сырые графики в ответы на человеческом языке.

Для инженера поддержки это означает конкретные вещи

Инцидент разбирается за минуты, а не за час
Эскалация идёт с данными, а не с догадками
Не надо помнить синтаксис запросов - AI напишет за вас
Меньше стресса, потому что AI как второй инженер, который уже посмотрел на все дашборды

Весь стек бесплатный. AI можно запустить локально. Начать можно с малого - Prometheus + Grafana + один exporter. Потом добавить логи, трейсы, AI. Шаг за шагом.

Главное - не пытаться поставить всё сразу. Начните с метрик, привыкните к дашбордам, потом наращивайте.

В следующих статьях разберём каждый слой подробно

На основе серии статей Cumhur M. Akkaya об Observability 3.0 AI-Powered APM. Адаптировано и упрощено для инженеров поддержки.

Observability 3.0 простыми словами. Мониторинг с AI для тех, кто на передовой