1. Введение

Всем привет! Меня зовут Яблоков Олег, я — ведущий инженер ИТ‑отдела Navio и отвечаю за систему мониторинга основной инфраструктуры компании. Это работа на стыке разработки и эксплуатации (development & operations, DevOps), наблюдаемости (Observability) и обеспечения надёжности сервисов (Site Reliability Engineering, SRE). Моя основная задача не просто собирать метрики, а сделать так, чтобы по ним можно было быстро понять статусы сервисов и не утонуть в шуме оповещений.

Когда я пришел в компанию около года назад, система мониторинга уже существовала и закрывала базовые задачи. В наборе технологий использовались Prometheus, Thanos, Alertmanager, Grafana, Elasticsearch и различные наборы оповещений. Со временем количество компонентов и инструментов увеличилось, что усложнило их сопровождение и масштабирование.

В этой статье я расскажу, как происходила миграция мониторинга в Kubernetes, почему в качестве основной базой данных временных рядов (Time Series Database, TSDB) была выбрана Victoria Metrics, как мониторинг связали с Gitlab и Argo CD, пересобрали систему оповещений (alerting) и начали постепенно двигаться от инфраструктурного мониторинга к сервисному подходу и практикам обеспечения надёжности сервисов (Site Reliability Engineering, SRE). 

2. С чего все начиналось.

Изначально мониторинг представлял собой связку Prometheus, Thanos, Alertmanager, Grafana и Elasticsearch. Разворачивалось все через Docker Compose на отдельных серверах, а сама система постепенно росла вместе с инфраструктурой.

Со временем мониторинг начал ощущаться не как единая платформа, а как набор исторически сложившихся компонентов. В систему добавлялись новые сервисы, проверки и правила, но общий подход постепенно размывался. Чем больше становился контур, тем тяжелее было его сопровождать: слишком много связей между компонентами, ручных настроек и неочевидных зависимостей.

Отдельной проблемой стали оповещения (alerting). Предупреждения, устаревшие правила и действительно критичные события часто выглядели одинаково. В результате оповещения начали восприниматься как постоянный шум, а не как инструмент оперативной реакции на инциденты.

При этом сам мониторинг был в основном инфраструктурным. Это позволяло видеть состояние серверов, загрузку ресурсов и базовые системные метрики, но не давало понимание того, что происходит на уровне сервисов. А для бизнеса наличие свободной памяти на сервере не имеет большого значения, если у пользователей не работает авторизация или приложение начинает отвечать ошибками 500.

3. Почему решили все переделать.

К моменту миграции сошлось сразу несколько факторов. Старый мониторинговый контур стало тяжелее сопровождать: система разрасталась, количество сервисов увеличивалось, а вместе с ними росло и количество ручных настроек, зависимостей и точек отказа.

Переносить старую схему «как есть» в новый контур не хотелось, поэтому это был хороший момент для пересмотра архитектуры целиком и повод для того, чтобы избавиться от накопившихся исторических ограничений.

Отдельно появилась потребность двигаться в сторону практик обеспечения надежности сервисов (Site Reliability Engineering, SRE). Мониторинг уже перестал восприниматься просто как набор графиков и метрик. Возник запрос на более понятную оценку доступности сервисов, качества работы систем и скорости реакции на инциденты.

Если коротко, цели миграции были достаточно практичными:

• сделать мониторинг стабильнее и проще в эксплуатации;

• уменьшить количество ручного сопровождения;

• упростить хранение метрик и резервное копирование;

• пересобрать систему оповещений (alerting) и снизить шум;

• создать основу для сервисного мониторинга и индикаторы и цели уровня сервиса (Service Level Indicator / Service Level Objective, SLI/SLO).

Речь шла не столько о замене конкретной технологии, сколько о пересборке самого подхода к мониторингу и эксплуатации.

4. Почему Victoria Metrics

Выбор Victoria Metrics был скорее инженерным и прагматичным, чем идеологическим. Задачи «уйти с Prometheus любой ценой» не стояло — проблема заключалась в том, что существующая схема со временем стала слишком тяжелой в сопровождении и плохо подходила под новую архитектуру.

При выборе новой базы данных временных рядов (Time Series Database, TSDB) было несколько основных требований:

• нормальная работа в Kubernetes;

• более простая эксплуатация;

• предсказуемое хранение метрик;

• удобное резервное копирование;

• снижение общей сложности мониторингового контура.

В итоге Victoria Metrics хорошо вписалась в модель Kubernetes‑кластера и оказалась заметно проще с точки зрения сопровождения. В качестве основной схемы был выбран Victoria Metrics Cluster с операторами, агентами сбора метрик (vmagent) для сбора метрик и компонента обработки правил (vmalert) для обработки правил и оповещений.

Внутри кластера использовались два экземпляра компонента обработки и выборки запросов к метрикам (vmselect) и компонента приема и записи метрик (vminsert), работающих с компонентами хранилищ (vmstorage). Основное хранение метрик разместили на постоянных томах (Kubernetes PersistentVolumeClaim), а резервные копии — в S3-совместимом объектном хранилище.

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

5. Как выглядела новая архитектура

После миграции мониторинг полностью переехал в Kubernetes и начал собираться как единый сервисный контур.

Базовая архитектура выглядела следующим образом:

• Kubernetes — как основа платформы;

• агенты сбора метрик (vmagent) — для сбора метрик;

• компонент обработки правил (vmalert) и менеджер оповещений (Alertmanager) — для обработки правил и доставки оповещений;

• Grafana — для визуализации;

• Gitlab — как источник конфигураций и конвейеров непрерывной интеграции, а также способ доставки изменений (Continuous Integration / Continuous Delivery, CI/CD);

• Argo CD — для доставки изменений;

• S3 — для резервного копирования;

• специализированные Python‑проверки для сервисов и внутренних компонентов.

Помимо стандартных экспортеров (exporters) значимую часть мониторинга составляли собственные Python‑проверки. Они использовались для сервисов, где типовых метрик было недостаточно или требовалась более прикладная логика проверки доступности.

Конфигурации, правила и пользовательские модули хранились в Gitlab, собирались через Gitlab CI и разворачивались через Argo CD. На небольших стендах многие вещи еще можно поддерживать вручную, но при сотнях целевых компонентов и десятках визуальных панелей подход управления инфраструктурой через Git начинает серьезно экономить время и уменьшать количество ошибок.

В результате мониторинг стал ближе к модели «инфраструктура как код», где изменения можно нормально отслеживать, оценивать и откатывать, а не хранить в виде набора ручных правок на серверах.

6. Как проходила миграция

Миграция не произошла мгновенно. Новый контур запускался параллельно со старым: сервис сначала подключался к Victoria Metrics, после чего некоторое время работал сразу в двух системах.

В течение нескольких недель сравнивались метрики, проверялись метки (labels), корректность сбора и поведение оповещений. Только после этого сервис окончательно отключился от старого контура на базе Prometheus и Thanos.

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

Полный переход занял около полугода. Одной из самых неприятных частей оказалась адаптация старых Python‑проверок и внутренних служебных программ. За годы эксплуатации в них накопилось большое количество исторических допущений, привязок к старой инфраструктуре и неочевидной логики.

Если бы пришлось проходить этот путь повторно, я бы заранее сильнее унифицировал структуру репозиториев, раньше продумал конвейеры непрерывной интеграции и доставки изменений (Continuous Integration / Continuous Delivery, CI/CD) и уделил больше внимания архитектуре системы оповещений (alerting) еще до начала самой миграции.

7. Что мы начали отслеживать по‑настоящему

Одним из главных изменений стало переосмысление того, что вообще можно считать важным в мониторинге.

Изначально основной фокус был на инфраструктурных метриках: загрузке центрального процессора (Central Processing Unit, CPU), памяти, дисках и состоянии серверов. Такой подход помогает понимать общее состояние платформы, но далеко не всегда показывает, что происходит с сервисами глазами пользователей.

После миграции покрытие сервисного мониторинга начали постепенно расширять. В контур вошли система управления инцидентами, службы легковесного протокола доступа к каталогам (Lightweight Directory Access Protocol, LDAP) и активного протокола (Active Directory, AD), корпоративная энциклопедия, базы данных и другие внутренние системы.

Сервис может быть полностью «зеленым» по системным метрикам, но при этом пользователи уже сталкиваются с медленной работой, ошибками или проблемами авторизации. Именно в таких местах хорошо видно разницу между «инфраструктура жива» и «сервис действительно работает».

Постепенно мониторинг начал смещаться от проверки состояния железа к более прикладному вопросу: доступен ли сервис и работает ли он так, как от него ожидают пользователи и бизнес.

8. Как мы перенастроили систему оповещений

Наиболее заметный эффект в повседневной эксплуатации дал пересмотр системы оповещений.

В старом контуре предупреждения, устаревшие правила и действительно критичные инциденты часто выглядели одинаково. Со временем это привело к классической проблеме усталости от оповещений (alert fatigue) — оповещения начали восприниматься как постоянный шум.

Главная цель при пересборке системы оповещений (alerting) была достаточно простой: если приходит критичное уведомление, оно не должно выглядеть как очередное фоновое предупреждение.

Под это пришлось пересмотреть как сами правила, так и подход к доставке уведомлений:

• события‑предупреждения остались обзорными сигналами;

• критичные инциденты были выделены отдельно;

• уведомления начали разводиться по разным Telegram‑каналам в зависимости от команд и уровня критичности;

• появились предсказывающие сигналы, например предупреждения о заполнении дисков или деградации сервисов.

Постепенно сформировалось простое правило хорошего оповещения: оно должно быстро отвечать на три вопроса — что произошло, где произошло и насколько это критично.

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

9. Gitlab, Argo CD и мониторинг как код

Пока система небольшая, всегда есть соблазн поправить конфигурацию вручную прямо в рабочем контуре. Но с ростом инфраструктуры такие изменения начинают создавать все больше проблем: становится сложнее понимать, кто и что менял, а откаты превращаются в отдельную задачу.

Постепенно мониторинговый контур начали переводить на подход управления инфраструктурой через Git‑репозитории:

• конфигурации и пользовательские модули хранились в Gitlab;

• сборка выполнялась через Gitlab непрерывная интеграция (Continuous Integration, CI);

• доставка изменений происходила через Argo CD;

• часть инфраструктуры описывалась через Helm.

Такой подход позволил сделать изменения воспроизводимыми и управляемыми. Конфигурации начали проходить через стандартный конвейер доставки изменений (pipeline), изменения стало проще отслеживать, оценивать и откатывать.

На небольших стендах ручные правки еще могут работать, но при большом количестве целей мониторинга (targets), панелей мониторинга (dashboards) и правил оповещения (alert rules), управление инфраструктурой через Git становится скорее необходимостью, чем «хорошей практикой». Особенно если сопровождением платформы занимается ограниченное количество людей.

10.Резервные копии Victoria Metrics и история со сроком хранения (retention)

На бумаге резервное копирование выглядит достаточно прямолинейной задачей, но в реальном контуре все оказалось сложнее. Поскольку использовалась версия с открытым исходным кодом (community) Victoria Metrics, сценарии резервного копирования пришлось собирать самостоятельно.

В качестве основы использовалась утилита (vmbackup), вокруг которой была сделана собственная обвязка. Запуск происходил через задание Kubernetes, выполняемое по расписанию, а резервные копии складывались в S3-совместимое хранилище.

Дальше начали проявляться эксплуатационные детали: как часто запускать резервное копирование (backup), как не мешать рабочей нагрузке, сколько хранить копии и как проверять восстановление.

Самый неприятный инцидент произошел со сроком хранения метрик. Из‑за ошибки оказалось, что удержание (retention) выставлено всего на один месяц, и часть исторических данных была потеряна. Это был довольно болезненный урок.

После этого отношение к резервному копированию и сроку хранения сильно изменилось. Потеря исторических метрик — это не «неудобство», а полноценный инцидент, который влияет и на расследование проблем, и на анализ стабильности сервисов в долгосрочной перспективе.

В итоге проверки восстановления, контроль срока хранения и аудит резервных копий стали отдельной регулярной задачей, а не «фоновым процессом, который когда‑нибудь пригодится».

11.Первые шаги к надежности: индикаторы уровня обслуживания (Service Level Indicator, SLI) и цели уровня обслуживания (Service Level Objective, SLO)

Следующим этапом стало движение в сторону сервисной надежности и практик обеспечения надежности сервисов (Site Reliability Engineering, SRE). Постепенно для критичных сервисов начали появляться индикаторы уровня обслуживания (Service Level Indicator, SLI) и цели уровня обслуживания (Service Level Objective, SLO): сначала для системы управления учетными данными (Identity management, IdM), системы отслеживания инцидентов и корпоративной энциклопедии, а затем и для других внутренних систем.

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

На практике самая сложная часть оказалась не технической, а методологической. Для каждого сервиса пришлось отдельно определять, что вообще считать «доступностью». Протокол передачи гипертекста (HyperText Transfer Protocol, HTTP) 200 далеко не всегда означает, что сервис действительно работает нормально. Где‑то важна успешная авторизация, где‑то — корректное выполнение бизнес‑операции, а где‑то — стабильное время ответа.

Отдельной задачей стал расчет метрик именно в рабочие часы. Для части сценариев пришлось писать собственные Python‑агрегаторы и собирать отдельные визуализации в Grafana, включая «солнечные» (sunburst) диаграммы для менеджмента и команд эксплуатации.

Именно в таких местах хорошо видно разницу между «красивыми презентациями про обеспечение надежности сервисов (Site Reliability Engineering, SRE)» и реальной инженерной работой. Но в итоге у команд появилась более понятная картина доступности сервисов, а обсуждение качества работы систем стало опираться не на ощущения, а на конкретные измерения.

12.Что получилось в итоге

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

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

Сильнее всего изменения проявились в эксплуатации:

• критичные оповещения начали быстрее доходить до нужных людей;

• уменьшилось количество шумовых уведомлений;

• стало проще подключать новые сервисы к мониторингу;

• появилась более понятная картина доступности сервисов;

• ускорилось расследование инцидентов;

• команды начали лучше видеть влияние проблем на пользователей, а не только состояние инфраструктуры.

Отдельно изменилась прозрачность системы для бизнеса и менеджмента. Появились индикаторы уровня обслуживания (Service Level Indicator, SLI) и цели уровня обслуживания (Service Level Objective, SLO), а также измерения доступности сервисов и более понятные показатели стабильности. В результате обсуждение проблем постепенно сместилось из формата «кажется, все плохо» к разговору на основе метрик и наблюдаемых данных.

Для продуктовых и инфраструктурных команд это тоже оказалось полезным: стало проще понимать влияние деградаций на пользователей, а еще появилась возможность быстрее локализовывать проблемы и принимать решения на основе измерений, а не субъективных ощущений.

Для эксплуатации это тоже оказалось важным: когда у тебя есть история доступности, данные по деградациям и нормальные оповещения, становится проще принимать решения и расставлять приоритеты.

Сейчас дальнейшее развитие движется в сторону подходов искусственного интеллекта для ИТ‑операций (Artificial Intelligence for IT Operations, AIOps): автоматического поиска аномалий, корреляции событий и использования больших языковых моделей (Large Language Models, LLM) для подготовки кратких сводок по инцидентам. В качестве текстового слоя нам интересен GigaChat, поскольку он хорошо вписывается в инфраструктурные ограничения и внутренний контур компании.

13.Какие проблемы я бы выделил отдельно

Если бы пришлось давать советы тем, кто собирается проходить похожую миграцию, они были бы довольно приземленными:

1. Не пытайтесь мигрировать все сразу. Попытки одновременно перевезти мониторинг, внедрить подход управления инфраструктурой через Git и пересобрать архитектуру обычно заканчивается перегрузкой команды и хаосом.

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

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

4. Делайте миграцию поэтапно. Параллельный запуск старого и нового контура с возможностью отката почти всегда безопаснее, чем большое переключение «в один день».

5. Мониторинг инфраструктуры — это только начало. Настоящая ценность появляется тогда, когда мониторинг начинает показывать влияние проблем на сервисы, пользователей и бизнес‑процессы. Именно в этот момент наблюдаемость (observability) перестает быть просто набором графиков для инженеров и становится инструментом принятия решений.

14. Вывод

Проблемы мониторинга редко упираются только в выбор конкретного инструмента — будь то Prometheus, Victoria Metrics или любая другая база данных временных рядов (Time Series DataBase, TSDB). Гораздо чаще основные сложности появляются из‑за хаотичного роста инфраструктуры, ручных изменений, шумных оповещений и отсутствия общего подхода к эксплуатации.

Переход на Victoria Metrics в нашем случае стал скорее поводом пересобрать саму модель мониторинга: вынести ее в Kubernetes, привести к подходу управления инфраструктурой через Git‑репозитории (GitOps), сделать систему предсказуемее в сопровождении и начать двигаться в сторону сервисной надежности.

Самое важное изменение произошло даже не на уровне технологий. Постепенно мониторинг начал отвечать не только на вопрос «жив ли сервер», но и на вопрос «как себя чувствует сервис и что сейчас видит пользователь».

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

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

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