Зависимости, сервисы, SLA Модель Glaber, постановка проблемы

Идея

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

Чего не хватает в существующей модели сервисов и зависимостей.

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

2. Зависимости триггеров вне хоста не могут быть масштабированы: необходимо вручную назначать зависимости от других хостов.

3. Реализованная модель сервисов статическая, настраивается вручную, не масштабируется

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

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

6. Для больших систем — SLA - это интегральный показатель, который зависит от точки измерения. Поэтому вычисление SLA должно быть динамическим в зависимости от дерева выбранных объектов, и вероятно, считаться по истории проблем (естественно, эта история должна быть связана и доступна в UI вместе с SLA — для ответа на вопрос — что повлияло и дало такое качество услуги в этой точке).

Некоторые определения, логика, понятия, гипотезы

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

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

Примеры

• Порт клиентского коммутатора в провайдере интернет является крайней точкой наличия сервиса «Интернет».

• Компьютер бухгалтера является точкой для сервиса «программа для ведения бухгалтерии». Если компьютер может не входит в мониторинг, в таком случае точкой предоставления сервиса может также быть порт коммутатора.

• cdn распределенного web сервиса, работающий в разных странах

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

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

Пример

пользователь на рабочем месте пользуется корпоративным веб-порталом. Его точкой потребления (терминации) сервиса является его компьютер. Дерево сервиса может упрощенно быть таким:

ПК → сеть → веб-сервер→ сервер БД→ Файловая система→RAID массив→ жесткий диск

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

Направление движения от пользователя (от точки получения сервиса) к центральным элементам сервиса, а потом к базовым аппаратным компонентам назовем «вверх» (up).

Такое именование интуитивно понятно при движении от точки предоставления сервиса к серверам, его предоставляющим, но может путать при переходе от серверов к их аппаратным компонентам:

Пример

сервис «работа жесткого диска» является вышестоящим (основополагающим) для сервиса RAID массив. RAID массив является вышестоящим для файловой системы.

Соответственно, при движении от основополагающих компонентов до серверов, сети и потом до пользователя стоит называть движением «вниз» или down.

Понятия up и down (и никакие другие) предлагается использовать для обозначения отношений объектов в зависимостях.

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

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

Логика работы триггеринга, создания проблем в системе с сервисами и зависимостями.

Система мониторинга фиксирует нештатные ситуации путем вычисления логики в триггерах и создания объектов проблем.

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

Пример

при отключении коммутатора от сети пропадает доступ ко всем компьютерам, которые были к коммутатору подключены. При этом первопричина — недоступный коммутатор (cause) и последствия (outcome) — это недоступные ПК.

Наличие связей и отношений up/down позволит автоматизировать выставление статусов причины и следствия в таких случаях для объектов «проблема».

Техника: как предполагается описывать сервисные модели:

Атомарными элементами для подсчета сервисов и зависимостей являются триггеры, зависимости триггеров, зависимости между узлами.

Зависимость между узлами

Это новшество в Glaber.

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

Для управления зависимостями существует расширение АПИ (ссылка на описание), и добавлены элементы управления зависимостями в режиме редактирования хостов.

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

Например

при использовании модуля топологии можно автоматически через АПИ «заливать» подсчитанные зависимости коммутаторов

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

Зависимости триггеров в рамках сервисной модели предполагаются только в рамках одного узла (host).

Правила и логика настройки мониторинга для подсчета дерева сервисов

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

Например:

service = www_portal 

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

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

Вычисления триггеров делаются в нормальном режиме, теги и сервисная модель влияет на то, как обрабатываются проблемы (ниже).

Оценка влияния (impact)

Для оценки влияния предполагается, что на узле, где существует триггер со значением триггер, может быть числовая метрика (UINT64 или FLOAT), которая содержит в себе «вес» узла.

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

service = www_portal

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

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

Соображения по обработке проблем, их группировке и настройке сервисов

Фрагментация сервисов

Сервисы стоит разбивать на несколько под-сервисов, «соединяя» такие под-сервисы на узлах.

Например, узел, на котором работает база данных, соединяет в себя сервис базы данных и сервис RAID массива дисков.

Эскалация (группировка) проблем по причинам и следствиям выполняется только в рамках одного сервиса.

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

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

Пример работы группировки

Рассмотрим сервис корпоративный портал из примера выше:

ПК → сеть → веб-сервер→ сервер БД→ Файловая система→RAID масив→ жесткий диск

Допустим, что существует проблема в сервере БД и он медленно отвечает на запросы, что вызывает сработку триггера на узле с БД, триггера на веб-сервере и триггеров на ПК пользователей.

Сервис БД назначен на два узла — узел на котором работает ПО БД и на узел с приложением, где работает web сервер.

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

То есть будет создана проблема («медленная работа портала») на веб сервере, в которую будут, как зависимые или, вернее, как последствия, подчинены все проблемы связанные с медленной работой портала, которые сняли с ПК пользователей.

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

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

Общая логика работы такая

При жалобе пользователей можно в два клика дойти до первопричины:

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

При переходе на проблему веб сервера можно будет в свою очередь, увидеть, что первопричина медленной работы веб сервера — проблема с БД.

Такое разделение и иерархичность (ИМХО) будут более наглядны, чем создавать целиком единый сервис от пользователя до жестких дисков. Помимо неудобства настройки (например. Жесткие диски могут обслуживать также другие сервисы), цепочка расчетов и эскалации получается слишком длинной и вероятно, имеет больше шансов на ошибочные эскалации.

Непрерывность и целостность сервисов

при вычислении зависимости и первопричины поиск первопричины продолжается до момента, пока удается найти вышестоящий (в направлении от down→up) узел, у которого также существует триггер, для которого создана проблема с уровнем важности (severity) не ниже той, для которой ищется первопричина. Проблема помечается как «следствие» для такой проблемы. В случае, если триггер создает множественные проблемы, то используется самая последняя.

Пересчет причин и следствий

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

Алгоритм и идея подсчета SLA

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

Подсчет SLA выполняется путем умножения среднего значения метрики веса во время нахождения в состоянии ОК и отношении ко всему времени, за которое считается SLA умноженному на среднее значение метрики веса за все время.

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

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

«Эскалация» проблем вниз по дереву

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

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