netology-devops/src/homework/10-monitoring/10.1/readme.md

Выполнение домашнего задания по теме "10.1. Зачем и что нужно мониторить"

Q/A

Задание 1

Обязательные задания

1. Вас пригласили настроить мониторинг на проект. На онбординге вам рассказали, что проект представляет собой платформу для вычислений с выдачей текстовых отчетов, которые сохраняются на диск. Взаимодействие с платформой осуществляется по протоколу http. Также вам отметили, что вычисления загружают ЦПУ. Какой минимальный набор метрик вы выведите в мониторинг и почему?

Стоит выделить несколько основных метрик для мониторинга:

1. метрики дисков, а именно:

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

2. метрики web-сервера

   • количество входящих запросов в секунду (общая и по каждому endpoint), чтобы была возможность отследить неожиданные всплески запросов и, возможно, закрыть доступ по ip-адресу.
   • скорость выполнения запросов по каждому endpoint для контроля скорости работы приложения. В дальнейшем на основе этой метрики стоит построить мониторинг по процентилям (например, чтобы 98% запросов выполнялись в рамках определённого времени).

3. метрики процессора

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

4. метрики сетевого интерфейса

   • скорость приёма и отдачи информации по сети
   • общий размер принятой и отданной информации

   Данные метрики необходимы для анализа динамики сетевого взаимодействия и дальнейшего планирования апгрейда сетевых интерфейсов.

2. Менеджер продукта посмотрев на ваши метрики сказал, что ему непонятно что такое RAM/inodes/CPUla. Также он сказал, что хочет понимать, насколько мы выполняем свои обязанности перед клиентами и какое качество обслуживания. Что вы можете ему предложить?

В данном случае стоит определить конкретные SLA и SLO.

Например, можно определить следующие SLO (цели уровня обслуживания) с обсуждаемыми в дальнейшем значениями:

• 99.98% запросов обрабатываются успешно
• 90% запросов обрабатываются в течение 5 секунд

И возможно определение следующих SLA (соглашений об уровне обслуживания):

• доступность системы - 99.98%
• реагирование на инциденты:
  • при высокой нагрузке на процессор в течение некоторого времени (н-р, загрузка всех ядер >90% в течение 1 часа) команда произведёт горизонтальное масштабирование системы для распределения нагрузки в течение 3 часов.
  • при критическом уровне свободного места (н-р <3GB) будет подключен дополнительный физический/сетевой диск в течение 3 часов.
  • реагирование на резкий и неожиданный всплеск входящих запросов в течение 1 часа

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

Если нет финансирования, значит необходимо искать варианты среди решений с открытым исходным кодом (или свободных решений). Из вариантов:

• elk-стек (elasticsearch + logstash + kibana) + сбор логов при помощи logstash/fluentd
• clickhouse + grafana + vector. vector используется в качестве принимающей точки, так и для непосредственно сбора логов.
• grafana loki + grafana + сбор логов при помощи fluentd.

4. Вы, как опытный 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 успешно обработанными.

Задание 2

Дополнительное задание

Вы устроились на работу в стартап. На данный момент у вас нет возможности развернуть полноценную систему мониторинга, и вы решили самостоятельно написать простой python3-скрипт для сбора основных метрик сервера. Вы, как опытный системный-администратор, знаете, что системная информация сервера лежит в директории /proc. Также, вы знаете, что в системе Linux есть планировщик задач cron, который может запускать задачи по расписанию.

Суммировав все, вы спроектировали приложение, которое:

• является python3 скриптом

• собирает метрики из папки /proc

• складывает метрики в файл 'YY-MM-DD-awesome-monitoring.log' в директорию /var/log (YY - год, MM - месяц, DD - день)

• каждый сбор метрик складывается в виде json-строки, в виде:

  + timestamp (временная метка, int, unixtimestamp)
  + metric_1 (метрика 1)
  + metric_2 (метрика 2)
  
    ...
  
  + metric_N (метрика N)
  

• сбор метрик происходит каждую 1 минуту по cron-расписанию.

• количество собираемых метрик должно быть не менее 4-х.

Для успешного выполнения задания нужно привести:

1. работающий код python3-скрипта
2. конфигурацию cron-расписания
3. пример верно сформированного 'YY-MM-DD-awesome-monitoring.log', имеющий не менее 5 записей

Пример python-скрипта, который снимает некоторые метрики из файлов директории /proc: monitor.py.

Конфигурация cron-расписания:

* * * * * monitor.py

Пример формируемого файла: 22-09-23-awesome-monitoring.log.