AIOps на VPS: self-hosted ИИ-мониторинг open source

Datadog и New Relic берут плату за хост, за ГБ или и то, и другое. Для одиночного разработчика или небольшой команды, управляющей одним-пятью VPS, эти расходы быстро накапливаются при малой отдаче. Актуальные цены смотрите на странице цен Datadog и странице цен New Relic.

Альтернатива: запустить весь стек мониторинга, анализа логов и реагирования на инциденты на одном VPS. Open-source инструменты вроде SigNoz, Grafana+Loki и Ollama дают наблюдаемость, обнаружение аномалий на основе ИИ и автоматическое исправление. Общая стоимость: цена вашего VPS. На Virtua Cloud это от 24 EUR/мес за сервер с 2 vCPU и 4 ГБ RAM для базовой наблюдаемости, или 48 EUR/мес за полный стек на сервере с 4 vCPU и 8 ГБ RAM.

Эта статья описывает пять уровней self-hosted AIOps-стека. Это не пошаговый туториал. Каждый раздел объясняет, что делает уровень, рекомендует инструменты и ссылается на отдельное подробное руководство, где вы всё устанавливаете и настраиваете.

Что такое AIOps и зачем это VPS-операторам?

AIOps — это использование ИИ и машинного обучения для автоматизации мониторинга, анализа логов, обнаружения аномалий и реагирования на инциденты. Для операторов VPS это замена ручного цикла: проверять дашборды, читать логи, перезапускать сервисы. Вместо оплаты корпоративных SaaS-платформ вы запускаете open-source инструменты на той же инфраструктуре, которой уже управляете. Ваши данные остаются на вашем сервере. Ваши расходы остаются фиксированными.

Корпоративное определение AIOps сосредоточено на корреляции тысяч алертов по сотням микросервисов. Это не тема данного руководства. Для операторов VPS, управляющих одним-пятью серверами, AIOps означает:

Собирать метрики, логи и трейсы в одном месте вместо SSH на каждый сервер.
Запускать локальную LLM для обнаружения паттернов в логах, которые grep и регулярные выражения пропускают.
Автоматизировать реакцию на типичные сбои: заполненный диск, упавший процесс, утечка памяти.
Получать ИИ-отзыв о коде до того, как он попадёт в продакшн.

Стек состоит из пяти уровней. Все они не обязательны. Начните с наблюдаемости, добавьте ИИ-анализ, когда объём логов сделает ручной просмотр болезненным, и переходите к самовосстановлению по мере роста уверенности.

Сколько стоит self-hosted мониторинг по сравнению с Datadog?

Self-hosted AIOps-стек на VPS Virtua Cloud стоит от 24 до 96 EUR/мес в зависимости от количества развёрнутых уровней. Это полная стоимость: сервер, хранилище, трафик и всё программное обеспечение. Коммерческие альтернативы вроде Datadog используют модели ценообразования «за хост» и «за ГБ», которые масштабируются с вашей инфраструктурой. Их расходы растут с добавлением хостов, увеличением объёма логов или включением APM-трейсинга.

Функция	Коммерческий SaaS (Datadog, New Relic)	Self-Hosted (VPS Virtua Cloud)
Мониторинг инфраструктуры	Оплата за хост, по уровням	Включено (Prometheus + Grafana)
Управление логами	Оплата за ГБ приёма + индексация за событие	Включено (Loki или OpenObserve)
APM / Трейсы	Дополнительная плата за хост	Включено (SigNoz или Tempo)
ИИ-анализ логов	Недоступно или отдельный модуль	Включено (Ollama + локальная LLM)
Алертинг	Включено	Включено (Alertmanager)
Хранение данных	Ограничения провайдера (дни-месяцы)	Вы решаете. Диск — единственное ограничение.
Расположение данных	US/EU (выбор региона)	Ваш VPS. Ваша юрисдикция.
Модель ценообразования	За хост + за ГБ, растёт с использованием	Фиксированная ежемесячная стоимость VPS

Актуальные коммерческие цены смотрите на страницах Datadog и New Relic. Стоимость self-hosted решения зависит только от выбранного плана VPS.

Колонка self-hosted предполагает один план vCS-8 (4 vCPU, 8 ГБ RAM, 160 ГБ SSD), на котором через Docker Compose работает полный стек наблюдаемости. Если нужны только базовые метрики и логи, vCS-4 (2 vCPU, 4 ГБ RAM) за 24 EUR/мес справится с Grafana + Loki + Prometheus для небольших нагрузок.

Для команд, которым также нужен уровень ИИ-анализа (Ollama с моделью на 3-7 млрд параметров), VPS на 8 ГБ — это минимум. Ollama с Gemma 2 (2B) работает примерно на 2 ГБ RAM, оставляя достаточно места для SigNoz или Grafana рядом.

Какие open-source инструменты наблюдаемости лучше всего работают на VPS?

Уровень наблюдаемости собирает метрики, логи и трейсы из ваших приложений и инфраструктуры. Три open-source стека доминируют в этой области: SigNoz, OpenObserve и Grafana + Loki. Каждый делает свои компромиссы между функциональностью, потреблением ресурсов и сложностью.

Инструмент	Лучше всего для	Логи	Метрики	Трейсы	Бэкенд	Мин RAM	Сложность
SigNoz	Полная замена APM от Datadog	Да	Да	Да	ClickHouse	4 ГБ	Средняя
OpenObserve	Лёгкая агрегация логов	Да	Да	Да	Встроенный (Rust)	~1 ГБ	Низкая
Grafana + Loki + Prometheus	Зрелая экосистема, расширяемость	Да (Loki)	Да (Prometheus)	Через Tempo	Несколько	2-4 ГБ	Выше

Все три поддерживают OpenTelemetry для инструментирования. Это значит, что вы можете инструментировать приложение один раз и сменить бэкенд позже без изменения кода приложения.

Когда выбирать SigNoz вместо OpenObserve?

Выбирайте SigNoz, когда нужен полноценный мониторинг производительности приложений: распределённые трейсы, карты сервисов, отслеживание ошибок и коррелированные логи. SigNoz использует ClickHouse как движок хранения, который хорошо справляется с данными высокой кардинальности, но требует больше RAM. Развёртывание через Docker Compose требует минимум 4 ГБ RAM для SigNoz, а для продакшн-нагрузок с ClickHouse рекомендуется 8 ГБ.

Выбирайте OpenObserve, когда основная потребность — агрегация и поиск логов. OpenObserve поставляется как единый бинарник, написанный на Rust. Запускается с менее чем 1 ГБ RAM в базовой конфигурации Docker Compose. Заявляет о 140-кратном снижении стоимости хранения по сравнению с Elasticsearch благодаря колоночному сжатию. Если вы инди-хакер с одним приложением и хотите быстрый поиск по логам без оверхеда ClickHouse, OpenObserve — более лёгкий путь.

Оба инструмента имеют веб-интерфейсы для запросов и дашбордов. SigNoz даёт более полный опыт, похожий на Datadog. OpenObserve компактнее и быстрее развёртывается.

Grafana + Loki всё ещё лучший выбор в 2026 году?

Grafana + Loki остаётся самым гибким вариантом. Не самая простая настройка, но выигрывает по широте экосистемы. Тысячи комьюнити-дашбордов для любого мыслимого сервиса. Экспортёры Prometheus покрывают базы данных, веб-серверы, метрики оборудования и пользовательские метрики приложений. Loki обрабатывает агрегацию логов с языком запросов LogQL, который повторяет PromQL.

Компромисс: больше движущихся частей. Минимальный стек Grafana — это Grafana (UI), Prometheus (метрики) и Loki (логи) как отдельные контейнеры. Плюс Promtail или Alloy как сборщик логов. Итого четыре контейнера ещё до вашего приложения. На VPS с 4 ГБ этот стек помещается, но запас остаётся минимальным.

Выбирайте Grafana + Loki, если уже знаете экосистему, нужна глубокая настройка или хотите интегрировать инструменты, которые поддерживают только экспорт метрик Prometheus.

Как добавить ИИ-анализ логов в стек мониторинга?

Запустите локальную LLM через Ollama для анализа логов без отправки данных во внешний API. Ollama предоставляет модели вроде Gemma 2 (2B), Llama 3.2 (3B) или Qwen 2.5 (7B) через локальный HTTP API. Скрипт или cron-задача подаёт фрагменты логов модели и просит выявить аномалии, обобщить паттерны ошибок или предложить коренные причины. Без расходов на API. Без утечки данных с вашего сервера.

Здесь self-hosted AIOps расходится с традиционным мониторингом. Grafana и Prometheus говорят, что произошло. Локальная LLM помогает понять, почему.

Что делает уровень ИИ-анализа:

Обнаружение аномалий: подайте последние 1 000 строк логов модели с промптом вроде «определи необычные паттерны или ошибки в этих логах». Модель пометит записи, отклоняющиеся от нормальных паттернов.
Обобщение ошибок: когда инцидент генерирует сотни строк логов, LLM сжимает их в читаемую сводку с вероятной коренной причиной.
Распознавание паттернов: со временем появляются повторяющиеся паттерны ошибок. LLM может группировать связанные ошибки и выявлять повторяющиеся проблемы, которые не вызвали бы пороговых алертов.

Размеры моделей для VPS:

Модель	Параметры	Потребление RAM	Скорость (токенов/сек, CPU)	Лучше всего для
Gemma 2 (2B)	2,6 млрд	~2 ГБ	~15-20	Быстрая сортировка логов на VPS с малым объёмом RAM
Llama 3.2 (3B)	3,2 млрд	~2,5 ГБ	~10-15	Баланс анализа и скорости
Qwen 2.5 (7B)	7 млрд	~5 ГБ	~5-8	Глубокий анализ, требуется VPS от 8 ГБ

На VPS с 4 vCPU без GPU ожидайте инференс только на CPU. Модель на 2-3 млрд выдаёт полезный анализ логов за 5-15 секунд на запрос. Этого достаточно для пакетного анализа каждые несколько минут, но не для потоковой обработки в реальном времени.

Это не магия. Маленькие модели галлюцинируют. Они упускают контекст. Иногда помечают нормальные записи логов как подозрительные. Относитесь к ИИ-анализу логов как к помощнику сортировки, а не оракулу. Всегда проверяйте его предложения по реальным логам и метрикам.

Что такое самовосстанавливающийся VPS и как он работает?

Самовосстанавливающийся VPS автоматически обнаруживает и устраняет типичные сбои без вмешательства человека. Базовая архитектура: Prometheus следит за метриками, Alertmanager выдаёт алерты при превышении порогов, а приёмник вебхуков выполняет скрипты восстановления. Добавление LLM в этот цикл позволяет обрабатывать сбои, не соответствующие предопределённым правилам.

Конвейер самовосстановления:

Prometheus собирает метрики каждые 15 секунд (CPU, память, диск, статус процессов, частота HTTP-ошибок).
Правила алертинга определяют условия: использование диска выше 90%, сервис не отвечает 60 секунд, использование памяти устойчиво выше 95%.
Alertmanager получает алерт и маршрутизирует на вебхук-эндпоинт.
Обработчик восстановления получает вебхук. Для известных ситуаций (полный диск, упавший сервис) выполняет предопределённый скрипт. Для неизвестных вызывает локальную LLM через Ollama с контекстом алерта и последними логами, запрашивая диагноз и рекомендацию.
Выполнение (опционально): для известных высоконадёжных восстановлений (перезапуск сервиса, очистка временных файлов, ротация логов) обработчик выполняет автоматически. Для предложенных LLM действий отправляет рекомендацию в канал уведомлений для подтверждения человеком.

Типичные автоматические восстановления:

Диск заполнен: очистить /tmp, ротировать старые логи, удалить неиспользуемые Docker-образы командой docker system prune.
Сервис упал: systemctl restart <service>, затем проверить работоспособность. Если падает снова в течение 5 минут — эскалация на человека.
Нехватка памяти: определить крупнейшего потребителя памяти, перезапустить, если он превышает ожидаемый уровень.
Истечение сертификата: запустить обновление Certbot, когда до истечения сертификата менее 7 дней.

Начинайте консервативно. Автоматизируйте только те восстановления, которые вы десятки раз выполняли вручную и полностью понимаете. Пусть LLM предлагает действия для незнакомых ситуаций, но сохраняйте человека в цикле для выполнения.

Для бескодового подхода к маршрутизации алертов и рабочим процессам восстановления n8n может выступать слоем оркестрации между Alertmanager и вашими скриптами восстановления.

Как ИИ вписывается в ваш CI/CD-конвейер?

ИИ-ревью кода ловит баги, уязвимости безопасности и проблемы производительности до того, как код попадёт на сервер. Workflow-процессы GitHub Actions могут отправлять diff-ы pull request-ов в Claude или Gemini для анализа, публиковать комментарии ревью и блокировать мёржи при обнаружении критических проблем. Это работает в вашем CI/CD-конвейере без изменений на VPS.

Что находит ИИ-ревью кода, а линтеры — нет:

Логические ошибки и граничные случаи, которые статический анализ не может обнаружить.
Уязвимости безопасности в контексте (линтер отмечает опасные функции, но LLM понимает, почему окружающий код делает их эксплуатируемыми).
Регрессии производительности: «этот запрос в цикле будет обращаться к базе данных N раз».
Пробелы в документации: отсутствующая обработка ошибок, неясные имена переменных, недокументированные побочные эффекты.

Этот уровень отличается от остальных тем, что обычно работает в CI-платформе (GitHub Actions, GitLab CI), а не на вашем VPS. Однако, если хотите всё держать на своём сервере, можно запустить CI-раннер на VPS и направлять запросы ревью на локальную Ollama. Компромисс: более медленные ревью с маленькими моделями против более быстрых и точных с облачными API.

Что такое наблюдаемость LLM и зачем она нужна?

Наблюдаемость LLM отслеживает работу ваших ИИ-инструментов: потребление токенов, задержку, частоту ошибок, затраты и качество вывода. Если вы запускаете любую функцию на базе LLM (чат-бот, ассистент кода, анализатор логов, генератор контента), Langfuse даёт видимость каждого вызова. Это уровень «мониторинг мониторов» вашего AIOps-стека.

Langfuse — open-source платформа для LLM-инженерии. При self-hosted развёртывании работает как два контейнера (web + worker) с PostgreSQL и опционально ClickHouse для аналитики. Предоставляет:

Трейсинг: видеть каждый вызов LLM с входными данными, выходными данными, задержкой и количеством токенов. Погружаться в многошаговые workflow агентов, чтобы найти, где тратятся время и токены.
Оценка: оценивать выходные данные с помощью LLM-as-a-judge, человеческой обратной связи или пользовательских метрик. Отслеживать качество во времени.
Отслеживание расходов: рассчитывать реальные затраты на каждый вызов LLM, на пользователя, на функцию. Сравнивать производительность моделей при разных ценовых уровнях.
Управление промптами: версионировать и A/B-тестировать промпты. Откатывать, когда новый промпт ухудшает качество вывода.

Если вы запускаете Ollama для анализа логов (уровень 2 этого стека), Langfuse трейсит каждый запрос анализа. Вы видите, какие запросы по логам дают полезные результаты, с какими модель справляется плохо и как меняется задержка при смене модели.

Langfuse интегрируется с OpenTelemetry, LangChain, LlamaIndex и OpenAI SDK (с которым Ollama совместим). Инструментирование обычно занимает несколько строк кода.

Этот уровень нужен, когда использование LLM выходит за рамки экспериментов. Как только вы зависите от ИИ-выводов для алертинга или восстановления, нужно знать, когда модель начинает выдавать мусор.

Какие ресурсы VPS нужны для полного AIOps-стека?

Ресурсы зависят от развёрнутых уровней. Вот три конфигурации, привязанные к планам VPS Virtua Cloud:

Конфигурация	Уровни	План VPS	CPU	RAM	Диск	EUR/мес
Стартовая	Grafana + Prometheus + Loki	vCS-4	2 vCPU	4 ГБ	80 ГБ	24
Стандартная	SigNoz + Ollama (модель 3B)	vCS-8	4 vCPU	8 ГБ	160 ГБ	48
Полный стек	SigNoz + Ollama (7B) + Langfuse + Alertmanager	vCS-16	8 vCPU	16 ГБ	320 ГБ	96

Стартовая справляется с метриками и агрегацией логов для одного-трёх небольших приложений. Дашборды и алерты без ИИ-анализа.

Стандартная добавляет ИИ-анализ логов. SigNoz занимает около 4 ГБ, Ollama с моделью 3B использует около 2,5 ГБ. Оставшаяся RAM идёт на ОС и ваши отслеживаемые приложения. Оптимальный вариант для одиночного разработчика или небольшой команды.

Полный стек запускает все уровни, описанные в этом руководстве. Модель на 7 млрд параметров даёт лучший анализ, чем 3B-модель, но требует больше RAM. Langfuse добавляет около 1 ГБ. Эта конфигурация для команд, запускающих LLM-функции в продакшне и нуждающихся в полной наблюдаемости инфраструктуры и ИИ.

Все конфигурации работают через Docker Compose. Отдельные статьи содержат точные файлы docker-compose.yml для каждого инструмента.

Замечание об использовании диска: данные наблюдаемости растут быстро. SigNoz с ClickHouse хорошо сжимает (ожидайте 5-10-кратное сжатие логов), но закладывайте 1-5 ГБ новых данных в день в зависимости от детализации логов. Настраивайте политики хранения с первого дня. Диск на 160 ГБ при умеренных темпах приёма даёт примерно от одного до трёх месяцев данных.

Когда стек мониторинга работает на европейском VPS, ваши данные наблюдаемости никогда не покидают юрисдикцию. Метрики, логи и трейсы часто содержат персональные данные: IP-адреса, идентификаторы пользователей, пути запросов, сообщения об ошибках с пользовательским контекстом. Отправка этих данных на SaaS-платформу в США создаёт риск трансграничной передачи по GDPR, даже если провайдер предлагает регион в ЕС.

С self-hosted стеком на VPS Virtua Cloud во Франции или Германии вы контролируете:

Где хранятся данные. На диске, в вашем VPS, в европейском дата-центре.
Кто имеет доступ. Без сотрудников провайдера, без субпроцессоров, без соглашений о передаче данных третьим лицам.
Как долго они хранятся. Вы устанавливаете политику хранения. Без навязанных провайдером минимумов или графиков удаления данных.

Это не юридическая консультация. Обратитесь к вашему специалисту по защите данных для конкретной ситуации. Но с технической точки зрения self-hosted мониторинг устраняет целую категорию вопросов о передаче данных.

С чего начать?

Ваша точка входа зависит от опыта и проблемы, которую вы решаете сейчас.

Если вы новичок в мониторинге серверов (инди-хакеры, первый VPS):

Начните с SigNoz. Он даёт метрики, логи и трейсы в одном инструменте с веб-интерфейсом. Один файл Docker Compose, один инструмент для изучения.
Когда освоитесь с чтением дашбордов, добавьте Ollama для ИИ-анализа логов.
Пока не автоматизируйте восстановление. Сначала разберитесь в нормальном поведении вашего сервера.

Если уже используете Prometheus или Grafana (DevOps-практики):

Добавьте Loki для агрегации логов, если ещё не сделали.
Интегрируйте Ollama для ИИ-сортировки логов рядом с существующими правилами алертинга.
Постройте workflow самовосстановления с вебхуками Alertmanager.
Добавьте Langfuse, когда начнёте полагаться на вывод LLM для операционных решений.

Если хотите полный стек с первого дня (ИИ-разработчики):

Разверните VPS vCS-8 или vCS-16 на Virtua Cloud.
Настройте SigNoz для наблюдаемости.
Запустите Ollama с моделью 7B для анализа логов и обнаружения аномалий.
Подключите Alertmanager к вашим скриптам восстановления.
Разверните Langfuse для мониторинга LLM-уровня.
Добавьте ИИ-ревью кода в CI/CD-конвейер.

Каждая отдельная статья в этом тематическом кластере — самостоятельный туториал. Можно проходить их в любом порядке. Стек модульный: каждый уровень работает независимо и приносит пользу сам по себе.

Авторское право 2026 Virtua.Cloud. Все права защищены. Данный контент является оригинальным произведением команды Virtua.Cloud. Воспроизведение, повторная публикация или распространение без письменного разрешения запрещены.