Любой еком динамичен и требует масштабирования, а значит, необходимо постоянно отслеживать, как система выдерживает растущие нагрузки. Авария на уровне инфраструктуры почти всегда означает цепную реакцию и отказ всего остального. Логично, что еще более важной задачей, чем отслеживание, является предупреждение потенциальных угроз. Делается это с помощью настройки специальных триггеров — при наступлении определенного события (например, на диске осталось менее 20% свободного пространства) система генерирует соответствующий алерт. Он, в свою очередь, направляется команде по любым выбранным каналам (к примеру, удобно использовать для этого ботов в Телеграм). Аналогично работают и сообщения о том, что все в порядке и система вернулась в штатный режим. Алерты могут иметь разный уровень критичности и заблаговременно подсветить большинство потенциальных проблем. Общее число триггеров может измеряться десятками, а иногда и сотнями событий. Здесь лучше руководствоваться принципом - чем больше знаем, тем лучше.
Выглядит круто
Есть еще Sentry https://sentry.io/welcome/ , серверную часть которой можно поставить локально в своей инфраструктуре, плюс она открыта полностью.
Еще Sentry это не просто мониторинг а телеметрия ( сбор ошибок в первую очередь ) и агенты к ней есть как для бекэнд так и для фронтэнд части - т.е можно видеть в реальном времени все ошибки с трейсами в системе вообще, без всякой формы обратной связи и не тревожа пользователей.
Но вообще автор не рассказал до конца: сам по себе такой мониторинг мало полезен, к нему нужна настроенная система реагирования на сбои, хотя-бы в виде отсылки sms/email оповещений при сбоях. Просто так сидеть и пырить на эти графики 24х7 живому человеку - никаких сил не хватит.
Спасибо за комментарий. Что касается темы алертов на события - она в статье упомянута, посмотрите внимательнее. Возможно, в будущем напишем подробнее о тонкой настройке оповещений.