Система мониторинга Яндекс

2,184 views

Published on

Система мониторинга Яндекс

Published in: Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,184
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
29
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Система мониторинга Яндекс

  1. 1. Система мониторинга ЯндексМаксим Лапань <lapan@yandex-team.ru>Яндекс
  2. 2. Мониторинг: функции Чем больше серверов вы • Задачи мониторинга:обслуживаете,обслуживаете тем чаще • Сб данных о работе Сбор бвозникают проблемы. серверов, сервисов, свичей и т д ; т.д.; Присматривать за парой • Оповещение осерверов возможно За возможно. возникновении проблем;десятком неудобно. За сотней • Анализ собранных данныхуже нереально нереально. (графики). (графики)
  3. 3. Требования к мониторингу• Прозрачная масштабируемость до десятков датацентров;• Мониторинг нескольких тысяч устройств в каждом ДЦ;• Обработка нескольких тысяч уведомлений в день день.
  4. 4. Суровая действительность: nagios• На серверах по cron запускаются скрипты с проверками, результаты отправляются на сервера nagios;• Конфигурация nagios — большой- большой файл, генерируемый скриптами с описанием серверов, сервисов, групп, правил оповещения и т.д.;• Помимо nagios, данные хранятся в rrd, по которым строятся графики.
  5. 5. Nagios: недостатки• Система не отказоустойчива и масштабируется переносом части проверок на отдельные сервера;• Все изменения конфигурации выполняются правкой файлов конфигурации с последующим перезапуском nagios (~10-15 минут);• Слишком большой интервал между проверками и замерами параметров;• RRD усредняет данные, поэтому невозможно сказать, каково было точное значение параметров, например, месяц назад. Каждую из этих проблем в отдельности можно было бы решить Однако решить. решив все, получим почти полностью переписанный nagios.
  6. 6. Светлое будущее: zabbix• Особенности:• Вся конфигурация хранится в базе управляется через web-интерфейс; базе, web интерфейс;• Единая точка доступа для пользователей;• Разграничение доступа к данным и конфигурации;• Минимальный интервал между замерами — 1 секунда;• С серверов собираются не результаты проверок (сломалось или нет) а нет), количественные характеристики работы, которые анализируются на стороне сервера;• Время хранения данных ограничено лишь дисковым пространством;• Развитые возможности анализа собранных данных.
  7. 7. Архитектура zabbix Web interface Zabbix agent — многопоточный демон,собирающий требуемые параметры намашине и отправляющий результаты насервер; DB Zabbix server — собирает данные,выполняет проверки и рассылаетуведомления Zabbix server Web interface — изменение параметров inte face з е е е а а е омониторинга, визуализация данных,управление оповещениями, и т.д. agent SNMP TCP/HTTP/..
  8. 8. Недостатки Все данные истории хранятся в базе что неэффективно и базе,ограничивает масштабируемость; Не б Н обеспечивается отказоустойчивость. йЧто делать? Хранить историю в распределенной FS; Сооружать отказоустойчивую конфигурацию.
  9. 9. Яндекс-zabbix Датацентр 1 Д Zabbix agent Virtual IP Zabbix agent GPFS Zabbix agent g z.server z server mysql mysql Web frontend Oracle RAC Датацентр 3 Датацентр 2 GPFS GPFS Web frontend Web frontend Oracle RAC Oracle RAC z.server z.server mysql mysql mysql mysql
  10. 10. Мониторинговая пара• Два сервера, mysql master-master репликация;• Переключение virtual IP выполняется средствами uCARP;• В среднем переключение происходит за 1-2 секунды, прозрачно для агентов;• На активной машине пары используется локальный memcached;• Каждый сервер пары полностью автономен, то есть может выполнятьмониторинг датацентра и отправку уведомлений даже в случае потериконнективности между ДЦ. ДЦ Virtual IP z.server z server mysql mysql
  11. 11. Хранение историиДля хранения данных и состояния мониторинговой пары используетсяGPFS. В кластер GPFS входят обе машины пары и сервер с web-интерфейсом.интерфейсомХранятся все данные всегда За год в результате детального мониторинга всегда.1000 серверов (30 параметров с сервера, интервал обновления 5 секунд)накапливается 1.5 Тб данных. GPFS Web frontend Oracle RAC z.server mysql mysql
  12. 12. Web-интерфейсWeb-морда балансируется по ДЦ и использует локальный кусочек RAC. Примодификации данных в базе конфигурации срабатывают специальныетриггера, выполняющие асинхронную репликацию изменений в mysql намониторинговых парах. Таким образом, в каждом ДЦ хранится отдельнаяреплика конфигурации мониторинга. Web frontend Oracle RAC Web frontend Web frontend Oracle RAC Oracle RAC
  13. 13. Переделки в zabbix Хранение исторических данных в файловой системе В базе системе.хранится только конфигурация; Механизм асинхронной репликации конфигурации с oracle в mysqlво все датацентры; Разделение ответственности zabbix-серверов по датацентрам; д р р д ц р ; Поддержка в zabbix-сервер virtual IP; Улучшения в интерфейсе по работе с большим количествомсерверов и проверок.
  14. 14. Final Спасибо за внимание! С б Максим Лапань <lapan@yandex-team.ru>

×