Выполнение [домашнего задания](https://github.com/netology-code/mnt-homeworks/blob/MNT-13/10-monitoring-01-base/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](https://hub.docker.com/_/elasticsearch) + [logstash](https://hub.docker.com/_/logstash) + [kibana](https://hub.docker.com/_/kibana)) + сбор логов при помощи [logstash](https://hub.docker.com/r/elastic/filebeat)/[fluentd](https://hub.docker.com/_/fluentd) * [clickhouse](https://hub.docker.com/r/yandex/clickhouse-server) + [grafana](https://clickhouse.com/docs/en/connect-a-ui/grafana-and-clickhouse/) + [vector](https://hub.docker.com/r/timberio/vector). vector используется в качестве принимающей точки, так и для непосредственно сбора логов. * [grafana loki](https://hub.docker.com/r/grafana/loki) + grafana + сбор логов при помощи [fluentd](https://hub.docker.com/_/fluentd). > 4. Вы, как опытный SRE, сделали мониторинг, куда вывели отображения выполнения SLA=99% по http кодам ответов. > Вычисляете этот параметр по следующей формуле: summ_2xx_requests/summ_all_requests. Данный параметр не поднимается выше > 70%, но при этом в вашей системе нет кодов ответа 5xx и 4xx. Где у вас ошибка? По всей видимости не учитываются возможные ответы со статусами `3xx` (редиректы). Необходимо добавить метрику `summ_3xx_requests` и изменить формулу на следующую: ```text (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-строки, в виде: > > ```text > + 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](./task2/monitor.py). Конфигурация cron-расписания: ```text * * * * * monitor.py ``` Пример формируемого файла: [22-09-23-awesome-monitoring.log](./task2/22-09-23-awesome-monitoring.log).