Your SlideShare is downloading. ×

Bykov monitoring mailru

1,153

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,153
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
17
Comments
0
Likes
1
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

×