Bykov monitoring mailru
Upcoming SlideShare
Loading in...5
×
 

Bykov monitoring mailru

on

  • 1,406 views

 

Statistics

Views

Total Views
1,406
Views on SlideShare
1,041
Embed Views
365

Actions

Likes
0
Downloads
16
Comments
0

6 Embeds 365

http://profyclub.ru 265
http://ritconf.ru 66
http://www.ritconf.ru 13
http://new.profyclub.ru 13
http://profyclub.ontico.ru 7
http://2011.ritconf.ru 1

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

Bykov monitoring mailru Bykov monitoring mailru Presentation Transcript

  • Мониторинг как высоконагруженный проект Олег Бунин Быков Александр 14.4.10
  • Зачем нужен мониторинг ? • Контроль работоспособности системы; • Контроль ключевых рабочих параметров; • Своевременное обнаружение неполадок; • Локализация неполадок; • История событий и анализ инцидентов; • Предупреждение и профилактика отказов.
  • Исходные данные • Больше тысячи серверов, десятки проверок на каждом; • Используемые протоколы: PING, HTTP, SNMP, SMTP, POP3, OPORT; • Несколько датацетров, сложная сетевая инфраструктура; • Высокая связанность проектов между собой; • Морально устаревшая система мониторинга. View slide
  • Старая система • Медленный опрос (большой цикл по всему конфигу); • Медленная база (все результы проверок в СУБД); • Неэффективный формат истории в СУБД; • Большое количество конфигурационных файлов; • Небогатый интерфейс. View slide
  • Требования времени • Моментальное обнаружение сетевых проблем (до 20 секунд); • Быстрый опрос основных сервисов (до 60 секунд); • Высокая производительность (должно умещаться в сервер); • Децентрализованность и работа при потере связности; • Интеграция с системой управления конфигурацией; • Удобный и быстрый интерфейс (группировки и фильтры); • История с расширенным поиском, графики.
  • Nagios не предлагать • fork() на проверку это очень дорого; • Минимальный интервал проверок 60 секунд; • Сложные и громоздкие конфиг-файлы; • Невозможность нормального мониторинга по SNMP; • Централизация мониторинга на одной машине; • Медленный и неудобный интерфейс; • Невозможность интеграции из-за отсутствия СУБД.
  • Собираем велосипед
  • Оптимизация СУБД • Оставляем совместимость по базе со старой системой; • Список проверок и сервера переносим в базу; • В базе храним только негативные статусы; • Положительные статусы храним в memcached; • В историю пишем запись по окончании проблемы; • Из разных баз собираем информацию интерфейсом.
  • AnyEvent и сотоварищи XS-модули: • AnyEvent::FastPing; • AnyEvent::HTTP; • AnyEvent::Socket (SMTP, POP3, OPORT, MRIM ...); Проблемы: • Необходимость rate limit; • Большой объем трафика создаваемый HTTP.
  • Особенности протокола SNMP Плюсы: • Возможность мониторинга сетевого оборудования; • Доступно множество рабочих параметров; • Расширяемость через agent и embeded perl; Минусы: • Необходимость последовательного сканирования; • Небогатые возможности проверок; • Проблемы реализации клиентов (блокирйющий exec).
  • Клиент SNMP::Multi • Родной XS-модуль для пакета net-snmp; • Лимит на кол-во одновременных сессий из-за select; • Приходится экономить и делать последовательный опрос; • Зависающие запросы на большом количестве сессий; • Нормальной замены нет.
  • Немного про SNMP-inform • Уведомление с подтверждением о доставке; • Теоретически мгновенное уведомление о проблемах; • Но опять проблемы с реализацией: - в сервер жестко зашито число повторных отправок - из-за этого иногда не доставляются
  • Вопросы ? bykov@corp.mail.ru