Выполнение домашнего задания по теме "10.1. Зачем и что нужно мониторить"
Q/A
Задание 1
Обязательные задания
- Вас пригласили настроить мониторинг на проект. На онбординге вам рассказали, что проект представляет собой платформу для вычислений с выдачей текстовых отчетов, которые сохраняются на диск. Взаимодействие с платформой осуществляется по протоколу http. Также вам отметили, что вычисления загружают ЦПУ. Какой минимальный набор метрик вы выведите в мониторинг и почему?
Стоит выделить несколько основных метрик для мониторинга:
-
метрики дисков, а именно:
- оставшееся свободное место, чтобы иметь возможность вовремя среагировать на отсутствие места для сохранения отчётов
- скорость чтения/записи с заранее определённой максимально допустимой скоростью как threshold. Это необходимо, чтобы понимать, в какой момент скорость работы приложения упирается в "железо", а когда есть проблемы со скоростью обработки вычислений внутри самого приложения.
-
метрики web-сервера
- количество входящих запросов в секунду (общая и по каждому endpoint), чтобы была возможность отследить неожиданные всплески запросов и, возможно, закрыть доступ по ip-адресу.
- скорость выполнения запросов по каждому endpoint для контроля скорости работы приложения. В дальнейшем на основе этой метрики стоит построить мониторинг по процентилям (например, чтобы 98% запросов выполнялись в рамках определённого времени).
-
метрики процессора
- загруженность ядер виртуальной машины, чтобы иметь возможность увидеть возможную проблему быстродействия приложения.
-
метрики сетевого интерфейса
- скорость приёма и отдачи информации по сети
- общий размер принятой и отданной информации
Данные метрики необходимы для анализа динамики сетевого взаимодействия и дальнейшего планирования апгрейда сетевых интерфейсов.
- Менеджер продукта посмотрев на ваши метрики сказал, что ему непонятно что такое RAM/inodes/CPUla. Также он сказал, что хочет понимать, насколько мы выполняем свои обязанности перед клиентами и какое качество обслуживания. Что вы можете ему предложить?
В данном случае стоит определить конкретные SLA и SLO.
Например, можно определить следующие SLO (цели уровня обслуживания) с обсуждаемыми в дальнейшем значениями:
- 99.98% запросов обрабатываются успешно
- 90% запросов обрабатываются в течение 5 секунд
И возможно определение следующих SLA (соглашений об уровне обслуживания):
- доступность системы - 99.98%
- реагирование на инциденты:
- при высокой нагрузке на процессор в течение некоторого времени (н-р, загрузка всех ядер >90% в течение 1 часа) команда произведёт горизонтальное масштабирование системы для распределения нагрузки в течение 3 часов.
- при критическом уровне свободного места (н-р <3GB) будет подключен дополнительный физический/сетевой диск в течение 3 часов.
- реагирование на резкий и неожиданный всплеск входящих запросов в течение 1 часа
- Вашей DevOps команде в этом году не выделили финансирование на построение системы сбора логов. Разработчики в свою очередь хотят видеть все ошибки, которые выдают их приложения. Какое решение вы можете предпринять в этой ситуации, чтобы разработчики получали ошибки приложения?
Если нет финансирования, значит необходимо искать варианты среди решений с открытым исходным кодом (или свободных решений). Из вариантов:
- elk-стек (elasticsearch + logstash + kibana) + сбор логов при помощи logstash/fluentd
- clickhouse + grafana + vector. vector используется в качестве принимающей точки, так и для непосредственно сбора логов.
- grafana loki + grafana + сбор логов при помощи fluentd.
- Вы, как опытный SRE, сделали мониторинг, куда вывели отображения выполнения SLA=99% по http кодам ответов. Вычисляете этот параметр по следующей формуле: summ_2xx_requests/summ_all_requests. Данный параметр не поднимается выше 70%, но при этом в вашей системе нет кодов ответа 5xx и 4xx. Где у вас ошибка?
По всей видимости не учитываются возможные ответы со статусами 3xx (редиректы).
Необходимо добавить метрику summ_3xx_requests и изменить формулу на следующую:
(summ_2xx_requests+summ_3xx_requests)/summ_all_requests
В данном случае считаем ответы 3xx успешно обработанными.