Каталог решений - Мониторинг производительности и искусственный интеллект

Промо 

Кто хочет, чтобы о проблемах производительности сообщалось заранее, до начала падения системы?
Чтобы мониторинг с пристрастием осуществлялся 24 часа в сутки 7 дней в неделю?
Чтобы при наличии сложных ситуаций мы узнавали первыми, а не пользователи?
Кто хочет повысить качество сервиса и перейти на новый уровень?
Зачем разбирать вручную логи технологического журнала и входить в когнитивный диссонанс, когда есть для этого специальный и обученный помощник?

Ответ на эти вопросы и многое другое найдете в этой статье. Ок, Лариса! Поехали…

Введение 

Это первая часть по вопросам практики применения искусственного интеллекта и в ней мы рассмотрим применение нечеткой логики (fuzzy logic). В следующих статьях будем двигаться дальше и затронем применение нейронных сетей. И все это на 1С.

Что будет делать наш AI Лариса? Выполнять сбор данных о производительности, обрабатывать и принимать решение в онлайн режиме, а затем оповещать о проблемах через мессенджер (хотя, она может конечно выполнить и более сложные проактивные действия). Обо всем этом ниже.

Структура статьи

1. краткий обзор методологии
2. как это работает
3. настройка и запуск
4. видео-урок
5. замечания

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

Мы будем использовать открытый Фреймворк "Мониторинг производительности" (https://github.com/Polyplastic/1c-parsing-tech-log).
 

I) Краткий обзор (на пальцах)

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

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

Процесс преобразования числовых значений в логические термы называется процедурой фаззификации (fuzzification).

Согласно рисунку у нас получается, что диапазон значений соответствующий терму "замерз" будет (от абсолютного нуля до 35), "нормальная" от 34 до 37, а жар от 37 до максимально возможной.

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

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

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

Если температура тела "нормальная" и пациент "здоров" тогда
  решение "все хорошо",
Иначе если температура тела "переохлаждение" и "здоров" тогда
  решение "необходимо согреться",
Иначе т.д.

Все те же самые размышления мы можем распространить на оборудование:

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

В предыдущей статье "За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С"  я предоставлял таблицы параметров счетчиков производительности для 1С сервера и MS SQL, в них для каждого элемента приводились оценки допустимых значений и рекомендации.

К примеру, "Buffer cache hit ratio (Коэффициент обращений к буферному кэшу)" рекомендуется чтобы был близок к 100%. Соответственно, если он ниже, то в системе наблюдаются проблемы, а если около 0, то значит скорее все плохо, чем хорошо.
Или счетчик "Свободно мегабайт на диске", должен быть гораздо больше 0 иначе у Вас система просто перестанет работать.

2. Информация на основе текущего опыта для конкретной системы.

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

Общее понимание работы нечеткой логики в упрощенном представлении у Вас должно появиться и теперь мы готовы двигаться дальше.

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