Большинство наших приложений сегодня имеют довольно простую конечную точку работоспособности:

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

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

Верните JSON с данными о вашем здоровье

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

Предполагая, что вы выполните проверки, упомянутые в этом сообщении, это может быть примером ответа вашей конечной точки:

Также не забудьте правильно установить HTTP-статус ответа, чтобы он соответствовал статусу вашего приложения (200, когда все в порядке, и 503, когда все в плохом состоянии).

Проверьте подключения к БД

Независимо от того, используете ли вы PostgreSQL, MongoDB или любую другую базу данных, важно проверить, жива ли ваша БД или нет ли у ваших подключений таймаута.

Например, MongoDB имеет команду ping, которая может проверить, живо ли ваше соединение. Не забудьте заключить этот вызов в блок тайм-аута, как в этом примере:

С помощью этой проверки вы можете убедиться, что ваша БД отвечает вовремя.

РЕДАКТИРОВАТЬ 20.12.2016:

Как отметил в комментариях Марко Сингер:

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

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

КОНЕЦ РЕДАКТИРОВАНИЯ 20.12.2016

Проверьте ваше соединение с Redis

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

Redis имеет ту же команду ping, которую я упоминал для MongoDB, но в этом случае она возвращает строку 'PONG'.

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

А по поводу этого…

Проверьте задержку очередей ваших фоновых заданий

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

Упомянутый Sidekiq предлагает вам несколько очень удобных методов для проверки задержки любой очереди:

Что может быть включено в ответ вашей конечной точки:

А как насчет вашей конечной точки работоспособности? Что вы проверяете? Оставить комментарий :)

Если вас интересует больше сообщений о мониторинге, вы можете проверить этот пост о двух простых инструментах мониторинга для вашего приложения.