• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Система мониторинга Яндекс
 

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

on

  • 1,429 views

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

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

Statistics

Views

Total Views
1,429
Views on SlideShare
1,429
Embed Views
0

Actions

Likes
1
Downloads
17
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

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