Организация системы мониторинга
Мониторинг — это главное, что есть у админа. Админы нужны для мониторинга, а мониторинг нужен для админов.
За последние несколько лет поменялась сама парадигма мониторинга. Новая эра уже наступила, и если сейчас вы мониторите инфраструктуру как набор серверов — вы не мониторите почти ничего. Потому что теперь «инфраструктура» — это многоуровневая архитектура, и для мониторинга каждого уровня есть свои инструменты.
Кроме проблем типа «упал сервер», «надо заменить винт в рейде», теперь надо понимать проблемы уровня приложения и уровня бизнеса: «взаимодействие с микросервисом таким-то замедлилось», «в очереди слишком мало сообщений для текущего времени», «время выполнения запросов к бд в приложении растет, запросы — такие-то».
У нас на поддержке около пяти тысяч серверов, в самых разных конфигурациях: от систем из трех серверов с кастомными докеровскими сетками, до больших проектов с сотнями серверов в Kubernetes. И за всем этим надо как-то следить, вовремя понимать, что что-то сломалось и быстро чинить. Для этого надо понять что такое мониторинг, как он строится в современных реалиях, как его проектировать и что он должен делать. Об этом и хотелось бы рассказать.
Как было раньше
Лет десять назад мониторинг был гораздо проще, чем сейчас. Впрочем, и приложения были попроще.
Мониторились, в основном, системные показатели: CPU, память, диски, сеть. Этого вполне хватало, потому что там крутилось одно приложение на php, и ничего больше не использовалось. Проблема в том, что по таким показателям обычно мало что можно сказать. Либо работает, либо нет. Что именно происходит с самим приложением, выше уровня системных показателей понять сложно.
Если проблема была на уровне приложения (не просто “сайт не работает”, а “сайт работает, но что-то не так”), то клиент сам писал или звонил, сообщал, что есть такая-то проблема, мы шли и разбирались, потому что сами мы такие проблемы заметить не могли.
Как сейчас
Сейчас совсем другие системы: с масштабированием, с автоскейлингом, микросервисы, докеры. Системы стали динамичными. Часто никто толком не знает, как именно все работает, на скольких серверах, как именно оно развернуто. Оно живет своей жизнью. Иногда даже неизвестно, что и где запущено (если это Kubernetes, например).
Усложнение самих систем, конечно, повлекло за собой большее количество возможных проблем. Появились метрики приложений, количество запущенных тредов у Java application, частота garbage collector pauses, количество событий в очереди. Очень важно, чтобы мониторинг также следил за масштабированием систем. Допустим, у вас Kubernetes HPA. Надо понимать, сколько запущено подов, и с каждого запущенного пода должны идти метрики в систему мониторинга приложения, в apm.
Все это нужно мониторить, потому что все это отражается на работе системы.
И сами проблемы стали менее очевидными.
Условно, проблемы можно поделить на две большие группы:
Проблемы первого рода – не работает основная, “пользовательская функциональность”.
Проблемы второго рода – что-то работает не так, как должно, и может куда-то не туда привести.
То есть теперь надо мониторить не только дискретное “работает/не работает”, а гораздо больше градаций. Что, в свою очередь, позволяет ловить проблему до того, как все рухнет.
Кроме того, теперь надо следить и за бизнес-показателями. Бизнес захотел иметь графики о деньгах, о том как часто идут заказы, сколько времени прошло с последнего заказа и так далее — это теперь тоже задача мониторинга.
Правильный мониторинг
Проектирование и вообще
Представление о том, что именно надо будет мониторить, должно быть заложено в момент разработки приложения и архитектуры, и речь даже не столько про серверную архитектуру, сколько про архитектуру приложения в целом.
Разработчики/архитекторы должны понимать какие части системы критичны для функционирования проекта и бизнеса, и заранее думать о том, что их работоспобность надо проверять.
Мониторинг должен быть удобным для админа, и давать представление о том, что происходит. Цель мониторинга – вовремя получить оповещение, по графикам быстро понять, что именно происходит и что именно нужно чинить.
Метрики и оповещения (алерты)
Алерты должны быть максимально понятными: админ, получив алерт, даже если он не знаком с системой, должен понять, о чем этот алерт, в какую документацию смотреть, или хотя бы кому позвонить. Должны быть четкие инструкции, что именно нужно делать, и как именно решать проблему.
Когда возникает проблема, очень хочется понять, из-за чего она возникла. Получая алерт о том, что у вас не работает приложение, вам очень хотелось бы знать, какие еще смежные системы ведут себя не так, какие еще есть отклонения от нормы. Должны быть понятные графики, собранные в дашборды, из которых сразу будет видно, где отклонение.
Для этого надо точно понимать, что нормально, а что не нормально. То есть должна быть достаточная историческая справка о состоянии системы. Задача заключается в том, чтобы покрыть алертами все возможные отклонения от нормы.
Когда админ получает алерт, он либо должен знать что с ним делать, либо кого спросить. Должна быть инструкция как именно нужно реагировать, и ее надо регулярно обновлять. Если у вас все работает через систему оркестрирования, то, наверное, у вас все хорошо, если все изменения происходят только через нее, в том числе и мониторинг. Система оркестрирования позволяет адекватно следить за актуальностью мониторинга.
Мониторинг должен расширяться после каждой аварии — если внезапно возникла какая-то проблема, которая проскочила мимо мониторинга, то, очевидно, надо замониторить эту ситуацию, чтобы в следующий раз проблема не была внезапной.
Бизнес-показатели
Полезно мониторить время с последней продажи, количество продаж за период. Если выложили релиз, то что изменилось: есть ли просадки по бизнес-показателям? На это отвечает, конечно, A/B тестирование, но графики тоже хотелось бы иметь. И надо мониторить действия конечного пользователя: писать скрипты на phantomjs, которые повторяют покупку, проходят по всем этапам основного бизнес-процесса.
Также вам, наверное, интересно знать, работает ли сервис логистики, или не свалился ли в очередной раз IpGeoBase. (Комментарий редактора: IpGeoBase — сервис, который использует большое число интернет-магазинов на 1С-Битрикс для определения местоположения пользователя. Чаще всего это делается непосредственно в коде загрузки страницы, и когда падает IpGeoBase — у нас перестают отвечать десятки сайтов. Кто-нибудь пожалуйста, скажите программистам, что это надо обрабатывать и делать таймаут, и кто-нибудь — пожалуйста попросите IpGeoBase не падать).
Нужно понимать, зависит ли просадка по бизнес-показателям от вашей системы, или от внешней.
Мониторинг мониторинга
Сам мониторинг тоже должен хоть как-то мониториться. Должен быть какой-то внешний кастомный скрипт, который будет проверять, что мониторинг работает нормально. Никому не хочется проснуться от звонка, потому что ваша система мониторинга упала вместе со всем дата-центром, и вам об этом никто не сказал.
Основные инструменты
В современных системах, которые масштабируются, у вас наверняка используется Prometheus, потому что аналогов в принципе нет. Для того, чтобы просматривать удобные графики от Prometheus нужна Grafana, потому что в Prometheus графики так себе. Нужен также какой-то APM. Либо это самописная система на Open Trace, jaeger и или что-то подобное. Но это редко кто делает. В основном используется либо New Relic, либо специфичные системы для стеков, типа Dripstat. Если у вас не одна система мониторинга, не один Zabbix, вам еще нужно понимать, как собирать эти метрики, и как раздавать алерты; кого оповещать, кого поднимать, в каком порядке, к кому какой алерт относится, и что с ним вообще делать.
Теперь по порядку.
Zabbix — не самая удобная система. Есть проблемы с кастомными метриками, особенно, если система масштабируется, и вам нужно определить роли. И хотя можно строить очень кастомные графики, алерты и дашборды, все это не очень неудобно и нединамично. Это статичная система мониторинга.
Prometheus — отличное решение для сборки огромного количества метрик. У него примерно те же возможности, что у Zabbix по кастомным алертам. Можно выводить графики и строить алерты по любым диким сочетаниям нескольких параметров. И это все очень здорово, но очень неудобно смотреть, поэтому к нему добавляется Grafana. Grafana очень красивая. Но сама по себе не очень помогает для мониторинга систем. Зато по ней удобно все читать. Лучше графиков, наверное, и нет.
ELK и Graylog — для сбора логов по событиям в приложении. Может быть полезно для разработчиков, но для подробной аналитики обычно не достаточно.
New Relic — APM, тоже полезный для разработчиков. Есть возможность понять, когда у вас в приложении прямо сейчас что-то идет не так. Понятно, какие из внешних сервисов не очень хорошо работают, или какая из баз медленно отвечает, либо какое системное взаимодействие просаживается.
Свой APM — если вы написали свою систему на Open Tracing, zipkin или jaeger, то, наверное, вы знаете, как именно это должно работать, и что именно, и в какой части кода идет не так. New Relic тоже позволяет это понять, но это не всегда удобно.
Заключение
О том какие показатели надо мониторить лучше думать в время проектирования системы, заранее подумать о том какие части системы критичны для ее работы и о том, как проверять их работу.
Алертов не должно быть слишком много, алерты должны быть актуальными. Должно быть сразу понятно, что сломалось и как это чинить.
Чтобы правильно замониторить бизнес-показатели, надо понять как устроены бизнес процессы, что нужно вашим аналитикам, хватает ли инструментов чтобы замерить нужные показатели, и как быстро можно узнать, если что-то пойдет не так.
В следующем посте мы расскажем как правильно спланировать мониторинг современной инфраструктуры, на всех уровнях: на уровнях системы, приложений и бизнеса.
Источник
Способы осуществления мониторинга
Все многообразие применяемых способов, технологий осуществления мониторинга можно свести к нескольким группам:
1. Текущее наблюдение осуществляется для отслеживания изменений профессионального развития под влиянием образовательного процесса и определения смысла происходящих явлений. Эффективность педагогического наблюдения зависит от психологической компетентности педагога, его опыта, отношения к обучаемым, профессиональной позиции т.д. Наблюдение всегда характеризуется субъективностью, что может отрицательно сказаться на качестве мониторинга.
2. Метод тестовых ситуаций заключается в том, что педагог создает специальные условия, в которых каждый из структурных компонентов учебно-профессиональной деятельности проявляется наиболее отчетливо. Для этого осуществляются приемы прерывания учебных действий обучаемых, постановки уточняющих вопросов, стимулирования рефлексии своих познавательных действий, дозирования помощи в учении и др.
3. Экспликация (отлат. explicatio — развертывание, разъяснение) — развертывание содержания учебно-профессиональной деятельности. Этот метод позволяет не только диагностировать происходящие изменения в развитии обучаемого, но и оперативно вносить коррективы в процесс образования.
Экспликация осуществляется путем постановки наводящих вопросов, оказания помощи в виде подсказок и совместных действий, поощрения педагогом обучаемых. Регистрация эксплицируемых характеристик осуществляется в простейшем случае посредством использования метода наблюдения, а фиксация данных — с помощью опросников, в которых отражаются эмпирически наблюдаемые учебно-профессиональные действия и качества обучаемых.
4. Опросные методы позволяют получить информацию о развитии субъектов образовательного процесса на основе анализа письменных или устных ответов на стандартные специально подобранные вопросы. Опросники дают возможность определить уровень выраженности или сформированности основных компонентов учебно-профессиональной деятельности, особенности направленности обучаемых и педагогов, а также отдельные учебно-познавательные свойства и качества.
Одним из действенных методов мониторинга является анализ результатов учебно-профессиональной деятельности, при котором по заранее намеченной схеме изучаются письменные тексты, графические
материалы, технические изделия, творческие работы обучаемых.
6. Тестирование — это один из субъективных методов сбора данных об уровне развития педагогических процессов и степени выраженности психического развития субъектов образования. Важным достоинством тестирования является ориентация на норму, что позволяет сопоставлять, сравнивать оценки, полученные при помощи теста. Для мониторинга применяют интеллектуальные, личностные, межличностные тесты, практические тестовые задания, процессуальные тесты.
Выделяют три формы мониторинга.
1. Стартовая диагностика обучаемости и воспитуемости осуществляется сотрудниками психологической службы. Ее результаты в самом общем виде доводятся до сведения педколлектива. Большое внимание уделяется рекомендациям по коррекции этих двух важных показателей продуктивности образовательного процесса.
Для осуществления мониторинга профессионального развития в течение всего времени обучения в учебном заведении применяется экспресс-диагностика социально и профессионально важных характеристик обучаемых. Экспресс-диагностику также проводит психолог, но ее результаты обсуждаются с педагогами, которые оперативно вносят коррективы в учебно-образовательную деятельность. Данные экспресс-диагностики становятся ориентировочной основой для построения программ педагогических наблюдений, анализа продуктов деятельности, проектирования учебных задач и ситуаций. В случае необходимости по результатам стартовой и текущей диагностики проводятся психолого-педагогические консилиумы.
3. Финишная диагностика профессиональной подготовленности выпускников, помимо определения уровня сформированных социально-профессиональных знаний, навыков и умений, включает диагностику степени развития качеств, необходимых будущему специалисту.
Последовательное осуществление мониторинга позволяет обеспечить интеграцию трех сторон личностно ориентированного профессионального образования: развития личности, профессионально-образовательного процесса, взаимодействия обучаемых и педагогов.
В логике личностно ориентированного профессионального образования актуальным становится мониторинг профессионально-образовательного процесса и профессионального развития обучаемых. Рассмотрим мониторинг этих двух взаимосвязанных процессов.
Мониторинг профессионально-образовательного процесса
Основные задачи мониторинга:
• отслеживание трудностей, непонимания, препятствий, возникающих при усвоении нового учебного материала;
• создание реального механизма управления профессионально-образовательным процессом;
• получение информации о сформированности способов учебно-познавательной деятельности;
• индивидуализация педагогом своей деятельности;
• обнаружение и фиксация непредсказуемых, неожиданных отклонений в профессионально-образовательном процессе.
Решение этих задач на основе традиционной оценки образовательного процесса, базирующейся на определении показателей сформированности знаний, умений и навыков, а в отдельных случаях — на диагностике психического развития, затруднено. Конечно, по результатам многолетних оценок информация такого рода имеется и на ее основе вносятся коррективы и в содержание образования, и в технологии обучения. Но оперативное отслеживание и корректировка образовательного процесса возможны только на основе мониторинга.
Способы осуществления мониторинга профессионально-образовательного процесса можно разделить на две группы:
• способы сбора информации, регистрации состояния текущих процессов;
• способы учета полученных данных при принятии управленческих решений и регуляции образовательного процесса[20].
Сбор информации осуществляется с учетом структуры профессионально-образовательного процесса:
• учебно-познавательной и профессионально ориентированной мотивации;
• обобщенных способов выполнения учебных и профессиональных действий при решении учебных задач;
• оценки уровня развития познавательных и учебно-профессиональных способностей обучаемых.
Мониторинг мотивации учения может быть достаточно успешно осуществлен с помощью метода наблюдения. Наблюдая за деятельностью обучаемых в различных учебно-профессиональных ситуациях, анализируя их отношение к учебе и будущей профессии, оценивая их достижения, педагог делает заключение об уровне выраженности у обучаемых позитивной мотивации. В отдельных случаях целесообразно использование специальных методик, направленных на диагностику мотивов учения.
Следующим моментом мониторинга является отслеживание процесса формирования обобщенных способов учебно-профессиональных действий. Педагог оценивает уровень их выраженности, систематически анализируя организацию учебного (рабочего) места, планирование выполнения учебно-профессиональных заданий, методику работы с учебно-технологической документацией, соблюдение правил техники безопасности при работе.
Важной частью мониторинга является оценка уровня развития познавательных и учебно-профессиональных способностей обучаемых. Для отслеживания уровня их выраженности целесообразно использование фрагментов интеллектуальных тестов, метода тестовых ситуаций и наблюдения за обучаемыми в процессе решения учебно-профессиональных задач.
Отрефлексированные в мониторинге уровни выраженности компонентов профессионально-образовательного процесса отражаются в специальном бланке (табл. 26). Помимо уровней выраженности структурных компонентов обучения, в бланке указываются его организационные формы и технологии осуществления мониторинга.
Регистрационный бланк мониторинга профессионально-образовательного процесса
Учебная профессия, специальность | Учебный предмет | Ф.И.О. учащегося | Группа №____ Время проведения мониторинга |
Темы занятий: | |||
Учебное задание | Количество часов | Число членов группы | |
Формы организации профессионально-образовательной деятельности: ФО БО ИО ФО – фронтальная (кооперативная организация), БО – бригадная (групповая) организация, ИО – индивидуальная (самоуправляемая) организация |
Структурные компоненты обучения | Технологии мониторинга | Уровни выраженности компонентов обучения | ||||
I | II | III | IV | V | ||
1. Учебно-познавательные мотивы 2. Профессионально ориентированная мотивация | Наблюдение, опросные методы Экспликация, анализ результатов учебно-профессиональной деятельности | | | | | |
2.1.Обобщенные способы учебных действий 2.2.Обобщенные способы профессиональных действий 2.3.Способы узкопрофессиональных действий 2.4.Способы самоконтроля | Наблюдение, эксплицирование Наблюдение, метод тестовых ситуаций, анализ результатов деятельности Наблюдение, метод тестовых ситуаций, анализ результатов выполнения практических заданий | | | | | |
3.Развитие познавательных и учебно-профессиональных способностей 3.1. Познавательные способности 3.2. Учебно-профессиональные способности 3.3. Профессиональные способности (ключевые квалификации) 3.4. Специальные (квалификационные) способности 3.5.Учебно-профессиональная самостоятельность | Наблюдение, тестирование (экспресс-диагностика) То же То же То же То же | | | | | |
Примечание. Уровни выраженности компонентов обучения: I – не проявляется; II – выражен удовлетворительно; III – отчетливо выражен; IV – хороший уровень выраженности; V – высокий уровень выраженности.
Регистрационный бланк заполняется преподавателем в конце изучения раздела профессионально-образовательной программы, объединяющего несколько тем занятий. Мастер производственного обучения заполняет бланк после выполнения комплексных работ, включающих несколько 4—6-часовых занятий. В конце каждой четверти, семестра показатели регистрационных бланков отражаются в итоговом индивидуальном профиле профессионально-образовательного процесса учащихся.
Результаты индивидуального мониторинга могут быть сведены в таблицу, отражающую профиль профессионально-образовательного процесса по учебным предметам (производственному обучению), а в отдельных случаях и по специальности. Для проведения этой процедуры каждому уровню выраженности присваиваются баллы от одного до пяти. Определяется среднеарифметический показатель, и строится профиль профессионально-образовательного процесса по учебному предмету или специальности, комплексу общепрофессиональных и специальных дисциплин (табл. 27).
Профиль профессионально-образовательного процесса
Источник