мониторинг чего или зачем

мониторинг

Медицинский мониторинг. | Погодный мониторинг. | Мониторинг условий труда в различных странах. | Центральный банк России внедрил систему текущего мониторинга рынка.

Смотреть что такое «мониторинг» в других словарях:

МОНИТОРИНГ — (от англ. monitoring, от лат. monitor напоминающий, надзирающий), комплексная система наблюдений, оценки и прогноза изменений состояния окружающей среды под влиянием антропогенных воздействий. Мониторинг не включает управление качеством… … Экологический словарь

Мониторинг — система сбора/регистрации, хранения и анализа небольшого количества ключевых (явных или косвенных) признаков/параметров описания данного объекта для вынесения суждения о поведении/состоянии данного объекта в целом. То есть для вынесения суждения… … Википедия

мониторинг — – аналитический контроль химических загрязнений на исследуемой территории. Общая химия : учебник / А. В. Жолнин [1] Мониторинг – относительно продолжительное наблюдение за изменениями параметров (состава) объекта или процесса, фиксация изменений… … Химические термины

МОНИТОРИНГ — МОНИТОРИНГ, комплексная система наблюдений, оценки и прогноза изменений состояния биосферы или ее отдельных частей, главным образом под влиянием человеческой деятельности (так называемого антропогенного воздействия). Наиболее важны в системе… … Современная энциклопедия

Мониторинг — (от лат. monitor тот, кто напоминает, предупреждает * a. monitoring; н. Monitoring; ф. monitoring; и. monitoring) комплексная система регламентированных периодич. наблюдений, оценки и прогноза изменений состояния природной среды c целью… … Геологическая энциклопедия

МОНИТОРИНГ — [ Словарь иностранных слов русского языка

Мониторинг — МОНИТОРИНГ, комплексная система наблюдений, оценки и прогноза изменений состояния биосферы или ее отдельных частей, главным образом под влиянием человеческой деятельности (так называемого антропогенного воздействия). Наиболее важны в системе… … Иллюстрированный энциклопедический словарь

МОНИТОРИНГ — наблюдение за состоянием окружающей среды (атмосферы, гидросферы, почвенно растительного покрова, а также техногенных систем) с целью ее контроля, прогноза и охраны. Различают глобальный, региональный и локальный уровни мониторинга. Проводится с… … Большой Энциклопедический словарь

МОНИТОРИНГ — (от лат. monitor тот, кто напоминает, предупреждает), комплексная система наблюдений, оценки и прогноза изменений состояния биосферы или её отд. элементов под влиянием антропогенных воздействий. М. может быть локальным, региональным и глобальным … Биологический энциклопедический словарь

мониторинг — прогноз, оценка, наблюдение Словарь русских синонимов. мониторинг сущ., кол во синонимов: 4 • наблюдение (60) • … Словарь синонимов

Мониторинг — (англ. monitoring) система наблюдений, оценки, прогноза состояния и динамики какого либо явления, процесса или иного объекта с целью его контроля, управления его состоянием, охраны, выявления его соответствия желаемому результату или… … Энциклопедия права

Источник

Архив форума

Я бы никогда не сказала «мониторинг за». А притянуть для объяснения, думаю, можно вот это:

МОНИТОРИНГ м.
2.Наблюдение, оценка и прогноз состояния окружающей среды в связи с хозяйственной деятельностью.

То есть это не просто_контроль_, а именно контроль с оценкой. Потому и предлог не нужен, и род. п. А от «окружающей среды» ухожу, распространяю на любой мониторинг.

В силу близости к любителям помониторить (экологию главным образом) слышу настолько давно и часто, что перестал задумываться о нормативности. По аналогии с контролем все три формы управления в ходу: мониторинг чего, мониторинг за чем и даже мониторинг над чем. Впрочем, мне лично ближе первый вариант.

>>>>То есть это не просто_контроль_, а именно контроль с оценкой.
А бывает контроль без оценки?

Все началось, когда в русскоязычные просторы принялся неконтролируемо проникать, вникать и помыкать ими английский. Слово «контроль», прежде смыслово отделенное от «управления», стало с этим управлением смыкаться, подразумевать собою «контроль-управление».
Естественно, потребовался термин, продолжающий традиции «чистого», пассивного контроля, контроля-наблюдения. Им и стал «мониторинг».

>> А бывает контроль без оценки?

Тогда добавлю к своему: «с оценкой и выводами (то есть с теми самыми прогнозами, может быть)».

Кстати, смотря что называть оценкой. Можно ведь тупо фиксировать, никак не _оценивая_.

>> Слово «контроль». стало с этим управлением смыкаться, подразумевать собою «контроль-управление».

>>>>. смотря что называть оценкой. Можно ведь тупо фиксировать, никак не _оценивая_.

Вот это фигня, Петька, и назвается мониторингом.

Вот пример из нормативного документа по мониторингу!
РБ-046-08 Мониторинг метеорологических и аэрологических
условий в районах размещения объектов использования
атомной энергии.
В системе мониторинга следует предусматривать…
Подсистема наблюдений
Подсистема обработки данных наблюдений
Подсистема выдачи прогнозных данных
Подистема выдачи рекомендаций

Анатоль, но ведь вот и здесь «мониторинг_чего-то».

«Наиболее близкий русский эквивалент слова «мониторинг» — отслеживание. Термины контроль, надзор, присмотр, пригляд, которые иногда указывают в качестве синонимов, имеют всё же несколько другое значение».
© Вики

«Мониторинг — систематический сбор и обработка информации. «

Имхо, «мониторинг за» — несочетаемо, как и «отслеживание за» (в отличие от слежения). Но не исключаю влияния на эту несочетаемость и моей собственной отсталости ;).

The Webster dictionary defines monitoring as:
• To watch, check or observe for a special purpose.

And the Oxford dictionary:
• To observe, supervise, or keep under review; to measure or test at intervals, especially for the purpose of regulation or control, or to check or regulate the technical quality of something.
• Any instrument or device for monitoring some process or quantity.

Подвожу итог: зря я этот «мониторинг» не в Ошибки в СМИ, а сюда пристроила. 🙂

Кстати, утверждён ГОСТ Р 53239-2008 «Хранилища природных газов подземные. Правила мониторинга при создании и эксплуатации» с датой введения в действие 1 января 2010 г.
У меня нет утверждённой редакции, но в той, с которой я работал, тоже «ЧЕГО-ТО»:
Настоящий стандарт устанавливает правила проведения мониторинга геологической среды при создании и эксплуатации подземных хранилищ углеводородов.

Источник

Давайте обсудим мониторинг

Вот уже четвертый год я занимаюсь организацией того, что принято называть 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 для интеграций входят в комплект.

Вместо заключения

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

Это первый текст из трех запланированных – дальше я бы хотел затронуть тему логирования и его синергии с мониторингом, после чего, возможно, перейти к некоторым техническим деталям (уже не только сухим текстом). Если вам было бы интересно об этом почитать, пожалуйста, напишите в комментариях. Попробуем разобрать и обсудить сначала общий подход к сбору и централизованному хранению журналов, их роль в оценке состояния наблюдаемой площадки, а также затронем вопрос – «можно ли отрывать логи от метрик?».

Источник