Что значит мониторить информацию

Значение слова «мониторить»

монито́рить

1. выполнять мониторинг — систематическое наблюдение за какими-либо процессами, данными ◆ Мы мониторим весь берег на глубину сто миль. У нас тут ни рыба не проплывёт, ни птица не пролетит без разрешения по месту жительства! Василий Аксёнов, «Негатив положительного героя», 1996 г. (цитата из НКРЯ)

Делаем Карту слов лучше вместе

Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!

Спасибо! Я обязательно научусь отличать широко распространённые слова от узкоспециальных.

Насколько понятно значение слова клейковина (существительное):

Синонимы к слову «мониторить&raquo

Предложения со словом «мониторить&raquo

Понятия, связанные со словом «мониторить»

Отправить комментарий

Дополнительно

Предложения со словом «мониторить&raquo

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

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

Вам следует регулярно мониторить конкурентов, работать над ещё большим уменьшением цены, либо переходить в другую ценовую нишу.

Источник

Мониторинг — что это такое

Здравствуйте, уважаемые читатели блога KtoNaNovenkogo.ru. Периодически возникает желание объяснить те термины, что я и многие другие постоянно используют в своих статьях в интернете или в устной речи. До этого мы уже поговорили про гайды, про геймеров, про парадигмы, а так же коснулись темы троллинга, хейтерства и перфекционизма.

Сегодня у нас на очереди мониторинг. Что это такое? Зачем он нужен? Что можно и нужно мониторить? Кто этим занимается? Да и зачем вообще все это нужно? Вот такой вот краткий план для данной публикации. Поехали.

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

Сразу стоит оговориться, что слово это очень популярно и широко распространено. Используется оно чуть ли не во всех жизненных аспектах и потому интерес к нему довольно высок. Образовано оно, как ни удивительно, от английского слова monitoring, что в переводе означает: контролировать, проверять, наблюдать.

Собственно, на этом статью можно было бы и закончить, ибо ключевые слова, позволяющие понять что такое мониторинг, уже прозвучали — это контроль, наблюдение, проверка (периодическая или постоянная). Но все же я с вашего позволения продолжу и скажу хотя бы еще пару слов в пояснение сути, ну и примеры приведу для наглядности.

Если попробовать дать определение мониторингу другими словами, то это будет сбор информации. Причем собираться может все что угодно — данные по концентрации вредных веществ в атмосфере, финансовые показатели банков, информация проходящая в СМИ по какой-то тематике, доступность сайтов, значение текущих курсов валют (либо криптовалют) и т.д.

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

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

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

Если вы живете в крупном городе, то наверняка в вашем подъезде ведется видеонаблюдение, которое тоже можно отнести к процессу мониторинга. Данные собираются на постоянной основе, а потом при необходимости могут послужить для прояснения моментов криминального и другого характера.

Мониторинг в примерах — какой он бывает

Наверняка вы слышали про финансовый мониторинг, когда центробанк отслеживает ключевые показатели банков, чтобы вовремя понять, что с каким-то из них начинают происходить неприятные вещи. Хотя, подобного вида наблюдения и проверки в финансовой сфере проводятся и на более низких уровнях — внутри банков, компаний и предприятий. Но суть та же — выявить признаки нестабильности, воровства или других негативных (или позитивных) тенденций.

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

Мониторинг ведется практически во всех сферах жизнедеятельности — в образовательной, в культурной, в средствах массовой информации, в промышленности и сельском хозяйстве, в информационных средах (например, мониторинг общественного мнения), в сфере здравохранения и многом другом.

Почему это так важно? Зачем на это тратится столько времени и средств?

Ну, потому что это позволяет получить обратную связь и понять, что делается правильно, а что нужно менять.

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

И еще большее значение мониторинг приобретает в эпоху цифровых технологий. Данных становится больше, анализировать их на глазок уже очень сложно, а значит становятся востребованы услуги тех, кто предлагает на аутсорсинге свои услуги по их сбору, упорядочиванию и представлению результата в удобоваримом виде.

Например, сервисы подобные Яндекс Маркет помогают вам сделать правильный выбор в том, что именно и где именно лучше купить. По сути, это вариант маркетингового мониторинга рынка на предмет лучшего предложения в сегменте и лучшего продавца (по цене и качеству обслуживания), опирающегося на отзывы пользователей (данные).

Так же примером могут служить сервисы мониторинга курса обменников, которые собирают данные по текущим курсам обмена с десятков, и даже сотен пунктов обмена, позволяя вам буквально за минуту выбрать самый выгодный для вас курс в более-менее надежном обменнике. Последнее опять же реализовано на сборе отзывов пользователей уже совершавших там обмены.

Если у вас уже есть свой сайт или вы только планируете его создать, то вам будет сложно обойтись без сервисов мониторинга доступности сайтов, которые смогут вас оперативно предупредить (сообщением на Емайл или СМС-кой на телефон) о том, что ваш сайт стал недоступен пользователям сети (возникли проблемы с хостингом, ваш сайт подвергся ддос-атаке или еще что-то случилось). Без постоянного мониторинга доступности вы об этом оперативно не узнаете и можете потерять позиции в поисковых системах.

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

О будущем мониторинга

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

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

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

Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru

Эта статья относится к рубрикам:

Комментарии и отзывы (3)

Мониторинг по-русски — это и проверка и наблюдение, смотря в каком контексте оно употребляется.

Если в медицине, то это больше наблюдение, чем проверка. А вот если дело касается предприятия, то мониторинг — это скорее уже проверка. Допустим предприятию выделили деньги, и проводят мониторинг чтобы посмотреть что было сделано, куда были потрачены и т.п.

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

Светлана: кто первый встал, того и тапки. Этот принцип действует везде.

Чтобы тебя понимали ты должен пользовать общепризнанной терминологией. А она идет к нам, в основном, из английского языка.

Если проанализировать, то еще до Вашего рождения в русском языке половина (или больше) слов были заимствованы.

Источник

Что такое мониторинг и где он применяется?

Без сомнения, вам неоднократно встречалось красивое слово «мониторинг», которое часто употребляют журналисты, политики и общественные деятели.

Если вы еще не знаете, какое значение имеет это слово и в каких случаях используется, прочтите нижеследующую статью.

Многие могут заметить, что слово «мониторинг» очень похоже на слово «монитор». Это не удивительно, ведь в английском языке, из которого заимствованы оба слова, «monitor» означает «наблюдатель». Соответственно, мониторинг – это наблюдение какого-либо процесса в области социальных взаимоотношений, финансов, изменений природной среды и т.д.

Мониторинг – это постоянное систематическое наблюдение, сбор и упорядочение информации, необходимой для:

– изучения объекта, либо процесса;

– принятия решения о способах воздействия;

– предотвращения ухудшения обстановки и предупреждения об опасности.

Под финансовым мониторингом сегодня понимают контроль оборота денежных средств, который осуществляется для того, чтобы препятствовать незаконным финансовым операциям, отмыванию «грязных» денег и финансированию преступных, в частности, террористических организаций.

Для этого в РФ действует Федеральная служба финансового мониторинга, которая работает в контакте со службами безопасности всех коммерческих и государственных банков и других финорганизаций.

Финансовому мониторингу подлежат предприятия, организации и частные предприниматели, которые осуществляют финансовые операции в крупных объемах или участвуют в регистрации сделок, в обороте крупных сумм наличности, а также в обороте драгоценных металлов и камней.

Банковский мониторинг – это одна из функций обеспечения безопасности как конкретного банка, так и государства в целом. Он осуществляется, с одной стороны, государственной ФСФМ, а с другой – внутренней службой безопасности банка.

Контролю подлежат внешние и внутренние денежные операции всех организаций, которые подпадают под действие мониторинга.

Банковский мониторинг включает:

– регистрацию операции мониторинга;

– ведение анкеты клиента банка, будь то организация или частное лицо;

– создание «черного списка» подозреваемых в незаконном обороте средств, контакты и операции с которыми могут содержать криминал;

– контроль финансовых операций на основании ежедневной банковской документации.

Внутренняя служба безопасности банка отслеживает денежные операции внутри банка и предотвращает возможные нарушения или преступления.

Мониторинг в образовании – это важная часть обеспечения качества образовательного процесса. Без постоянного контроля качество обучения неминуемо будет снижаться, учащиеся – получать незаслуженно высокие оценки, а коорупционная составляющая станет в образовательной системе основным фактором получения документов об окончании учебного заведения.

Любое учебное заведение, будь то общеобразовательная школа, вуз или профессиональные курсы, обязано давать учащимся определенный объем знаний. Мониторингу подлежат:

– учебные программы, их содержание и методики преподавания;

– система оценивания знаний и соответствие оценок, получаемых учащимися, объему усвоенного материала;

– профессионализм преподавателей, их соответствие занимаемым должностям;

– материальная база учебного заведения, ее соответствие современным требованиям;

– объем финансирования учебного заведения и его финансовая документация.

Мониторинг в сфере образования осуществляют соответствующие службы Минобрнауки.

Для современного мира очень важен постоянный мониторинг окружающей среды, или экологический мониторинг. Это комплекс наблюдений за состоянием природной среды, окружающей человека, изучение влияния техногенных факторов на природу и прогноз изменений ее состояния, благоприятных и неблагоприятных для людей.

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

В РФ мониторингом окружающей среды занимаются несколько различных ведомств: Госкомитет по экологии, Академия наук, Санэпиднадзор, Гидрометцентр, Роскомвод, Роскосмос и др.

Источник

Что такое мониторинг и его уровни

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

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

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

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

Источник