пятница, 30 июля 2010 г.

[prog] Расскажу о своем опыте периодической отсылки e-mail-ов

В продолжение вчерашней заметки поделюсь своим небольшим опытом. Для обслуживания своего софта на серверах мы разработали несколько маленьких рубиновых (написанных на языке Ruby) инструментов под общим названием pma tools. Например, там есть инструмент log_archiver, который архивирует старые логи. И инструмент too_old_eraser, который отвечает за удаление слишком старых архивов и вспомогательных файлов. И еще несколько специализированных скриптов.

За работой этого хозяйства (которое работало в автоматическом режиме по расписанию) нужно было следить. Например, извещать системных администраторов о проблемах. Или, как это бывало при вводе в строй новых серверов, напоминать о том, что какой-то инструмент на сервере не запущен.

Решили мы это дело просто. Каждый скрипт из состава pma tools логировал свои действия. А логгер анализировал, какие сообщение идут из скрипта. Если в лог файл попадали только сообщения с уровнями важности DEBUG, INFO и NOTICE, то такой лог считался успешным. А вот если в лог попадало хотя бы одно сообщение с уровнями WARN, ERROR или FATAL, то такой лог объявлялся проблемным.

Успешные и проблемные логи раскладывались по разным каталогам. Система каталогов вот такая:

log/
`- log_archiver/
   `- ok/
   `- problems/
`- too_old_eraser/
   `- ok/
   `- problems/
...

Т.е. если какой-то скрипт работает без проблем, то содержимое его каталога ok постоянно пополняется. Если же в его работе возникает сбой, то появляется новый файл в каталоге problems.

За всем этим хозяйством следит самый главный скрипт – result_analyzer. Он запускался периодически и проверяет содержимое каталогов ok и problems для каждого из компонентов. Если он находит новые файлы в каталоге problems, то формирует e-mail системному администратору о проблеме компонента. Если же он обнаруживает, что для компонента слишком долго нет новых файлов в каталоге ok – что, обычно, свидетельствовало о том, что компонент забыли настроить и запустить – то системному администратору сообщается и об этом.

Поскольку result_analyzer запускается где-то раз в 15 минут и за один проход собирает все проблемные логи в один e-mail по каждому из компонентов, то это дало разумный компромисс между оперативностью отсылки уведомления о проблеме и количеством этих уведомлений.

Так же result_analyzer удаляет устаревшие файлы логов из каталогов ok и problems. Причем его можно настроить так, чтобы у разных типов логов время жизни было разным. Скажем, успешные логи живут не более 2-х часов, а проблемные логи – не менее 3 дней.

Вот такой велосипед мы собрали на коленке лет пять назад. До сих пор работает :)

2 комментария:

  1. Если бы еще на файловых системах транзакции бы работали... )

    ОтветитьУдалить
  2. То это были бы уже и не файловые системы :)

    ОтветитьУдалить