что такое мониторинг объектов
Что такое мониторинг объектов
Статья 96. Мониторинг
1. Под мониторингом в целях настоящего Федерального закона понимается режим дистанционного государственного контроля (надзора), заключающийся в целенаправленном, постоянном (систематическом, регулярном, непрерывном), опосредованном получении и анализе информации о деятельности граждан и организаций, об объектах контроля с использованием систем (методов) дистанционного контроля, в том числе с применением специальных технических средств, имеющих функции фотосъемки, аудио- и видеозаписи, измерения, должностными лицами контрольного (надзорного) органа в целях предотвращения причинения вреда (ущерба) охраняемым законом ценностям.
2. Мониторинг основан на добровольном участии контролируемых лиц и осуществляется в случаях, установленных положением о виде контроля, по заявлению контролируемого лица на условиях соглашения между контролируемым лицом и контрольным (надзорным) органом.
3. Требования, которым должно соответствовать контролируемое лицо для осуществления мониторинга, устанавливаются положением о виде контроля.
4. Порядок организации и осуществления мониторинга устанавливается положением о виде контроля, соглашением между контрольным (надзорным) органом и контролируемым лицом.
5. Положение о виде контроля регулирует порядок подключения контролируемого лица (объекта) к автоматизированным информационным системам сбора и обработки данных, работающим в автоматическом режиме, специальным техническим средствам, имеющим функции фотосъемки, аудио- и видеозаписи, измерения, иным средствам сбора или фиксации информации, порядок доступа к указанным информационным системам и иным средствам сбора или фиксации информации, порядок обмена документами и иной информацией, а также характеристики автоматизированных информационных систем сбора и обработки данных, средств сбора или фиксации информации, места их установки, их количество, требования к необходимому программному обеспечению и при необходимости иные условия.
6. Форма соглашения о мониторинге утверждается контрольным (надзорным) органом и не может предусматривать преимущества для отдельных контролируемых лиц или оказание предпочтения отдельным контролируемым лицам.
7. Техническое оснащение и сопровождение мониторинга на объектах контролируемого лица производятся за счет контролируемого лица, если иное не установлено положением о виде контроля или соглашением о мониторинге.
8. Мониторинг осуществляется на основании решения контрольного (надзорного) органа, выпускаемого по результатам проведения оценки соответствия контролируемого лица требованиям, предъявляемым к нему для осуществления мониторинга, технической готовности контролируемого лица и контрольного (надзорного) органа к информационному взаимодействию в рамках мониторинга и заключения соглашения о мониторинге.
9. Соглашением о мониторинге между контролируемым лицом и контрольным (надзорным) органом может предусматриваться срок осуществления мониторинга, который не может быть менее одного года.
10. Уполномоченное должностное лицо контрольного (надзорного) органа принимает решение о прекращении осуществления мониторинга в одном из следующих случаев:
1) выявление несоответствия контролируемого лица требованиям, предъявляемым к нему для осуществления мониторинга, в том числе к технической оснащенности и сопровождению мониторинга;
2) неисполнение контролируемым лицом положений соглашения о мониторинге между контролируемым лицом и контрольным (надзорным) органом;
3) подача контролируемым лицом заявления о прекращении осуществления мониторинга;
4) иные случаи, установленные положением о виде контроля.
11. Контрольный (надзорный) орган уведомляет контролируемое лицо о прекращении мониторинга в течение десяти дней со дня принятия решения о прекращении осуществления мониторинга.
12. Федеральным законом о виде контроля может быть предусмотрено осуществление обязательного мониторинга в отношении контролируемых лиц, соответствующих критериям, установленным федеральным законом о виде контроля.
13. Порядок организации и осуществления обязательного мониторинга устанавливается положением о виде контроля.
14. Техническое оснащение и сопровождение обязательного мониторинга производятся за счет средств соответствующего бюджета бюджетной системы Российской Федерации, если иное не установлено федеральным законом о виде контроля.
15. Обязательный мониторинг осуществляется без ограничения срока его проведения.
16. Контролируемые лица, в отношении которых осуществляется обязательный мониторинг, освобождаются от плановых контрольных (надзорных) мероприятий в отношении соблюдения обязательных требований, являющихся предметом такого мониторинга.
17. В случае получения в ходе мониторинга, в том числе обязательного мониторинга, сведений о фактах нарушения обязательных требований контрольный (надзорный) орган принимает решения в соответствии с частью 2 статьи 90 настоящего Федерального закона.
Значение слова «мониторинг»
Мониторинг — система сбора/регистрации, хранения и анализа небольшого количества ключевых (явных или косвенных) признаков/параметров описания данного объекта для вынесения суждения о поведении/состоянии данного объекта в целом. То есть для вынесения суждения об объекте в целом на основании анализа небольшого количества характеризующих его признаков.
Мониторинг параметров — наблюдение за какими-либо параметрами[уточнить]. Результат мониторинга параметров представляет собой совокупность измеренных значений параметров, получаемых на неразрывно примыкающих друг к другу интервалах времени, в течение которых значения параметров существенно не изменяются.
Мониторинг веб сайтов — процесс проверки работоспособности и тестирования параметров доступности сайта или веб сервиса в сети Интернет. Специальные сервисы мониторинга сайтов имитируют действия тысяч посетителей для того, чтобы посмотреть, как ресурс реагирует на посещаемость и использование различной функциональности. При обнаружении какой-либо неисправности сервис посылает веб-мастеру сигнал, благодаря чему специалист сможет в короткие сроки восстановить работоспособность собственного ресурса. Использование мониторинга доступности сайтов обладает массой дополнительных преимуществ.
Мониторинг состояния — наблюдение за состоянием объекта для определения и предсказания момента перехода в предельное состояние. Результат мониторинга состояния объекта представляет собой совокупность диагнозов составляющих его субъектов, получаемых на неразрывно примыкающих друг к другу интервалах времени, в течение которых состояние объекта существенно не изменяется. Принципиальным отличием мониторинга состояния от мониторинга параметров является наличие интерпретатора измеренных параметров в терминах состояния — экспертной системы поддержки принятия решений о состоянии объекта и дальнейшем управлении.
Мониторинг систем слежения и охранно-пожарной сигнализации — процесс непрерывного, автоматизированного сбора информации поступающей от охранно-пожарной сигнализации и систем слежения ГЛОНАСС/GPS, установленных на объектах всех видов собственности. Целью мониторинга систем слежения и охранно-пожарной сигнализации является своевременное доведение поступивших сигналов «Тревога» должностным лицам соответствующих частных организаций и государственных служб (охрана, полиция, МЧС, медицина, техническим специалистам и пр.), для осуществления необходимых действий и плановых мероприятий по защите, как жизни и здоровья работников (клиентов), так и сохранности имущества находящегося на объекте.
Мониторинг критически важных и опасных объектов — процесс инструментального автоматизированного круглосуточного наблюдения за отдельными параметрами объектов. Целью мониторинга является предупреждение чрезвычайных ситуаций и повреждения или разрушения объектов. Основным отличием этого вида мониторинга является то, что в процессе мониторинга отслеживаются деформации и сдвиги объекта и отдельных его элементов, что позволяет предотвратить наступление негативного события, а не проинформировать экстренные службы о случившемся ЧП. Мониторинг осуществляется с помощью оптических, лазерных и геофизических методов и инструментов.
Мониторинг в маркетинге — это систематическое и плановое наблюдение за состоянием рынка с целью его оценки, изучения трендов (тенденций), исследования конкурентной среды. Маркетинговый мониторинг необходим для эффективного ведения бизнеса. Результаты мониторинга дают возможность вносить корректировки в маркетинг, в управление. Наиболее близкий русский эквивалент понятия «мониторинг» — отслеживание.
Мониторинг — систематический сбор и обработка информации, которая может быть использована для улучшения процесса принятия решения, а также, косвенно, для информирования общественности или прямо как инструмент обратной связи в целях осуществления проектов, оценки программ или выработки политики. Он несёт одну или более из трёх организационных функций:
выявляет состояние критических или находящихся в
Мониторинг технического состояния зданий, сооружений, строительных конструкций. Цели и задачи мониторинга.
ОСНОВНЫЕ АСПЕКТЫ МОНИТОРИНГА
Основным нормативны документом, регламентирующим проведение мониторинга технического состояния зданий и сооружений, является ГОСТ 31937-2011 «Здания и сооружения. Правила обследования и мониторинга технического состояния».
Однако, есть и другие нормативные документы, регламентирующие проведение мониторинга.
— подробно узнать о нормативно-технической безе, регламентирующей мониторинг, можно в разделе: «Мониторинг технического состояния зданий и сооружений».
При проведении мониторинга, ведется контроль за состоянием конструкций здания или сооружения. Отслеживается процесс развития дефектов (трещин, прогибов, деформаций и пр.). При необходимости, производится геодезический контроль за деформациями и осадками зданий, сооружений, или отдельных конструкций.
В составе мониторинга производится контроль технического состояния наружных стен.
Для контроля, на трещине установлен индикатор часового типа.
В составе мониторинга производится контроль технического состояния наружных стен.
Для контроля, на трещине установлен индикатор часового типа.
Мониторинг технического состояния зданий, сооружений и отдельных конструкций (далее Объекта) обычно проводят:
— для предупреждения ухудшения состояния объекта, в следствии воздействия внешних негативных факторов;
— для своевременного выявления конструкций, в которых произошли изменения напряженно-деформированного состояния;
— для обеспечения безопасного функционирования объекта, за счет своевременного обнаружения, на ранней стадии, негативного изменения технического состояния строительных конструкций, которые могут повлечь переход объектов в ограниченно работоспособное или в аварийное состояние;
— для контроля степени и скорости изменения технического состояния объекта и принятия, в случае необходимости, экстренных мер по предотвращению его обрушения.
В процессе мониторинга, как правило, выполняются следующие работы:
— производится предварительное обследование строительных конструкций объекта;
— составляется программа мониторинга, с расчетом периодичности наблюдения за состоянием объекта;
— разрабатывается проект размещения опорных реперов, контрольных индикаторов, маяков и деформационных марок (далее – приборов контроля), с расчетом их количества и расположения;
— производится монтаж приборов контроля на объекте;
— при необходимости, производится определение координат и высот центров опорных реперов относительно пунктов государственной геодезической сети;
— выполняется систематическое снятие показаний с установленных приборов контроля на участках где выявлены деформации, трещины, и пр.;
— при необходимости, осуществляется контроль за осадками здания или сооружения, а также контроль планово-высотного положения фундамента методом геометрического нивелирования;
— в процессе мониторинга составляются промежуточные отчеты о ходе ведения работ;
— по окончанию проведения всех работ по мониторингу разрабатывается финальное заключение о состоянии объекта.
— процесс ведения мониторинга подробно описан в разделе: «Мониторинг технического состояния зданий и сооружений».
При выборе системы наблюдений необходимо учитывать цель проведения мониторинга, а также скорости протекания процессов и их изменение во времени, продолжительность измерений, ошибки измерений, в том числе за счет изменения состояния окружающей среды, а также влияния помех и аномалий природно-техногенного характера.
Программу проведения мониторинга согласовывают с заказчиком. В ней, наряду с перечислением видов работ, устанавливают периодичность наблюдений с учетом технического состояния объекта и общую продолжительность мониторинга.
В составе мониторинга производится контроль за трещиной в несущей стене.
Контроль выполняется с использованием прямого пластинчатого маяка.
Методика и объем системы наблюдений при мониторинге, включая измерения, должны обеспечивать достоверность и полноту получаемой информации для подготовки исполнителем обоснованного заключения о текущем техническом состоянии объекта (объектов).
В ходе длительных наблюдений и при изменении внешних условий необходимо обеспечить учет изменения условий и компенсационные поправки (температурные, влажностные и т.п.) для измерительных устройств.
Используемые для наблюдений средства измерений и оборудование должны быть сертифицированы, поверены (калиброваны) и аттестованы уполномоченными органами.
В результате проведения каждого этапа мониторинга должна быть получена информация, достаточная для подготовки обоснованного заключения о техническом состоянии объекта и выдачи краткосрочного прогноза о его состоянии на ближайший период.
В составе мониторинга производится контроль за трещиной в несущих стенах.
Контроль выполняется с использованием углового пластинчатого маяка.
В составе мониторинга производится контроль за трещиной в несущих стенах.
Контроль выполняется с использованием прямого пластинчатого маяка.
ЦЕЛИ И ЗАДАЧИ МОНИТОРИНГА
Укрупненно, по целям и задачам, мониторинг можно разделить на три группы:
— общий мониторинг технического состояния объекта;
— мониторинг технического состояния объектов, находящихся в ограниченно работоспособном или аварийном состоянии;
— мониторинг технического состояния объектов, попадающих в зону влияния строек или природно-техногенных воздействий.
ОБЩИЙ МОНИТОРИНГ ТЕХНИЧЕСКОГО СОСТОЯНИЕ ОБЪЕКТА
При общем мониторинге, как правило, не проводят обследование технического состояния объекта в полном объеме, а проводят визуальный осмотр конструкций с целью предварительной оценки категории технического состояния, измеряют статические и динамические параметры.
Если, по результатам предварительной оценки, категория технического состояния объекта соответствует исправному или работоспособному техническому состоянию, то повторные измерения статических и динамических параметров проводят через два года.
Если, по результатам повторных измерений, изменения статических и динамических параметров не превышают 10%, то следующие измерения проводят еще через два года.
Если, по результатам предварительной оценки, категория технического состояния объекта соответствует ограниченно работоспособному или аварийному состоянию, или при повторном измерении статических и динамических параметров объекта, результаты измерений различаются более чем на 10 %, то техническое состояние такого объекта подлежит обязательному внеплановому обследованию.
Для выявления и контроля за кренами и деформациями, при проведении мониторинга применяются геодезические приборы.
На фото показан тахеометр.
Для выявления и контроля за кренами и деформациями, при проведении мониторинга применяются геодезические приборы.
На фото показан теодолит.
МОНИТОРИНГ ТЕХНИЧЕСКОГО СОСТОЯНИЯ ОБЪЕКТОВ, НАХОДЯЩИХСЯ В ОГРАНИЧЕННО РАБОТОСПОСОБНОМ ИЛИ АВАРИЙНОМ СОСТОЯНИИ
При мониторинге объектов, категория технического состояния которых соответствует ограниченно работоспособному или аварийному состоянию, контролируют процессы, протекающие в конструкциях и грунте-основания. Мероприятия по контролю следует выполнять до проведения работ по восстановлению или усилению объектов, а также во время проведения таких работ.
На каждой стадии мониторинга проводят следующие работы:
— определяют текущие статические и динамические параметры объекта и сравнивают их с параметрами, измеренными на предыдущем этапе;
— фиксируют степень изменения ранее выявленных дефектов и повреждений конструкций объекта и выявляют вновь появившиеся дефекты и повреждения;
— проводят повторные измерения деформаций, кренов, прогибов и т.п., и сравнивают их со значениями аналогичных величин, полученными на предыдущем этапе;
— анализируют, полученную на данном этапе мониторинга информацию, и делают заключение о текущем техническом состоянии объекта.
МОНИТОРИНГ ТЕХНИЧЕСКОГО СОСТОЯНИЯ ОБЪЕКТОВ, ПОПАДАЮЩИХ В ЗОНУ ВЛИЯНИЯ СТРОЕК ИЛИ ПРИРОДНО-ТЕХНОГЕННЫХ ВОЗДЕЙСТВИЙ
При мониторинге осуществляется контроль технического состояния объектов, расположенных в непосредственной близости от зоны строительства.
Мониторинг должен начинаться до начала производства строительно-монтажных работ, и продолжаться в течении всего периода строительства.
При мониторинге объектов, попадающих в зону влияния строек или природно-техногенных воздействий, производится регулярная оценка технического состояния здания или сооружения. Ведется контроль за развитием выявленных дефектов (трещин, прогибов, деформаций и пр.). Производится геодезический контроль за деформациями и осадками.
В процессе мониторинга, как правило, выполняются следующие мероприятия:
— контроль за деформациями и развитием дефектов, выявленных на период до начала строительно-монтажных работ;
— контроль за появлением деформаций и дефектов, возникших в период производства строительно-монтажных работ;
— контроль за осадками здания или сооружения на период до производства строительно-монтажных работ, а также во время выполнения строительно-монтажных работ;
— разработка заключения о техническом состоянии зданий или сооружений с указанием степени влияния производства строительно-монтажных работ на их состояния и пр.;
— выдача экспертного заключения по требованию надзорных организаций, переговоры с представителями надзорных организаций, собственниками, инициативными группами и пр.
Авторы: редакционная статья ТехСтройЭкспертизы
Что такое мониторинг и его уровни
Поговорим о том, какие уровни мониторинга бывают и что стоит измерять и анализировать в IT-проектах.
Зачем нужен мониторинг и что это такое
Случается, что серверы падают и программы ломаются. Это неизбежно. Случайный баг, скачок напряжения в сети, сбои в подаче электричества — всё это может вызывать поломки.
Кроме того, помимо очевидных проблем, могут быть и куда менее очевидные. Например, менеджеры по продукту приняли плохое решение, реализовали плохую фичу и из-за нового релиза упала выручка. Технически код хорошо работает, серверы в порядке — но бизнес несет убытки.
Начнем снизу: мониторинг оборудования
Что бы вы ни запускали — у вас всё равно будут серверы в дата-центре, а у них есть определенные параметры производительности. Эти показатели надо мониторить на каждом сервере, обслуживающем ваших клиентов:
Список параметров вполне очевиден. Мониторинг этих значений позволяет диагностировать большую пачку неприятных ситуаций, которые могут привести к полному или частичному коллапсу инфраструктуры.
Для анализа поведения серверов в самом простом виде можно использовать штатные средства контроля по типу htop. Более гибкое и масштабируемое решение — Zabbix — он уже умеет анализировать основные параметры целого кластера серверов и собирать их в одной панели. Такое решение требует настройки со стороны квалифицированного администратора.
Поднимаемся выше: мониторинг состояния приложений
Допустим, мониторинг серверов у нас есть и они выглядят адекватно. Памяти много, нагрузка на процессор — незначительная. Наверное, всё хорошо организовано, клиентов немного, всё работает как часы? Может быть. Или всё упало, программы не запущены, клиенты не могут попасть на сервер и выполнить запросы? Тоже может быть.
Какой из вариантов правильный — подскажут метрики приложений.
У любого приложения должны быть параметры, по которым разработчики и администраторы понимают, что программа работает и в ней что-то делается. У каждой программы эти параметры свои, но вот несколько примеров, которые позволят понять, какие метрики нужно придумать для приложения:
У вас в системе 100 активных пользователей, они генерируют 1 000 запросов в минуту и у них случается 1 ошибка в час? Допустим, что всё хорошо. У вас в системе 3 активных пользователя, они генерируют 10 000 запросов в минуту и ловят 5 000 ошибок? Наверное, стоит начать беспокоиться. Даже если метрики нагрузки на процессор и диски в порядке.
Для мониторинга на этом уровне подойдет специализированная СУБД — Prometheus, Graphite, InfluxDB. С установкой самой базы данных проблем не будет, а вот посчитать и пробросить нужные метрики в базу — для этого понадобятся усилия программистов.
Для удобства анализа ко всем этим базам лучше всего подключить Grafana — графический инструмент для отображения статистики и метрик.
Есть еще специфические системы отлова ошибок в коде — они могут вовремя оповестить программистов о сбойной ситуации. Иногда этого вполне достаточно для базовой диагностики проблем. Хороший пример такой системы — Sentry.
Третий уровень: мониторинг бизнес-метрик
Конечная цель любой программы — решать чьи-то проблемы и получать за это деньги. Это значит, что для управленцев нужны метрики, которые расскажут:
Список метрик, которые нужны бизнесу, велик и зависит от конкретного проекта и индустрии. Лучше всего вам помогут разобраться с правильными параметрами менеджеры продукта.
Минимально здесь можно обойтись Google Analytics — базовые конверсии и переходы можно смотреть в готовых системах анализа пользовательского поведения. Более глубокое понимание ситуации потребует четкой и слаженной работы администраторов, программистов и ребят из отдела аналитики — они смогут правильно реализовать и посчитать тонкие поведенческие аспекты. Например, зависимость выручки от A/B-тестов на бэкенде.
Давайте обсудим мониторинг
Вот уже четвертый год я занимаюсь организацией того, что принято называть Observability. Набранный за это время опыт я обличаю в текст, делюсь им с вами в виде размышления-рекомендации и выношу на суд общественности. Здесь практически не будет технических деталей – статья намеренно написана таким образом, дабы изложенное можно было положить на практически любой стек технологий. Дело в том, что инструменты врываются в тренды и покидают их с невероятной скоростью, посему их выбор остается за вами. Давайте обсудим мониторинг.
О мониторинге в контексте метрик
Если спросить среднестатистического технаря-инженера, с чем у него ассоциируется мониторинг, то скорее всего вам ответят – «метрики приложения», и подразумеваться будет их сбор и некоторая визуализация. Причем, о изнанке этого процесса, как показал мой опыт, многие даже не задумываются – в понимании большинства «оно просто показывается в Grafana/Kibana/Zabbix/подставьте нужное».
Из чего же сделан мониторинг?
Со временем, я для себя вывел следующие аспекты:
Сбор метрик из различных источников – приложения, показатели хоста, «железной» части площадки; различия в pull и push моделях пока не затрагиваем, об этом чуть позже
Запись и дальнейшее их (метрик) хранение в базе данных с учетом особенностей самой БД и использования собранных данных
Визуализация метрик, которая должна балансировать между возможностями выбранного технологического стека, удобством использования дашборд и «хотелками» тех, кому с этим всем предстоит работать
Отслеживание показаний метрик по заданным правилам и отправка алертов
О сборе метрик
Итак, вы решили создать систему мониторинга. Первым шагом предлагаю задуматься о том какие метрики собирать:
Показатели обслуживаемых приложений – здесь появляется слой метрик, которые можно связать с процессами, в корректности и стабильности работы которых вы напрямую заинтересованы; ими могут быть гипервизор, ваш софт для клиента, некоторые системные процессы.
На этом уровне появляется возможность (а часто необходимость) устанавливать однозначную связку «инфраструктура-приложение». В самом простом виде она может выглядеть так – вы мониторите состояние процесса «запущен/не запущен», к этой метрике привязываете теги с именами хоста и приложения, по сумме которых можно будет однозначно определить, к чему именно эта метрика относится
Показатели бизнес-процессов – сюда относится информация, на основе которой можно делать выводы о работоспособности бизнес-функций.
В качестве примера возьмем операцию списания денег с лицевого счета пользователя – допустим, для успешного выполнения операции необходимо, чтобы был доступен личный кабинет (веб-сервер), сервис постановки задач в очередь, брокер асинхронных сообщений, платежный шлюз и база данных. Чтобы быть уверенным, что операция может быть выполнена, вам понадобится следить за состоянием всей цепочки, хотя бы в самом простом виде – работают ли все приложения в ней
Результаты смок-тестов – по сути, расширение предыдущего уровня; это показатели периодически выполняемых фейковых бизнес-операций, по которым можно будет поймать проблему
Pull VS Push
Предмет жарких споров в тематических каналах и форумах с извечным вопросом – что же лучше?
Push-модель – это когда у вас есть классическая БД, в которую активно пишут агенты. Отличается большим объёмом точек конфигурирования (как правило, по количеству агентов мониторинга), но в то же время дает возможность базе заниматься своей основной задачей – хранить метрики и управлять их жизненным циклом, пассивно ожидая, пока в неё что-нибудь положат.
Pull-модель – насколько мне известно, относительно новый подход, набравший популярность с приходом в нашу жизнь платформ для оркестровки контейнеров. В этом случае, сам сервер мониторинга ходит по пассивным экспортерам и забирает у них метрики. Плюс – единая точка конфигурирования, сам сервер, которому надо рассказать, что и откуда забирать. ИМХО, он же и главный минус – в случае отвала сети вы теряете показатели за время её простоя. Отлично показывает себя в эфемерных средах вроде K8s, когда количество сущностей, которые необходимо мониторить, изменяется с течением времени. За их пределами уже не столь удобен – для получения метрик от хостов вам понадобятся агенты-экспортеры.
Выбор модели остается за вами – исходите из ваших потребностей и задач.
О хранении
Здесь буду немногословен – на текущий момент придумано немало TSDB (Time-Series DataBase), заточенных именно под временные ряды. Вам остается только выбрать то, что по соотношению «доступный функционал – производительность – удобство и возможности языка запросов» покажется максимально приемлемым.
Мой личный фаворит – VictoriaMetrics, рекомендую ознакомиться.
О визуализации
Подобно тому, как метрики делились на уровни, аналогично разделяется и визуализация:
Уровень площадки – самый высокий уровень визуализации, с которого, после получения алерта, пользователю мониторинга стоит начинать работать. Дашборд(ы) здесь представляют собой набор логически разделенных индикаторов «всё хорошо/что-то сломалось».
Например, каждая панель показывает состояние какой-либо группы приложений – Nginx`ы, Apache`и, Службы виртуализации; при наличии проблемы с любой из сущностей группы панель переходит из состояния «всё хорошо» в состояние «что-то сломалось», привлекая внимание
Уровень группы – следующий уровень, к которому переходит пользователь; должен быть доступен по drilldown-ссылке с предыдущего дашборда. Если ранее мы подсветили, с какой группой возникла проблема, здесь мы должны ответить на вопрос «с каким именно объектом группы?».
Продолжая начатый выше пример, здесь отображаются все Nginx на вашей площадке, по которым выведены ключевые показатели – состояния процессов, состояния соединений с БД, количество ошибок и так далее. Тут не стоит сильно вдаваться в детали, пяти-шести панелей на объект наблюдений будет достаточно
Уровень объекта – конечная точка движения нашего пользователя в большинстве случаев.
На этом уровне детально визуализируются метрики конкретного приложения/процесса/другого подвергнутого принудительному мониторингу объекта. Здесь пользователь должен найти для себя ответ на такой вопрос – «что же именно сломалось?». Начиная с этого уровня, переходы между дашбордами должны наследовать контекст – если пользователь на уровне группы кликнул по панели процесса nginx_01 хоста proxy.local, метрики именно этого приложения на этом хосте и должны отображаться
Уровень фрагмента объекта – формально, продолжение предыдущего уровня, но введен вот зачем: если какая-либо часть нашего объекта имеет слишком много метрик и достойна того, чтобы рассматриваться отдельно, под неё заводится персональный дашборд.
Например, у нашего Nginx есть апстримы со своими метриками; дабы не усложнять уровень объекта и не перегружать его, мы заводим под апстрим персональный дашборд, а на предыдущем оставляем только кликабельные индикаторы с состоянием апстрима «онлайн/частично онлайн/оффлайн». И вновь, переходы должны наследовать контекст, чтобы облегчить пользователю навигацию
Уровень инфраструктуры – самый низкий уровень визуализации и отправная точка в сборе метрик.
Тут отображаются показатели хост-системы и окружающего «железа». Хорошим ходом будет разбить на разные дашборды метрики разных частей – состояние CPU, RAM, дисков и т.д., организовав возможность горизонтального перехода между ними. Переход же на этот уровень можно создать с двух предыдущих, снова с учётом ранее установленного контекста; если пользователь смотрел на метрики приложения на хосте proxy.local, этого хоста метрики и должны отображаться
Подводя итог написанному выше, у нас получается такая диаграмма уровней, демонстрирующая путь пользователя:
Пользователь мониторинга двигается сверху вниз, разбирая инцидент
Делайте ваши дашборды шаблонными, с возможностью установки контекста через переменные. Мысль достаточно очевидная, согласен, но, тем не менее, мне приходилось встречать хардкод хостов и приложений, порождающий ворох из копий одних и тех же дашборд, что выливалось в неподдерживаемый хаос
Также, стоит выносить в переменные различные потенциально изменяемые вещи – имя базы данных с метриками, вручную составленные словари «число-значение» и т.п.
Добавляйте описание к всем панелям. Если отображаемая на панели информация кажется хоть немного неочевидной, не поленитесь дать ей описание – буквально одно-два предложения сильно облегчат работу пользователей и помогут вам же, когда возникнет необходимость вернуться к работе с дашбордом
В качестве средства визуализации сейчас лидирует небезызвестная Grafana, в которой есть функционал переменных, внутренних и внешних ссылок c шаблонизацией, комментариев к панелям и еще всякое-всякое.
О алертинге
Алертинг, пожалуй, самая значимая часть системы мониторинга. На мой взгляд, при идеальном алертинге визуализация метрик и вовсе не нужна – хорошее, годное сообщение сообщает ровно столько информации, сколько нужно для начала работ по восстановлению.
К сожалению, или к счастью, в мире нет ничего идеального, но можно попробовать к этому приблизиться. Итак, хороший алерт можно приготовить из таких ингредиентов:
Полнота сообщения – в теле алерта должна содержаться информация о том, что именно произошло и за какой период времени.
Пример: «Средняя нагрузка на CPU превышает 90% в течение последних пяти минут»; пользователь, получивший такое сообщение, видит информацию, во-первых, о событии, во-вторых, о его длительности на момент получения, что позволяет сходу примерно оценить масштабы бедствия.
Здесь стоит уточнить, что метрика обычно оценивается за некоторый период, из которого выводится максимальное/среднее/минимальное/иное другое значение, а не её мгновенный показатель – это позволяет сгладить (или же выделить – зависит от того, что именно вам нужно) всплески и временнУю задержку в доставке метрик до базы данных
Уточняющие метаданные – алерт должен сопровождаться набором тегов/лейблов, раскрывающих контекст события; это могут быть имя хоста, приложения, идентификатор uri веб-сервера и т.п.
Штамп времени первого срабатывания – тут всё просто, в алерте жизненно необходима метка времени, чтобы при получении нотификации можно было понять, новый ли алерт у вас сработал, или это всё еще горит старый
Ссылка на систему управления алертами/систему визуализации метрик, на ваш выбор – она нужна для получателя, чтобы он смог сразу перейти в мониторинг, а не тратил время на судорожный поиск закладки в браузере
С самим алертом, вроде, разобрались, теперь немного о процессе нотификации:
Не допускайте спама со стороны системы управления алертами. Когда вашего получателя заваливает письмами/СМСками/сообщениями от бота, рано или поздно он перестанет предавать им хоть какое-то значение и пропустит критичную нотификацию. Хорошим тоном будет настроить рассылку таким образом, чтобы по уже «горящим» алертам повторные уведомления отправлялись спустя какое-то время
Выделите ключевые метаданные и группируйте алерты по ним; тогда вместо, например, семи сообщений по одному объекту, ваш пользователь получит одно, в которое будут вложены остальные. Это также позволяет снизить количество нотификаций (помним про предыдущий пункт)
Предусмотрите возможность для себя и/или пользователя временно отключать некоторые алерты, например, на время технических работ
Если ваша система это позволяет, настройте иерархию алертов с автоматическим подавлением нижестоящих. Если у вас из сети выпал сервер, нет необходимости дополнительно слать письма о том, что приложения на нем стали недоступны, это и так очевидно из первого
Разделите алерты по группам – инженерам пусть приходят технические алерты, а бизнесу бизнесовые. Условной коммерческой дирекции не интересно, что у вас упал Nginx (им это ни о чем не скажет), для них куда важнее знать, что цепочка выполнения бизнес-функции «покупка товара» развалилась и компания несет потенциальные убытки
Рекомендую пощупать AlertManager – приложение из стека Prometheus, в котором есть все описанные выше возможности. Лично для меня он стал той самой «серебряной пулей», решившей сразу вагон и маленькую тележку проблем. Веб-хуки и API для интеграций входят в комплект.
Вместо заключения
В первую очередь, выражаю благодарность тем, кто прочитал до конца; надеюсь, что статья показалась вам интересной и полезной.
Это первый текст из трех запланированных – дальше я бы хотел затронуть тему логирования и его синергии с мониторингом, после чего, возможно, перейти к некоторым техническим деталям (уже не только сухим текстом). Если вам было бы интересно об этом почитать, пожалуйста, напишите в комментариях. Попробуем разобрать и обсудить сначала общий подход к сбору и централизованному хранению журналов, их роль в оценке состояния наблюдаемой площадки, а также затронем вопрос – «можно ли отрывать логи от метрик?».