Если проект работает в продакшене прямо сейчас, это не значит что он не перестанет работать завтра. Почему? Существует масса причин, почему все может пойти не так:
Ни одной из этих проблем нельзя избежать, даже если купить самое дорогое оборудование и нанять большую команду тестировщиков. Ошибки и сбои происходят регулярно у всех, а вот скорость их обнаружения и починки зависит от того, как настроен мониторинг.
Мониторинг неотъемлемая частью любого проекта, который помогает быстро обнаруживать неполадки и устранять их. Он включает в себя три основных элемента:
На базовом уровне, мониторинг есть в любом облаке. Для готовых сервисов типа балансировщика нагрузки или очереди, облака дают полный спектр метрик, какой только себе можно вообразить. Для серверов, мониторинг включает в себя информацию о загрузке процессора, потреблении оперативной памяти, сетевому трафику и нагрузке на диск. Этих метрик может быть недостаточно, если нужен тонкий контроль происходящего. Кроме того, на сервера ставятся программы, которые сами требуют мониторинга. Например для веб-сервера нужно, как минимум следить за количеством входящих запросов и ответами.
Откуда берутся данные для графика? Система мониторинга получает их от агента, специальной программы, которая установлена на сервер и собирает информацию о системе. Конкретно Digital Ocean, умеет устанавливать агент автоматически при создании сервера. Агенты внешних систем мониторинга придется ставить самостоятельно, например, с помощью Ansible.
Независимо от способа установки, все агенты работают примерно одинаково. Они получают данные от операционной системы или запущенных на ней программ и отправляют их в центральное хранилище. Получение данных происходит двумя способами: вытягиванием данных или приемом входящих данных.
В большинстве ситуаций предпочтительно вытягивание, так как его контролирует сам агент. Он извлекает нужную ему информацию от системы или приложений. Сюда входит масса различных вариантов взаимодействия: периодическое чтение файлов, запуск программ возвращающих нужные данные, http-запросы, например, в случае Nginx, который отдает специальную страницу с информацией о происходящем внутри него.
В большинстве систем мониторинга, агенты поставляются с готовыми интеграциями, либо расширяются сторонними решениями, которые знают как извлекать данные из приложений. А если такой интеграции нет, то всегда можно написать свою проверку.
В такой модели работы важно смотреть на интервал опроса. Чем он меньше, тем быстрее и точнее мы получаем информацию, но при этом нагрузка на систему возрастает, чем он больше, тем меньше точность, но меньше нагрузка на систему. Как ориентир можно смотреть на интервал в 15 секунд, но учитывайте, стоимость сервисов мониторинга часто зависит от скорости опроса.
Как только данные начинают поступать в сервис мониторинга, их сразу можно выводить на графиках. Благодаря готовым интеграциям, эти сервисы знают о том какие метрики и как собираются, поэтому часть графиков уже готова и, даже, объединена в дэшборды. Пример дэшборда Kubernetes в DataDog:
Наличие графиков полезно, когда мы уже знаем о проблеме и пытаемся в ней разобраться, но они не помогают узнать о существовании проблемы, пока мы на них не смотрим. Для оповещений нужно настраивать алерты. Каждый алерт следит за какой-то метрикой и срабатывает в том случае, если ее значение отклоняется от допустимого.
Оповещение о проблемах может происходит разными способами от сообщений в слаке до смс. Существуют даже специальные сервисы, которые настраивают правила оповещения команды в порядке дежурства до тех пор, пока кто-то не откликнется.
Интересно то, как алерты создаются. Представьте себе задачу отслеживания нагрузки на процессор. Если она высокая, то нужно разобраться почему и, в случае необходимости, добавить новый сервер. Кажется, что достаточно установить алерт на превышение порога нагрузки на процессор, например, в 80%. То есть если нагрузка на процессор выше 80%, то уходит оповещение. Звучит просто, но такой способ не приведет ни к чему хорошему. Нагрузка имеет свойство скакать. В течении дня она не раз может прыгать выше 80%, но большую часть времени не превышать 40%. В итоге слак будет завален сообщениями о несуществующих проблемах. Примерно тоже самое можно сказать и про любую другую метрику. Чтобы мы не отслеживали, пиковые значения всегда могут превышать норму. Как тогда быть?
Алерты создают по двум основным схемам:
Насколько такая настройка точная и гарантирует наличие или отсутствие проблемы? К сожалению, не существует способа точно определить когда проблема есть, а когда ее нет. Конечно же существуют практики того, как лучше настраивать алерты, но, по большей части, все зависит от конкретной системы, нагрузки на нее, интервале опроса и других параметров.
Главное в работе с алертами - реакция. Если алерты настроены плохо и срабатывают тогда, когда реакция не нужна, они быстро превращаются в белый шум, на который никто не обращает внимание. Становится легко пропустить что-то действительно важное. Алерты должны срабатывать только тогда, когда на них требуется реакция. Это требует постоянного добавления, удаления и настройки существующих алертов.
В тех случаях, когда готовый сервис мониторинга использовать не получается или нельзя, для мониторинга пользуются готовыми открытыми проектами. Сюда входят две системы:
hexlet program download devops-for-programmers monitoring
Зарегистрируйтесь на Datadog
Добавьте алерт на проверку доступности главной страницы приложения. Она должна отдавать 200 Status Code
Вам ответят команда поддержки Хекслета или другие студенты.
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.
Наши выпускники работают в компаниях:
Зарегистрируйтесь или войдите в свой аккаунт
Задавайте вопросы, если хотите обсудить теорию или упражнения. Команда поддержки Хекслета и опытные участники сообщества помогут найти ответы и решить задачу