Содержание

Мониторинг сервисов

Вернуться в оглавление Документации Pandora FMS

Мониторинг сервисов

Версия Enterprise.Мониторинг сервисов является функцией только версии Enterprise Pandora FMS.

Введение

Сервис в Pandora FMS - это совокупность ресурсов информационных технологий (Information Technology, сокращенно IT) на основе их функциональных возможностей.

Сервисом может быть, например, официальный сайт компании, Customer Relationship Management (CRM), приложение поддержки или даже все принтеры компании или в доме. Сервисы PFMS - это логические группы, включающие хосты, маршрутизаторы, коммутаторы, брандмауэры, веб-узлы и даже другие Сервисы.

Pandora FMS представляет Сервисы как совокупность контролируемых элементов (Модули, Агенты или другие Сервисы) индивидуальное состояние которых определенным образом влияет на глобальную функциональность предоставляемого Сервиса. Более подробную информацию вы можете получить в обучающем видео «Мониторинг Сервисов в Pandora FMS».

Сервисы в Pandora FMS

Базовый мониторинг в Pandora FMS заключается в сборе метрик из различных источников, представляя их в виде систем контроля (называемых Модулями). Мониторинг на основе сервисов позволяет группировать предыдущие элементы таким образом, что, играя с определенными правилами, основанными на накоплении отказов, можно контролировать группы элементов различных типов и их взаимосвязь в более крупном и общем сервисе.

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

Сервисы мониторинга представлены в рамках трех категорий: обычный режим, по важности и по цепочке каскадных событий.

Как работает простой режим

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

Только элементы, помеченные как критические, будут учитываться при расчетах, и только critical статус этих элементов будет иметь значение.

Пример:

Случай 1:

Результат: Сервис в состоянии warning, потому что принтер не находится в критическом состоянии, маршрутизатор находится в критическом состоянии представляет только 50% критических элементов, сервер Apache не находится в критическом состоянии и не вносит вклад в оценку.

Случай 2:

Результат: Сервис в состоянии critical (принтер все еще не имеет никакого значения).

Случай 3:

Результат: Статус сервиса будет normal, поскольку ни один из ключевых элементов не является critical (опять же, принтер по-прежнему не имеет никакого значения).

Как работают сервисы в зависимости от их важности

Необходимость мониторинга Сервисов как чего-то «абстрактного» возникает при столкновении со следующим вопросом:

Что произойдет с моим приложением, если элемент, который по сути критическим не является, перестанет работать?

Чтобы разрешить все эти сомнения, в Pandora FMS появляется функция мониторинга через Сервисы, которая помогает:

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

Через Консоль Pandora FMS следует определить Дерево Сервиса, в котором необходимо указать элементы, влияющие на приложения или приложения, а также степень их влияния.

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

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

Пример

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

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

Если бы один из двадцати серверов Apache был отключен от сети, из-за такого большого количества резервирования, было бы разумно оповестить, предупредить всех сотрудников? Каково правило предупреждения?

Можно сделать вывод, что Pandora FMS должна предупреждать только в случае отказа очень важного элемента (например, маршрутизатора) или если несколько серверов Apache одновременно отключатся, но какое их количество? Чтобы определить это, необходимо присвоить весовые значения списку компонентов, описанному выше:

Коммутаторы и маршрутизаторы

По 5 баллов, если они находятся в critical и 3 балла, если они находятся в warning.

Серверы Web

1,2 балла каждому в состоянии critical, мы не наблюдаем статус warning.

Серверы WebLogic

2 балла каждому в состоянии critical.

Cluster MySQL

5 балла каждому в состоянии critical и 3 балла в статусе warning.

Тип элемента Приписывание веса
Normal Warning Critical Unknown
Router 0 3 5 5
Switch 0 3 5 5
Apache server 0 0 1,2 1,2
WebLogic server 0 0 2 2
MySQL server 0 3 5 5

Поскольку в нормальной ситуации сумма весов равна нулю, поэтому в данном примере установлено, что порог статуса warning должен быть больше 4, а для состояния critical больше 6:

Конфигурация Сервиса
Normal Warning Critical
0 >=4 >=6

Сценарии сбоев:

В последней ситуации Pandora FMS оповестит соответствующую рабочую группу (операторов, техников и т.д.).

Вы можете получить интересную информацию о Мониторинге Сервисов в блоге Pandora FMS

Сервисы корень

Версия Enterprise.Версия NG 726 или выше.

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

Аналогично, и основываясь на этой концепции, когда сервис, определенный в узле Pandora FMS, появляется как элемент сервиса Корень в Метаконсоли, именно сервер Метаконсоли будет оценивать его, обновляя значения, хранящиеся в узле.

Это обеспечивает более эффективную распределенную логику и позволяет реализовать каскадную систему защиты на основе сервисов..

Сервисы в Metaconsole позволяют добавлять в качестве элементов сервиса как другие сервисы, так и модули и/или агенты, поскольку в предыдущих версиях разрешалось добавлять только узловые сервисы.

Создание нового Сервиса

Pandora Server

Компонент PredictionServer должен быть включен, чтобы использовать Сервисы.

Компонент PredictionServer должен быть запущен, и должна быть установлена версия Enterprise Pandora Server.

Введение

Сервисы могут представлять:

Значения Сервиса рассчитываются с помощью Сервера прогнозирования. (PredictionServer).

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

Чтобы создать новый сервис, перейдите в раздел Topology Maps > Services.

Появится вид дерева со всеми Сервисами.

Начальная конфигурация

Для создания нового сервиса нажмите на кнопку Create Service и заполните появившуюся форму:

Name

Это должно быть уникальное имя, позволяющее идентифицировать Службу.

Description

Обязательно. Это описание, вместо названия, появляется на карте Сервиса, при просмотре таблицы Сервиса и в Widget Сервисов.

Group

Группа, к которой принадлежит сервис, полезно в ограничениях ACL.

Agent to store data

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

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

Режим для расчетов веса.

Mode

Метод расчета весов элементов. Он может иметь 2 значения:

Unknown elements as critical

Позволяет указать, что элементы в неизвестном состоянии вносят свой вес, как если бы они были элементом в критическом состоянии.

Режим smart доступен только начиная с версии 7.0 NG 748 Pandora FMS.

Режимы автоматический и простой предыдущих версий станут ручными при применении MR 40 в обновлении версии.

Favorite

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

Quiet

Активирует бесшумный режим работы Службы, чтобы она не генерировала предупреждения или события.

Cascade protection enabled

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

Calculate continuos SLA

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

Если вы отключите эту последнюю опцию, после создания Сервиса удалится история данных этих модулей, таким образом, вы потеряете информацию.

SLA interval

Период времени для расчета эффективного SLA сервиса.

SLA limit

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

Alerts

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

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

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

Нажмите на кнопку Add element, и появится всплывающее окно с формой. Форма будет немного отличаться, если сервис находится в режиме smart или в режимеmanual.

Description

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

Type

Выберите Сервис, Модуль или Агент; если вы находитесь в режиме Smart, также появится тип Dynamic (динамический).

Agent

Система поиска агентов (видна, если элемент для создания или редактирования имеет тип Агент или Модуль).

Module

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

Сервис

Выпадающий список сервисов для создания элемента (виден только в том случае, если создаваемый или редактируемый элемент имеет тип Сервис).

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

Ручной режим

Следующие поля доступны только для сервисов в ручном режиме:

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

Режим Smart

В сервисах в интеллектуальном режиме (Smart), поскольку для элементов не определены веса, способ расчета их состояния следующий:

Режим Dynamic

Следующие поля доступны только для элементов типа Dynamic (сервисы в режиме Smart):

Matching object types

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

Filter by group

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

Having agent name

Правило для указания имени Агента, которым должен обладать элемент, чтобы быть частью Сервиса. Указывается текст, который является частью имени желаемого Агента.

Having module name

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

Use regular expresions selector

Если вы включите эту опцию, будет использоваться механизм поиска через Регулярные Выражения (regex или regexp) но в соответствии с тем, как MySQL обрабатывает регулярные выражения.

Having custom field name

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

Having custom field value

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

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

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

Пример

Если вы решите отфильтровать Агентов группы Servers, чье имя Агента содержит Firewall и имя модуля содержит Network, вы можете получить следующий результат.

Пример

Если бы конфигурация динамического элемента была следующей.

Все модули, имя которых включает «Host Alive», которые находятся в агенте, имя которого включает «SW»,в группе «Servers», с пользовательским полем, имя которого включает «Department» и значение которого также включает «Systems», будут использоваться как элементы сервиса.

Динамические элементы не подвержены каскадной защите Сервисов.

Модули, которые создаются при конфигурировании сервиса:

Визуализация Сервисов

Простой список всех сервисов

Это список операций, который показывает все созданные сервисы, и к которым пользователь имеет право доступа в Консоли Pandora FMS. Нажмите на Операция > Мониторинг и внутри него Сервисы.

Каждая строка представляет собой Сервис:

Group

Иконка группы, к которой принадлежит сервис и которую может видеть пользователь.

Critical

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

Warning

Пороговое значение сумм веса для присваивания сервису предупреждающего статуса.

Value

Значение сумм веса элементов, которые содержат сервис.

Статус

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

SLA

Значение SLA с одним из следующих возможных значений:

Таблица всех служб

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

Простой список сервиса и всех содержащихся в ней элементов

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

Pandora FMS отобразит страницу, подобную той, что показана на следующем снимке экрана:

Список элементов, составляющих Сервис, расположен внизу:

Type

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

Name

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

Weight critical

Значение связанного веса, когда элемент находится в критическом состоянии. Следующие три столбца (Warning weight, Weight Unknown и Weight OK) соответствуют последовательно предупреждению, неизвестный и нормальный./p>

Data

Значение элемента, которое в зависимости от типа может быть:

Статус

Значок, представляющий одним из кодированных цветов статус элемента.

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

Вид карты сервиса

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

Возможными узлами являются:

Узел Модуля

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

Узел Агента

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

Узел Сервиса

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

Цвет Узлов и соединительных стрелок зависит от статуса узла в соответствии с кодировкой: зеленый ОК, красный критический, желтый предупреждающий или серый неизвестный статус.

Внутри узла вы будете иметь:

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

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

Сервисы в визуальной консоли

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

Нажмите для увеличения

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

Haga clic para ampliar

Управление:

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

Древовидный вид сервиса

Этот вид позволяет визуализировать сервисы в форме дерева.

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

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

Ограничение разрешений ACL применяется только к первому уровню.

Как интерпретировать данные сервиса

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

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

С другой стороны, важно знать, как рассчитывается % выполнения сервиса:

Расчет весов в простом режиме

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

Расчет весов в соответствии с их важностью

Предположим, существует сервис, определяемая 95-процентным соответствием в 1-часовом интервале. Представьте таблицу значений, где t - время, x - % соответствие уровня сервиса (SLA), а s - соответствие или несоответствие сервиса (1 - соответствует, 0 - не соответствует). Через 1 час у нас будет ровно 12 образцов (при условии интервала в 5 минут).

Предположим случай, когда сервис работает хорошо в течение первых 11 проб (первые 55 минут), а на 60-й минуте выходит из строя, мы получим следующие значения:

   t    |   s   |    x
--------+-------+--------
1          1      100
2          1      100
3          1      100
4          1      100
5          1      100
6          1      100
7          1      100
8          1      100
9          1      100
10         1      100
11         1      100
12         0      91,6

Этот случай легко рассчитать, % рассчитывается в зависимости от количества образцов, в t3, например, есть 3 общих образца, с тремя образцами, которые соответствуют сервису, 100%, в то время как в t12, у нас есть 12 образцов и 11 действительных: 11/12.

Предположим, что он находится в середине пробы и постепенно восстанавливается.

   t    |   s   |    x
--------+-------+--------
1          1      100
2          1      100
3          1      100
4          1      100
5          1      100
6          0      83,3
7          1      85,7
8          1      87,5
9          1      88,8
10         1      90
11         1      90,9
12         1      91,6

Пока все похоже на предыдущий пункт, но давайте посмотрим, что произойдет, если мы продолжим движение во времени:

   t    |   s   |    x
--------+-------+--------
13        1      91,6
14        1      91,6
15        1      91,6
16        1      91,6
17        1      91,6
18        1      100
19        1      100
....

Здесь мы видим неинтуитивное поведение, поскольку объем достоверных образцов продолжает быть 11 для временного окна до t18, где единственное достоверное значение оставляется, так что при t18 соответствие становится 100%. Этот диапазон между 91,6 и 100 объясняется размером окна. Чем длиннее окно (обычно при расчете SLA это день, неделя или месяц), тем менее резкой будет эскалация.

Каскадная защита сервисов

Версия Enterprise.Версия NG 725 или выше.

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

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

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

Каскадная защита сервиса точно предупреждает о выходе из строя корневых элементов независимо от глубины определенного сервиса.

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

Анализ корневых причин

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

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

 Тело оповещения: образец сообщения
 Цепочка событий, приведших к такому состоянию службы, выглядит следующим образом:
 _rca_

В итоге будет получен результат, аналогичный приведенному ниже:

Тело оповещения: образец сообщения
Цепочка событий, приведших к такому состоянию службы, выглядит следующим образом:
[Aplicación Web -> HW -> Apache server 3]
[Aplicación Web -> HW -> Apache server 4]
[Aplicación Web -> HW -> Apache server 10]
[Aplicación Web -> DB Instances -> MySQL_base_1]
[Aplicación Web -> DB Instances -> MySQL_base_5]
[Aplicación Web -> Balanceadores -> 192.168.10.139]

Глядя на этот вывод, мы можем интерпретировать, что:

Эта дополнительная информация позволяет уточнить причину состояния сервиса, сокращая расследование причин аварии.

Группы Сервисов

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

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

Для более четкого понимания что такое группировки сервисов ниже приведены два примера.

Примеры мониторинга сервисов

Сервис Pandora FMS

Вариант использования, в котором проводит мониторинг состояния Сервиса мониторинга Pandora FMS, состоящий из службы Apache, службы MySQL, сервера Pandora и Tentacle, с соответствующими весами важности.

Haga clic para ampliar

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

Haga clic para ampliar

В этом случае общая служба Pandora FMS достигнет статуса critical при достижении веса 2, и статуса warning при весе 1. Как видно, четыре компонента имеют разный вес в службе Pandora FMS:

Сервис кластерного хранения, объединение сервисов

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

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

Haga clic para ampliar

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

На следующем изображении показана конфигурация весов, присвоенных двум основным элементам сервиса хранения:

Haga clic para ampliar

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

Haga clic para ampliar

Вернуться в оглавление Документации Pandora FMS