Какова должна быть область проверки работоспособности системы, которая развертывает веб-приложение?

Сегодня у меня была задача «написать проверку работоспособности» для долго работающей службы, которая представляет собой систему оркестровки для развертывания веб-приложения.

Я пытаюсь определить, какой будет область для такой проверки работоспособности, и придумал следующие вопросы, связанные с областью проверки работоспособности:

1. Достаточно ли правильно считать службу работоспособной, если система оркестровки сообщает, что задача выполняется?
2. Или мы должны вручную пинговать каждый сервис?
3. Или он должен пойти дальше и попытаться убедиться, что веб-приложение выполняет то, что оно должно делать, например показ веб-страницы?
4. Должна ли проверка работоспособности также проверять, работают ли некоторые зависимые службы? Как база данных или сама система оркестровки. Или это ответственность другого медицинского осмотра?
5. И наконец, если одна из зависимых служб мертва, а веб-приложение впоследствии выходит из строя, должно ли веб-приложение сообщать о плохом состоянии или это хорошее состояние, потому что это не ошибка веб-приложений?

Я знаю, что это 5 отдельных вопросов, но все они относятся к области проверки работоспособности для долгосрочной службы, которая развертывает веб-приложение, поэтому я подумал, что было бы разумнее объединить их в один вопрос.

Это трудно реализовать для меня, потому что я не уверен, что определение здорового состояния или как должна выглядеть стандартная проверка работоспособности для чего-то подобного.

Что должна содержать проверка работоспособности для этой конкретной услуги?

Это трудно реализовать из-за определения того, что является здоровым

Вы ответили на свой вопрос здесь. Определение проверки здоровья будет варьироваться, потому что меняется состояние здоровья. Это также зависит от того, что выдает проверку здоровья.

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

Вероятно, в большой организации у вас будет какой-то стандарт того, что должна делать проверка здоровья. Пойми это.

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

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

Для отредактированных вопросов:

Достаточно ли правильно считать службу работоспособной, если система оркестровки сообщает, что задача выполняется?

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

Или мы должны вручную пинговать каждый сервис?

Это может работать, в зависимости от области применения вашего приложения. Если проверка службы отвечает на "ты жив?" Пинг тогда это может быть все, что требуется. Но если служба легко может быть «живой и отзывчивой, но на самом деле не работающей», то, возможно, вам нужно проверить и другие вещи.

Или он должен пойти дальше и попытаться убедиться, что веб-приложение выполняет то, что оно должно делать, например показ веб-страницы?

Ваша проверка работоспособности должна гарантировать, что требуемая функциональность, которая ожидается, работает должным образом.

Если ваше приложение возвращает «здоровый» и не может делать то , что ему нужно сделать, вы можете также избавиться от всего Healthcheck , поскольку это дает ложные срабатывания (не говоря уже о запутать черты из людей , которые пытаются отладить эту проблему - «эй наш веб-сервер показывает здоровый, почему мы не можем видеть страницу? ').

Должна ли проверка работоспособности также проверять, работают ли некоторые зависимые службы? Как база данных или сама система оркестровки. Или это ответственность другого медицинского осмотра?

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

Например, для чтения веб-сервера из базы данных требуется информация о состоянии встроенной в него базы данных, иначе веб-приложение просто рухнет при сбое вызовов API. Вы можете тривиально изменить эти вызовы, чтобы включить их в свою проверку здоровья.

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

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

И наконец, если одна из зависимых служб мертва, а веб-приложение впоследствии выходит из строя, должно ли веб-приложение сообщать о плохом состоянии или это хорошее состояние, потому что это не ошибка веб-приложений?

Это в основном ответил выше. Я бы порекомендовал, чтобы ваша медицинская служба возвратила код / ​​сообщение / что-либо, что дает эту информацию. Обе части информации важны: что зависимая служба, в которой нуждается ваша служба, устарела и что ваша служба не будет работать так, как ожидалось.

Обычно проверка работоспособности означает «жив ли он и отвечает». Дальнейшие проверки более узкие и полностью зависят от использования системы. Пройдете ли вы лишнюю милю, чтобы убедиться, что система правильно обрабатывает запросы, решать только вам, но сначала вы должны сделать основы - проверить это там, проверить, может ли он получать запросы и будет возвращать ответ.

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

Проверка зависимых систем не является частью проверки работоспособности, вам нужно, чтобы она была простой и автономной. Добавьте проверку работоспособности для каждой зависимой службы по очереди. Таким образом, вы можете получить список работающих, исправных систем и легко определить, когда кто-то выходит из строя, какой это!

По моему опыту, критически важные службы, как правило, имеют следующие функции:

Сердцебиение

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

Панировочные сухари

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

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