Как стать автором
Обновить

IT Service Health Monitoring средствами R. Взгляд под иным углом

Программирование *IT-инфраструктура *Big Data *R *

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


Ключевые слова: cmdb, multi-agent sumulation, monte-carlo, ml.


Является продолжением серии предыдущих публикаций.


Постановка задачи


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


  • есть CMDB (конфигурационная база элементов ИТ). Она содержит описание элементов и связей между ними (граф);
  • есть система мониторинга, которая как-то снимает показания физических воплощений CI элементов;
  • есть какой-то бизнес-сервис, который базируется на инфраструктурных элементах (сервера, приложения, API, тесты, ...);
  • связь между сервисом и элементами обычно описывается деревом и называется ресурсно-сервисной моделью (РСМ);
  • у инфраструктурных элементов есть свои параметры (KPI) по которым с учетом топологической связности надо посчитать здоровье бизнес-сервиса (health/KQI).

Типовую картинку РСМ возьмем с документации одного из апологетов этой темы (HP).


РСМ. Исходник был здесь:https://docs.microfocus.com/OMi/10.62/Content/OMi/images/ServiceHealth.png


Как делается обычно


Типовая процедура внедрения РСМ состоит из:


  • составления списка сервисов;
  • составления списка ресурсов;
  • составления топологической связи между ресурсами;
  • составления правил пропагандирования состояний и метрик.

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


Технические ссылки:



Альтернативный план


Ручное исполнение задачи в 2021 году выглядит уныло и тоскливо. Но у нас под руками есть компьютер. Можно попробовать применить его по назначению — позабивать цифровые гвозди.


План


  • фаза «multi-agent sumulation»: рассматриваем ресурсы как самостоятельных агентов, обладающих свойствами (входные параметры) и коммуницирующих друг с другом (связи в дереве РСМ);
  • фаза «itsm»: прописываем любым удобным нам способом поведение на уровне отдельных агентов (функцию выхода от состояний входа);
  • фаза «monte-carlo»: генерим подходящее подмножество входных состояний всех объектов и проводим расчет отклика MAS структуры;
  • фаза «ml»: сворачиваем полученный data.frame ансамбль правил (rule fit, см Modern Rule-Based Models by Max Kuhn), «объясняемый» представителям от бизнеса;
  • фаза «prod»: полученные ml матрицы загоняем в «кремний» и получаем event propagation в режиме реального времени на одном «смартфоне».

При чем тут R?


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


Писать multi-agent simulation нудно и есть масса мест для ошибок. С другой стороны у нас есть механизм реактивного программирования в Shiny, который обеспечивает коммуникацию между объектами. Воспользуемся им, см. подсказки в Reactive programming in R by Joe Cheng, DSC 2014


Пример идеи в коде, связка трех нод-агентов nodeA -> nodeB -> nodeC.


MAS на «коленке»
library(tidyverse)
library(magrittr)
library(shiny)
library(foreach)
library(iterators)
options(shiny.suppressMissingContextError=TRUE)

makeReactiveBinding("nodeA")
nodeA$in_1 <- NULL
nodeA$in_2 <- NULL
nodeA$out <- reactive(nodeA %$% (in_1 + in_2))

makeReactiveBinding("nodeB")
nodeB$in_1 <- reactive(nodeA$out())
nodeB$in_2 <- NULL
nodeB$out <- reactive(nodeB %$% (in_1() + in_2))

makeReactiveBinding("nodeC")
nodeC$in_1 <- reactive(nodeB$out())
nodeC$in_2 <- NULL
nodeC$out <- reactive(nodeC %$% (in_1() * in_2))

df <- tidyr::expand_grid(val1 = 0:5, val2 = 0:5, val3 = 0:5, val4 = 0:5) %>%
  # результат прямого расчета для демо-сверки
  mutate(direct_res = (val1 + val2 + val3) * val4)

res <- foreach(it = iter(df, by = "row"), .combine = "c") %do%
  {
    nodeA$in_1 <- it$val1
    nodeA$in_2 <- it$val2
    nodeB$in_2 <- it$val3
    nodeC$in_2 <- it$val4
    shiny:::flushReact()
    nodeC$out()
  }
df$mas_res <- res

Далее натянуть на data.frame ансамбль деревьев (или gbm или еще что...) и сделать прогноз можно двумя строчками. При этом формулу отклика для каждого агента можно писать любыми доступными средствами. В силу того, что состояния агентов (ноды) в этой задаче ограничены, можно вместо формул для поведения отклика отдельного агента (ноды) создать конфигурационный excel (пример ниже), который понятен любому менеджеру и не требует никаких споров. Считаете, что в строчке #7 на выходе должно быть 'bad'? Пишем и даже не спорим. «Мой сервис — мои правила!»


Конфигурация агента для менеджеров


Собственно все, задача решена, кино кончилось.


Предыдущая публикация — «Немного о параллельных вычислениях в R».

Теги:
Хабы:
Всего голосов 1: ↑1 и ↓0 +1
Просмотры 1.1K
Комментарии 2
Комментарии Комментарии 2

Публикации

Истории

Работа