Фатальные ошибки в живых серверах - PullRequest
1 голос
/ 05 января 2009

Я пишу некоторое клиент-серверное программное обеспечение и сталкиваюсь со следующей проблемой дизайна. Обычно я использую макрос VERIFY очень свободно - если что-то не так на компьютере пользователя, я хочу, чтобы программное обеспечение не работало и регистрировало ошибку, чтобы ее можно было исправить. Я никогда не был фанатом игнорирования каких-либо ошибок.

Однако сейчас я пишу сервер. Если сервер умирает, многие клиенты выходят из строя, поэтому сервер должен умереть как можно меньше. Поэтому я не знаю, как лечить некоторые состояния, которые в противном случае я бы считал фатальными исключениями.

Например, я получаю сетевой пакет от пользователя, который не вошел в систему. Хотя это не должно происходить, у меня достаточно опыта, чтобы знать, что время от времени случаются «невозможные» ошибки. Так что я уверен, что если я сделаю фатальную ошибку в этих случаях, сервер в конечном итоге рухнет. С другой стороны, я мог бы регистрировать и игнорировать ошибку и продолжать, но, боюсь, некоторые ошибки могут остаться незамеченными.

Что бы вы сделали в такой ситуации?

1 Ответ

3 голосов
/ 05 января 2009

Если вы можете исправить ошибку, то, очевидно, она не была фатальной. Я не вижу преимущества неудачи, если вы можете зарегистрировать ошибку и продолжить выполнение - самое важное, что вы зафиксировали ошибку в журнале. Если вы можете восстановиться и продолжать работать в обычном режиме, то это лучший путь.

Вы должны дополнительно внедрить систему уведомлений ( мониторинг сервера ), которая в зависимости от уровня ошибки будет уведомлять вас с различной степенью срочности, чтобы вы могли как можно скорее забрать что-нибудь критическое по времени. Для серверов существуют такие общие системы, как Nagios и Munin . Вам следует взглянуть на то, что они делают, и посмотреть, сможете ли вы что-то взять у них и внедрить / интегрировать в свою систему.

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

...