введение

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

Характер мониторинга

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

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

Здесь основной бизнес-процесс платформы мониторинга разделен на семь шагов, как показано на следующем рисунке:

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

2. Сбор данных

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

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

3. CMDB

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

Так что же такое CMDB? CMDB (база данных управления конфигурацией) — это база данных управления конфигурацией. Его можно разделить на прикладной или бизнес-ориентированный в зависимости от сцены. Короче говоря, CMDB управляет различными моделями ресурсов и базовыми данными, так что различные приложения платформы мониторинга могут легко использовать ресурсы и данные моделей для бизнес-обработки и синхронизации данных. Чтобы построить CMDB, модель ресурсов должна быть сначала сильно абстрагирована. Поскольку объекты мониторинга эксплуатации и обслуживания в основном включают в себя различные объекты ресурсов, такие как компьютерные залы, машины, различные устройства и сервисы приложений, требуется универсальная модель ресурсов, чтобы справиться с различными сценариями использования. Весь жизненный цикл объекта ресурсов от покупки, использования, мониторинга до замены включает синхронизацию данных о ресурсах между несколькими подсистемами, поэтому необходимо обеспечить согласованность и точность данных между подсистемами. При поддержке двух предыдущих этапов это последний этап, на котором в полной мере используются данные CMDB. Он должен обеспечивать мощную поддержку в визуализации данных, автоматическом мониторинге и обслуживании, интеллектуальном мониторинге и работе с данными.

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

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

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

4. Отслеживание первопричины

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

1. Вспомогательный анализ графика тренда

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

2, системный независимый анализ

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

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

(1) Скрининг зон разлома При возникновении неисправности в первую очередь необходимо отсеять конкретную неисправную аппаратную и машину. Если обнаружится, что время отклика интерфейса предприятия истекло, какие различные приложения задействованы в бизнесе, какие экземпляры службы соответствуют этим приложениям, и в каком компьютерном зале и на каком компьютере развернуты эти экземпляры? Что такое зависимое ПО промежуточного слоя и где развернуто ПО промежуточного слоя? На первом этапе проверки вы можете определить, на каких машинах, в каких комнатах и ​​в каких службах могут возникнуть проблемы. На этой основе проанализируйте, есть ли высокая нагрузка на серверы в этих компьютерных залах, нормально ли работает каждая служба и нормально ли работает зависимое промежуточное программное обеспечение, а затем объедините с такой информацией, как наличие непрерывных журналов ошибок для дальнейшей фильтрации. чтобы сузить область поражения.

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

5. Хранение данных

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

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

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

Уровень доступа к данным в основном отвечает за функции унифицированного доступа к трафику, аутентификацию интерфейса, статистику трафика и коммутацию трафика.

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

(1) Поддержка высокопроизводительного хранения массивных данных о событиях;

(2) Поддержка нечеткого поиска на основе описания события;

(3) Он может легко реализовать горизонтальное расширение узлов хранения данных;

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

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

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

6. Резюме

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

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