УДК 004

Комплексный мониторинг ИТ-инфраструктуры: имплементация метрик и алертов для повышения эффективности работы операционных групп

Сидоров Иван Александрович – генеральный директор ООО "Сумма АйТи Инновации"; выпускник Института математики, экономики и информатики Иркутского государственного университета.

Маликов Александр Валинурович – технический директор ООО "Сумма АйТи Инновации"); выпускник Института математики, экономики и информатики Иркутского государственного университета.

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

Ключевые слова: ИТ-инфраструктура, информационные технологии, системный мониторинг, анализ эффективности функционирования, метрики, алерты, сигналы.

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

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

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

Эффективный комплексный мониторинг инфраструктуры позволяет ИТ-специалистам обеспечивать постоянную работоспособность и производительность систем компании. Сегодня изменения в инфраструктуре происходят быстрее, чем когда-либо прежде, а сложность систем, уникальный характер приложений и нехватка навыков администраторов в области ИТ могут вызвать проблемы при функционировании, а также при интеграции с новыми модулями. Между многооблачными средами, архитектурой на основе контейнеров и локальной инфраструктурой, использующей всё, от новейших технологий с открытым исходным кодом до устаревшего программного обеспечения, становится всё труднее достичь ситуационной осведомленности о состоянии ИТ-среды. Многие компании осуществляют попытки организации контроля, добавляя большое количество инструментов мониторинга инфраструктуры, что зачастую только усиливает нагрузку как на систему, так и на специалистов, ответственных за контроль. Таким образом возникает ИТ-парадокс: с каждой новой облачной службой, контейнерной средой и решением с открытым исходным кодом для повышения качества ИТ-системы, количество технологий и зависимостей увеличивается, что затрудняет активный мониторинг систем в масштабе и снижает качество решения в целом. [1]

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

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

Чтобы опередить постоянно растущее разнообразие и сложность ИТ-систем, мониторинг должен работать «умнее, а не сложнее». Такие технологии, как машинное обучение (МО) и искусственный интеллект (ИИ), способствуют мониторингу инфраструктуры за счет более быстрого сбора и анализа данных со всех аппаратных и программных компонентов, составляющих ИТ-стек. Наиболее ощутимым результатом использования инструментов и процессов интеллектуального мониторинга инфраструктуры является почти немедленное оповещение о проблемах с производительностью и временем безотказной работы, которые затем можно эффективно и действенно решить, чтобы избежать перерывов в работе. [2]

Использование искусственного интеллекта и непрерывной автоматизации – наиболее многообещающий путь перехода от ITOps (IT Operations) к AIOps (АI Operations). Искусственный интеллект для ИТ-операций (AIOps) – это дисциплина применения искусственного интеллекта, как правило, машинного обучения и распознавания образов – или детерминированного, причинно-следственного ИИ – для выполнения и автоматизации задач, которые команда ITOps обычно выполняет вручную. Таким образом, архитектура мониторинга в сочетании с ИИ может быть хорошим решением для избыточной работы, поможет сократить среднее время обнаружения и ремонта неполадок. Полностью исключить ошибки системы невозможно. Однако в случае сбоя необходимо быстро определить неисправный компонент и использовать автоматизацию для решения проблемы и восстановления ИТ-инфраструктуры.

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

Также следует определить, что означает корректная работа приложения. Используя искусственный интеллект и глубокое обучение, можно обнаружить скрытые аномалии почти в реальном времени и заблаговременно предупреждать операционную группу о необходимости действовать до того, как проблема повлияет на производительность ИТ-инфраструктуры. Истинная ценность AIOps может быть реализована только тогда, когда информация, которую можно получить из модулей ИИ, внедряется в операционные процессы и процедуры. Данное взаимодействие осуществляется с помощью инструментов совместной работы, которые могут отображать и публиковать результаты моделей ИИ. Эти инструменты объединяют всех специалистов организации, что дает возможность более осмысленно взаимодействовать, используя информацию, предоставленную ИИ. Повышение эффективности данных процессов возможно путем подключения чат-бота, позволяющего собирать и интерпретировать больше информации от модулей ИИ. [3]

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

Для стабильной работы ИТ-инфраструктуры и эффективного беспрерывного функционирования технической поддержки следует сформировать полный комплекс метрик, после чего изучить и проанализировать их динамику, оценить результаты и сформировать принципы работы с инцидентами. Визуализация динамики возникновения инцидентов с использованием дашбордов и графиков позволит выявить зависимости и реагировать на причину инцидента до возникновения неполадок в ИТ-инфраструктуре. [4,5]

При этом для сохранения эффективности контроля ИТ-инфраструктуры важно поддержание баланса мониторинга, который заключается в реализации двух условий:

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

Методы сбора метрик

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

USE (Utilization, Saturation, Errors) – метод Брендана Грегга (англ. Brendan Gregg) предназначенный для оценки производительности системы на основе определения основных метрик для каждого ресурса инфраструктуры.

Ключевые метрики:

  • Utilization (использование) – время (или процент) использования ресурса, который занят «полезной работой»;
  • Saturation (насыщенность) – количество отложенных задач или работы поставленной в очередь;
  • Errors (ошибки) – объем ошибок в работе ресурса.

RED (Rate, Errors, Duration) – метод, придуманный Томом Уилки (англ. Tom Wilkie), который предполагает сбор метрик с самих приложений и многоуровневых инфраструктур. Этот способ позволяет охватить наиболее очевидные проблемы, возникающие в инфраструктуре.

Ключевые метрики:

  • Rate (запросы) – количество поступающих запросов за определённый период времени;
  • Errors (ошибки) – количество возникающих ошибок за определённый период времени;
  • Duration (длительность) – время, затрачиваемое системой на обработку одного запроса.

Подход LTES (Latency, Traffic, Errors, Saturation) используется по тому же принципу, что и предыдущие два метода. Для этого проводят оценку следующих метрик:

  • Latency (длительность) – количество времени, требуемое на обработку запроса (при этом рекомендуется раздельно определять время на запросы успешные и ошибочные);
  • Traffic (объем запросов) – количество запросов для каждого составного элемента инфраструктуры (в случае веб-сервиса рассматриваются http-запросы и т.д.);
  • Errors (ошибки) – количество возникающих в системе ошибок за единицу времени;
  • Saturation (насыщение) – количественный показатель, отражающий число задач, находящихся в очереди на решение. Этот показатель дает возможность оценить объем используемых ресурсов.

Несмотря на то, что каждый из описанных методов охватывает различные метрики, их объединяет «Е» – параметр ошибок. Выбрать один «правильный» метод невозможно: следует определять компоненты для мониторинга, исходя из каждого отдельного случая, опираясь на логику реализации инфраструктуры. Например, метод USE больше всего подойдет для обработчиков задач или шины данных, тогда как RED и LTES – для мониторинга инфраструктуры application-сервера.

Концепции автоматического оповещения

Автоматическое оповещение о достижении порогового значения метрики носит название алерингта. Формирование алертинга опирается на три концепции – Service level indicators (SLI), Service level agreement (SLA) и Service level objectives (SLO).

SLI представляет собой набор метрик, позволяющих оценить статус системы на данный момент, её производительность и степень «удовлетворенности» работой системы конечных потребителей. Концепция SLI может объединить 500 разных ошибок или охватить весь объем активных пользователей ИТ-инфраструктуры.

SLA представляет собой показатели, отражающие внешнее обязательство перед пользователями. В дословном переводе это звучит как «соглашение об уровне доступности сервиса». При определении SLA следует учитывать, что этот параметр должен отражать качество работы системы, быть измеримым и универсальным, а также полностью зависеть от работы исполнителя. Если степень корреляции между метрикой и исполнителем слабая, то она не сработает, SLA будет необъективным и контроль утерян. Метрик SLA не должно быть много: если их выделяется несколько, то должна быть однозначно определена ключевая. В качестве примера метрик SLA можно привести временные ограничения на решения задач (каждая поступающая задача должна быть решена не более чем за 2 часа) или статистические (в первые 24 часа должно быть решено не менее 80% поступающих задач).

SLO – совокупность «желаемых» значений SLI (целевых). Если в процессе функционирования система выходит за пределы SLO значений, то это приводит к нарушению SLA определенного компонента или модуля. «Право на ошибку» (Error Budget) характеризует максимальное допустимое отклонение от целевых значений параметров. В качестве примера можно привести максимальную длительность, на протяжении которой веб-страница не отвечает, или наибольший уровень нагрузки на процессор.

Исходя из этого, SLO могло бы отразить те пороговые значения, на которые устанавливаются алерты, однако требуется учитывать, что SLO представляет собой целевые «желаемые» показатели, и не всегда отклонение от желаемого является ошибкой и нарушением. Таким образом, если устанавливать алерты на пороговые значения SLO, то повышается вероятность возникновения большого количества «лишних» оповещений при нормальной работе системы – так называемого «алертного шума». В обратном случае сигнал может появиться уже в тот момент, когда произошло нарушение SLA. Образуется задача установки алертов таким образом, чтоб они срабатывали в подходящий момент, сохраняя баланс между тем, когда уже «всё плохо» и тем, когда они будут просто создавать «шум» при адекватной работе системы. Решение этой задачи позволит получать сигналы в тот момент, когда вероятность возникновения проблемы уже идентифицирована, однако критическая ситуация еще не наступила. Этого можно достичь при установлении алертов на значения, которые находятся в промежутке от SLO до Error Budget: то есть система ещё работает в штатном режиме, однако показатели отклоняются от «целевых» и стремятся выйти за границы SLA.

Базовые метрики и сигналы

Можно определить базовый перечень метрик, пороговых значений, которые будут считаться универсальными и подойдут для мониторинга простых и составных многоуровневых ИТ-инфраструктур.

Первая группа метрик CPU, которые позволяют провести мониторинг использования процессорного времени, включает 2 основных сигнала:

  • CPU idle time (загрузка ЦП) < 10% в течение 10 min;
  • CPU Load Average превышает количество доступных процессоров и не равно 0 в течение 5 min. [6]

Данные алерты помогут определить критический уровень высокой нагрузки на сервере. Фиксируются единоразовые скачки нагрузки, которые не являются проблемными, и выделяются длительные периоды роста нагрузки (в данном случае, более 10 min), которые, вероятнее всего, приведут к сбою работы. Кроме этого фиксируется недоступность сервера.

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

  • заполнение SWAP > 90% (можно использовать для версий ядра Linux младше третьей);
  • swapin > 1 Мбайт/с в течение 2-5 min (активная запись в SWAP, можно использовать для новых версий ядра Linux)
  • используемая оперативная память > 85% от общедоступного объема. [6]

Степень загрузки оперативной памяти напрямую влияет на скорость работы инфраструктуры. Приближение показателя utilization к значению 100% приведет к проблемам в работе системы или отказу работы компонента ООМ (Out of memory). Предложенные выше значения могут считаться универсальными и быть использованы для мониторинга большинства ИТ-инфраструктур, однако в зависимости от особенностей систем, они могут быть скорректированы, что позволит контролировать интенсивность алертинга.

Третья группа метрик важна для контроля дисковой подсистемы. Возможные сигналы:

  • iostat (нагрузка на диск) > 95% на протяжении 60 минут;
  • free inodes (по каждому разделу) <10%;
  • свободное место на диске (по каждому разделу) <10% + дополнительный алерт < 5%. [6]

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

Устанавливая сигналы для контроля дисковой подсистемы, следует определить тип программного обеспечения. В зависимости от специфики функциональности системы возможно временное резкое увеличение количества данных или потребности в объеме свободного пространства не менее 15% или даже 20%. Если особенных требований нет и дисковая подсистема имеет достаточно большой объем, то пороговый сигнал может быть установлен на значении 3-5%.

В процессе мониторинга файловой системы должен осуществляться контроль состояния сетевых дисков (маунтов) и настройка сигналов на две характеристики: наличие маунта и корректность функционирования его файловой системы.

Четвертая группа метрик служит для проведения дополнительного мониторинга дисков. Сюда можно отнести:

  • отличие результата SMART-теста диска от «passed» (если тест не пройден, то будет присвоен статус failed: диск считается неисправным и возникает риск утери данных);
  • количество поврежденных секторов HDD > 1;
  • процент износа SSD < 10% от полезного срока службы. Данный порог обычно определяется производителем после перехода диска в read-only режим;
  • уровень использования NVMe > 90%;
  • доля резервной области NVMe < 15%;
  • количество ошибок целостности данных NVMe > 1. [6]

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

  • сигнал на «вылет» диска из рейда;
  • сигнал, срабатывающий при запуске проверки/синхронизации после восстановления диска в массиве (помогает понять, что резкие скачки в нагрузке на CPU или память временные и не являются проблемой);
  • количество «битых» дисков > 1.[6]

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

Важной группой метрик являются параметры соответствия серверного времени желаемому или эталонному. Расхождение временных характеристик может стать причиной сложнодиагностируемых ошибок в серверной или в клиентской части. Для исключения данных ошибок важно определять статус используемых на сервере приложений синхронизации времени. Это могут быть ntpd, chronyd или systemd-timesyncd. Для этого могут быть использованы такие сигналы (или интерпретированные под специфику той или иной системы):

  • > 500 миллисекунд на протяжении 5 min;
  • < 500 миллисекунд на протяжении 5 min.

Существенное расхождение временных параметров может иметь различные последствия: cron-задание, настроенное на 12:00, будет запущено раньше или позже требуемого и сместит формирование отчётов, например для руководства или налоговой службы.

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

  • входящая нагрузка >75% (в некоторых случаях >90%) от лимита;
  • исходящая нагрузка >75% (в некоторых случаях >90%) от лимита;
  • алерт на аномальный скачок трафика (входящего или исходящего). [6]

Данная совокупность алертов может считаться минимально необходимой и достаточной базой при формировании принципов мониторинга ИТ-инфраструктуры. При этом каждая совокупность сигналов может быть дополнена другими алертами, которые будут зависеть от типа сервера, программного обеспечения и пр. Например, можно контролировать работу охладительных систем, температуру процессора и других параметров, однако нет смысла мониторить все сигналы, особенно те, которые сложноинтерпретируемы и требуют больших затрат сил и времени на сбор. Главное – не вносить «алертного шума», который возникает при получении многочисленных сигналов каждую минуту.

Дополнительные метрики и сигналы

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

  • на увеличение/уменьшение на хосте количества виртуальных машин;
  • на определение количества виртуальных машин в статусе != running.

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

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

Docker / docker_alive – сигнал о приостановке работы сервиса docker.

Docker / KVM / LXC amount_changed – сигнал об изменении количества запущенных контейнеров. В случае получения алерта требуется уточнение, является ли данное изменение плановым (приостановка работы и соответствующее уменьшение) или внеплановым (увеличение). В последнем случае на новый контейнер устанавливается мониторинг.

Docker / KVM / LXC – сигнал на остановку определенного контейнера с конкретным названием или маской. Определение причины остановки (аварийная/плановая) является важным аспектом мониторинга контейнеров. [7]

Контроль инфраструктуры веб-сервиса является важным аспектом системы мониторинга. Первое, с чем соприкасаются клиенты – веб-интерфейс. Основные метрики для оценки функционирования веб-сервера предлагается рассмотреть на примере веб-серверов Nginx и Apache, которые можно назвать наиболее популярными.

Для мониторинга веб-сервисов необходимы такие алерты: 

  • Nginx status (RPS). Сигнал при нулевом RPS на протяжении 10 min. При этом наиболее вероятно, что при получении такового сигнала веб-сервер абсолютно не работает. Второй сигнал может быть установлен на существенное превышение стандартной нагрузки. Определение нормальных и нестандартных отклонений возможно на основании статистики по данной метрике;
  • Apache sent no data > 3 min. Данный сигнал должен возникать в случае отсутствия данных по количеству свободных воркеров на протяжении заданного времени. Apache sent no data указывает на то, что веб-сервер не работает;
  • Apache IdleWorkers > 3 min. Данный сигнал устанавливается в случае отсутствия свободных воркеров на протяжении заданного времени. Это приводит к возникновению очереди из входящих запросов к веб-серверу, которые ожидают обработки. В результате данная ситуация может негативно сказаться на обслуживании пользователей;
  • Apache/Nginx 5xx_errors. Алерт на возникновение «пятисотых» ошибок в системе. Порог данного сигнала определяется нормальной активностью сервера, а частое срабатывание алерта указывает на наличие ошибок в системном коде или инфраструктуре;
  • Apache/Nginx 4xx_errors. Сигнал на «четырехсотые» ошибки, настраивается, исходя из средней активности на сервере. Появление алерта может быть вызвано ошибками в инфраструктуре (например, в случае проблемы в системе синхронизации данных на CDN-серверах) или проведением DDoS-атак или попыток взлома каких-либо элементов системы (например, личного кабинета пользователя);
  • Apache/Nginx – rate. Доля ошибок определенного кода. Рассчитывается как процентный показатель в рамках общего объема запросов к веб-серверу. Данный сигнал позволяет определить совокупную значимость ошибок и принимать дальнейшие меры. Если количество ошибок менее 1%, то скорее всего ситуация в рамках нормальной, а если их более 50% – требуется срочно перестроить работу системы. [7]

Мониторинг сервера, который несет ответственность за работу системы, реализует выполнение кода, проводит обработку запросов к базе данных и пр. Речь идет о контроле работы application-сервера – одного из важнейших объектов мониторинга. Наиболее актуальным является анализ сигналов для вариантов PHP-FPM и Apache, однако общая совокупность алертов может считаться универсальной для мониторинга прочих application-серверов:

  • RPS = 0 на протяжении 3 min. Данный алерт обращает внимание на тот факт, что пользовательские запросы не уходят в пул обработки;
  • timeout 3 min. Сигнал о том, что application-сервер не присылает данные более заданного времени. Из этого можно сделать вывод, что сервер недоступен. [7]

Кроме общепринятых web- и application-серверов в рамках ИТ-инфраструктур могут использоваться прочие приложения, которые также нуждаются в регулярном контроле стабильной работы. Такими приложениями могут выступать модули рассылки сообщений, обработки очередей, Node.js-приложения и т.д.

Провести мониторинг дополнительных ИТ-инфраструктур возможно путем использования инструмента Supervisor, предназначенного для управления сервисами и приложениями. В данном случае можно применить следующие алерты:

  • supervisor is_alive – сигнал, который позволит определить работоспособность самого менеджера процессов Supervisor;
  • amout_changed – сигнал, который должен сработать в случае изменения количества запущенных процессов через менеджер Supervisor. Так же, как и в случае с контролем контейнерных приложений, алерт может возникать как при плановом, так и при аварийном изменении;
  • supervisor – сигнал, отражающий остановку того или иного процесса. [7]

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

  • is_alive – сигнал, который срабатывает на плановую или аварийную остановку или запуск определенного приложения;
  • errors_count – сигнал, который срабатывает при возникновении ошибок в работе сервиса. Это касается ошибок, обрабатываемых самим сервисом без его перезагрузки/остановки. Пороговое значение высчитывается индивидуально для каждого сервиса.

Кроме ИТ-инфраструктуры жизненно важным для работоспособности системы остается контроль доступности URL-адресов, доменов и SSL-сертификатов. Внутренний мониторинг серверов и модулей не исключает необходимость контроля «снаружи». Наоборот, это позволит осуществлять более комплексную оценку, посмотреть на инфраструктуру «глазами» пользователя. В рамках внешнего мониторинга проверяют доступность приложений, наличие заданного контента, графическое отображение, возможность подключения из других стран, регионов и пр.

Вот список алертов, которые позволят сконфигурировать базовый мониторинг внешнего состояния проекта:

  • HTTP CODE – срабатывает, когда http-код ответа отличается от «нормального» (2хх, 3хх) в течение 2 min. Показывает, что какая-либо страница (например, конкретная новость в новостной ленте, статья в блоге или карточка товара) недоступна для пользователей из-за ошибки в работе приложения, инфраструктуры или ошибок на уровне интернет-провайдера.

Для формирования базового контроля достаточно использовать 4 алерта:

  • PAGE SIZE – алерт, который срабатывает в случае изменения размера ответа при запросе к конкретному URL. Это возникает при наличии ошибок шаблонизатора, базы данных, когда блок на странице в процессе разработки был случайно удален и так далее. Классический порог данного алерта – ±20% от «эталонного» значения;
  • RESPONSE TIME – алерт, сигнализирующий о превышении времени ответа на запрос над «нормальным» на протяжении 3 min. Это даёт возможность отследить сложности в процессе взаимодействия с базами данных, сетевые проблемы или проблемы при обновлении кода на странице;
  • sent no data – сигнал, срабатывающий когда система контроля не получает данные метрик. Возникнуть данная проблема может в случае аварии или при внутренних проблемах самого мониторинга;
  • SSL-cert expire date, domain expire date – сигнал, призванный напомнить об истечении срока действия SSL-сертификата или регистрации домена. Обычно пороговое значение устанавливается на 7 дней. [7]

Заключение

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

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

Список литературы

  1. Ревнивых Александр Владимирович, Федотов Анатолий Михайлович Мониторинг информационной инфраструктуры организации // Вестник НГУ. Серия: Информационные технологии. 2013. №4. URL: https://cyberleninka.ru/article/n/monitoring-informatsionnoy-infrastruktury-organizatsii (дата обращения: 11.2.2022).
  2. Дурманов Е.Е. Мониторинг информационной инфраструктуры в режиме реального времени // Материалы XI Международной студенческой научной конференции «Студенческий научный форум» URL: https://scienceforum.ru/2019/article/2018011594 (дата обращения:11.12.2022 ).
  3. Шамин И.М. Мониторинг IT-систем и сетевых устройств // Международный студенческий научный вестник. – 2019. – № 2. URL: https://eduherald.ru/ru/article/view?id=19569 (дата обращения: 11.12.2022).
  4. Using ML/AI to Support Infrastructure Monitoring URL: devops.com/using-ml-ai-to-support-infrastructure-monitoring (дата обращения: 11.12.2022).
  5. Artificial intelligence-based network traffic analysis and automatic optimization technology – Jiyuan Ren , Yunhou Zhang , Zhe Wang // Yang Song Northeast Branch of State Gird Corporation of China, #1, Yingpan North Street, Shenyang. Chinа academic editor: Thippa Reddy Gadekallu URL: https://www.aimspress.com/article/doi/10.3934/mbe.2022083?viewType=HTML (дата обращения: 11.12.2022).
  6. Мониторинг начинается с метрик, или Как не сделать из алертов белый шум – Открытый ресурс Хабр. URL: https://habr.com/ru/company/itsumma/blog/596845 (дата обращения: 11.12.2022).
  7. Мониторинг начинается с метрик. Часть 2: серверное ПО – Открытый ресурс Хабр. URL: https://habr.com/ru/company/itsumma/blog/657189 (дата обращения: 11.12.2022).

1 команды разработки (developers, Dev-команда) и сопровождения, или поддержки (operations, Ops-команда)

Интересная статья? Поделись ей с другими: