Bykov monitoring mailru

  • 1,076 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,076
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
17
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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