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), сделать систему предсказуемее в сопровождении и начать двигаться в сторону сервисной надежности.
Самое важное изменение произошло даже не на уровне технологий. Постепенно мониторинг начал отвечать не только на вопрос «жив ли сервер», но и на вопрос «как себя чувствует сервис и что сейчас видит пользователь».
В результате мониторинг стал не только техническим инструментом эксплуатации, но и способом быстрее понимать влияние инцидентов на пользователей и внутренние сервисы компании. Это позволило сделать реакцию на проблемы более предсказуемой, а обсуждение доступности сервисов — более предметным и основанным на измерениях.
В итоге у команд появилась более прозрачная картина доступности систем, а у эксплуатации — более понятный и управляемый контур наблюдаемости. Это не убрало полностью сложность сопровождения, но позволило заметно снизить хаос и сделать дальнейшее развитие системы более предсказуемым.
Если смотреть назад, главный вывод для меня достаточно простой: миграция мониторинга — это в первую очередь история про процессы, эксплуатацию и накопленные инженерные компромиссы, а уже потом про выбор конкретной технологии.
ссылка на оригинал статьи https://habr.com/ru/articles/1043548/