Битрикс24 использует стандартные системы мониторинга: Nagios, Shinken, Munin, Zabbix. Преимущества этого подхода в том, что когда используешь стандартные – легче обучить и найти персонал. Задача мониторить всё, но аккуратно. Выделены и технические и бизнес метрики. Пороги для алертов устанавливаются опытным путем.
Мониторинг
Что мониторится:
- Физические сервера (их мало): рейды, S.M.A.R.T. и др.
- Сеть: загрузка канала, связность узлов, потери пакетов, SpeedTest и др.
- OS: memory, load average, swap и др.
- Критический софт: кол-во процессов, потребление ими %CPU, memory и т. д.
- Базы данных: Буферный пул, hit rate, количество медленных и очень медленных запросов и др.
- Нетипичные метрики: наличие бэкапов, срок делегирования доменов, баланс у провайдера смс-уведомлений, отсутствие в блэк-листах почтовиков, срок действия SSL сертификатов и др.
Мониторинг сети SpeedTest помог выявить ситуацию, когда на некоторых серверах был зашейплен канал.
Введен мониторинг очень медленных запросов по объему данных и по времени. Важно, так как между запросом, который длиться 2 секунды и 20 секунд, есть большая разница. Эти данные сразу отправляются разработчикам.
Был опыт работы с мониторингом каждого пользователя. В результате треть нагрузки вызывала только система мониторинга.
Система мониторинга так же мониторится.
«Бизнес»-метрики Битрикс24:
- Количество регистраций (в большую и меньшую сторону).
- Ошибки в регистрациях.
- Пул предподготовленных болванок регистраций в разных регионах.
- Количество процессов, ответственных за регистрации.
Для подстраховки через Cron настроен скрипт, который случайным образом проверяет host во всех регионах и в случае проблем шлет алерт.
Сбор данных со стороны пользователя
Реализован механизм сбора данных со стороны пользователя. Имплементация на JavaScript из приложения через Navigation Timing API.
Для этого со стороны пользователя собираются данные: время ответа back end, время рендеринга страницы и др. Это помогает выявлять проблемы со стороны пользователя. Плюс это дает данные скорости загрузки по разным регионам. Эти дополнительные данные помогают выяснить проблемные участки по back-end, front-end, rendering и объяснить, например, что у пользователя есть проблемы с провайдером.
Визуализация мониторинга
В компании 1С-Битрикс для визализации раньше использовали мунин, теперь меньше. Сейчас в основном используется плагин PNP for Nagios, который собирает данные из алертов, рисует графики и удобно зумит. На сегодняшний день эти приложения закрывают потребности в визуализации.
Аналитика
Полученные данные анализируются с целью выявить тренды. Это позволяет спланировать мощности железа, сравнить настройки софта и видеть развитие с течением времени.
Отдельно стоит анализ MySQL. Обрабатываются данные по числу запросов и соединений в базе данных, данные по количеству медленных и очень медленных запросов и другие.
Уведомления
Система оповещения со временем пришла к порядку, когда только о критичных ошибках идет оповещение. Остальные алерты решаются в рабочем порядке.
Каналы оповещения:
- SMS – от двух операторов. Для разных проблем настроены разные списки адресатов. Повторность – через 15 миинут, через 2 часа. Контроль прямо через смс – на случай когда скрипты сами решают проблемы.
- E-mail – шлется «дайджест» проблем вместо одного сообщения на каждый алерт.
hints: Ссылки на iphone и на android парсятся по разному. Если на первом они активны даже без http, то на android нет, должны быть написаны полностью
Алгоритм поиска причин проблем
Чтобы выявить причину проблем нужно собрать данные с мониторинга, логов, графиков.
Для анализа логов заготовлены скипты-парсеры логов для поиска ошибок. Error.log всегда включен и связан с системой мониторинга. Важным моментов является наличие таймингов в логах. Это позволяет агрегировать логи и видеть состояние сервиса в целом.
Графики анализируются в сравнении с предыдущими периодами. По необходимости используются инструменты поиска проблемных мест с учетом предыдущих периодов.
Инструменты, которые помогают выявить источник проблем:
- server-status от Apache
- Логи медленных запросов php-fpm, apache, nginx, MySQL
- Pinba
- Xhprof
Другие утилиты, которые могут помочь:
- unix: netstat, lsof, strace, gdb
- grep, awk, sort, uniq и т.п.
- команды для MySQL: EXPLAIN, SHOW ENGINE, SHOW PROCESSLIST, InnoDB STATUS и т. п.
hints:
Быстрое решение проблем – перезапуск Apache / nginx / PHP-FPM
Автоматизация
Типовые решения Битрикс24 автоматизируются. Все алерты анализируются и группируются по способу решения проблемы. Проблемы, которые можно решить одинаковым образом, автоматизируются.
Примеры автоматизации:
- Критическое изменение load average – запускаются или останавливаются сервера и происходит автоматическое масштабирование
- Автоматический рестарт проблемных сервисов, например, при утечке памяти.
- Автоматическое «удаление» проблемных машин
- Автоматическое восстановление репликации
- Автоматическое переключение трафика в случае аварии на уровне целого ДЦ
Реализуют автоматизацию с помощью простого иснтрумента event handler, который есть и в Nagios, и в Shinken. По сути, это срабатывание определенных скриптов на определенные алерты.
Пример скрипта:
Для типовых решений, которые нельзя полностью автоматизировать, заведены готовые playbooks. Они реализованы с помощью Ansible. Пример playbook: в mysql есть переменные, которые нельзя изменять в runtime. Playbook делает всё. Он переключает трафик на один дата-центр, останавливает mysql, меняет переменные и запускает его обратно, отслеживает репликацию между дата-центрами и выполняет все тоже самое в другом дата-центре.
Про команду
В начале работы сервиса Битрикс24 взаимодействие сотрудников проходило под лозунгом «слабоумие и отвага». С того времени многое было сделано, но плакат до сих пор вдохновляет.
Коммуникация
Коммуникация между сотрудниками проходит через бизнес процесс сервиса Битрикс24. Вначале разработчики запускают деплой и сообщают, что выкатили релиз на эталонную среду. Далее тестировщики проводят свой цикл работ с ними и сообщают о завершении. Потом бизнес процесс уходит на утверждение техническому директору либо руководителю разработки, который дает добро на выкатку кода в stage или production. Когда заканчивается процесс деплоя, идет дополнительная проверка. Вся информация доступна в приложении, через браузер и смартфон.
Сотрудники данные по работе сервиса могут получить самостоятельно . Для этого все логи доступны через Elasticserch в Kibana. Таким образом, разработчики получают данные сами. Это значительно снижает нагрузку на мониторинг.
Для запросов реализован механизм открытой линии заявок. Сотрудники пишут в чат не конкретному человеку, а в очередь, которая распределяется на всех. Из очереди задачи распределяются на нужных сотрудников.
Поиск, обучение и работа персонала
При найме нового персонала учитываются понимание работы с linux и владение стандартными инструментами. Этого достаточно, чтобы понять может человек решать проблемы на базовом уровне или нет.
Для документирования используются своя wiki, где описываются все вопросы. Это помогает быстро включить сотрудников в работу.
Дежурства организованы по неделям. Для планирования используется календарь Битрикс24. Задача дежурного за день сделать так, чтобы ночью он спал спокойно. Основная задача – обработка алертов. Для координации работы есть планёрки.
Итог
Сегодня мониторинг Битрикс24 хорошо организован. Силами коллектива из трех человек обеспечено не только круглосуточное дежурство, но и развитие архитектуры. Ставка на использование облачных серверов подтвердила свои преимущества. Благодаря облачному хостингу сервис Битрикс24 направляет свои усилия на развитие проекта вместо изучения лишней компетенции в отношении серверной части.
Битрик24 в цифрах:
- Около 300 виртуальных серверов и прочих сервисов.
- 14 дата-центров практически по всему миру.
- До 135 000 хитов в минуту в пике.
- 100М хитов к динамике в сутки.
Хотите подобную систему мониторинга своего продукта, обращайтесь [email protected]