Привет! В этом посте мы расскажем про то, почему вообще выбрали именно Zabbix для мониторинга, для чего его используем, и как решились обновиться сразу с версии 4.4 до 6.0.
Как и для чего мы используем Zabbix в МКБ
Система мониторинга на Zabbix используется в МКБ для мониторинга инженерного оборудования, инфраструктуры, ПО, метрик ИТ-систем, а также для сбора бизнес-метрик. А так как это opensource, то Zabbix можно подключить к различным системам и собирать метрики с них с помощью единого инструмента.
Задача систем мониторинга — вовремя просигнализировать о проблемах, а лучше раньше, чем пользователи и клиенты банка заметят их. Наш Zabbix прекрасно с этим справляется.
Сейчас у нас на Zabbix-мониторинге более 12 000 хостов, мы собираем порядка 500 000 разных метрик. Плюс Zabbix — в его масштабируемости, он позволяет поставить специальные proxy-сервера, которые будут собирать метрики даже в закрытых vlan, а также уменьшают нагрузку на Zabbix-server, так как основная обработка идет на Proxy. Таких прокси у нас сейчас 15+, и их число растёт.
Сам же Zabbix у нас играет роль зонтика, собирая метрики не только самостоятельно, но и с других систем — Prometheus, ElasticSearch. Мы выбрали его потому, что у него отличная гибкая настройка оповещений, которая не лежит в каком-то отдельном файле, а настраивается через специальный веб-интерфейс. При этом Zabbix не ограничен методами, которые в него встроены из коробки — с помощью специальных скриптов и команд можно доставать метрики вообще из чего угодно и как угодно, а также форматировать вывод.
Сложность работы с ним определяется как раз именно сложностью уровня поддержки, а именно — умением людей писать эти скрипты.
У нас есть группы поддержки, сопровождающие ИТ-системы Банка. В паспорте систем определены метрики, заведенные на Zabbix, а также триггеры для 2 и 3 линии поддержки и круглосуточной ночной смены (дикие и необузданные NightGuards).
Одна ИТ-система отличается от другой архитектуры и ключевыми точками мониторинга. У нас разработаны стандартные модели здоровья, но кроме них для каждой ИТ-системы настраиваются дополнительные метрики и триггеры.
Также мы мониторим истечение учётных записей, истечение сертификатов (всех), vsphere, собираем специализированные метрики с кубер-кластеров, с api сервисов и точек интеграции.
/У нас есть мониторинг доступности, построенный на ElasticSearch, и алерты по изменению процентов доступности считаются Zabbix-ом посредством запросов ElasticSearch к сервису. Само собой, реагируем и на события в логах — все системы в ElasticSearch пишут логи, а Zabbix смотрит в конкретный индекс и определяет появление каких-то паттернов или флагов, после чего оповещает об этом нужные команды. Есть возможность делать к этим логам SQL-запросы, а также полнотекстовые и поисковые. Кастомизируемость тут отличная, и движок ElasticSearch можно в полной мере использовать для агрегирования данных.
Чего нам не хватало в версии 4.4
В принципе, поверье «Работает — не трогай» никто не отменял. Но версии ПО обновлять нужно, как в плане безопасности, так и новых функций. Например, в нашем случае в 4.4 банально не хватало некоторых полезных для нас вещей.
Прежде всего, отказоустойчивого решения по Zabbix-серверам. Система у нас высоконагруженная, её использует множество людей в Банке, так что стабильности и надёжности её работы нам и не хватало. Не было возможности адекватно растащить всё по разным ЦОДам, чтобы при падении одного ЦОДа кластеры на другом нормально себя чувствовали.
В результате перехода получилась следующая схема:
Схема отказоустойчивого кластера по ЦОДам с указанием холодного резерва прокси
Отказоустойчивость Zabbix системы обеспечивается следующим образом:
1. Отказоустойчивость серверов БД. Два сервера БД postgresql организованы в кластер patroni. При падении одного сервера время простоя около минуты.
2. Отказоустойчивость самого за счет объединения в HA cluster, который был не доступен в нашей старой версии Zabbix.
3. Доступность веб серверов осуществляется за счет заведении публикации на балансировщики с keepalived и haproxy.
4. Отказоустойчивость Zabbix-proxy осуществляется за счет холодного резерва. Раз в неделю все Zabbix-proxy бекапятся и восстанавливаются в другом ЦОДе в выключенном состоянии. Система рабочая! При отказе прокси мы просто поднимаем его копию в другом ЦОДе
Кроме этого, для версии 4.4 был и набор нереализуемых требований от нашей информационной безопасности (мы же Банк, в конце-то концов). Выдача доступов для пользователей в 4.4 была сильно ограничена.
А в 6.0 появилось сразу несколько полезных штук:
— Zabbix Agent 2.0, позволяющий делать дополнительные проверки по k8s и Docker прямо из коробки.
— возможность проверять содержимое папки и выводить служебную информацию, которая крайне важна.
Как мы переезжали на новую версию
Мы построили тестовый стенд, полностью повторяющий наш боевой Zabbix, и раскатали на него бэкап боевой базы. После чего реализовали достаточную нагрузку на базу, сопоставимую с реальной, и провели необходимые учения. Мы полностью обновили тестовый стенд с 4.4 до 6.0 по заранее разработанному и согласованному на архитектурном комитете плану.
План, к слову, был необходим — не просто потому, что так правильно, а потому, что система мониторинга используется многими в Банке, многие коллеги из разных департаментов получают из неё алерты, метрики и не только. Поэтому просто взять и отключить на время систему мониторинга просто потому, что можем (ну, или нужно для технических работ) нельзя.
Так что мы заранее разработали план действий и спрогнозировали общее время недоступности системы, представили, в какой день недели лучше это делать, чтобы напрячь наименьшее количество коллег, а потом после тестирования и провели все работы по обновлению.
Для минимизации простоя мы сделали отдельные новые сервера БД, на которые и залили дампы свежих баз, а также развернули отдельные Zabbix-servers и Zabbix-web (2шт) с нужным ПО для нужной версии. Эта отдельная новая структура как раз пригодились нам для того, чтобы не портить старое, а в случае чего иметь возможность быстро откатиться в работоспособное состояние. То есть мы обновляли в момент работ только Zabbix-proxy (15 штук) и переезжали на новые сервера.
Нюансы:
1. Если нет возможности обновить БД до нужной версии, есть специальный ключ AllowUnsupportedDbVersions=1
2. Появилась возможность выставить количество Odbc поллеров StartODBCPollers=200
3. На время работ лучше отключать media type, чтобы не спамить письмами
Проблемы, возникшие после перехода
Самая главная проблема — массово поотваливались наши кастомные дашборды, которых у нас было достаточно. Дело вот в чём — в 4.4 была сущность под названием Application. В 6.6 эта сущность название на item tag. Поэтому все кастомные дашборды, настроенные на application, развалились, особенно где использовались Repeat options.
Но и это ещё не всё — при использовании на дашбордах applications для повторяющихся плиток Grafana сходила с ума и создавала бесконечное число плиток. После чего ожидаемо помирала.
Так что, если будете обновляться похожим образом, учитывайте эту историю с изменением сущностей.
Что в итоге
Благодаря тщательной подготовке и построению полноценного тестового стенда для тренировки и созданию параллельно новых БД, Zabbix-web и Zabbix-server систем мы перешли на 6.0 без каких-то критичных проблем. Хотя, на самом деле, между 4.4 и 6.0, как вы понимаете, достаточно промежуточных версий, и скачок между обновлениями у нас получился неслабый.
Ждем неожиданностей от версии 7.0, но меньше, чем от этого перехода 🙂
ссылка на оригинал статьи https://habr.com/ru/articles/853360/
Добавить комментарий