Рассмотрим простую машину FreeBSD, на которой запущен SMTP-сервер - как я могу автоматически проверить, что он работает правильно (например, принимать входящие SMTP-соединения для определенных получателей и отбрасывать почту в каком-то Maildir)?
Мы уже используем программное обеспечение для мониторинга серверов (в этом случае, Nagios) и, конечно же, проводим ручные тесты, но мне было интересно: есть ли какой-нибудь общий способ запускать автоматические функциональные тесты на серверных службах?
Пример того, о чем я думаю: при перенастройке нашего сервера (что обычно происходит внутри виртуальной машины в целях тестирования) я рассматриваю возможность
Я полагаю, что возможность выполнить серию таких тестов для других служб (например, проверка возможности создания резервных копий, проверка того, что сервер IMAP принимает соединения для определенных пользователей и что он отображает правильную почту) может быть полезен для тестирования изменений конфигурации или для проверки правильности работы резервных копий восстановленной системы.
Этот вид тестов может быть более или менее легко записан как тест Nagios (насколько просто, зависит от рассматриваемого сервиса). Помните, что тест Nagios - это простая вещь, по крайней мере, интерфейс для Nagios, это просто программа или сценарий оболочки, возвращающий четко определенный ответ (код возврата и некоторый информационный текст).
Кроме того, уже доступно множество модулей для всех видов услуг, проверьте Обмен Nagios. Решение для вашего примера почты: этот.
Вы могли бы использовать ожидать для взаимодействия с сервисом, например
#!/usr/bin/expect -f
set timeout 1
spawn telnet localhost 25
expect "220 *"
send -- "helo localhost\n"
expect -- "250*Hello\ localhost*"
send -- "mail from: root@localhost\n"
expect -- "250\ OK"
send -- "rcpt to: root@localhost\n"
expect -- "250\ Accepted"
send -- "data\n"
expect -- "354*"
send -- "functional test\n.\n"
expect -- "250\ OK*"
send -- "quit\n"
expect "221*closing\ connection"
назовите это так
/path/to/expect.script | grep -q "250 OK"
if [ $? = 0 ]
then
echo "Message queued successfully"
else
echo "Message Failed to queue"
Затем вы можете продолжить, чтобы увидеть, правильно ли было доставлено сообщение в почтовый ящик, Maildir или что-то еще. Вы можете изменить localhost для удаленного хоста по вашему выбору, хотя это усложняет проверку доставки, но вы всегда можете использовать ожидание для входа в систему - это очень мощный инструмент.
Пользуюсь NAGIOS.
Если я заинтересован в тестировании отдельной функции, которая образует шаг в цепочке, предоставляющей некоторые бизнес-услуги, я проверяю это: для тестирования SMTP-сервера я буду использовать плагин SMTP, который подключается к порту 25 и ищет подходящий баннер; то же самое с сервером IMAP; и так далее.
Если меня интересует проверка сквозной последовательности, успешность или неудача всей цепочки, я проверю ее успешное завершение. Чтобы протестировать описанную вами цепочку, у меня вполне может быть задание cron, которое каждые 30 минут отправляет письма, содержащие определенную тестовую строку, на определенный адрес, и у меня будет плагин NAGIOS, который ищет эту строку в почтовом ящике получателя, и проверяет, регулярно ли обновляется.
Обычно я делаю и то, и другое, поэтому, если сквозной тест переходит в состояние ALERT, я ожидаю увидеть, что один или несколько промежуточных шагов также перешли в состояние предупреждения - возможно, приемник SMTP не работает или сеть связь между ними не работает, или диск заполнен на приемнике - и это даст мне первый ключ к исследованию сквозного отказа. Часто я группирую отдельные пошаговые тесты и сквозные тесты в одну сервисную группу для быстрого и удобного просмотра неисправных компонентов.
Но я считаю что отдельные плагины NAGIOS всегда должны быть небольшими и легкими. Итак, обратите внимание, как приведенный выше сквозной тест только окончательный успех или неудача цепочки; он ничего не делает для проверки шагов цепочки. Чем сложнее отдельный плагин, тем больше вероятность его неожиданного отказа и тем выше вероятность получения ложных срабатываний (или, что еще хуже, ложноотрицательных результатов) от моей системы мониторинга.